When do you feel like you’re “senior”

Dear new developer,

I thought this was a great tweet. It’s worth clicking through and reading the responses. I wrote my own tweet in response, but thought I’d write about it a bit more here.

First, it’s worth acknowledging that the term “senior developer” means different things in different places and times. Certainly the knowledge expected of a senior developer in 2020 is different than in 2010. And likewise, a senior developer at a small consulting company will probably be ineffective at Google and vice versa. I’ve written more about the various types of senior developers here.

It is also worth pointing out that a senior developer isn’t the same as being a good coder. A senior developer has that skill plus many others. So, how do you know you are a good coder? In my mind, there are three attributes:

  • You know your tools
  • You can figure out what the right code to write is
  • You can make the right set of tradeoffs

Let’s examine each of these in turn.

First, it’s important to know your tools. These could be low level tools like the syntax of your language or your text editor. They could be higher level tools, like an open source framework or a custom library. They could be computer science focused tools like a parser.

But you need to know these tools and what are the right ones to apply to solve the problem at hand. Otherwise you’ll either be re-inventing something that has already been done or trying to apply the wrong tool to a problem (much like using a saw to hammer a nail; can be done, isn’t pretty).

Next, you need to figure out what the right code to write is. Even if it is no code. This means that you don’t expect to be handed a full set of requirements from some all knowing figure. It means you dig in and understand the domain. That you apply your knowledge and skills to the problem. And that you use the above tools to solve the problem within the constraints that you are operating.

For that is the final piece. Every bit of code has its own context in which it was written. The code that you write to load a CSV file one time can be undocumented and slow. The code that you write that will be executed multiple times by every application user should be polished, tested and fast. As a senior developer, I think you know that “good code” is context dependent.

You understand that context and make appropriate choices to get the job done.

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