Shortly after announcing the first drop of Nancy, my friend Mark Nijhof asked me

“one thing that keeps sounding in the back of my head is; why not use Sinatra instead?”

The short answer to this is; If it makes more sense for you and your project to use Sinatra, then you should! However it is my experience that it’s not always that black and white when it comes the question “why don’t you use…?”. The answer really depends on what type of developer you are and the surrounding circumstances.

Now let me clarify that Mark said he liked Nancy and that this was just a feeling he got while reading the post. This post has less to do with Mark and more to the discussion about “why don’t you use…?” since it is a repeating topic that pop back up every now and then.

Say you are doing contract work, either on your own or at an agency. Here is depends on two things; do you specialize at delivering software on a specific platform or do you target a wider audience? Second, does the client have any demands on the platform and technology stack that you use?  So the ability to choose technology stacks in either of these situations should be self evident. If you are in a position where both the client and employer lets you choose the best stack for the project then you are in a sweet position!

Imagine you are working in-house at a product company, should you just be able to pick any technology stack that you feel is the best for the task? Would you let your employees do that if you were the CEO? There are additional costs for training team members and you risk in getting way too many go-to-guys, the people that have a passion for a certain technology. And what if some of these guys were to leave? Then what? It’s not that easy to recruite people with cross-technology stack experience, especially those with senior skills in all of them.

I know that at the place where I work it would not be a good idea to start building out products using django, ruby, scala – whatever – simply because our organization could not handle it. At least not today. And who knows what it will be like in another year? A couple of years ago we wouldn’t have been able to use Kanban efficiently, but we matured over time and today we use it with great success.

I am a firm believer of “use the right tool for the job”, but I am very aware that it’s not only the framework or programming language that defines what “the right tool” is, there are lots of organizational and surrounding factors that all have a play in that.

Have you ever stopped to think about the industry you have choose to work in (I’m bluntly assuming that if you are reading this you are working in the software industry in some way)? I would call it one of the most complex industries in the world. Think about it. We are working in an industry that is evolving at an incredible pace, contains an incalculable number of technologies, frameworks, best practices and constantly redefines the definition of how things should be done in the best possibly way. It’s the industry that makes the rest of the world tick. Daunting really, if you think about it.

A while back I read a couple of posts by Gil Zilberfeld (here and here) where Gil talks about the responsibility that vendors such as Microsoft plays in the role of securing the quality of the work that is produced in our industry. While I think I see the points  Gil is trying to make, I think he misses the beat a bit and I have a hard time agreeing with the conclusions he draws.

The way I see it there are two types of developers; those that are just in it to pay the bills and those that consider themselves as craftsmen. If you consider yourself a craftsman then you should already be aware that you are responsible for your own faith and actions in this industry. But, if you are just in it to pay the bills then you are probably also looking to do so by doing the least amount of work and that includes looking for information on how to solve a particular problem or how to apply a technology onto your stack.

So if you are one of the developers that are only looking towards Microsoft (or the relevant company for the technology stack you are working on) is it their fault if you implement something in a way that could be considered bad? Of course not! Sure there are a lot of outdated and down right poor samples at the Microsoft (or relevant company) website and their idea on how certain things should be solved are bound to differ from others (and that’s definitely not to say that there isn’t good contents, there are a ton of it). However, if you rely on a single source of information, you are always going to get an opinionated view. Take my word on it (right?).

Doctors reads medical journals, publishes research papers, attend conferences, network with colleagues and make sure they stay up to date with the latest in their field. I’m pretty sure you are happy that they spend all of this time to make sure they can provide the best possible care and treatment when someone are in need of their services. I know I am.

Just as with any other profession, developers are responsible for their own education, for honing their skills in the craft that they have chosen to practice. In order to keep up in an industry that evolves at the speed of light you need to invest in yourself. The code you write today should be some of the best you have ever written, while a year later you should be considerably less excited about its quality. It’s a sign of growth. That you’ve continued to move forward as a craftsman, that you skills have been honed and broadened during the past year.

So what about the tools? Do we really rely on them too much to get the work done? I would say, definitely not! But again you have to specify just exactly what you are talking about when talking about tooling. If you rely on visual designers, drag and drop, wizards and the likes to to the majority of your work, then yes you are probably relying too much on your tools. Odds are that you will have a hard time to get anything outside of standard behavior to run and there will be pain points when you need to debug.

However you would do yourself (and your employer) a huge disservice if you did not make it your goal to know the tools in your toolbox as good as possible. What’s wrong with knowing how to use the debugger, the IDE and tools like ReSharper as good as possible? Used correctly they will have a huge impact on productivity. Make sure you know the finer details of the tools and make them work for your and not the other way around. Yes, sometimes tools do get in the way of the goal, even slow you down, and when that is the case, don’t use the tools! Tools are there to help you when you need them, not to act as a crutch you always have to lean on so you don’t fall on your ass.

Well there you have my thoughts on the subject. It’s always up to the developer, not the companies. Always.