What drives software engineers crazy?

Rachel Zheng Business Development Manager at Honyee Media

March 12th, 2015

I'm following a good discussion called "what drives designers crazy?" Definitely opened my eyes to what frustrates designers, so I want to start a discussion around the same topic for software engineers. What drives you crazy? I don't want this to become a complaint thread, think of it as a way to educate your non-engineering colleagues on how to better interact.

Charlie Pham I have passions in film, music, web and geeky things

March 13th, 2015

Constantly asking if its done yet.

No it isn't because requirements keep changing. stop asking...you should know better

Eric Wold

March 12th, 2015

I'll just mention the top few I've heard from my people before.

When management:

Makes them move on before they can "properly" finish what they are doing
Does not allow any refactoring because they think it doesn't add value
Rapidly changing requirements

Eric Wold

March 12th, 2015

Oh how did I forget this one:

They want to be told the goal and be free to choose their own implementation/solution. Drives them crazy when non-coders try to tell them HOW or HOW NOT to solve an issue.

Michael Barnathan Adaptable, efficient, and motivated

March 12th, 2015

My #1 pet peeve is working with founders who micromanage the project and need to be in constant communication about it - particularly if that communication involves changing direction often. Keeps me out of a flow state and makes it harder to actually get the work done.

#2 would probably be the "perpetual MVP", which stays alive but never graduates into an actual product. If an MVP works, the idea is usually that you want to develop it further into a solid product, not move onto another MVP. And if it doesn't, you shouldn't keep maintaining it; scrap it and move on.

Caner Öncü Software Developer - OBSS

March 13th, 2015

Micro-management
Non-stop change of requirements

Madness!

Eric Wold

March 13th, 2015

@Ana,

You bring up a great point. Let's revisit the "rapidly changing requirements" part. Even my best engineers, at times, fall into a viewpoint where they see rapidly changing requirements as a "necessary evil". They don't really LIKE it, even though they express an understanding of it.
However, as a leader... I've come to see "rapidly changing requirements" as an opportunity with different facets.

Sometimes it means "We are rapidly learning more about this situation and let's pivot now rather than keep going in what now looks like a mediocre direction for [insert random item]".
Sometimes it's about leveraging a great competitive strength relative to larger players that can't keep up with my product changes.
- I have made sudden changes before specifically because of intelligence received about the way a competitor was doing something. Our original plan would have worked, but the change was a strategic choice related to branding and the desire to be a little unique.
- Some of that I was able to share. Some of it the engineers took on faith because of our great relationship. It would have driven them crazy if we didn't already have a strong relationship of trust in place first.

And sometimes I've seen the above used as excuses to cover a PMs lack of research... which drives engineers crazy! And just to get a bit meta... it drives engineers crazy to one moment receive compliments on their brilliance and the next be expected to pretend like they don't know the PM just used the above otherwise-legitimate justifications as BS excuses to cover their lack of research...

John Arroyo Delivering ecommerce and cloud applications, CEO of Arroyo Labs

March 13th, 2015

I want to build on what @eric already said. He touched on the top 4.

Being indecisive is not "pivoting". Changing your direction midstream before something is done has to be strategic and infrequent. It's very frustrating for the developer when specs keep changing mid sprint, if done too much it can de destructive to your product too and lead to unintentional spaghetti code. In extreme cases it leads to nasty bugs and developers that leave.

A fifth pet peeve would be lack of appreciation after a difficult sprint. If your developer makes a Hail Mary pass to build within your crazy constructs, take minute to appreciate the progress of the team. Don't use that success to justify requiring another Hail Mary for the next sprint. That's how programmers burn out.

The appreciation doesn't have to be verbal (although maybee it should be). Giving the developers a sane sprint load after a very hectic one shows you give a shit.

Ana Ulin Experienced builder of software and teams

March 13th, 2015

I think Eric pretty much nailed it, except for the "rapidly changing requirements" part. I would expect strong engineers in rapidly-moving start-up teams to be comfortable with rapid change and to expect it; it's part of the job.

Something that hasn't been mentioned yet and I find really frustrating: When non-eng asks about "how fast can you build this", without ever taking into account the ongoing maintenance and cognitive load costs of adding every new feature.

Jake Carlson Software Development Manager at Oracle

March 13th, 2015

Changing requirements mid-stream is absolutely fine (and often necessary), especially in a startup environment. In fact I make it a point to question and ultimately enhance requirements as I go, and the products I work on are better for it.

The real cause for irritation should be when the reasonfor the change is due to ineptitude (poor planning, insufficient research, indecisiveness, poor communication, whimsy, etc). When there are good, justifiable reasons -- uncontrollable circumstances, data unknowable at the outset, reactions to competitors, etc -- engineers should understand the need to change midstream and get on board.

I have found that by far what drives me craziest is being treated like a robot. Engineers solve technical problems, just as designers solve usability problems, and just as 'business people' solve 'business' problems. Going to an engineer asking them how long it will take to do X -- where X is the solution that a non-technical person came up with on his/her own -- is flat out disrespectful.

Specialists are hired to solve problems in their particular field. When the problem-solving aspect of their job is taken away, they become resentful and bored, and the company is ultimately worse off for not allowing the specialist to solve the problems he/she is most qualified to solve. Sometimes it may seem subtle, but it has a big impact on my morale as an engineer. Am I seen as an expert in my field whose opinion is sought on all matters even remotely in my wheelhouse, or am I a robot that receives instructions and produces an output at a predictable rate?

"How long would it take you to do X (what) in such-and-such a way (how)?" is absolutely the wrong way to start a conversation with me about a new feature / initiative that I'm hearing about for the first time. The implicit assumptions are:

You made the decision to do X without involving me in the conversation.
You already know X is the right thing to do; you 'solved' the problem for me -- you just need me to implement your solution.

Not only does this diminish my self-worth, but it also de-values me in your eyes as a decision-maker / problem-solver. It makes me into a tool to be used rather than an expert that can help steer the decision-making process for things I am well-qualified to have an opinion on. Further, if I am assertive in pushing back against the pre-conceived solution I don't like, I am forced to be confrontational / argumentative -- and perhaps even an impediment to progress. That's just silly, but it was a set up, I tell you!

Instead, try this: "We have an issue: X (what). Can I get your ideas on how to solve it? My initial thoughts are we could do Y (how) to solve it. If you need some time to think it over, we can talk about more tomorrow (or whenever)." By simply starting the conversation like that you've respected me by involving me in the decision-making process and have (rightly) conceded that I have a wealth of experience / expertise that may be valuable in solving the problem. You've also mentioned your idea as something that needs to be sanity-checked against my experience / expertise, and that's a good thing because, frankly, technical solutions conjured by non-technical folks absolutely do need that.

I've been in the game long enough to know that it's always better to talk out solutions before implementing them. Others may not like it, and you may end up actually doing the originally proposed solution anyway, but until you have that conversation you are in very risky territory. 5 minutes of discussion is a small price to pay to prevent a potentially disastrous implementation just because the engineer wasn't assertive enough to ask questions.

And really, none of this is any different for any other profession. It's all about respect. If you hire / partner with a specialist, presumably your reason for doing so is because you recognize that they are more qualified in their area of expertise than you are. How foolish then to not involve them in discussions / decisions that pertain to their specialty! In theory most people would agree with that, but in practice I have seen plenty of the opposite.

And that, my friends, is what drives me the craziest as an engineer.

Eleanor Carman Incoming BLP Sales Associate at LinkedIn

June 3rd, 2015

Because of how great the discussion was on this topic, we decided to dedicate an entire blog post. See the summary of these responses and more on the FD blog!

Question stats