Skill stacking

Dear new developer,

I found this post, “How to Become the Best in the World at Something”, enlightening. The author is arguing that if you pick one area to be the best in, you’re going to have to be very very good at it. For example, if I wanted to be the best in the world at building websites with Rails, I’d have to work very very hard at it.

If you, on the other hand, pick a few things to be excellent at, you will have an easier time being the best in the world who can do all those things well. For example, if I were to be the world at building websites with Rails for CSA farms in the USA with ecommerce and email functionality, I’d have to understand and be good at:

  • building websites with Rails
  • knowing the needs of CSA farms
  • understanding ecommerce
  • knowing email strategies

I’d need to know a lot about all of these, but I wouldn’t need to be world class in all of them to be world class in the overlap between them. The post has some nice graphs illustrating this.

Here’s a great quote from the post:

Let’s run some numbers on this. If your city has a million people, for example, and you belong to the top 10% of six skills, that’s 1,000,000 x 10% x 10% x 10% x 10% x 10% x 10% = 1. You’re the number one person in your city with those six skills. Bump that number up to 10 skills? Boom, you’re the best in the world at that combination of 10 skills.

This is another way of saying what a lot of business advice says: nicheing down is an effective business strategy. By nicheing down, you are decreasing the number of people that you are competing with and also making it easier to market yourself to people who need you. It’s a lot easier to focus on CSA farms who need ecommerce websites with email and to gain excellence in understanding their problems and potential solutions than it is to gain excellence in all things Rails. (I wrote about this a bit in deep vs wide experience.)

The whole post is worth a read.

Sincerely,

Dan

Three Tips for New Developers

Dear new developer,

I ran across this post with three tips for new developers.

The tips were:

  • Develop broad expertise
  • Work in application support
  • Hone your interpersonal skills

This especially resonated with me. Note that the javascript frameworks indicate this article is a bit dated; I’d substitute React, Vue and Angular for jQuery, MooTools and Prototype, but the premise is the same. You can’t make an intelligent choice between alternatives if you only understand one of them.

To sum it up, I advise new developers to work with multiple platforms. For instance, C# developers should get familiar with truly open source alternatives like PHP or Ruby, and web developers should get to know more than just one JavaScript framework like jQuery — they should get to know MooTools, Prototype, and more. Another consideration is that doing consultant work often means working within the client’s environment and technologies, so the ability to dive into new (or new to you) technologies is a must.

I can’t argue with any of these. From a high level view, when you are beginning your career, you want to learn as much as possible from a variety of perspectives. This will inform your career in the future and let you make decisions from a position of knowledge, rather than assumption. So spread your wings. When I was a new developer, I worked all up and down the software stack, from server management to database administration to front end development. And I learned what I was both good at and enjoyed.

The other thing to be aware of is that you are more likely to be hired for potential rather than knowledge early in your career. That means that if you step into, say, an application support role and then want to move out of it, you can focus on what you learned or how you improved the company, rather than what you did. A senior application support developer who’d been working in that field for ten years would have a harder time making that pitch than a newer developer.

Finally, improving your “soft” skills of communication and team work will pay dividends in the future. Rare are the developer jobs that are 100% (or even 80%) focused on coding. Defining the problem is often the hardest part of the development process, and it certainly has the most value. (Which would you rather have, the perfect solution to the wrong problem, or the 80% solution for the right problem?)

The entire post is worth a read.

Sincerely,

Dan