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

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!

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.

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.

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...

Justin Kruger Javascript Architect & Software Engineer

March 13th, 2015

I have worked in development for a long while and these seem to be the biggest issues.

Defining an engineering process, and then not following it. I can't tell you the number of times I have seen this happen. If you don't want to be agile or waterfall, then think-out and document a well thought out process, have reasons, or at least good hunches on why something else might be better.
Asking an engineer how long something is going to take, and then promising to someone else that it's going to take less time than the engineering team committed too.
Planing 60+hr weeks for months at a time. Studies have shown crunch time works for about 2 weeks at greater productivity, but at 4 weeks you are less effective, than no crunch time at all.
Having unclear guidelines, and then after they complete a task telling them they did it wrong. It's much better at this point to say thank you for taking a 1st stab at it, but now after seeing it I think it would be best if we change 'x','y','z'. Saying it's bad and telling them to do something else is like hitting reset on their video game's saved game file. Try to do more of a 'yes/great' and ... approach.
Telling multiple engineers on the same team they are due for the same promotion, this always backfires. Your engineers will talk, someone will say something stupid and then your team will be competing with each other instead of working together. Someone will end up acting like a cowboy, and take huge unnecessary risks.
Redesigning a feature half-way through it's creation, and the blaming the engineer for it not getting done on the original schedule. ( this is classic scope creep, agile and waterfall both try to defend against this )
Treating engineers like 'mindless worker bees' when they are probably some of your strongest logical thinkers. Give them the strategic information they need to make good decisions. Working in a 'need to know' environment and not getting all of the necessary information upfront only to find out later that you could have known about some nugget of information earlier.
Ass in chair politics!
Having to work along side with crappy engineers, because the company won't suss-out and fire bad engineers. Towing along bad engineers demoralizes good engineers to the point they will quite or leave.
Say you are Test Driven, and then never schedule the time to write tests.
Ask an engineer to build a rapid prototype, or a proof of concept, and then ship/sell it, and complain about bugs. Proof of Concepts are not for users, they are experiments to see if a piece of tech should be built.
Any complex solution that has not been tried before ( within the team ) probably needs to be rewritten 3 times. 1st time is a POC (proof of concept), next is an arhitectual refactor, and then the 3rd time fixes a ton of bugs. Not planing for this extra time always leads to issues, and technical debt.