I think much of it applies to Systems Engineers who are tasked with "building" IT infrastructure and Application Infrastructure as well as Admins who write scripts[1] for others as well.
Some of the quotable pieces I liked:
"Cards on the table, software engineers generally have a reputation for being arrogant, disagreeable, and moody. We also have a reputation for saying “no”, for debating pedantic details, and thinking we know how to do everyone’s job better than they can. In general, this reputation is deserved. That’s exactly what we do, day in, day out, as we intermix writing code with checking in on Twitter and Hacker News."
"Reputations aren’t randomly given out, they are earned based on experience."
"And here’s the real crux of the problem: software engineers aren’t builders. Software engineers are creators. Building is what you do when you buy a piece of furniture from Ikea and get it home. The instructions are laid out and if you go step by step, you’ll get that comically small table you wanted. Creating is a different process, it’s birthing something without direction or instruction. It’s starting with a blank canvas and painting a masterpiece. Software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked."
"Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea. In reality, these documents rarely contain enough information to build an actual thing. They’re usually just the starting point. And that presents a unique problem to the engineer.
To understand the problem, consider the job of building a house. Someone has decided they want to build a house on a specific plot of land. The house is to be two stories and have a garage. There’s even a rough sketch of the front of the house scribbled down on a napkin. That person comes to you with this information and the napkin and says, “this is enough for you to start building, right?” Are you able to start building?"
"“Well,” your customer tells you, “why don’t you just start building, and I’ll get you the details as they become available. That way, we’re not wasting any time.”"
"The old adage, “when you assume, you make an ass of u and me,” is about as true as can be. Assumptions are dangerous and often wrong. Yet without making some assumptions, the project can’t move forward. So that’s what you do."
"In almost every other industry where things are built, it is expected that all requirements and details are agreed upon and finalized before building commences. Except in software. In software there’s “not enough time” to gather all the requirements ahead of time. The importance of moving quickly is hammered into us from day one. And so engineers learn to fill in the gaps left by product managers just to keep the project going."
"This is one of the top things that make engineers grumpy: constantly shifting priorities. If something is a number one priority on one day and something else is a number one priority on the next day, that means inevitable context switches must occur. Creative types don’t like being interrupted until they’re finished, which is why engineers are happy to continue coding until the wee hours of the morning just to complete what they’ve been working on. Interrupting the flow makes us less productive."
"What can we do to make this go faster? Do you need more engineers? (Throwing more engineers at a problem frequently makes it worse. The only way to get something built faster is to build a smaller thing.)"
"Engineers don’t hate hard work or long hours; we hate when it doesn’t pay off."
"It’s typically not a designer or product manager that’s woken up in the middle of the night because something is broken in production."
"It’s difficult to get into a good flow while coding if you know you have a meeting coming up in an hour or two hours, that’s always in the back of your mind while coding. It is amazingly unproductive to code for an hour, stop for an hour, code for an hour, stop for an hour, etc. You can’t get into a flow and just as you start, you have to stop. The software engineer brain has to switch into a good mode for coding in that switch takes time."
joe
[1] Perhaps a title could be Software Engineer Lite?
