LWN.net Logo

Scenes from the Real Time Linux Workshop

Scenes from the Real Time Linux Workshop

Posted Oct 8, 2009 14:53 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
In reply to: Scenes from the Real Time Linux Workshop by farnz
Parent article: Scenes from the Real Time Linux Workshop

I think you just described the difference between what I would call a "coder", and what I would call a "software engineer."

The member of the "army" is what I would call a coder. Someone who can output code. That's it. Give them a well defined spec and a list of things to go do, and they'll go do it. Best to leave the system architecture (the "why" and higher levels of "how") to someone who understands things at a deeper level. Give the coder good libraries and tools that make it easy to rely on those libraries so that they don't run afoul of big-Oh problems too often. Give them solid coding guidelines and they'll produce something that works more often than not. Hand them a working system that has a few bugs along with the bug reports, and they'll probably manage to fix the bugs, or at least mitigate them.

Your first example are the folks you want working on the overall system and its architecture, and on writing the really tough bits. You also want them looking over the coder's shoulders from time to time to make sure they're not too far off the course. :-) These sorts of guys also ought to be designing and implementing the libraries that the coders rely on, so that even if the glue between the components is dodgy, at least the components themselves are solid.

I see it as the difference between a mechanic and a mechanical engineer. A basic mechanic can follow the service manual and keep your car maintained and on the road, although a complex problem with your car might perplex them. A more experienced mechanic can even work through some of the more complex problems and do work on custom modifications. They know how to take a car completely apart and put it back together. But, you wouldn't ask them to build a car from scratch, starting with a blank piece of paper.

A mechanical engineer though works at a different level, figuring out how all the pieces need to work so that they can do what they do. They're working with different alloys and metals, deciding whether the engine will have an aluminum block or a cast iron block. They're working out the intake and exhaust paths to meet their design targets. They're working out the control programs that run on the engine controller to control spark timing, air/fuel ratios under various loading conditions, and balancing power output vs. engine life. And so on. These folks are also likely to find basic auto maintenance extremely tedious, and may not even be all that great at it because their heart's not in it. But, they can do it if they need to.


(Log in to post comments)

Scenes from the Real Time Linux Workshop

Posted Oct 8, 2009 15:06 UTC (Thu) by farnz (guest, #17727) [Link]

You're missing one detail about the "army" as against a coder; you can trust your coders to follow the spec and do the list of things roughly as you asked them to. The "army" is people who have the skill level for a coder, but believe that they're software engineers.

So, your coder will follow spec. Your "army" member will ignore the spec because what he's doing is "just as good, but easier to implement", resulting in your carefully written spec to handle 10,000 users on that bit of kit only handling 10, thanks to the changes you've encountered.

Taking your analogy to mechanics further, the "army" members are basic mechanics who genuinely believe that they're as good as or better than mechanical engineers; in particular, if a mechanical engineer were to specify a particular type of oil for a new engine, the "army" member would happily substitute 10W30, because "it's all oil, anyway". They'll move your carefully chosen spark timings and air-fuel ratios, because "everyone knows that you get more power this way". They'll change your engine to output twice the power, then complain when it lasts one year, not 20.

In short, they bodge, they apply myths, and they don't understand, but they get very upset if you dare suggest that they're a mechanic, not a mechanical engineer.

Scenes from the Real Time Linux Workshop

Posted Oct 8, 2009 21:15 UTC (Thu) by marcH (subscriber, #57642) [Link]

> Taking your analogy to mechanics further, the "army" members are basic mechanics who genuinely believe that they're as good as or better than mechanical engineers; in particular, [...] they'll change your engine to output twice the power, then complain when it lasts one year, not 20.

Just like any other analogy, this analogy is not perfect. It breaks here: the wannabe mechanical engineer is fortunately limited by its tools and physical laws of nature, whereas the wanabee software engineer can wreak havoc without any practical limit.

Oh the army

Posted Oct 10, 2009 20:45 UTC (Sat) by man_ls (subscriber, #15091) [Link]

It gets worse IME. You cannot even try to explain concepts like database locking, transactionality, threading or concurrency to army members, because you will meet their blank stares. It is worse because, even if farnz already said above that the standard answer is "who cares, synchronized takes care of that" (which it of course doesn't), database locking and transactionality are essential in most modern Java code. I've seen pools with only one object, TCP/IP connections that are tracked incorrectly (and which often break), deadlocks in database code... all of which were designed by an army member and later had to be corrected by a proper engineer.

Hey, I may not grasp a lot of the concepts in engineering, but at least I try to listen when people explain them to me.

Oh the army

Posted Oct 10, 2009 21:21 UTC (Sat) by nix (subscriber, #2304) [Link]

"synchronized takes care of that" is what the smart ones say. The dumb
ones say "I can do threads" when they mean "I have used $FRAMEWORK that
hides all the threading and multiprocessing issues from me. I used it for
six months, five years ago."

(I *wish* I was exaggerating. I really do.)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds