programming

Most programmers know what's to focus on when trying to become better in their profession. This website offers a very good list. But lately I am finding increasingly that there are other things a programmer must be able to do in order to be truly successful that technology-focused sites often neglect to mention.

These are traits that are not often focused on by a lot of programmers I know. They're implicit things that some programmers just seem to be forgetting, or don't place a high enough value of. But I think if you don't possess the traits mentioned in this post then you can never be an effective programmer. Here's some of the things I found extremely useful on my current project. They apply to projects done in teams but you can just as easily apply them to lone wolf projects (but you'll be playing out all the roles mentioned below by yourself).

Deal with crap legacy code. Know how to deal with badly written and undocumented legacy code. Don't refactor a solution that's worked for years if it's not necessary. Don't break shit. Get to know the code before attempting to make major changes in it. If you are thinking that you will not be confronted with a situation like that then you are naive and should go back to school.
Know your priorities. Yes, designing that new e-mail framework from scratch is a great challenge, but there's also 5 minor bugs that break the product. Don't indulge yourself on what you like better, don't rely on other people to prioritize for you, know what's important yourself. This is one of the most important skills a programmer can have, especially when functioning in a team.
Communicate. Don't do something without confirming what it is you're actually doing. Don't try to get away with doing things according to the problem description if you know the problem description doesn't make sense.
Know better. People will ask you to do stupid shit, then change their mind and ask you to do even more stupid shit. Expect this and program your system accordingly so you don't have to change it all the time while you're in requirement limbo. (Which can last months, trust me.)
Don't trust people. If a person tells you that a piece of code is not in use and you can delete it, ignore him/her completely and do a full-text search. The only thing you can trust as a programmer is full-text search!
Don't trust new technology. If you have a crappy solution to a problem that has been working fine for years, don't change it. Almost always there will be business logic behind the crap solution that you are not aware of and will unknowingly refactor away, realizing only weeks later that you broke something important. (Unit tests avoid this problem, of course.). This point is a bit tricky and depends on the case, the crappiness of the original source code and the wackiness of the framework you're planning to replace it with.

But the most important skill is, in my opinion: achieving the right balance between writing clean code and getting things done. This is by far the most difficult thing to master for any programmer, and I have seen countless of my brilliant colleagues (and myself too) fail horribly at this. At some point in your project you will have an upcoming deadline that you simply cannot complete in time. Then what do you do? Do you try to do things properly and deliver an incomplete product? Do you fudge things up and deliver poor quality code? And where do you draw the line?

This is a bit tricky, but it's nothing compared to deciding on which technologies to use months before a deadline. That's when you really need to be able to estimate what the project's going to need and what technologies should be used. Compromises must be made and you must think about how much crap you'll tolerate given the deadline. That is the real skill of a programmer. It's not about achieving technological brilliance in every facet of the project, it's about getting the product out the door, and making compromises along the way to do it.

Programming is not fun. The perfect piece of software is also the most boring piece of software. Even the most exciting project consists of 90% boring code and only 10% exciting code, and that's an optimistic estimate. So what do I do when I am faced with a boring task? I procrastinate.

When I procrastinate I know that I'm doing something wrong. I feel guilty for it, so I punish myself by doing other tasks that I don't like to do, or by watching a movie, but not the movie I really wanted to watch. In other words, I am an expert at wasting time. I do realize this, and lately I've been developing even more elaborate excuses in philosophical directions. "I don't want to work on this because I don't believe it will make money.", "I don't want to work on this because I can think of something better. (but I haven't), "I don't want to work on this because life is meaningless and we're all going to die". My reality distortion field could use some improvement.

A project I'm working on right now involves building an online shopping system (well, sort of) consisting of a mobile website and an administrator area. It's not the most exciting project to begin with, but even then there are parts of the project that I like to work on more than others. For instance, dealing with user registration and authentication is an incredibly boring thing to do, and has little to no relation at all to the business logic. It's something I just want to get over with as quickly as possible, yet I can't. Code like this requires time and attention to detail. It has to be properly tested and properly thought out, otherwise obvious bugs will appear. I am frustrated that I cannot program this part of the project any more quicker. Despite all the programmer optimizations like a brilliant library with pre-made components, dual screens, superfast IDE hotkeys, a development server that redeploys automatically whenever you save a file, fact is that there is still a minimum amount of time that must be spent to get a task like this done properly.

And that's where the reverse-logic comes in. The task is boring. The time required is more than expected. Why not stop working and surf the net for a while? And then watch a movie? And then go downstairs and walk around a bit? And then it's time for dinner. And then you've completely forgotten about the task until you come back to your PC and your IDE is still there, staring back at you.

Even if you're only making progress very slowly, progress is progress. Even if you fail, you will have learned something. Another project I'm working on involves text detection. I spent about a week learning the basics, reading and misunderstanding papers. I spent another week teaching myself how to do a specific machine learning technique. The results were horrible. None of my training methods worked. Even though I failed at this particular way of doing it, I learned a lot about the theory and the tools involved.

Doing anything is better than doing nothing. Or more specifically, if you want to accomplish task A then doing a very tiny bit of work on task A is better than doing a lot of work on task B. I honestly don't have the patience to work on the same task for a very long amount of time, which is why I chose to work on multiple projects at once. I do tend to prioritize whichever project is at a more 'fun' state, but I rarely if ever let a project lie dormant for longer than two days. I'm quite happy with the way I'm developing now, except for one thing: procrastination. I need to build up some developer stamina so I can keep coding for longer periods of time without losing interest.

Lastly, going off on a tangent for a bit, one of the things that helps keep me motivated is pride in ownership. It's the thing I hated the most about extreme/pair programming: the code produced is extremely generic, and after you're done with it it's no longer your responsibility. That does not motivate me at all. Much like the rest of my generation I don't believe in a blame culture, but that doesn't mean you can just remove ownership on all code and still have as much motivation. Note that I'm not saying anything about quality of the code. If the developer is sufficiently skilled there should(!) be no difference. But at least with an ownership culture you will something very concrete to be proud of.

So, to summarize, my main techniques of fighting procrastination are to do multiple projects at once and to take pride in ownership. The main point though, is to simply spend time on your project, even if your progress is slow. Staring at your IDE for an hour and writing only 10 lines of code is better than watching a movie and writing nothing. Doing this is not easy, especially in the beginning. You have to build it up slowly and strike the right balance.

The colorful wolf

A competent programmer

The irony of procrastination