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

Admit your weaknesses

Dear new developer,

I just had a conversation with my boss. I said “Hey, sometimes I can be overly direct and it comes off like an a**hole. I’ve been told I’ve been condescending by co-workers. I’m working on being more empathetic but if you see behavior like this from me, please let me know.”

A few years ago, I wouldn’t have had the confidence to say this. I do this now because I’m aware of my weaknesses and I own them and share them.

This can only help a good manager. (If you don’t have a good manager, then you have bigger problems. I’d start interviewing.) They can help you grow and place you in situations where your strengths can shine and your weaknesses won’t be fatal.

What kind of skills might you have weakness in? There are two dimensions to think about:

  • innate <-> malleable
    • Is the weakness innate in who you are (you are not tall enough to play professional basketball) or how you define yourself (you are simply not interested in learning enough about good design to become a designer), or is it learnable (you want to learn how to write code)?
    • Far more things are learnable than we give ourselves credit for, it is most often a matter of energy and time. That said, as you get on in your career, some weaknesses may be not worth the effort to remediate. I don’t care enough about pixel placement to ever be a designer, which puts certain developer jobs off limits for me. But I have tried the proverbial full stack position a number of times. Don’t write off something until you’ve tried it.
    • The more innate your weakness in a skill required for a job, the more proactive you should be in dealing with the weakness. This includes, as I did, informing your manager of your weakness and then doing some self work to determine how to improve (or if you even want to).
  • core to your job <-> ancillary to your job
    • Is the skill you are weak in important to your job (are you supposed to be able to speak in front of people professionally and yet you have stage fright) or related but not crucial (you need to know a certain technology and you are not conversant with it, but are familiar with the domain space and have learned similar things before).
    • The more core this skill is to your job the more proactive you should be in fixing your weakness–either finding a way to improve or finding a way to shift jobs.

When should you have this conversation about weakness? Not in the job interview. In the job interview you should be trying to put your best foot forward (and evaluating the job), not talking about your weaknesses. However you should consider how your weaknesses might play in to your ability to succeed in your job, which might cause you to pause in taking it.

Also, do not do this in your performance review. That should be about putting your best foot forward to move forward on your career goals (title, money, position, opportunity) as best as you can. (If you have had the conversations previously and have remediated some of the issues, that’s a fine topic to discuss because it shows growth.)

I think the best time to have the conversation about your weaknesses with your manager is after:

  • you have a clear idea about your weaknesses
  • you know how they will affect or not affect your ability to perform in the job
  • you have a plan to ameliorate their effects if they will cause performance issues
  • you have been on the job at least a month or two, and have some wins (because you overindexed)
  • you trust your manager

If all of these are true, then you will be in a good position to frankly discuss the weakness and take steps to minimize the impact. It’s best to do this in a face to face conversation.

If you can’t do this with your manager, at the least have this conversation with yourself. On paper or while exercising or commuting, think through your weaknesses and how they apply to your current position. You may find that your current position is absolutely suited to you, in which case, congratulations. You may find an area to work on or improve (“man, I really need to get better at listening before I talk”), in which case, congratulations. You may find that your current job is perversely lined up with your weaknesses, in which case, take a look around.

Sincerely,

Dan

 

Try contracting

Dear new developer,

You have a portable skillset; most every company needs software, just like everyone needs accountants.

You have a “means of production” that only costs a few thousand dollars: your laptop.

You are in demand (as long as you have the right skills, experience and salary expectations).

Please take a chance during the first decade of your career and try contracting.

There are two paths to contracting. The first is where you go through an agency and they place you. The second is where you contract directly with a client. Each of these paths is different.

The agency path is easier. The agency finds the work, treats you as essentially an employee, and sends you to client work. However, you’ll get paid by the hour and you’ll have the chance to see into a number of different companies without making the commitment of being an employee. (It’s been a few years since I did this so the model may have changed slightly.). This can be a good experience, but it can also be frustrating as you will likely not be treated as well as a full time employee (FTE) while on this contract. This treatment is assuaged by more money and freedom.

The direct to client path is harder, but worth more. Here you will learn all kinds of skills not directly related to development. You’ll learn about sales, about customer support, about requirements gathering, about invoicing and getting paid. All these are fantastic additions to your toolkit. If nothing else, they’ll give you an appreciation for all other company departments, because when you are a client facing contractor, you have to perform all their job functions for yourself. Getting this business running will take longer than just calling an agency, passing their interview, and getting placed at a client. The plus is you’ll have a lot more control and you will likely have more income.

Even if you want to stay a full time developer for the rest of your career, a stint as a contractor can expose you to new ideas, let you gain new skillsets and give you an appreciation for the work that other departments do (man, sales is hard!).

Sincerely,

Dan