The Top 4 Things That Drive Software Engineers Crazy

Posted by Madeline Reddington /June 3, 2015 / Advisors, Engineering, Entrepreneurial Advice, Hot Topics

threesixtyfive | day 244There is a much lauded schism between coders and non-coders but there doesn’t have to be. The key to any good working relationship is understanding how others work. In a recent FD:Discuss post, engineers opened up about what drives them crazy. Here are the top four things that drive software engineers crazy, and some tips on creating a better working relationship:


1. Rapidly changing requirements with sloppy reasoning.

Being indecisive is not pivoting.  Tweet this

“Being indecisive is not pivoting, writes John Arroyo, Founder & CTO of Arroyo Labs. “Changing your direction midstream has to be strategic and infrequent. If done too much it can be destructive to your product too and lead to unintentional spaghetti code.”

Yes, changes on the fly will always be par for the course running a startup, and strong engineers in startup teams should be comfortable with adapting to rapid change. But being onboard for those new expectations is much easier to do when the changes are strategic and intentional, an engineer knows why they’re happening, and there’s trust between the engineer and the person in charge. There is fine line between moving fast and thrashing.

2. Perpetual MVP

Engineers don’t want to continuously work on code that stays alive but never graduates into an actual product.  Tweet this

Engineers don’t want to continuously work on code that stays alive but never graduates into an actual product – that means nothing is really getting implemented. “If an MVP works, the idea is to develop it further into a solid product, not to move on to another MVP. If it doesn’t, you shouldn’t keep maintaining it, scrap it and move on,” said Michael Barnathan of the Polymath Foundation.

3. Unrealistic timing goals A big vein-popper from many engineers is “redesigning a feature halfway through its creation and then blaming the engineer for it not getting done on the original schedule,” writes Social Helix/Ideix founder Justin Kruger. Among some other mistakes Kruger notes are asking the engineering team for a timeline and then lowballing the timeline to a 3rd party, planning crunch time weeks (60+ hours) for months at a time, and not leaving sufficient time to test and debug new complex solutions.

The long and short of it is, give the engineering process the time it needs. Develop aggressive, yet realistic estimates with your engineers, and know that modifying your requirements may change those estimates.

4. Micromanagement “I have found that by far what drives me the craziest is being treated like a robot. It makes me into a tool to be used rather than an expert who can help steer the decision-making process for things I am well-qualified to have an opinion on,” said Jake Carlson

I have found that by far what drives me the craziest is being treated like a robot.  Tweet this

Talk to your engineers about problem-solving or implementing new features before just assigning them as a task. And make the conversation an open one in which you ask for their opinion on what might work best. Communicate; don’t micromanage. Treating your engineers like worker bees not only frustrates valuable employee, you’re also missing out on what could be a wealth of problem-solving experience and strong logic skills to draw upon.

Perhaps the biggest takeaway here is to listen. As you would with any other team members you hire, nourish relationships with your engineers that balance the give and take. Don’t discount something you might not understand, but rather take the time to understand it and explain limitations to them. 

Want to make sure you avoid these and other snafoos? Connect with world-class technical advisors Connect Now