Hi, this is the 11th part of a series of posts on 30 tips to becoming a better developer. If you would like to keep up to date with the topics that I am covering, just check the main post.

As software developers, we enjoy thinking of a system in as higher level as possible. This has been an organizing principle in software development: people tend to create higher level abstractions that make it easier to reason about a more complex system.

However, working at higher levels of abstraction has its cost. Inefficiencies become harder to see, and at some point performance becomes a problem that needs to be handled.

A layered approach to software

Computers are organized in layers. The lowest level is hardware. In a higher level is application code. It is nice to work on higher levels, but if you don’t understand the most basic parts of the system it becomes difficult to make competent decisions. This is even truer as code gets more abstract.

This is not say that one shouldn’t be working at higher level. In fact, even though we shouldn’t understand about concepts such as machine language, it would be counter-productive to work with machine-dependent code.

The idea is that you should know (or at least have a good idea of) what is happening at the lower levels of your code. This way, you can understand what trade offs are being made in your code.

Another reason why it is important to understand the lower levels is that you can “break free” of the higher level language if necessary. People working in time sensitive code (such as game programmers) already know when to use C or assembly for critical sections of their programs. A smart software architect knows when to reach for help on the lower levels of the software architecture.

This is specially true when higher level abstractions don’t work. For example, suppose there is a bug in a compiler or interpreter. How can you diagnose it? The only way is understanding what they do and how it should be done correctly (in this particular case it involves checking the machine code generated by the compiler). Otherwise, one is at the mercy of whoever is supplying the programming software used.

Conclusion

Thinking with his/her own head is very important for a software developer. Understanding the lower layers of the system you are working with will make wonders for you ability to think by yourself.

In this respect, one of the great advantages of open source software is to allow people to poke the innards of applications and even the operating system. Despite what you think of software freedom, working with open source software may improve your awareness of lower levels of the system.

Another possible help is to read books and articles that can shed some light on the lower layers of your system. Here are a few suggestions:

• Advanced Windows is a great book on how the Windows OS works;
• Understanding the Linux Kernel is a great introduction to the kernel and its main structures;
• Computer Systems: A Programmer’s Perspective gives an overview of computer systems, including assembly language, hardware, databases, networks, and related topics.

Similar Posts:

• What to watch for in a Framework
• Why C++ will not die
• Day 14: Understanding Software Libraries
• Day 28: Frequently Repackage Code Into Smaller Libraries
• Day 1: Read Other People’s Code