Every couple of days on Twitter I see another tweet or link to an article where a software developer is sharing their insights on their favorite tools.
Every couple of weeks on Twitter I see another tweet or link to an article where a software developer is sharing their insights on their workflow.
Every couple of months on Twitter I see another tweet or link to an article where a software developer is sharing their insights on why developers should take more ownership in their craft.
I read as many of these as I can because I want to grow, get smarter, and often really like the people posting these tweets and articles.
There is nothing wrong with any of these. They’re great.
Often the writing is solid and I know, for a fact, that many of them help people with direct questions they have.
But there’s an overall challenge that I witness in the development community that I spend time in.
It’s a challenge of focus.
Because every couple of days on Twitter I see another tweet or link to an article where a software developer is sharing their frustrations with some client.
Because every couple of weeks on Twitter I see another tweet or link to an article where a software developer is sharing their tips on how to stay away from horrible clients.
Because every couple of months on Twitter I see another tweet or link to an article where a software developer is sharing their take on how to be a good client.
There is nothing wrong with any of these. They’re helpful.
Often the writing is solid and the tips are great.
But the challenge is that it leads to a precarious dynamic where we’re super focused on our own internal tools and processes, while also trying desperately to put limits, constraints and healthy boundaries around client interactions.
The result is that we spend our time working on the right process, with the right tools. But sometimes we miss the mark on creating the right product.
That’s why I land on this insight.
Building software the right way is not as important as building the right software.
It’s why learning to listen well with clients is critical.
It’s why defining executable requirements is critical.
It’s why having acceptance tests articulated and automated is critical.
I know, it almost sounds like I’m writing a post on processes and tools.
I don’t have all the answers. And I don’t want to write tons of articles on workflow and tools. Mostly because others write them better.
But I do want to motivate you. To challenge you.
To help you make a decision about what’s most important.
The right way? Or the right result?
Because I deeply believe this. And I hope you do too.
Building software the right way is not as important as building the right software.