Five tips to become a good programmer

This blog post is different from my previous posts. The subject is not a technical one this time - instead, I'd like to share some of my personal experiences and opinions about how to become a good programmer.

In my opinion, a good programmer is simply somebody who does the job right. It’s about delivering an application that optimally supports the end user in what he or she wants to do. That’s the main goal of a programmer. To be more specific, I sometimes use this metaphor: you might be able to drive a screw into a piece of wood using a hammer, but a screwdriver is more appropriate and uses less energy. The same is true for software applications. Besides that, a good programmer delivers according to requirements such as time, money, performance, maintainability and anything else required by the client.

This post discusses five tips on how to achieve this goal. Feel free to use them or ignore them just as you please! Many of the examples come from my main field of work: building applications using the Microsoft .Net framework.

1. Keep your knowledge up to date

Software development isn’t an easy job; it requires skill and a lot of knowledge about the technology that is being used. For a web application, you may end up using HTML, JavaScript or C#, to name just a few. This is all way too much to learn on a rainy Sunday afternoon - it requires many weeks of training.

As well as having the training, you need to know how to use all of these languages and frameworks when developing your application. To be able to do that, you should practise a lot: write prototypes, follow tutorials and so on.

Before starting on my first real project using AngularJS, I thought it was a framework I knew quite well. I had practised by building the PhoneCat app from the tutorial (AngularJS had version 1.2 in those days) and I felt confident that I could build my own controllers, views, services and factories (directives were to be the next step). It was a sobering experience - the first weeks on the project were tough! It was an intense period that really made me sweat.

You are faced with a steep learning curve when you begin using AngularJS. Working with it on a daily basis turned out to be the best way of fully getting to grips with this great framework’s massive potential.

In addition to knowing about the frameworks you use, you should know how to use your tools, how to refactor your code in your IDE, how to commit or shelve changes in your source control system (make sure you use one!) and how to handle merge conflicts. Also know your test framework(s), and your build and deployment system. Last but not least, your application runs on infrastructure, which means that your application will interact with it. Are there any dependencies, such as system and security settings? How about network bandwidth and latency? Your application should be able to run on any machine - not just yours.

I strongly advise you to know about and use the SOLID principles. Not simply for the sake of writing SOLID code, but so that your work generates better results! These results may be used for many years to come and may be maintained, adapted and improved many times over. All this work is much easier and less time-consuming if your application is written according to these principles. It helps to measure the quality of your code using tools like SonarQube, FxCop, StyleCop and ReSharper.

To be honest, not all of my code is SOLID - and that’s something which comes right back at me! For example, when writing unit tests I might discover I have added a dependency in my class that may be very difficult to mock. It takes up so much time – sometimes more than three times the initially estimated time. And I don’t like reporting delays…! Or it might happen that I have to make a (seemingly) simple adjustment that turns out to affect 20 classes throughout my application. That can take a week of work. Again, this won’t make my manager very happy. So much for that raise I hoped for!

2. Know what you are doing

Fully understand each piece of code you write. If you don’t, your application may end up doing something you didn’t want it to or it may become really slow. That’s not, in my opinion, optimally supporting the end user.

Be cautious with code simply copied from an Internet source. The circumstances required for this piece of code to run well may be completely different from the circumstances in your application. You probably won’t be able to change it so that it functions slightly differently.

You also need to be aware of possible legal implications of using this code. I agree - the Internet is a great source of information. I use it too; nowadays mostly for finding documentation. It’s now a few years since Scott Hanselman posted a blog about googling code snippets for problems you encounter while coding, but his suggestions are still valid.

Suppose you ended up with Entity Framework entities out of sync with the data stored in your database. DbContext.Entry(entity).Reload() resolves this, but it also slows down your application because of the network roundtrip involved. At that exact moment, this might not be too much of a problem.

However, it’s better to find out the cause of the inconsistency. Maybe you or one of your colleagues used a stored procedure to alter the data in your database. In that case, you can discuss the implications of this and find a faster, more appropriate way of keeping your entities in sync with your data. The inconsistency may also have been caused by too many different actions in your DbContext’s using block.

Sometimes I end up trying something to get things working, but without success. So I try something else - again, without success. And so on, and so on. Obviously, this is a waste of both time and effort. I call it the KOT method: Keep On Trying (in Dutch: EMP-methode: En Maar Proberen). If you have a thorough understanding of your code, you don’t need to use this method.

3. Keep your eye on the ball - focus!

One of the things I find difficult about my job, because it requires a heavy context switch, is keeping track of time. When developing an application, you can get bogged down in all kinds of minute detail. It’s very easy to get stuck into the details, looking for the source of the error you want to fix. And before you know it, a lot of time has slipped by…

