Adi Levin's Blog for programmers

June 17, 2009

What makes one programmer better than others

Filed under: programming — Adi Levin @ 6:53 pm
Tags: , ,

Programming speed and quality

What is the goal of a programmer? It is to create high quality software. Even though it is hard to define quality, it is not hard to assess the value of any module, but it can only be done over time, by observing how useful that module is and how well it responds to the varying requirements. Therefore, an experienced programmer or team-leader working closely with other programmers can easily assess the contribution of each programmer based on the modules that they have written. It is not uncommon to find that a certain programmer is 10 times more productive than his/her colleague – in some cases even 100 times more!

When facing a complaint regarding the poor quality of their programs, many programmers blame their managers or the circumstances for not giving them enough time. “If I had more time – I could do a much better job”, suggesting that the speed of programming conflicts with quality; “It’s true that we should have done that, but there was no time – we had much more urgent problems that needed to be solved” – admitting failure to foresee problems and prevent them from happening. Managers who are not familiar with programming often fail to correctly assess the value of a programmer. The simple claim that speed conflicts with quality appears to be obviously correct.

Many do not realize that speed of programming goes hand in hand with software quality. A fast programmer will finish his project sooner than expected, leaving more time for certain activities that will improve software quality: Testing, adding desired functionality, and doing infrastructure work from which other programmers may benefit as well. A fast programmer can quickly make progress and show partial results, thereby enabling decision makers to evaluate the design and to change it to better fit the requirements, before it is too late to change the design. This way, the final product is better suited to the requirements.  Writing reusable code and investing on infrastructure enhances both the speed of programming (because less code needs to be written for new modules) and the quality of the program (because code that is being used a lot is easier to debug – since bugs in it will appear more often than in code that is rarely being used).

It is not surprising, then, to see a programmer that is exceptionally fast and at the same time known for producing high quality code. It is also common to meet a programmer who is exceptionally slow, and at the same time produces really bad code, that tends to be thrown away in time, and replaced by better code.

That said, I should also stress that a programmer should not hurry too much. Each programming project has its appropriate pace, which is not dictated by product dead-lines. As explained above, writing code too slowly is not good for quality. But writing code too fast is also dangerous, if the programmer skips certain critical stages in the process, such as unit-testing, documentation, analysis and understanding of the requirements.

In conclusion, high quality of software requires to understand the right pace in which the project should develop. A skilled programmer should require more time when needed, and make the optimal use of the given time, by working efficiently and not too slowly.

Sucessful programming

Having said that, I am not suggesting that a programmer’s value should be measured by the speed of programming, in the sense of number of lines of code written per day. This is not a good measure because certain modules contribute much more than other modules, without proportion to the size of their code. A routine that is used by many other routines can have a high degree of contribution; A routine that requires less maintenance (or none at all) contributes more than a routine that needs a lot of maintenance; A routine that contains bugs can have a negative contribution to the product.

Over time, a better measure of the success of a programmer or a programming team, is the ratio between the time they spend putting out fires (treating emergency situations), and the quality-time spent working on actual enhancements. It is very important to monitor this ratio. If it deteriorates, it signifies a problem that may get worse, until it becomes extremely difficult and costly to make changes in the software.

The real challenge is not to write a program, but to write a program that will prove useful and satisfying for many years to come. This is very demanding, because it requires to foresee requirement changes and to enable easy modification of working code. It is challenging, but can be achieved by a talented and professional team of programmers.

Since a program grows and changes over time, a programmer should take measures to make it as easy as possible to understand it and modify it in the future. Therefore, communication among programmers (through good naming, coding conventions and documentation) is as important as writing code that works. Your program should be understood by people – not only by the computer.

The principle of proximity

This can be achieved by adopting certain habits and conventions. In particular, the principle of proximity – related things in the code should be as close as possible to one-another, or easy to find. For example, a declaration of a class or variable should be as close as possible to where it is being used. Functions should be kept short, such that they won’t require endless scrolling to go through them. The principle of proximity also says that documentation inside the source code is the most important part of the system documentation, because it is always there when you need it. You don’t need to look for it. It is also much easier to update comments inside the source code, when making modifications, than to update the related description of the software (such as SRS, SDD) which is written in a separate document and in different terms. In an ideal situation, the code does not require explanations at all, because it is self-documenting, due to the wise choice of names and an intuitive choice of functions, classes and modules.

The principle of visibility

