7 Blunders Great Developers Say 'No' To

Do you want to be more than a code monkey ?

Code monkeys build what is put in front of them, while great developers understand the context around their tasks. In my own quest to become more than a fleshy automaton, I try to keep track of the traits and actions of the best developers so I can emulate them. The best always seem to know when an idea will lead to pain down the road, when corners can and can’t be cut, what work is a waste of time to bother with. They see the bigger picture and understand the value of ‘No’ instead of blindly following what ends up on their plate. What you don’t do is as important as what you do. Every time you say ‘Yes’ to something, you are turning down other possibilities even if you don’t realize it.

If you want to be a great developer, learn to say ‘No’ more.

Great developers say ‘No’ to… 🔗︎

• No to… building features which aren’t worth the energy investment. Review the business value of what you’re creating, could the time be better spent elsewhere? Are you spending days working on a feature which barely moves the needle?
• No to… inordinate testing. You can write all the tests you want, but you’ll never cover every scenario. Eventually your code has to go to production and run into the “long tail of things that will probably never happen, but one day they do” . Keep a reasonable standard for testing, then have systems in place that let you safely test in production . Your app likely isn’t keeping astronauts alive, do you really need 100% coverage?
• No to… code which increases the complexity of a project for no gain. Clever code is rarely maintainable. Code is read more often than it is written , don’t be wasting your own time 6 months from now. Let’s K.I.S.S . (Keep it Simple Stupid).
• No to… piles of paperwork around the tasks you need to accomplish, such as Jira stories. Every little thing you do doesn’t need to be explicitly tracked. Create higher-level stories which encompass the hiccups you might encounter along the way.
• No to… excessive meetings, or meetings without a purpose. A common cry from developers is “too many meetings” , but it’s not a hatred for meetings themselves. It’s a hatred for bad meetings and their ability to disrupt an entire day of work if scheduled poorly.
• No to… shiny new frameworks & tools. The allure is strong. Trust me, I get it, I fall into the same trap constantly. If you’re part of a larger organization, don’t make it difficult to maintain what you built if you leave. If you’re small, don’t add risk to your endeavor without thinking through the trade offs being made. Make tech choices intentionally .
• No to… excuses. Take ownership of the work you do and predict problems so you can get ahead of them. When things blow up, buckle down and find a solution instead of pointing fingers. The business’ customers don’t care who made it break, they just want it fixed.

The great developers I’ve worked with understand when saying ‘No’ will lead to a better outcome. Software development is an expensive undertaking, so even small blunders can have a big impact. Finding ways to cut out the cruft burning through developer time makes you a more valuable member of the team. If you want to emulate the best, learn to say ‘No’.

Photo by Sarah Kilian on Unsplash