Hey all! Today is our second anniversary since graduation, Happy Birthday!
No, I don’t have any cake for you, I think by now, we all know the cake is a lie. Instead, I’ve a not-that-long blog post, summarizing all the awesome things that happened this year. We’ve certainly come a long way since our humble beginnings, the community is stronger than ever and the site has been steadily growing for quite some time now.
So, without further ado, here’s what’s been going on this past year:
Programmers’ second year had some truly exciting moments. First, Anna Lear joined the evil corporate machine and we found ourselves short of a moderator. This prompted our second community moderator election, a process that I was very proud to be part of. The elections run smoothly, with surprisingly little drama and participation, although a bit low, was increased comparing to our first election.
Then, after the dust from the election settled down, we had our first ever contest. An exciting month long event that brought us some awesome questions, and some of the best answers I’ve ever read on the site. You can read more about the contest in this blog post, and it’s never too late for your feedback.
Which, of course, brings us to this very blog. The blog had a rocky start, although it was first proposed in June 2011, we didn’t really seemed to be able to get enough people interested in contributing. We went through various Meta discussions, two calls for contributors, a lot of candidates in the elections commited to make the blog happen, and finally we launched and posted our first blog post almost a year after the blog was first proposed. Kudos to the awesome blog team and everyone else involved for making this happen!
Lastly, starting from late January we undertook the monumental task of cleaning up our most problematic tags. The Structured Tag Cleanup started with the most bothersome of our tags, career and continued with software-engineering and software-development. The clean up effort ended on early April, at which point we’ve gone through 1000+ questions. Those of you who were active at the time may remember that we got at least a couple of blatantly off topic career questions per day, cleaning up 600+ broken windows in the various career related tags took care of that problem almost instantly.
We kick off our third year with the Hat Dash, a network wide event starting on Wednesday, it’s going to be fun!!!
The Stack Exchange network has grown rapidly this past year, right now there are 92 graduate and beta sites and a lot more are very close to popping out of Area51. Here’s a brief list of new technology oriented sister sites that you might find interesting (in no particular order):
When Computer Science first appeared, a question was asked in our Meta about clarifying the boundaries between the two sites. Inspired by that question, and after a brief discussion with a CS moderator, Raphael, we decided to test those boundaries by re-asking CS’s highest voted algorithmic question on Programmers. The answers the question received on Programmers are surprisingly different than the ones it received on CS, which, at least to me, says that although the sites overlap a bit, they have distinctly different audiences:
- Why is quicksort better than other sorting algorithms in practice? (Programmers version)
- Why is quicksort better than other sorting algorithms in practice? (CS version)
And of course, although not a technology oriented site, The Workplace deserves an honourable mention. The site was initially proposed on Area51 to fill the gap for all those general career related questions we couldn’t really support on Programmers, and it was greeted with enthusiasm from Programmers’ regulars when it finally made it to beta. Even today, 8 months into beta most of the site’s high rep users are also Programmers’ regulars, and all four pro tempore moderators are significant contributors on our site. If you haven’t visited the site already, trust me, it’s awesome!
There have been a ton of new features this year, with two very important changes for Programmers:
- We are no longer a migration target from Stack Overflow, and
- We now require registration for asking questions (but not for answering them).
Network wide the more significant changes were:
- Reputation history changes
- Flag weight was removed from user profiles
- Real time updates to questions, answers, and inbox
- Rejected migrations
- Community review tasks (aka the new review queues)
- Disabling migration for questions older than 60 days
I wanted to close this with a list of awesome questions from the past year. At first I wanted to bring some new attention to a few hidden gems, showcase posts from less popular tags, blah blah blah, but at the last moment I decided to go simply with the questions with the highest score. It might not be the best metric we have, but it’s the only metric that I felt would adequately represent the wider community. Here they are, our top twenty questions:
- My boss decided to add a “person to blame” field to every bug report. How can I convince him that it’s a bad idea?
- Is the use of “utf8=✓” preferable to “utf8=true”?
- What is the Mars Curiosity Rover’s software built in?
- I’m doing 90% maintenance and 10% development, is this normal?
- I’ve inherited 200K lines of spaghetti code — what now?
- Should I intentionally break the build when a bug is found in production?
- What software programming languages were used by the Soviet Union’s space program?
- Why can’t the IT industry deliver large, faultless projects quickly as in other industries?
- Torvalds’ quote about good programmer
- Should you keep a copy of all the code you write?
- Why is 80 characters the ‘standard’ limit for code width?
- Why was Tanenbaum wrong in the Tanenbaum-Torvalds debates?
- How do I review my own code?
- Why are shortcuts like x += y considered good practice?
- How to keep a big and complex software product maintainable over the years?
- Has “Not everyone can be a programmer” been studied?
- How do operating systems… run… without having an OS to run in?
- Is it just me or is this a baffling tech interview question?
- Is constantly looking for code examples a sign of a bad developer?
- Is the phrase “never reinvent the wheel” suitable for students?
All in all, it’s been an awesome year! Keep on rockin’, Programmers!
One of the very first ideas we had for this blog was to convert some of the wonderful gems of the early era of our site, the undisciplined period, to blog posts. Questions that were once enthusiastically received by the community, but no longer fit Programmer’s scope.
The first deleted question I’ve chosen is Jon Skeet’s “What’s your most controversial programming opinion?” question (available only to 10K+ users, sorry), a +391 scored question that was originally asked on Stack Overflow on January 2, 2009. What follows are twenty of the highest voted answers, in random order…
Programmers who don’t code in their spare time for fun will never become as good as those that do.I think even the smartest and most talented people will never become truly good programmers unless they treat it as more than a job. Meaning that they do little projects on the side, or just mess with lots of different languages and ideas in their spare time.
Unit testing won’t help you write good code.The only reason to have Unit tests is to make sure that code that already works doesn’t break. Writing tests first, or writing code to the tests is ridiculous. If you write to the tests before the code, you won’t even know what the edge cases are. You could have code that passes the tests but still fails in unforeseen circumstances. And furthermore, good developers will keep cohesion low, which will make the addition of new code unlikely to cause problems with existing stuff.
by Chad Okere
The only “best practice” you should be using all the time is “Use Your Brain”.Too many people jumping on too many bandwagons and trying to force methods, patterns, frameworks, etc. onto things that don’t warrant them. Just because something is new, or because someone respected has an opinion, doesn’t mean it fits all.
by Steven Robbins
Most comments in code are in fact a pernicious form of code duplication.We spend most of our time maintaining code written by others (or ourselves) and poor, incorrect, outdated, misleading comments must be near the top of the list of most annoying artifacts in code. I think eventually many people just blank them out, especially those flowerbox monstrosities. Much better to concentrate on making the code readable, refactoring as necessary, and minimising idioms and quirkiness. On the other hand, many courses teach that comments are very nearly more important than the code itself, leading to the this next line adds one to invoiceTotal style of commenting.
by Ed Guiness
“Googling it” is okay!Yes, I know it offends some people out there that their years of intense memorization and/or glorious stacks of programming books are starting to fall by the wayside to a resource that anyone can access within seconds, but you shouldn’t hold that against people that use it. Too often I hear googling answers to problems the result of criticism, and it really is without sense. First of all, it must be conceded that everyone needs materials to reference. You don’t know everything and you will need to look things up. Conceding that, does it really matter where you got the information? Does it matter if you looked it up in a book, looked it up on Google, or heard it from a talking frog that you hallucinated? No. A right answer is a right answer. What is important is that you understand the material, use it as the means to an end of a successful programming solution, and the client/your employer is happy with the results.
Not all programmers are created equal.Quite often managers think that DeveloperA == DeveloperB simply because they have same level of experience and so on. In actual fact, the performance of one developer can be 10x or even 100x that of another. It’s politically risky to talk about it, but sometimes I feel like pointing out that, even though several team members may appear to be of equal skill, it’s not always the case. I have even seen cases where lead developers were ‘beyond hope’ and junior devs did all the actual work – I made sure they got the credit, though.
by Dmitri Nesteruk
I fail to understand why people think that Java is absolutely the best “first” programming language to be taught in universities.For one, I believe that first programming language should be such that it highlights the need to learn control flow and variables, not objects and syntax. For another, I believe that people who have not had experience in debugging memory leaks in C / C++ cannot fully appreciate what Java brings to the table. Also the natural progression should be from “how can I do this” to “how can I find the library which does that” and not the other way round.
If you only know one language, no matter how well you know it, you’re not a great programmer.There seems to be an attitude that says once you’re really good at C# or Java or whatever other language you started out learning then that’s all you need. I don’t believe it- every language I have ever learned has taught me something new about programming that I have been able to bring back into my work with all the others. I think that anyone who restricts themselves to one language will never be as good as they could be. It also indicates to me a certain lack of inquistiveness and willingness to experiment that doesn’t necessarily tally with the qualities I would expect to find in a really good programmer.
It’s OK to write garbage code once in a while.Sometimes a quick and dirty piece of garbage code is all that is needed to fulfill a particular task. Patterns, ORMs, SRP, whatever… Throw up a console or web application, write some inline SQL (feels good), and blast out the requirement.
Print statements are a valid way to debug code.I believe it is perfectly fine to debug your code by littering it with System.out.println (or whatever print statement works for your language). Often, this can be quicker than debugging, and you can compare printed outputs against other runs of the app. Just make sure to remove the print statements when you go to production (or better, turn them into logging statements).
Your job is to put yourself out of work.When you’re writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned. If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment’s notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can’t do that, then you’ve failed miserably. Interestingly, I’ve found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.
by Mike Hofer
Getters and Setters are highly overused.I’ve seen millions of people claiming that public fields are evil, so they make them private and provide getters and setters for all of them. I believe this is almost identical to making the fields public, maybe a bit different if you’re using threads (but generally is not the case) or if your accessors have business/presentation logic (something ‘strange’ at least). I’m not in favor of public fields, but against making a getter/setter (or Property) for everyone of them, and then claiming that doing that is encapsulation or information hiding… ha!
by Pablo Fernandez
SQL is code. Treat it as such.That is, just like your C#, Java, or other favorite object/procedure language, develop a formatting style that is readable and maintainable. I hate when I see sloppy free-formatted SQL code. If you scream when you see both styles of curly braces on a page, why or why don’t you scream when you see free formatted SQL or SQL that obscures or obfuscates the JOIN condition?
UML diagrams are highly overrated.Of course there are useful diagrams e.g. class diagram for the Composite Pattern, but many UML diagrams have absolutely no value.
by Ludwig Wensauer
Readability is the most important aspect of your code.Even more so than correctness. If it’s readable, it’s easy to fix. It’s also easy to optimize, easy to change, easy to understand. And hopefully other developers can learn something from it too.
XML is highly overrated.I think too many jump onto the XML bandwagon before using their brains… XML for web stuff is great, as it’s designed for it. Otherwise I think some problem definition and design thoughts should preempt any decision to use it.
by Over Rated
Software development is just a job.I enjoy software development a lot. I’ve written a blog for the last few years on the subject. I’ve spent enough time on here to have >5000 reputation points. And I work in a start-up doing typically 60 hour weeks for much less money than I could get as a contractor because the team is fantastic and the work is interesting. But in the grand scheme of things, it is just a job. It ranks in importance below many things such as family, my girlfriend, friends, happiness etc., and below other things I’d rather be doing if I had an unlimited supply of cash such as riding motorbikes, sailing yachts, or snowboarding. I think sometimes a lot of developers forget that developing is just something that allows us to have the more important things in life (and to have them by doing something we enjoy) rather than being the end goal in itself.
by Greg Beech
If you’re a developer, you should be able to write code.I did quite a bit of interviewing last year, and for my part of the interview I was supposed to test the way people thought, and how they implemented simple-to-moderate algorithms on a white board. I’d initially started out with questions like:
Given that Pi can be estimated using the function 4 * (1 – 1/3 + 1/5 – 1/7 + …) with more terms giving greater accuracy, write a function that calculates Pi to an accuracy of 5 decimal places.It’s a problem that should make you think, but shouldn’t be out of reach to a seasoned developer (it can be answered in about 10 lines of C#). However, many of our (supposedly pre-screened by the agency) candidates couldn’t even begin to answer it, or even explain how they might go about answering it. So after a while I started asking simpler questions like:
Given the area of a circle is given by Pi times the radius squared, write a function to calculate the area of a circle.Amazingly, more than half the candidates couldn’t write this function in any language (I can read most popular languages so I let them use any language of their choice, including pseudo-code). We had “C# developers” who could not write this function in C#. I was surprised by this. I had always thought that developers should be able to write code. It seems that, nowadays, this is a controversial opinion. Certainly it is amongst interview candidates!
by Greg Beech
Design patterns are hurting good design more than they’re helping it.Software design, especially good software design is far too varied to be meaningfully captured in patterns, especially in the small number of patterns people can actually remember – and they’re far too abstract for people to really remember more than a handful. So they’re not helping much. And on the other hand, far too many people become enamoured with the concept and try to apply patterns everywhere – usually, in the resulting code you can’t find the actual design between all the (completely meaningless) Singletons and Abstract Factories.
by Michael Borgwardt
Less code is better than more!If the users say “that’s it?”, and your work remains invisible, it’s done right. Glory can be found elsewhere.
by Jas Panesar
What do you think? And more importantly, what’s your most controversial programming opinion?
A few more controversial programming opinions: