Justin Kan on whether you should work at a startup

Dear new developer,

Justin Kan has deep experience in the startup space, including at an accelerator called Y Combinator. He gave a talk about why you should work for a startup, and why you shouldn’t. Here’s the transcript,, and here’s a blog post based on it. If you’re looking for good management, avoid startups:

The management at startups generally sucks. I wish I was joking, but sadly it is very true.

On the flip side of that:

At a startup, you will get access to jobs that you are completely unqualified for and you might not be able to do well (yet).

(Possibly the two are related!) There’s a lot more good advice in there, well worth the read.

As a new developer, you may have a risk profile that allows you to work at a small startup. If you can swing it, you’ll never have an opportunity to learn more about how to build a business. The first few years of your career are precious and should be spent carefully. The more experienced I get, the less risk I want to take (all other things being equal), and I’ve seen that be the case for most of my colleagues.

How can you choose the right place? I’m no expert there, as I’ve fallen into several great jobs. But I’d recommend:

  • working at a place with no jerks
  • optimizing for learning

That’s about it. Yes, make sure you are paid market rate. Yes, make sure you are being challenged. Yes, don’t get taken advantage of. But for the first few years of your career you have the opportunity to take positions at pay levels and in areas that may be closed off later in your career.

Choose wisely.



Making mistakes is OK

Dear new developer,

One time, not too many years ago, I was using git. I had used it for some personal projects, but hadn’t used it in the team setting before. We were using this git branching model. I was creating feature branches and working on them.

However, often I would be working on the same feature branch as a colleague. The first couple of times I was doing that, I used ‘git checkout -b <branchname>’ to checkout the branch. I’d then pull down the remote branch ‘git pull origin <branchname>’ and work on it.

Do not do this. Doing this will checkout a branch named <branchname> but it will be off whatever branch you were previously on. The pull will then merge the remote code. So you’ll get the code you want to work on, but there will be other code lurking. No good!

Instead, run ‘git fetch origin<branchname>’ and then ‘git checkout <branchname>’.

I point this out not because I’m trying to teach you version control (though you should learn it).

I point it out because this was a mistake. I don’t think any code escaped into production, but it definitely confused some team members and could have been very bad. It’s one of many many mistakes I’ve made in my career.

Mistakes happen to everyone. It’s important to learn how to handle them.

First, find out what the mistake was. You need to have an understanding of the mistake so you can avoid repeating it. This may be a conversation with another team member, research, or both.

Second, acknowledge that you made the mistake. If you work in an environment where you cannot acknowledge errors, make plans to leave as soon as possible. You don’t have to wail and beat yourself up, but just saying “oh, wow, I really screwed up that git branch stuff. Sorry!” is going to let people know that you made a mistake and that you are adult enough to know it.

Third, clean up your mistake. You may need some help doing so, but part of taking responsibility for your mistakes is fixing them as best as you can.

Fourth, avoid making the same mistake again. This may involve keeping a notebook, a writing a blog post, or just committing the correct solution to memory (this depends on the scale of the mistake). Bonus points if you do this in such a way that other folks, either internal (wiki page, slack message) or external (blog post, stack overflow question and answer) can benefit from your mistake.

Mistakes happen. It’s OK. Don’t pretend you don’t make mistakes, own up to them, and try to make new ones rather than repeating.



How to market yourself as a new software developer

Dear new developer,

This post from Corey Snipes, an experienced software developer, is well worth a read. From the post:

People skills help so much. It’s hard to overstate that. I am a competent software developer, but I am really good at working on a team and that has carried me to increasingly sophisticated and interesting work my whole career.

There may be some kinds of software jobs where communication is not important. Maybe something in academia? Maybe finance? I don’t know, but every software job I’ve ever been in has fallen into one of a few categories:

  • working on a team. Here communication is important as it helps keep the team aligned and moving toward the correct goal
  • working by myself. Here communication is important because I’m talking to customers about what they need.