Another important principle in code construction is the principle of visibility, which says that all important information should be made explicit. You don’t get a higher score for keeping secrets. On the contrary – a program should be written in a way that makes the motivation and the meaning in it as visible as possible. Good naming is crucial here. A variable that represents an angle in degrees can be called “ang_degrees”. It is then obvious for a programmer using that variable, that it needs to be converted to radians before computing its cosine. Similarly, a point in screen space and a point in 3D model coordinates should be distinguished from one-another by their names (or even their types) in a way that makes it obvious that they are different creatures, and cannot be added, subtracted or compared to one-another. Such explicit naming saves a lot of time on searching and debugging. In the same spirit, coding conventions are also helpful, because they make it easier for team members to share their code, and find their way around the code of their colleagues.

Team work and Interdependence

Effective team work is a crucial factor in the efficiency of individual programmers. Many programmers strive to be independent – to be able to work on their own with as little support as possible from their colleagues. A more effective team work is achieved when programmers are interdependent. Interdependence means that team members have mutual access to the resources (time, knowledge, source code) of their colleagues. “Interdependence is a higher value than Independence”. Programmers double and triple their efficiency by working together. As an interdependent programmer, you should:

  • Share information and discuss problems informally. Tell other team members about things you’ve learned and how you solved problems. Even after completing a project, tell others about it – even if it is outside their area of responsibility.
  • Ask others to review your code – don’t just present a block diagram. People should have access to your code and have the capability of modifying it if needed.
  • Do not defend yourself against bug reports. Don’t make excuses, saying that a certain “bug” is a “feature”. The people who report bugs to you are really helping you, and you should thank them.
  • Assign the highest priority to interaction with co-workers. Do not arrive late to meetings. Postponing meetings, not showing up, or leaving in the middle of a meeting wastes the time of several people.
  • Be accessible (available) to co-workers. If you help them willingly, they will help you when you need them.
  • Give credit to others for good work that they have done. This will reduce the tension of competition inside the team.

Programmers should share information freely, and not treat pieces of code as their private territory. The important thing is to provide the best service – not to prove that you never make mistakes. Make it your goal to provide the best service to others.

Effective team work is at its best when the team is as small as possible. At the same time, the knowledge of team members should be as diverse as possible. When hiring a new programmer – prefer one that also brings with him knowledge that is different from the knowledge of other team members. It is often preferable to hire a programmer that has good programming experience, but has no experience in the specific domain or technologies of the company. Such a programmer will be highly motivated, and will contribute a fresh point of view.

The value of knowledge

The software industry differs from other engineering fields in the speed in which ideas turn into products. Because of that, the knowledge of programmers is the most important resource. However, the knowledge of a programmer when he is hired to the job is less important to his success than his learning capabilities. Software technologies change all of the time. It is a never ending challenge for a team of programmers to always evolve – never stop studying and learning. Good programmers Study and learn all of the time; Express themselves clearly, in a way that is easy for people to understand; Distinguish between what they know and what they don’t know. There is no one who knows everything. People should feel safe to say “I don’t know” and not be lazy to seek the appropriate knowledge.

Quailty-time with the computer

The work of a programmer includes design, review, writing code, testing and debugging. But this is not enough for really good programming. You need to get to know your program, and you need to get to know the computer. Why is that? Because in many cases, the programs are so complicated, that you don’t really know what goes on inside of them.

Even if you fully understand the routine that you wrote – do you know how many times it is called, and at what circumstances? Do you know what parameters are sent to it?  Every line of code that you write should be stepped-through using the debugger, at least once. Follow the execution of your code with your eyes, and see if it proceeds as expected. Insert breakpoints in every branch of the code, to make sure that you visit it at least once. Use a profiler to measure the performance and to build the call-graph of your functions. A profiler Profiling is extremely important for code optimization. Once you find the bottle-necks of your application, you know what you need to do in order to make it run faster. If you’ve never used profiling before, you will be surprised by what it can make you find out about your own code.

When you use library functions, or functions that were writtens by other people in your company, do you really know what they are capable of ? Or are you just “copying-and-pasting”? You should look at their documentation, or, in some cases, even go through some of their source code.

Quality-time with the computer is necessary for learning new technologies. If you hear of some kind of functionality or function library that interests you, you should find the time to play around with it. Download the library, write a program that uses it, get it to work. This is the best way to learn.

Another opportunity for quality-time occurs when you find yourself looking at old pieces of code that you wrote. Perhaps you’ll find out that some of it is unnecessary, or can be replaced by more modern tools, or needs documentation. Don’t hesitate to make changes in old and running code if it makes it better.

Quality-time is when you sit alone infront of your computer, paying attention to the finest details, absorbing information, playing around.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at

%d bloggers like this: