| |||||||||||||
Scenes from the Real Time Linux WorkshopScenes from the Real Time Linux WorkshopPosted Oct 7, 2009 3:17 UTC (Wed) by dicej (guest, #36115)Parent article: Scenes from the Real Time Linux Workshop
The lament about the "armies of Java programmers who have little understanding of how computers actually work" makes me wonder if part of the problem is a terminology barrier similar to the one separating academics and developers. A systems programmer might be dismayed that a "clueless" application programmer doesn't know what RCU stands for, whereas the latter can't believe the "outmoded" systems programmer doesn't know what MVCC stands for. Yet if they dig a little deeper, they'll find they've been talking about the same thing applied to different domains.
(Log in to post comments)
Scenes from the Real Time Linux Workshop Posted Oct 7, 2009 8:57 UTC (Wed) by farnz (guest, #17727) [Link] I understand where you're coming from, but it doesn't match my experience of the "army of Java programmers". Using RCU as an example: With a good Java programmer, I can discuss concepts like RCU, and I just have to remember that if we're using code to clarify, I must stick to Java syntax and semantics; not ideal, as my Java is very, very rusty, but we can communicate and both learn from the experience. Heck, I can even move right out of their comfort zone into things like higher order functional programming, and so long as I explain things clearly, they'll keep up. With a member of the "army", I'm stuck. Instead of being asked to explain why RCU's interesting, what it does for you, and how it compares to other solutions to the same problem, I get asked questions like "who cares? synchronized solves all that for you". I get an even worse reaction if I start to discuss things that aren't yet part of Java; "why would you even care about that?". My personal guess is that Java is the language that currently attracts people who don't like programming, but do it because it's the best paid of the jobs they can do. When the money moves to a different programming language, they'll follow.
Scenes from the Real Time Linux Workshop Posted Oct 7, 2009 14:09 UTC (Wed) by nix (subscriber, #2304) [Link]
Quite so. A lot of these people don't even have any clue what
computational complexity is, and have no desire to learn: and without knowing about *that* you have no hope of writing efficient or scalable code. (Other things are necessary, but big-O notation and all that it implies are essential.)
Scenes from the Real Time Linux Workshop Posted Oct 8, 2009 14:53 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
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.
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.)
|
|||||||||||||