the death of the engineer

I find it so amusing yet depressing how afraid your average engineer now is now afraid of a computer.

My brother started his first real engineering job and rapidly found himself with a problem he needed to solve. He can’t afford Matlab or Mathematica, so I suggested he teach himself Python and use that. After all, Python has excellent scientific credentials. He looked at Python and agreed it looked easy to learn and met his needs.

His boss however, vetoed the idea on the basis that if a tool were written in Python, no one would be able to come back later and edit it. The implicit assumption here seems to be that programming is hard. That no one else could learn enough of the language to later edit the program.

Once upon a time, computers didn’t do very much. They could read and write data and execute programs. Engineers and scientists had to teach themselves to write their own programs to solve their problems.

Over time programs got bigger and more complex. Then people started collecting them together into packages of tools and turning them into a product to sell to other people. They hired engineer-programmers to work on them. Eventually they glued user interfaces on top and so we get the engineering and scientific packages you see today. [My first programming job was working on one of these packages.]

New engineers start in the field and they are simply taught the package at the user interface level. Sometimes they hit the limits of the interface, and learn how to drive the individual programs underneath.

Rarely though do they still see the computer as the blank canvas which they can use to solve their problem. It does so much now that the idea of learning to make it do more seems foreign. Engineers are now afraid of the tool.

It is my belief that engineering students should be compulsorily exposed to some computer science; The core stuff with useful tools. They should have to implement algorithms that have meaning to engineers: solving equations, not a booking system for tennis matches. Perhaps then they’ll stop being afraid of using computers to do computation.

About Danielle

Danielle is an Australian software engineer, computer scientist and feminist. She doesn't really work on GNOME any more (sadly). Opinions and writing are solely her own and so not represent her employer, the GNOME Foundation, or anyone else but herself.
This entry was posted in Uncategorized. Bookmark the permalink.

10 Responses to the death of the engineer

  1. tvst says:

    As an engineer I have to say this is the exact opposite of my experience. Most engineers I know write tons of code, and are not afraid to make their own tools. But more often than not the code we write was meant for one-off experiments and is not exactly fit for a production environment.

    So maybe that is why the manager in this case advised against writing your own tools: maintenance.

    I do agree with the idea that engineers should be taught more computer science. In fact, *everyone* should be taught computer science at this point. Programming is the algebra of this generation.

  2. Danielle says:

    @tvst: out of interest what field?

    My limited experience (nowadays most people I work with did software, and before that geophysics) is that those studying electronics typically picked up a bit of programming, but those studying fields like mechanics or civil did not. [After graduating I found myself spending one afternoon writing the basis of a SCADA dialect translator for a friend who didn’t know where to start.]

    I agree maintenance is the problem no one thinks of. Like always, you have to estimate how much time is going to be spent doing it manually vs writing the tool + maintaining it. Where I think it goes wrong is when your estimates are biased by a fear of programming.

  3. Is your brother’s boss an engineer or a manager? If he’s an engineer, I must assume he’s a bit older than your brother. So the new generation, represented by your brother, is trying to create something, while the older generation is shivering in fear. Anyway, I really think we cannot generalize about this and just have to loot at this as a special case.

    I’ve too been in your brother shoes: I wasn’t allowed to use GNU/Linux with a web-interface administrative panel as a NAS server because people didn’t know how to use Linux (what is that supposed to mean, anyway???), I’ve come to realize that these are just isolated occurrences and fortunately don’t represent engineers in general, only bad bosses/managers.

  4. Heikki Paajanen says:

    This a little bit beside the point, but could GNU octave or Maxima be an option for your brother?

  5. Danielle says:

    @Heikki: yeah, I’ve already suggested Octave as another possible solution.

  6. Simon says:

    I think the assumption isn’t that “programming is hard” – it’s that introducing a new tool has downsides.

    The engineers are paid to solve engineering problems, not to be experts in a dozen programming languages. Which means that if Matlab or Mathematica is the tool of choice in the industry, writing something in Python is a problem. Not because it’s Python, but because nobody else in the team already knows it, and all of them have more important things to do than learn a new tool just because the new guy decided to be different…

  7. Danielle says:

    @Simon: Matlab would also be an acceptable tool (and also requires programming) except that’s not available either. It’s also very expensive.

    To be honest, I think programming is a fairly adaptable skill. So the language is actually the least important part.

  8. Simon says:

    It’s an adaptable skill, *if* you’re a programmer, someone who takes pride in being able to code in a dozen languages, and who enjoys learning new ones.

    Not so much if you’re the engineer who’s learned just enough to use a particular language (Matlab, for example) to solve his problems. Or likewise, the manager, who’s a whiz with a spreadsheet and VBS macros. It’s not that those people can’t code – it’s that coding isn’t their job. It’s just a tool that helps them do their job.

    That’s why the boss might veto Python – not because Python is hard, but because he has more important things for his engineers to do, than spend a couple of weeks learning enough of a new language to maintain the tools that one person wrote.

  9. Danielle says:

    @Simon: I don’t agree that you need to be a specialist programmer to switch languages, for the type of programming we’re talking about. You really only need to understand the fundamentals of programming. At least to read and edit someone’s code. I wrote Perl and Fortran using a reference manual.

    VBS macros are another possible solution, but they’re still programming, and people are still going to have to learn something in order to fix them.

    My point, which I’ve think you’ve missed, is that it feels to me like people don’t think to develop their own tools and scripts any more to make their lives easier. They’re afraid to because they don’t understand what a computer is any more.

  10. Simon says:

    No, I got your point – I just disagree. Being familiar with programming in general doesn’t mean you can pick up someone’s program in some new language, and start making changes. Read it, maybe, but even the best coders are going to take time to work out how to change things, and track down the subtle bug that depends on a quirk of one of the standard library functions.

    And my point is this – if you’re a specialist coder, that’s fine, learning things like that is what you do. But if you’re a random engineer who’s just trying to fix a bug in a tool that someone else wrote two years ago, it’s a waste of your time. Developing internal tools is something you do to help you solve engineering problems, and so by preference, it’s something you do with technologies like Matlab that you and your colleagues are already familiar with.

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>