At the beginning of every project the question is always muttered at least once:

So which language/framework are we going to build this in?

This is a complete guess, but I would wager that 90% of new projects are built with the same technology that the previous project used.

True, there are a subset of developers (just like consumers) that continually need to be on the bleeding edge, however, this is by far not the majority of people nor businesses.

Additionally, I do believe that almost every computer language has the ability to solve any problem (although elegance of the solution changes).

So boiling it down, I would say that there are only two reasons for choosing to stay on currently known technology, either comfort or confidence.

Most developers when asked the above question will default on their current tool set. This is because either:

• They are confident the current tools are correct for the job
• They are overly comfortable with their tools, thus lacking confidence in anything else

For example, remember the Lotus Notes and XML guy? If not, I once knew a developer who solved all problems with Notes and XML, regardless of context and complexity. This would be a great example of somebody that is overly comfortable in a tool set.

People who are comfortable are in fact – apathetic; however, it is very hard for some people to recognize. Because the apathetic person is actually confident and competent in their knowledge and tools they are infrequently challenged. Thus confidence can disguise comfort and apathy.

The thin line of confidence comes into play when someone is disciplined to know the difference, and make the judgment call that changing languages/frameworks will actually lower the probability of a successful project (whether wrong fitting technology or barrier to knowledge/skill entrance is to high).

The greatest gift you can give yourself at a frequent interval is a big kick in the ass. Getting out of comfort ruts is the only way we grow. Always challenge yourself to learn, always challenge yourself to grow, and you will know the difference between comfort and confidence.

Shawn Oster had some good thought food over on my last post. I thought I would reply on a post rather than getting lost in the comments.

I’ve always thought being a manager is just another skill like writing code or being a great graphic designer…

Completely agree, however it is very difficult for many developers to recognize that soft skills are just as hard to refine as hard skills. As a result, developers have a general lack of respect for managers because they can’t relate.

In my mind this also means that managers shouldn’t get paid any more or less than those they manage. They are just a person doing their job and the pay increases should go to those excelling in their positions, great devs or managers or tech support. Organizational hierarchy should not dictate pay hierarchy.

Again – completely agree. This is where the top C-level people have problems identifying with the hard skill grunts. They have built their companies predominately on soft skills such as the ability to talk and sell, so in turn, they will always value soft skilled managers as a greater asset than hard skill developers.

I find this completely idiotic. You can have a successful company built only with hard skilled people, but a company will never survive with a bunch of talkers.

Managers to some extent are nothing more than human calender keepers. Secretaries are calender keepers. Secretaries manage one or more people. Therefore, through boolean algebra we can assume that there is no difference and that secretaries are managers and thus should make more than the hard skill workers of the company that they serve. Of course this is completely backwards thinking in a capitalistic society – but why? If companies value soft skills so much – why isn’t this true? This is why I am so confused over company structures and salaries…

One justification for higher manager salaries is that only their necks are on the line; if a project goes south it’s only the manager that loses face yet this is rarely the case and where it is true I believe it should be changed so the entire team feels like their necks are on the line.

Completely and utterly – disagree. Shit always rolls down hill. The development team always ends up taking the heat for lost deadlines. Bad estimates, lost timelines, and bugs are always the center of attention but never lack of direction, feature creep, and fuzzy project visibility. The development team may not hear it, but behind closed management doors there is always finger pointing towards cube city.

Sharp developers are like Clone Troopers. They are quick, disciplined, and deadly in their specialty. The ability to instinctively react to pressure situations with high impact; all developers hope that they resemble this elite fighting force.

However, it’s inevitable.

Someday…somewhere…you will become a manager.

Managers are elite forces in their own galaxy (far, far away); however, when they attempt to reenter the development trenches they look like the clumsy 2nd generation Storm Troopers. There are two reasons why you will become a clumsy Storm Trooper when you become a manager:

1. You never were a Clone Trooper

Sorry, but you sucked as a developer and your company is too weak to fire you – so they promoted you. A lot of companies promote people to management to see if they have the soft skills to cover up for the lack of hard skills. Sorry to be the bearer of bad news…

2. Hard Skills: Don’t use ’em – you lose ’em

What I find humorous about this career “evolution” is that it is actually a devolution in your hard blue collar skills. Think about it, all of the skills that got you this current management promotion are now being put aside and a whole new skill set must be learned.

You will code less. You will sit in more meetings. You will stagnate.

When managers spend to much time in the meeting room (aptly named Death Star Room), developers turn into much weaker forms of their previous self. This common devolution can be handled in one of two ways: avoided or accepted.

Avoiding becoming that of which you hate is probably the most obvious. Keep coding. Work hard to relate to both sides of the business. Don’t let your skills slip. This sounds easier said than done, but it is necessary in being a great manager (as opposed to good).

Acceptance is a much harder thing to do. Most managers believe that they have been promoted because they are technologically superior! While this maybe true, this truth is only held for approximately 7 days max. Why 7 days? After 1 single iteration you no longer intimate with the code base and it’s not looking back…

Regardless if you choose to avoid or accept your change of skill set – be brutally honest with yourself! Always know your weaknesses and allow the stronger people on your team to fill in the gaps for you.

Great leaders are not great because of their single abilities, but because they have the ability to lead great people. Now go get ’em corporate TK-421!