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, which 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 a decade 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 – I wrote about this recently. 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 blog posting.
You didn’t really address, “why do you do it?”. My answer is usually, “I like solving problems.”, but I need to qualify this answer. I like to solve application-level problems, not implementation-level (e.g., in C) problems. I don’t like wasting my time debugging to find silly implementation-level problems, or wasting my design time on implementation-level concerns. As a Mentor Graphics’ BridgePoint user, I can work strictly at the application-level and leave the implementation-level concerns to the model compiler. Modern model compilers tend to do an amazingly good job, as well. I find this a much more satisfying way to work.
Good points Lee.
I think that I was first attracted to programming because I liked solving puzzles and finding solutions to problems. I think that sometimes it is the low-level stuff in embedded that makes for interesting challenges, but that’s a question of taste.
I personally think that tools like BridgePoint are ahead of their time and that model-based programming is definitely the way forward.
I will comment with a different perspective: ~Why~ I want to do it (because I’m not currently working in that area but sure hope to be real soon!)
I started with the opposite: I worked on some hardware designs, then “fell into” the need to write some embedded code.
I understand the low-level implementation of the code but saw how the following is so important for GOOD, QUALITY code:
1. Working in the abstract/higher-level domain to provide a good, efficient solution to a problem
2. The need to continue to learn more and strive for *professional* quality, not just barely getting by as seems to be the case in lot of code I’ve seen when learning
3. RTOS are very interesting, and emerging concepts like multi-core systems pique my interest
4. Learning more, and more, and more…!
There’s so much to learn and the need to understand software methodologies is one reason I like working on embedded software projects and wish to do it full-time.
You’re certainly right about debugging. I’ve helped strictly-software people debug lower-level mysteries, and it’s quite a challenge sometimes. Very humbling, too!
Good subject, Colin; I enjoyed this one a lot.
Good input. Thanks M_e.
While I agree that modern debuggers are very useful tools. But depending more on them will reduce the capability of designing the software well. I have seen many people spending more time debugging than actually designing / coding. Developers tend to write something quickly and then start debugging infinetley to make it run !!!
A proper mix of things is alway better.