Why I think engineers should be programmers
During my engineering education and the start of my career, a lot of design and drafting work was still done on paper. During that time I also discovered computers, and how they could be an extra tool in my toolbox.
During my bachelor’s degree I had already started writing reports using a wordprocessor on a computer rather than doing that on a typewriter. This was in fact the reason for me buying my first PC.
Calculations that are tedious and error-prone to do by hand can be trivial to run on a computer. And I was not sorry when I traded in my drawing board for 2D and later 3D CAD because it made me much more productive. (Still, to this day a lot of my work starts with sketches on paper, because it has such a low threshold.)
But it wasn’t long before I realized the limits of off-the-shelf software. Such programs are often not designed to work together (except with other programs from the same publisher). Vendor lock-in is a real problem, and the more specialized and expensive the softeware, the less incentive vendors have to fix it.
Then a friend (thanks Richard!) introduced me to Linux; basically a free implementation of the UNIX operating system. Some of the basic tenets of that OS family is the use of text files as a universal interface format and the use of “pipes” to string programs together. It comes with a significant number of text processing tools out of the box. Furthermore, several “scripting” languages are easily available.
In essence, UNIX programs are designed to easily cooperate.
Several of these UNIX-like operating systems are freely available, such as several Linux distributions, FreeBSD, OpenBSD and NetBSD. For these systems, a lot of software is freely available as well. Including programming languages such as Perl, Python or Ruby to name but a few.
So with this, I was no longer constrained to off-the-shelf software, but I could easily write custom programs for one-off jobs.
Over the years I have done countless of such custom programs. For example:
- Taking data extracted from accounting software and summarizing it in ways that the original system couldn’t.
- Calculating the bending stiffness (E·I) of the cross-section of a curved sandwich panel for different skin and core thicknesses.
- Calculating the elastic properties of fiber reinforced plastic laminates. This eventually grew into lamprop.
- Automating multi-parameter global design optimizations.
- Generate (GHS) labels for chemicals for putting on smaller packaging.
- Solving differential equations by integration. (e.g. beammech)
- Cleaning up and cropping x-ray images.
Many of those have been one-offs, but the ones I’ve linked to I have used and improved for years. This has saved me countless hours of tedious and error-prone work over the course of my career. Most of those programs are not very large; only small fraction are more than 100 lines of code and between 20 and 50 is more typical.
Some key takeaways from this (in no particular order):
- If you need to do something more than three times, see if you can automate it.
- Even if you only have to do it once, having a computer do it can be much less work than doing it by hand if the data set is large enough.
- Scripting languages like Perl, Python or Ruby are extremely powerful tools.
- For a lot of problems, (runtime) speed doesn’t matter. Ease of programming and correctness are much more important.
- Text data makes automation trivial; every programming language can read and parse it.
- Changes in data and scripts in plain text are trivial to track under revision control.
- And even for data in binary blobs, revision control when used wisely gives you an unlimited undo even if the original software doesn’t.
- The ability of revision control systems to track the development of your data and programs over time is priceless.
- Text data is timeless. You will still be able to read it decades later.
- Text data is not bound to a particular piece of software.
- Text data is also extremely easy to search in.
- Debugging scripts is easier much than debugging spreadsheets.
- UNIX operating systems are very toolbox-like, much more so than ms-windows or macOS.
For comments, please send me an e-mail.