Why write code?

I have a very basic question for you: what do you do and why do you do it? It is quite possible that, if you are reading this, you are an embedded software engineer. It is interesting to consider what that job actually entails. First off, how would you reply to the “What do you do?” question from someone you meet in a pub/bar? You would probably say Software Engineer, but they might ask you to expand on that. [Actually, such a reply can be a complete conversation killer. You might be better to reply with Airline Pilot or some such. Just invent a new persona and have some fun.]

It is easy to think of an embedded software engineer’s job as being all about writing code that programs a device to behave in a particular way. But that is a long way from the whole story…

It is interesting that programmers are trained to write code. A lot of time is spent discussing the best design and coding techniques for efficient reliable code. This is not wrong, but it is a curious priority because, if you look at how engineers actually spend their time, coding is only a small proportion. A large part of the development process is debugging and code maintenance.

About 15 years ago, Jack Ganssle wrote an article for Embedded Systems Programming magazine about debugging. In it he said “Learn to love your debugger – you’re going to spend a lot of time with it”. That is as true today as it was then. Maybe more so, as code volumes have increased dramatically. Typically, a developer will indeed spend more time checking the functionality of their code and identifying and rectifying bugs than they do actually coding.

The other time consuming activity is code maintenance. This may be to fix bugs that are detected after deployment or to enhance the functionality of a device later or may be a consequence of reusing code for a new application. In any case, engineers are faced with the prospect of working on code written by someone else a large proportion of the time. [Or code that they had written themselves and long since forgotten about.] What can we do with this knowledge? The answer is to adopt a programming style compatible with the expectation of future maintenance.

It is common practice to think in terms of writing “efficient” code. In other words, program in a style which is intended to result in the best code generation. That is short sighted. Modern compilers tend to do an amazingly good job. It is, therefore, much better to write code with the future human reader in mind:

• structure the code in a simple way
• use short expressions/statements
• comment the code
• do not assume the reader is an “expert” [for example, use redundant parentheses if that clarifies operator precedence]
• use meaningful names for identifiers
• comment some more

This is, by no means, an exhaustive list. The broad philosophy is write code to be read. Think of it as a form of human-to-human communication, the same as you would with an email, an article or a even blog posting.

This entry was posted on Thursday, October 15th, 2015 at 6:41 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.