To prevent such a time-consuming situation, you need some sort of timer that gives you a warning signal after a certain amount of time. That may be a timer in your head or an app on your device, but you do need that warning. When the signal goes off, you should ask yourself whether you should continue doing what you are doing, or maybe ask someone else to help you instead. And don’t hesitate to ask for help - you’re only human! When dealing with a situation like this, it’s easy to lose sight of the bigger picture. Someone else might see the situation differently, which could lead to a solution. You might also conclude that the error is of little consequence. If that’s the case, it may not be worth putting more time into finding the source of the error and fixing it. It’s taken me a few years, but this has really helped me avoid wasting time.

Another pitfall to avoid is losing track of the goal of your current work item. Just imagine: you need to add a dialogue requesting user input. So you start writing a piece of code, and after a while you want to find out if it’s working. Before you started, you retrieved the latest version of the source code. But then your application doesn’t start. There might be a network error, or one of your colleagues might have broken the build (it’s always one of your colleagues; never you!) or they might have introduced a bug. You might decide to go and fix the bug. That’s great! Half an hour later, you can start your application… but then you encounter another bug. Again, you might decide to fix this bug as well. What was it again that you were working on? The dialogue you are supposed to build isn’t finished yet, your time estimate of an hour has now become two hours of bug fixing.

I don’t mean that you shouldn’t fix bugs in the application you are building, but this simple dialogue may be a vital part of the demonstration to many of your client’s important contacts which is happening the next day. I strongly advise you not to fix the bugs yet. You are probably using some sort of issue/bug/work item tracking system. Just add a quick item for the bug you encountered and continue working on the work item at hand: the dialogue.

4. See the big picture

Most of the time, you are not the only developer working on an application. For the end result to work, your code should therefore fit into your colleagues’ code. The beginning of a new project is a good moment to discuss the architecture and technology used to build the application. This is an essential part of your project.

Peer reviewing during the project helps to keep the code in line with these guidelines. If you don’t, you might, for example, end up breaking the build because you introduced a dependency on a library your colleagues don’t have, or don’t yet have. I once heard a story about a developer who broke a build. He or she had to walk around in a bunny suit for the rest of the day. Do you want to run the risk of such humiliation?

You also need to realise that your application is probably not isolated in its use. Mostly, your application needs to exchange information with other, possibly external, applications. When you realise the impact of your work on existing data and applications, you will most likely avoid costly changes at a later stage in the project.

5. Enjoy your work!

Last but not least, enjoy your work! You have the greatest job in the world! (Or do you disagree…?) If the latter is the case, you should probably ask yourself what really makes you tick. Is software development really the job for you? Can you imagine still developing software in 10 or 20 years’ time?

It’s always good to remind yourself what you like about your job. Now and again, it helps you realise that things are not going so well and what you need to do to start enjoying your work again. Lack of motivation has a negative impact on the quality of your work. The following signs indicate a lack of motivation (with 5 being the greatest sign of demotivation):
1. you stop suggesting new ideas;
2. your work decreases in quality;
3. you feel tired at the end of the working day (or earlier - even at the start of your day);
4. you become evasive about your work so that your colleagues don’t notice the reduction in your productivity;
5. you start negatively affecting the productivity or even compromise the entire team's products.

There are many reasons why you might feel demotivated. Some of these you can change yourself - they are inside your circle of influence. For each of them, you have a choice: change it or accept it. However, many reasons fall outside of your circle of influence. You cannot change these sources by yourself, so you just have to accept them. This might be difficult to accept, but you have no choice.

Sometimes, your own manager might be the reason. He or she might be at your desk a couple of times a day, which might distract you. You can’t change this behaviour entirely, but you can influence it. Try to persuade him or her that the interruptions cause you to be much less productive. A good way to do this is to take a short test: your manager should take one minute to write down 3 sets of data: numbers ranging from 1 to 26, letters from A to Z, Roman numerals from I to XXVI. They cannot be written down consecutively - he or she has to mix them up (for example, 1 – a – I – 2 – b – II, etc.). After 30 seconds, interrupt them and ask for 5 European capitals. After they have given two or three capitals, say “sorry, that was not the one I was looking for” and ask them to continue. Note the progress made after 1 minute. Now ask them to do the same, but don’t interrupt this time. After one minute, the difference in progress is a good indication of the productivity loss caused when you are interrupted.

Don’t forget to celebrate your successes! It gives you all the energy you need to resolve the next problem.

Imagine a bug that is hard to fix. You start by reproducing it. Sometimes it all seems to work fine, and other times an exception is thrown (a race condition?). You ask yourself: are all my asynchronous tasks being handled correctly? Wait, that task isn’t finished but the application has already started using the result of the task. Let’s fix that. Testing… another exception is thrown, but this time by a different piece of code. Fix that piece as well, test it again… yes, it works! The results are consistent and can be reproduced. At such moments I literally shout for joy, and sometimes I even give myself a pat on the back. This might seem silly and people do laugh about it, but I really don’t care. It gives me a buzz and puts a smile on my face!