Responsible Software Development
I’ve been lucky enough to travel around seeing and organizing and speaking at technology conferences for the past several years. It’s interesting to see how people come together over something many outside the industry take for granted: developing software.
But there is something missing sometimes.
For the past while, I’ve been a Ruby developer predominately. I’ve worked with other languages, PHP, NodeJS, even some proprietary languages like Visual Basic and ASP. I moved to Ruby because of a job. I’m not complaining, I enjoyed taking my knowledge of the business logic and applying it to something new.
On reflection, though, we didn’t pick Ruby because it was cool, hip, or the new hotness. We used it because it was the right tool for the job.
The right tool for the job.
Let’s look at the job of software development. At it’s core, we take a specific need, something we think a customer, client, or end user needs in their life. Whether that be survey software, a randomizer for lists, cloud platforms, or social networks, we are attempting to build something to serve the perceived need. In doing so, we are solving problems.
Software development is similar to putting together a puzzle. The difference is we start only knowing some of the pieces. There are no clearly defined edges, no picture on the outside of the box to let us know what the completed puzzle will look like.
When it comes to the tools, we start with the familiar. We know what the givens are, to a degree. For example, when I want something simple, I’ll start with Ruby and Sinatra. I might not need a full on application abstraction, like Rails. I start here, not because it’s right, but because it’s my comfort zone.
Breaking the Mold
Some people never leave that comfort zone. They stick with one language, or framework, or community. Perhaps it’s out of fear of being called out as not being as knowledgable in other things.
For whatever reason, we need to break this mindset. What we really need to be doing is focusing on putting the puzzle together. That could mean a change in toolsets, or mindsets, or, imagine this, being prepared if the project we are working on or the company we work for pivots and changes what the puzzle should even be.
A hammer can’t fix everything. A single programming language can’t solve every problem. To that end, hammering a nail doesn’t mean a project is done, and we know software is a project that is never done.
Stay Flexible
We need to be solving problems, not raving about how awesome one tool or another is. You can learn something from every programming language.
It’s not about Ruby vs PHP vs Python. It’s not about VC vs Bootstrap. It’s not about Open Source vs Enterprise. It’s not about OO vs Functional. It’s not about this community over that community.
It’s about what you build serving a need & solving a problem. Does what you’re doing help a situation? Does it work for the humans using it?
These are the questions we need to analyzer whether what we do works.
