Roland's homepage

My random knot in the Web

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.

←  Engineering category FEA with Calculix (1)  →