On debugging

Dear new developer,

Debugging systems is a key skill to have. Here are a few thoughts about it.

  • Try to get the problem to be as simple as possible. Start with the problem and keep isolating and removing pieces and see if the problem persists. Modern systems are complex and the less you have to think about, the better.
  • Keep notes about what you’ve tried. These can go into a chat system if the debugging is high priority (on a production system during an outage) or in a private text document if the debugging is not (a bug you’re trying to understand).
  • Think about recent changes to the system if the bug is new. This isn’t always the cause, but it’s often part of it. Rarely does a system just degrade spontaneously.
  • Write an automated test to illustrate the bug (if possible). This will
    • speed up your fix because it gives you a tight loop of run test, make change, run test, make change.
    • ensure that your change actually fixes the bug as opposed to something else.
    • provide a regression suite that will prevent this bug from popping up again.
  • Start at one end of the system or the other when you are trying to isolate the issue and see where it appears. For example, for a user facing web application, start with either the browser or the data store.
  • Minimize impact to users. If you are working on a production bug, ideally you can test on staging (right?) because this gives you the most latitude. However, if you do that, make sure that staging and production are exactly the same, otherwise you will chase your tail. Even if you have to test on production you can print debugging statements only for certain users (you or admin users) or to comments.
  • Start with a hypothesis and work to continuously disprove or prove it, refining it as you know more information.



Learn to type quickly

Dear new developer,

Coding is so much more than typing into a computer. Other things that matter:

  • knowing who to talk to
  • what to build
  • when to discuss high and low level concepts
  • other processes like testing and documentation
  • communicating progress
  • course correcting when a project goes awry

These are all skills you need to be a great developer.

However, just like knowing the command line and a text editor, knowing how to touch type will make you more effective. Touch typing is the ability to type without looking at the keyboard with all 10 of your fingers (if you don’t have use of all your fingers or you use fewer, you can still type quickly).

Typing well is especially important because many forms of communication are text based (slack, email, ticketing systems). But even for plain old coding, being a touch typer will help you be more effective. This is because you’ll be able to implement things more quickly. You should learn your keyboard shortcuts for commonly used programs too.

You can Google “practice touch typing” and check out several sites (paid and free) to improve your speed. There are also competitions out there like typeracer. I was lucky enough to learn to touch type in school, so I haven’t had to try any of these out.

However, a big caveat. If I had the choice between being a fast typer who didn’t understand a problem space or a slow typer who did understand a domain, I’d pick the latter. Often, the best code is no code. So, focus on understanding and then solving the problem. Make sure you make your fast typing skills work in service of solving the correct problem, so you can be the fast typer who does understand the problem space.



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.



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.




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!).