Still having fun writing code

My comments about “20 controversial programming opinions”

I saw a post going around a couple months ago called “20 controversial programming opinions.” It’s Saturday afternoon and I’m running out of time for the weekly blog post, so I’m disagreeing with some of those “controversial” opinions as an easy way for me to make our team’s blogging deadline, so….

1.) Programmers who don’t code in their spare time for fun will never become as good as those that do. This is an elitist attitude, or at least I’ve been helpfully told this whenever I’ve espoused this same view in public. I’m a football junkie in the late summer and early fall. One of the things you hear coaches say is that a player is or isn’t getting valuable “reps” (repetitions). Just like football players learning the mechanics of their position and how to read the opposing team, developers become far better coders with more experience. The truth of the matter is that very few of us really get to grow up in shops where you can gain enough experience on the job to become genuinely good. Working on side projects, especially if you tackle challenging problems in those side projects, is really the only sure way to become a good developer for most people.

Besides, I’ve never met anyone who didn’t enjoy coding who was actually good at it.

2.) Unit testing won’t help you write good code. I think this opinion is short sighted. I just told someone the other day that Test Driven Development (TDD) as a design heuristic is overrated, but that far from saying that it’s useless. Writing your tests first or at least focusing upfront on how you’re going to test a piece of code is a very good way to arrive at orthogonal code – which generally coincides with “good” code that’s easy to work with, extend, alter, and understand in my experience. TDD also has a very big advantage in giving you much quicker feedback on API usage, especially if you’re using tests to drive out the signature of an API. In line with Lean thinking, building API’s and services by “pulling” necessary features discovered from writing tests against the consumer of the new API can easily lead to less wasted effort as can frequently happen from “push” design where you design an API for what you think you might need later. Whether or not TDD or even just plain unit testing pushes you to better code is almost a moot point, because having a far better safety net of unit tests makes refactoring much less risky — and refactoring absolutely leads to better code.

3.) The only “best practice” you should be using all the time is “Use Your Brain”. There’s a definite anti-intellectual backlash against abstract ideas like design patterns, Agile/Lean/Kanban processes, *DD techniques and the like that I think is just as unhelpful as swallowing those ideas hook, line, and sinker. Use your head doesn’t mean disregard everyone else’s ideas — unless you’re really smart enough to completely derive all the accumulated wisdom of the greater development community over the past 50 years from first causes. Maybe you just want to climb to the higher levels of Bloom’s Taxonomy when you do learn about these “best practices” things to use them more intelligently than that guy who went design pattern happy in the project you just inherited.

7.) If you only know one language, no matter how well you know it, you’re not a great programmer. I think there’s definitely some truth to this opinion, but I think the old “learn one new programming language a year” advice from the Pragmatic Programmers isn’t entirely good advice either. I definitely think you should expose yourself to a variety of programming concepts — and you could never do that inside a single programming language. All the same, I think that trying out a plethora of programming languages for a week or two leads to being more of a dilettante than a guy who’s very effective as a developer. If you want to be a better developer, absolutely try to learn a new programming language once in a while, but I’d first recommend trying to solve different and harder problems in a language you already know rather than writing tic tac toe a dozen different ways. To make it be more concrete, let’s say that we know two C# developers named Hank and Xavier. Hank does a highly challenging, in depth side project in C# and supports it through quite a few changes and iterations. On the other hand, Xavier does several small, simple versions of a TODO application in other languages. Both developers should have improved themselves, but I think I’d bet on Hank having gained more effectiveness as a developer than Xavier did in the same time frame. Maybe all I’m trying to say is that I think you should focus on deep problem solving skills instead of only shallowly learning lots of different new shiny object technologies and programming languages.

I think I could say a lot more, but there’s college football on and steaks in the fridge that won’t grill themselves today.

It looks like these opinions derive from one central idea. Learning new languages, understanding that tests (when written well) drive good architecture, trying out things on the side – these things are symptoms (features?) of something much deeper… that these developers have a fire inside.

about that last point – may be you’re right, but I’ve seen quite the opposite, actually. Many guys I work with learned C# and asked me in surprise why am I interested in learning Scala. May be the employer influence its employees in some way, may be it’s some mental conviction that MS won’t ever let them down