"From what I can tell, nothing is more frustrating to an engineer than a non-engineer asking for something complex, and treating it like it’s trivial."
Yes, yes, and more yes. When programmers say "possible," they mean before the heat death of the universe. That doesn't mean all possible things are automatically trivial, despite their apparent obviousness.
"Don’t pretend to be more technical than you are. Especially in the Bay Area. First of all, it’s incredibly transparent (even to non-technical people), and you will lose all credibility. It also pisses off engineers. "
<venting>
Seriously. Please don't condescendingly explain something technical, incorrectly, to someone who already understands it. AHHHHRGG! </venting>
Hear, hear! I really dread sitting through this, because it makes me cringe and squirm and want to correct them.
On the other hand, it teaches patience. Patience is worth a lot. When I first began tutoring comp sci students, I learned that, even among the technically inclined, you will need to sit through an enormous amount of misunderstandings and mind-numbing attempts to keep the ol' neurons firing just so. Think you have patience? Try teaching.
I picked up tutoring on the side to earn some extra money. As a side-effect, I feel like it's helping my skills in dealing with clients, programming, and teaching.
EDIT: Also, I love pair programming. Don't know about other people, but I feel as though I'm easily twice as productive on my normal days, even though I might be on an absolute roll by myself a couple times a week. It also seems to be easier to avoid design pitfalls or unnecessary debugging with an extra set of eyes on the code (as it's written).
Along with "don't pretend to be more technical than you are", I would add "Trust the engineer/dev/ux guy/programmer to do what you hired them to do".
I had the experience (that I imagine a lot of people share) of being hired by a non-technical founder in a start-up, who then wanted to micro-manage and give input on every minute decision that went into the building of the UI, even to the detrement of the user experience.
That should actually be #7, I think - I'll add it if I get the chance. I started off like the person you describe, and I have since moved pretty far in the opposite direction.
I've not yet been in the management position, but I definitely don't think it's an easy thing to do. It requires the loss of some control, and putting your neck out on the line, but when you've hired the person equipped for the job, it's ultimately best.
To be honest, I've met programmers who don't understand these issues as well as the author does. It's refreshing to see a non-techie who goes out of their way to understand these things.
Engineers precisely specify a problem and then build a solution that's correct to within a tolerance. I'm afraid I don't see the resemblance to programming.
You could describe programming that way too, though the "within a tolerance" would probably have to be about input coverage rather than output/behavior.
That depends on the program, I suppose. Some programs require more engineering than others. I think you could make a very good argument for the programmers at Google being engineers.
I disagree. I don't find many similarities between what I do and what a "real engineer" does. I do not consider myself an engineer; I write software. Nowhere in the 18 years I've been doing this for money have I met anybody that could explain what software engineering really is. Without a definition, the term to me is meaningless.
the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.
That's what they'll teach you at engineering school. Not everyone who is writing software is engineering.
To expand on this. It is illegal in Canada for anyone without a proper engineering degree to call themselves an engineer. For example a computer scientist cannot call themselves an engineer while a computer or software engineer could.
I'm a ringed engineer; I think it's appropriate for non-ringed engineers to still self-identify by that title. An engineer is a person who engineers things.
There's a legal restriction on Professional Engineer and the P.Eng designation, but that's for very good reasons which have to do with liability and the protection of the public. That's a different beast, though, and in the general case "engineering" a solution to a problem is still engineering, whether or not you have a piece of paper telling you it is.
When you're talking about a profession though, engineer means something very specific. It means that you're trained and licensed and can be held legally responsible if whatever you're building should malfunction. Referring to your profession as an engineer when you don't meet those criteria is a bit disingenuous. It's akin to the difference between calling yourself a doctor because you went to medical school, and calling yourself a doctor because you got a PhD in english lit.
This is a good point. Traditionally, engineering is more synonymous with structures, engines, tools etc. Where someone takes the prepared plans and develop the final product, they are referred to as a developer/builder/tool maker. Where (usually a team) e.g. architect/structural/mechanical/civil people etc.. work on the design/prepare the plan, they are referred to as engineers. Software developers or even software programmers take the prepared plan or design spec and write code. The software architect / software engineer (ausually a team also) etc.. are responsible for preparing the plan / design spec. Now to cap it all off - there is a middle ground - called an analyst/programmer who analyse, design and develop a solution. (The creative hair dresser - could also accommodate this spot middle ground).
Yes, yes, and more yes. When programmers say "possible," they mean before the heat death of the universe. That doesn't mean all possible things are automatically trivial, despite their apparent obviousness.