6 Tips: How to make/keep a Developer happy 😇 cover image

6 Tips: How to make/keep a Developer happy 😇

Oliver Sarfas • April 23, 2019

programming

Developers are a very "touchy" species. Often binary in their attitude and understanding of the world. How do you approach them with a problem? A solution? Or general conversation? Can developer's even be 'social'?

This is a follow up post from my article on "5 ways to Trigger a Developer", if you haven't already, be sure to read that!


📃 Specification

Anything that comes to a developer/team, should have a formal document / specification alongside it.

However, a specification is not the "be-all and end-all" of the work. We need support around this. What time scales are expected for this project / piece? Supporting designs, process / work flows? Existing competitors links (for referral)?

I get a lot of questions about "What should be in a specification?", this is a massive subject in itself, and I'll be sure to write a post on it in the near future

💬 Get us in early

So there's a new project on the horizon, a new client, or a feature-request. Let's get talking!

Involve your developer(s) as early as you can for these kinds of things. The early conversations are often where large decisions are made regarding functionality, and flow.

Involving them early will mean that the developer(s) will have a deeper understanding of the work when it comes to their desk in the future. The early discussions often include timescales and predictions of project length - get a developer's opinion on this as early as possible. As there's nothing worse that having to cram a 4 month project, into 8 weeks!

Having a developer or someone from your IT team early also means that they can interject at the early stages if something has been overlooked in a technical capacity.

💫 Tests and Automation

Allow time for tests. Ideally developers will be working in a Test Driven Development (TDD) flow nowadays, to allow for true coverage and early detection of bugs / issues whenever anything is changed.

Yes, you, or the client, don't really care for tests - that's a given. However, tests give code resilience and prove that things work as intended. It allows a developer, or team, to add, update, or remove functionality and have full sight of it's impact elsewhere.

On the subject of changing things...

🛠 Tinkering

Stop. Tinkering. With. The. Specification.

"Minor changes", we can appreciate - some text changes here, a colour there. But if you're making sweeping changes to the functionality, or process flow of a website / application - you're on a fast track to having a very angry developer / team.

Submit your "tinkers" in one simple format, ideally with screen shots. Appreciate that tinkering will delay the project / sprint, and you'll be fine. As Developers we like to say yes to most things. So let us crack on, and your changes will be implemented.

🎨 Design

Nice and easy followup from Tinkering - Design.

Now, there's a few developers that quite enjoy design and are often very good at it - Kudos to those guys. However there's a lot of us that either don't like it, or are just terrible at it. I'm both.

If we're given a specification, or requirement, with no design - you have no grounds to complain that the result "looks bad", or "isn't as we discussed"

Give us something concrete to work with, and we'll build it. Want something to look great as well as work? Get a designer on board to assist.

If you want us to design, and develop - pay us double wages 🤑🤑

🏠 Remote / Flexible Working

With the strength of the internet, technology, and plethora of communication applications nowadays - on-site working is dying out.

Allow your developers (and other staff) to work remotely wherever possible. Forcing someone to come into an office brings no benefit other than allowing for interruptions.

With tools such as Slack, Zoom, appear.in, and many others taking over - you can now do video conferences for free. Allowing for worldwide employers to hold meetings simultaneously.

Developers can commit, push, and deploy code from anywhere. Allow them to choose where that is.

Should you need to get people on site, and discuss things over a table - arrange for it, and get people together. However don't make that the default.

🎉 Honourable mentions