4 Easy Ways to Infuriate a Developer
Developers are warm, generous, intelligent people who are passionate about what they do. Nobody willingly signs up to be buried by the heavy quicksand of code unless, to them, it feels like the excitement and euphoria of seeing a double rainbow or the new Star Wars trailer. And if you haven’t seen it already, you can get your fix here.
But for the most part, devs are hard-working, detailed oriented idea makers that enjoy and appreciate their challenging jobs. However, given the number of balls they’re constantly juggling, throwing knives (or more often, chainsaws) into the juggling mix is one way to make them hate their jobs — and you in the process.
And you don’t want a developer to hate you. They know people who can make lasers-beams on sharks a reality. They can take down satellites. And they see the world in code — Neo had better watch out.
So here’s our fall compilation of the top 4 ways to infuriate a developer. You’ll probably want to avoid doing these:
1. Ask For Confident Timelines With Almost Zero Information Given
Do you see that delightfully shiny piece of equipment sitting in front of them? Yes, that thing. Well you’ve probably noticed it’s a computer, not a crystal ball (or Palantir for those who know) that gives them magical powers.
Giving an engineer information like “Well, I’d like to have users do this *waves hand* once they’ve clicked this *points in mid air*” is not going to cut it.
You’re at least 30 answers away from a real explanation of what you’d like to accomplish, and thus, 30 answers away from a reasonably accurate ballpark time estimate for how long this project is going to take.
Please try to remember the kinds of details developers ask for when you articulate a grandiose vision are for everyone’s benefit. They want to make sure they understand — and deliver — your project to your specifications.
Keeping this in mind, try to anticipate those questions and have answers to them before you request in-point accurate time frames. Remember no developer’s resume reads “Psychic” and few, if any, own a Palantir.
2. Attach Deadlines to Projects Before They’re Fully Scoped Out
Ugh. You were given a ballpark estima- no, wait, you were given a crop-field, 10,000 foot view estimate. And it was based on a handful of details, three head-nods and what looked like the vague outline of a Transformer you drew on the whiteboard. And now all of a sudden you’d like a deadline? How is that even possible?
There’s a big difference between being “agile” and being “ridiculous”. Please remember that developers have to flush out a lot of details at multiple levels of your project. It’s not just about what you want to build — it’s how it functions and works that’s important. So before you start whipping around terms like “deadline”, consider getting granular on the details.
3. Be Condescending About Bugs
This isn’t a simple game of tic-tac-toe. This is code. Lots and lots and lots of code that depends on the harmony between lots and lots and lots of other aspects of your project. Servers, designers, devices, browsers, other code, and other developers are just some of the areas your developer has to consider.
You could swear in Donald Trump to the Presidency, and make an Ewok VP and you still wouldn’t have a reference point on how many things could possibly go wrong here.
Be patient, be realistic and be respectful when it comes to bugs. With the right people, attitude, and process, your project will work well. No need to go heavy or belittle problems when they do happen.
4. Act Like You Forgot About the Technical Debt We All Acknowledged Was Going to Come Back Around and Kick Us in the Butt
Don’t whine about it. You were in the room, looked everyone in the eye and said, “OK”, when it was decided that “doing it quickly” and “hacking it together” was more important than “not building it with popsicle sticks and white-glue”.
There’s an age old expression — you get what you pay for. It’s true here as well.
No one knows how much of an impact hacking a solution together will have on your future projects. That’s why it’s best to invest, take your time, and build it right the first time.
But now that there are challenges, you’ve got to trust that the clean-up is an invaluable piece (even if the cost in time and resources is significant) to laying the foundation for future work and successful projects. It’s time to pay off that technical debt and create something awesome.
Fail to follow these and you’re in for a rough time with your developers.
Have other ideas on what infuriates a developer? Let us know below!