Join a meetup

Dear new developer,

You are probably pretty overwhelmed right now. There is a lot on your plate and you probably are just trying to keep up with the job.

I hate to do this, but I am going to ask you for some extra curricular time.

You need to join a technology meetup. Go to and search for one on your area, covering technology that you’d like to understand more about. Sign up and go to the next one. If there’s no meetup in the area, search for a virtual one, and join via video chat or audio chat.

When you are at the meetup, you might have a hard time chatting with people (I do!). I find the best way to do this is to be interested in them. Show up 15 minutes early. Find someone standing alone and walk up to them and introduce yourself. Then ask what brings them to the meetup and what they are working on. This will be awkward at first, but just like coding, gets easier the more you do it. (Not sure how to do this virtually, but try to chat with someone on the webinar.)

Then, sit down and enjoy the presentations. You’ll probably learn something.

Why should you do this?

  • It will expose you to new ideas that you can bring to your work
  • It will allow you to have professional conversations where the stakes don’t feel as high (you can admit ignorance to a total stranger more easily than to your boss).
  • It will allow you to practice networking and talking to strangers, but the topic will be something you know you are interested in.
  • You can make friends, or at least acquaintances in your industry.
  • When you are ready to hunt for a new job, you will have a network outside of your colleagues.
  • You will meet cool people.
  • You will learn new things.

You may, in time, choose to help organize or speak. These activities are valuable for your work life, but again are easier to practice outside of the work environment. But if all you do is attend a a single meetup regularly, you will still come out ahead.

Please, go sign up for a meetup today.



Know when to not throw in the towel

Dear new developer,

I wrote previously about when to throw in the towel. Now I want to mention when you shouldn’t.

Anything worth doing is hard. That includes software development. There are times, sure, when it feels like you’re a superhero. When the code is flowing. When you can hold the entire system in your head.

Those times are great, and, in my experience, rare.

There are also times when it’s a grind. When you look up at the end of the day and wonder “what did I actually do all day?” When you are picking up a new technology or system and it feels like you are on the last move of a game of Jenga, with all the pieces about to fall over.

This is the time when you need to stop, take a deep breath, and then keep going. That doesn’t mean you can’t pop up and ask questions or take breaks, but sometimes the only way out is through.

There’s an art to knowing the difference between a grind that you have to get through and a wall that you can beat your head against without making progress. I don’t have a simple way to differentiate, other than to say that the grind often happens at the beginning of a project (when you don’t know what you don’t know) and at the end of a project, when that last 5% that you put off because it was hard balloons to 25% (or more).

I have told teams in the past that “if we aren’t learning and making mistakes and doing new things, we aren’t doing it right”. That’s because if a software engineer knows how to do something, they’ll likely automate it (and then they won’t have to do it again).

Sometimes that learning process is joyful. Sometimes it grinds. You have to push through.



Laziness, impatience, hubris

Dear new developer,

Larry Wall has created foundational software (perl, patch). He coined the three virtues of a programmer:

  1. Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it.
  2. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to.
  3. Hubris: The quality that makes you write (and maintain) programs that other people won’t want to say bad things about.

These may seem crazy. Who wants to be seen as lazy, impatient or full of hubris?

But if you think deeply about it, Larry is saying that laziness makes you work in the short term to save effort in the long term. That impatience makes you write better code because computer time is less valuable than your time. And that hubris makes you want to develop software that you can stand proudly behind.

Makes a bit more sense, no?



Know when to throw in the towel

Dear new developer,

Sometimes, you just have to stop. Stop writing that code. If you’ve been banging your head on a problem, stop. If you’ve been thinking about a bug, stop. If you’ve been writing and writing code but you can’t seem to get anywhere, stop.

Go for a walk. Take a break. Talk to someone. Stroll around your office. Take a few minutes to write up the issue.

All of these actions will let your brain take a break. This often, but not always, brings perspective and a new approach to the issue.

If the problem is really serious, you may need to let it simmer for a day or so. I can’t tell you how many times I’ve gone to sleep with a problem and woken up with a novel approach. Not a solution, but a new way of thinking about it that leads, eventually, to a solution.

So, throwing in the towel, for the short term, is actually a viable problem solving technique. Running repeatedly into a wall is often a sign you need to take a break.



Choose an employer who treats you well during an interview

Dear new developer,

You may not realize it, but you have a lot of power during the interview. Sure, it doesn’t feel like it, but right now a lot of companies are seeking developers, and you are desired.

There are many many things to consider when taking a job, but one strong indicator of how you’ll be treated during your employment is how you are treated in the interview.

  • is the interviewer respectful
  • do they do what they say they are going to do
  • are they flexible
  • do they keep in touch

Basically, you will never have more power in the employer/employee relationship than you do when you are interviewing, because you have the most optionality (that is, you can talk to other employers with little to no friction). It’s definitely not the only thing that matters, but poor interview treatment indicates, in my experience, a general lack of concern which will lead to other unpleasantness.

If they don’t treat you right then, how will they treat you once you don’t have any other options.

Think about it.



Understand the business

Dear new developer,

Your code is written to further some end. It could be for academia, government, or, more likely, for business purposes. In all the cases, having a greater understanding of these overarching purposes will allow you to make smarter decisions and write better systems. However, just like in software development, business uses a lot of jargon.

It’s worth spending some time decoding that jargon. You may not understand every part of it (just like you probably don’t understand every piece of the system you are working on) but even a little can help. It can help you sift through possible solutions and connect with non technical staff.

For a very high level overview of how business and financial decisions are made, I can’t recommend the MBA Mondays series enough. From one of them:

If cash flow is positive for all periods, then you are done with cash. If it is negative, do one more thing. Divide your cash balance by the average monthly burn rate and figure out how many months of cash you have left. If you are burning cash, you need to know this number by heart as well. It is the length of your runway. For all you entrepreneurs out there, the three cash related numbers you need to be on top of are current cash balance, cash burn rate, and months of runway.

You can definitely find other sources for this information (I enjoyed The Personal MBA as well). These general purpose business books will give you a handle to have discussions with other people in the business. Have those discussions–at gatherings, in the hallway, at lunch. Take these opportunities to ask questions–people love to talk about themselves.

You don’t need to be an expert in the business your employer is in, but being even slightly familiar with it will give you a better understanding of how your technical decisions affect expenses and revenues.



Deep vs wide experience

Dear new developer,

You have only a finite amount of time, and the world is large.

Technology changes so often and so fast that it can often feel like there is not enough time. Here are two strategies.

The first is to focus on fundamentals. Yes, there’s a new javascript framework. But it will still have a way to represent data, it will still use algorithms, it will still store data durably, it will still have a build system. Learn these fundamentals for two different solutions and you will start to see patterns that will allow you to pick up new languages/frameworks more easily (because you can map back to an existing solution).

The second is to choose whether you want to go deep or go wide. Going deep is focusing on one domain or language and truly achieve mastery. This is a project of years and experience. This path will lead you to interesting jobs and big paychecks, if you pick the right area. If you choose poorly, you might have only a few employers to pick from. Working for a product company is the best way to go deep.

Going wide will mean that you never achieve true mastery. You will however, learn to pick up new skills quickly. You’ll learn to map between two dissimilar situations. You’ll start to see patterns across software development and business. You’ll always be more of a generalist than a specialist, and that will limit some job opportunities. Working for a consulting company is a great way to go wide.

Neither of these is a better path than the other, and you can, especially in your early career, switch between them. Try them both on and choose consciously.



Strong convictions, loosely held

Dear new developer,

When building a system, you’re going to be confronted with lots of decisions. Unless you are operating in a total vacuum, you’ll have to reach agreement with other people. This will lead to discussions and arguments, as all the people involved will bring their viewpoints and experience.

You should definitely participate, and bring your own experience and viewpoints.

However, everyone should pay attention to two things:

  • the usefulness of listening to everyone’s experience
  • the overarching goal to be achieved

The first is important because different experiences build a stronger solution, the same way a forest is more resilient than a field of wheat. But it’s also important because even if someone’s experience has no bearing to the problem at hand, if it is dismissed the person will have a harder time both contributing to the current problem’s solution (they won’t be bought in) and to issues in the future (when their experience might be more relevant).

The second is the right way to guide the conversation and to steer it towards success. No project or problem ever exists in isolation. It’s worthwhile to examine all the big decisions, and many of the smaller ones, in the context of the overarching goal. (Heck, there are some times when it is worthwhile to make sure you are working toward the correct overarching goal.)

When you listen to everyone and focus on the higher goal, good things happen. One especially good thing is that you may change your mind. The right way to do that is to argue as passionately as you can for your point of view (have a strong conviction), but not lose sight of the fact that you may be incorrect (loosely held). And if you are, then everyone benefits when you acknowledge the better solution and move forward with it.



Interviewing is a two way street

Dear new developer,

Interviewing is a two way street, and that means that you need to be evaluating your employer as much as they are evaluating you. Yes, you need a job, but your employer needs your skills. It’s also important to note that you’ll never have as much leverage with an employer as you do before you are an employee. You are going to spend a lot of waking hours working on behalf of this organization. Learn something about it.

Interviews are hard to do well. They are designed to extract as much information as possible from the candidate for the employer to be able to make a good decision. Good employers want the exchange to be bi-directional and will take steps to make that happen, whether that is publishing blog posts about the internals of the company or allowing plenty of time for questions or allowing access to individual contributors on the team.

Sometimes the biggest hints about how you will be treated come out in non verbal communication:

  • is the interviewer prepared
  • do things start on time
  • is it a real conversation or a grilling session
  • does the interviewer appear happy
  • do they do what they say they are going to do during the interview
  • are they flexible during the interview
  • do they respond to questions

All of these can add up to paint a picture about the company and the position. Note that none of these are related to the actual work you’ll be doing. That is important as well, but the context in which you do the work is crucial. If you are being paid $200k/year to do a job that makes you miserable, you will likely be unhappy. If you are paid $100k/year to do a job with a team and a project that you enjoy, you will likely be happy. (This assumes that you can live well on either $200k or $100k–feel free to double the numbers if that isn’t the case).

You will never be in a better position to leave a job than before you start it. That is the right time to make sure the information exchange is not one way.



Pick a no B.S. employer

Dear new developer,

You may or not may have the luxury of choosing where you work, but when you are looking for a job, steer away from employers that seem full of B.S.

What exactly is B.S. will vary for you. Some people can’t stand politics, while others can’t stand shifting priorities, while others can’t stand rigid hierarchies, while others can’t stand not knowing where they stand. It may take you some time to determine what you can’t stand in a work environment. But interviews go both ways, and when you are talking to possible employer, make sure you find out what their variety of B.S. is. (Unfortunately, all jobs have some kind of toil and drudgery.) You can do this by asking questions like:

  • what’s a typical day like
  • who makes decisions
  • what kind of projects do you do
  • what’s the best and worst parts of your job

No job is perfect, but by keeping an eye out for the particular forms of drudgery that you can tolerate and those you can’t, you’ll be able to find an employer that matches what you need and can offer.