3 ms·

I love the vernacular of the various software development cultures I see. In particular, the terms "engineer" and "designer" stand out to me. While software d

I love the vernacular of the various software development cultures I see. In particular, the terms "engineer" and "designer" stand out to me. While software development is generally thought to fall under the 'E' in STEM, it really has little to do with traditional engineering disciplines. (Eg. Building bridges or buildings.) In fact, in other disciplines it takes longer to build the final product than it does to design it, whereas with software, for most projects where the risk of wasting expensive resources is not involved, it's easier to write a prototype than to design your software up front. And yet the word "engineer" is used primarily to refer to a software developer, even though the term doesn't really fit the process of software development. I can't help but feel that the word "engineer" is less of a descriptive and more like a title, such as "writer" in graffiti. [0] "designer" is interesting because it assumes that all design work is the same in all contexts. Software is special in regards to design, because it features graphic design challenges which are also industrial design challenges. So while a reader peering in from the outside might be confused by the ambiguous "designer", in reality the term is usually referring to interaction design. This ambiguity gets especially interesting when you see the conversations that seem unaware of the difference between industrial and graphic design, leaving you guessing if the participants know or not. (Eg. "A lot of designers just want to make something pretty.") [0]: https://en.wikipedia.org/wiki/Graffiti_glossary https://en.wikipedia.org/wiki/Graffiti_glossary

ChuckMcM 14y ago
I certainly resonate with this line of reasoning. When working for Intel (putatively as a hardware engineer) I got criticized during a review period for 'sandbagging'[1] with the justification that the assembler I wrote I said would take 3 months (which it did) but I spend two months goofing off and one month writing it. I realized two things, one that hardware engineering had lots of great milestones, and two that software development sounded a lot like 'art' to people who aren't familiar with it. The salient clue was the Michelangelo quote "Every block of stone has a statue inside it and it is the task of the sculptor to discover it." Where a programmer might say every megabyte of memory has a program inside it and is is the task of the programmer to discover it. There aren't as many really crisp milestones you can say "we are here" and point to the place on the schedule where you are 'n' weeks away from completion. [1] sandbagging - creating an estimate for the time it will take to do something far in excess of the time it will really take in order to facilitate goofing off while not getting behind in your schedule commitments.
nialo 14y ago
The problem here isn't that programmers aren't like other engineers, it's that a software "design" is closer to what other engineers would call a specification. A better comparison to the finished non-software design is a finished piece of code, because that's the point where both pieces can be turned over to some non-engineer (either a compiler or a factory, say) to be made.

ChuckMcM 14y ago

I certainly resonate with this line of reasoning. When working for Intel (putatively as a hardware engineer) I got criticized during a review period for 'sandbagging'[1] with the justification that the assembler I wrote I said would take 3 months (which it did) but I spend two months goofing off and one month writing it. I realized two things, one that hardware engineering had lots of great milestones, and two that software development sounded a lot like 'art' to people who aren't familiar with it. The salient clue was the Michelangelo quote "Every block of stone has a statue inside it and it is the task of the sculptor to discover it." Where a programmer might say every megabyte of memory has a program inside it and is is the task of the programmer to discover it. There aren't as many really crisp milestones you can say "we are here" and point to the place on the schedule where you are 'n' weeks away from completion. [1] sandbagging - creating an estimate for the time it will take to do something far in excess of the time it will really take in order to facilitate goofing off while not getting behind in your schedule commitments.

nialo 14y ago

The problem here isn't that programmers aren't like other engineers, it's that a software "design" is closer to what other engineers would call a specification. A better comparison to the finished non-software design is a finished piece of code, because that's the point where both pieces can be turned over to some non-engineer (either a compiler or a factory, say) to be made.