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 meetup.com 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.

Sincerely,

Dan

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.

Sincerely,

Dan

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?

Sincerely,

Dan

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.

Sincerely,

Dan

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.

Sincerely,

Dan

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.

Sincerely,

Dan

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.

Sincerely,

Dan