So I agree with Corey that communication is crucial.

It’s important to be clear about your limits but also about your potential. New developers are hired for potential. Again, from Corey’s post:

Be honest about your capabilities. Some people will say “fake it till you make it” but that doesn’t work for me and I’m no good at it anyway. I’d rather work with someone who knows their limitations than someone who thinks they know everything, and that’s the sort of person that I try to be. Figure out how to acknowledge your inexperience without making it sound like a problem.

The post is full of other good tips for folks starting out. He talks about two different places where a new software developer can deliver a lot of value: a paid position in a large software team and a volunteer position building something for a small business. I’m not a huge fan of volunteering because I feel like people should be paid for value they provide, but I understand that when one doesn’t have a track record, one needs to build one any which way. Open source contributions are a great way to do that, but this activity is less focused and a longer play than finding a local business that needs a website and just putting one together.

Another tip that resonated was going to meetups and getting out into the community, but I’ve already written about that.



Show gratitude

Dear new developer,

I have found gratitude to be an invaluable part of my software development career.

First, being grateful makes me happier. It works for others too. When I get frustrated with someone at work, or some technology that is poorly documented or doesn’t do just want I want, taking a step back and being thankful for my position is just the antidote. It gives me perspective that software development is an awesome job compared to just about any others. Here’s a short list of how software development is awesome:

  • it is lucrative
  • there is a low barrier to entry
  • there are varied challenges
  • it is a broad industry
  • many jobs provide autonomy
  • remote work is a reality for many
  • there is an opportunity for continuous learning
  • developers are in high demand
  • workers are treated well (I know how health care workers, some with master’s degrees, are treated)

When I think about that, it makes the normal frustrations a bit easier to handle.

Showing gratitude to other team members also reminds me that everything is a team effort. It also has the side effect of making a job more fun, and making it easier to communicate in the future. Every team member has something to teach you.

Finally, being grateful makes me more fun to be around. Given roughly equal skills, who would you rather work with? A grumpy co-worker who is sullen and unhappy, or one who regularly shows appreciation for other team members? Who do you think will be remembered more fondly years later?

There is no need to be obsequious. You don’t need to over-thank anyone who helps you or buy people gifts. A simple “thank you” or mentioning your gratitude for the assistance to another team member in passing, done every day or two, will work wonders over the long haul. More tips about gratitude:

  • be professional. Make it short and sweet.
  • be specific: “thanks for the help with the XYZ component yesterday” is far better than “thanks for being you”
  • spread it around, including peers and people in other departments.

Remember, it’s good for you too, not just your career.



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



Potential vs delivery

Dear new developer,

Early in your career you are judged on potential. Frankly, this is because when you are young in your career, you don’t have much of a track record, so there’s not much else to judge you on.

This means that you can take more risks early in your career. You can shift around and explore different niches, whether technology or business size or domain. Each time you shift, you’ll bring over some relevant experience, but you’ll also be high potential and indicate a willingness to learn.

Companies have to train you on their process and their technology stack, and don’t necessarily expect you to ship on day one.

The older you get, however, the less you are judged on your potential, and the more you are judged on your ability to deliver. This is typically done by looking at your past accomplishments, as what you’ve done in the past is treated as a harbinger of the future.

While there still is spin up time (and the bigger the company, the longer the period; I worked at a large software company where people were surprised I shipped code in the first week) there’s an expectation that you slot in and pick things up more quickly when you are a more senior developer.

As you gain more experience, you have more human capital and are expected to deploy that capital on behalf of your employer.

Does that mean that once you’re a senior developer you can’t switch domains, tech stacks or company size? Absolutely not. But it does mean that you’ll have a harder time doing so and you’ll need to convince the hiring managers that your skill sets apply to the new venture. (There’s an entire book about doing this called What Color is Your Parachute.) You can always press the reset button and re-enter as a junior developer, if you can afford it, and if you can convince the hiring manager that you won’t leave the job as soon as you can find another one.

Take risks early.