Phil Bernie Consulting

I was reading a couple of posts the other day and it got me thinking about my current work situation. The first was a post on Coding Horror called Learning on the Battlefield and the second was Scott Hanselman’s post on Sharpening the saw for developers.

I often try to think of ways to learn new skills and actively try and learn about the latest patterns and concepts and it’s great to fill up on “theory” but so far I’ve found nothing better than rolling your sleeves up and getting your hands dirty with some code to really “Sharpen your saw” so to speak.

I’ve been doing a lot of work on a project that has had me writing and reviewing a lot of SQL code and it highlighted a couple of deficiencies in my SQL skills so I was glad to be brushing up in that regard, but that wasn’t what has interested me most about working on this project.

It has been surprising to notice there’s an underlying skill set that is being developed that is not as recognizable as the direct skills you’re learning. I’m finding more and more that it’s becoming easier to know where to apply different skills depending on the situation.

As I think about it, it has become clearer that the benefit of experience isn’t so much what you learn, but where you apply what you learn.

Take a high quality grad developer and a high quality senior developer with 5 or 6 years experience and ask them to learn about a technology. All things being equal I would expect them to learn the technologies equally well. The difference between them is how they use the technology.

More often than not the grad developer will take the approach of learning a technology and once learned find everywhere it can be applied.

A good senior developer will take the approach of learning a technology and evaluate whether or not it can be suitably applied to a given situation.

Of course these are just blanket statements but the more I look for ways to differentiate between the good developers and the great developers, the more I realise the differentiator is not what they know or what their skills are, but their ability to quickly and consistently choose the right way to solve a problem.

It’s not just good enough to solve a problem. Nearly any Joe Developer can solve a problem. It’s the ability to quickly evaluate and then decide on the optimal solution is what makes the difference. The better the developer the quicker they’ll discover the pitfalls of an incorrect solution. The best developers can not only say why the solution they chose is optimal, they can articulate why they solutions they discarded are unacceptable.

So where does experience come into this? Well there are a few exceptionally talented developers that will consistently choose the right path, no matter the situation, however for the rest of us, we need to actually experience the pitfalls before we can understand why a solution isn’t optimal and where it can be applied in future.

It’s experience that tells us that NHibernate is a good fit for a complex domain project, but may be overkill for a simple console application that only updates statuses on a few rows.

It’s experience that tells us that MSSQL reporting services is a good fit for our basic reporting needs, but we will need something more comprehensive for reporting against our data centre with terrabytes of data.

And it’s experience that gives us the knowledge to make these decisions early in the process instead of committing heavily to a suboptimal solution.

Whilst I would never hire on experience alone, in future I will be keeping a keen eye out for talented developers that have a diverse range of experience and can talk me through their thought process when choosing a particular solution to a problem over others.

I’ve been working with a tool called Tibco DataExchange the last couple of weeks and it’s been frustrating. The problem with Tibco DataExchange or “DX” as it’s known is that it’s a development tool, designed to provide a level of abstraction away from the “code” however it provides you with no way to drop back to view the code. It’s just magical fairies in the background doing what it thinks best and I hate it.

I don’t have a problem with visual tools that assist in making coding easier but I do take exception to tools that think they no better than you, and as such, hold you hostage to how they feel like implementing their solution.

A lot of people complain about the “drag and drop” mentality that Microsoft take to a lot of their development tools, however one thing they get right is that their visual tools are often little more than code generators. You can always drop back and work right in with the code.

The same can’t be said for DX.

I’ve worked with many visual tools and the best ones always have the same properties.

1. They excel at the basics and make it easy to leverage them to get up and running quickly so you get a good amount of benefit from them early.
2. They know their limits and get out of the way when you need to start doing some really heavy lifting.

Take a look at any visual tool and the ones you like will have these properties. They do what they do well and once you get to the point where they can’t help you anymore, they get out of the way.

Windows live writer is a good example. It makes writing blog posts dead simple, but if you need to make a custom layout change, you can drop to source view and do it yourself. It shows you exactly what it’s doing under the covers and lets you decide if that’s really what you want

Tibco DX is not a good example. It hides what it’s doing and gives you no way to choose an alternative. Instead you have to hack around the tool and you end up wasting so much time that you lose any initial value you got from allowing it to do the basics.

Given the choice, I’d rather a feature poor tool that got out of the way when it was no longer useful, than a feature rich tool that locked you in and gave you no choice to do it any other way but theirs.