Manage your career

Dear new developer,

You have to manage your career. If you don’t, no one else will.

This means three things.

  1. Know what you want.
  2. Communicate that.
  3. Make moves toward it.

Let’s talk about each of these in turn.

“Know what you want” is the hardest part. Because we are lucky to live in a world with lots and lots of options and opportunities. You can focus on one of a 100 different kinds of software development. And that is to say nothing about other related opportunities (product management, teaching, engineering management, etc) where your developer skillset will help set you apart.

My advice here is that you should pick one and follow it while it is interesting. If you have fundamental skills (problem solving, learning, listening, typing), you’ll be able to transition between areas. It may not be an easy transition and you may pay a price in terms of compensation or status or ego. You may have to spend precious time outside of work getting up to speed. But no decision is permanent. So pick what is interesting. Commit to it for a period of time (six months, a year). Realize that you can change (though, as mentioned above, that may have a cost), so commit.

“Communicate that” because if you don’t talk about what you want, you will have a hard time getting it. This is because people generally want to help, but need to know how to help. So, communicate your desires to your manager, to your communities, to your friends, to your co-workers. You don’t need to mention it every day, and you should tune your communication to your audience.

For example, if you are a web developer and want to be database focused, then volunteer to work on database projects. Mention it to your manager at your 1:1s. If there are people that are doing database work at your company, ask if you can meet them regularly.

This doesn’t mean you can avoid the web development work for which you are paid. What it means is that you can tune your work environment toward your interests. Not immediately and not at all companies, but often.

“Make moves toward it” means you aren’t just talking about your desired direction, but you are actually taking steps toward acquiring skills and doing that work. To expand ont the web developer -> databases example, take action. Present on databases at a meetup. Do a brown bag on databases at your company. Read a book about databases. See what you can apply to your current work.

However, sometimes you can’t make a move internally. Maybe the opportunity just isn’t there. Maybe the company needs you in your current spot. You may have to switch jobs. That’s OK.

Don’t burn any bridges, but when it is time to move on, move on. Find a new job with your new skills and knowledge, hopefully from the community you’ve found. Give notice and head off to a new adventure. (Don’t forget to connect to colleagues on LinkedIn.)

What’s the alternative? Floating through your career, buffeted from opportunity to opportunity, or worse, from job you’re afraid to lose to another job you’re afraid to lose.

That doesn’t sound like much fun.

Sincerely,

Dan

Contextual advice for new developers

Dear new developer,

A few months ago I asked Marie Chatfield, a front end developer and advice columnist, what her one best piece of advice for new developers was.

She wrote a great response. From the post:

For the self-taught programmer: I am amazed at your dedication and perseverance and ability to learn from different resources. Remember that other people have valuable things to teach you, too, and seek out trusted mentors or role models when you can. You will never stop learning in this industry, and you have shown already that you are ready and willing to put in the work. That’s going to take you far.

For the one who doesn’t see themself represented anywhere: I am so glad that you are here. I hope you can stay here for a long time. I hope you find communities that make you feel welcome and safe and included. You get to make the right choices for you and your health and safety, even if it makes others uncomfortable or disappointed. You don’t owe increasing the representation of a space with your presence to anyone. You belong here, and you should get to focus on doing the kind of work you want.

What I like most about this is that she gave contextual advice. New developers share many characteristics but are by no means a homogeneous group. The bootcamp grad who was a marketing guy previously is different than the computer science graduate who is starting her first job after college. They both differ from the kid who has been coding since they were twelve. I write these letters from a certain perspective, but know that everyone will read them from their own place.

I really also appreciated her advice to everyone:

 

  • It’s okay to fail. Everyone makes mistakes.
  • It’s okay to look things up. You don’t have to remember everything to be a good developer.
  • Everyone is nervous about interviews. They’re kind of awful. But you get through them.

 

I asked Marie for one piece of advice, but she gave more than ten. I enjoyed reading her advice to new developers and I hope you will too.

Sincerely,

Dan

PS She also has written some other great posts.

Context is king

Dear new developer,

I put this image in almost every presentation I do.

pumpkin-boat

There are two reasons.

  1. It’s a striking picture, and funny.
  2. It reminds me that context is important. In some contexts, a pumpkin is a decoration. In others, food. In others, a frickin’ boat.

On that note, I recently posted my letter on admitting weaknesses in a shared slack. Some of the feedback was that this would be counterproductive to your career if you’re a minority or female.

Whenever you get advice, whether written or verbal, it is always worth considering the source. Here’s some context for me: I’m a white, heterosexual cisgender male. I have been a developer for 20 years. I have worked in the metro Denver area for my entire professional career. I have worked about half of my career in consulting companies and half in product companies. I have worked about half of my career as a contractor and half as a full time employee. Though I have worked for companies as large as Oracle, the vast majority of my experience is in companies with under one hundred employees.

What that means is that if you are looking to join Facebook, or if you are a female person of color, my advice may not be useful. While I still hope you find some nuggets of usefulness, some of it may be less helpful.

You wouldn’t ask a doctor for legal advice or a developer for medical counsel. It’s always worth considering who is giving you the advice and where they are coming from.

Sincerely,

Dan

Are you ready to work remotely?

Dear new developer,

Remote work is fantastic. You avoid a commute, have control over your work environment, and save money on lunches. However, it has downsides. You need a fast internet connection, you must be disciplined, over communicate and stay on task. You have to be OK with relative solitude.

My desire to work remotely has changed over time. Frankly, for my first job, there’s no way I would have been happy working remotely. I enjoyed the collaboration, the camaraderie, and a place to go every day where there were interesting people. Even now, with Slack, Zoom and other modern tools, I’ve seen some new developers have similar concerns.

I do think that 100% remote work is different than “work from home once a week” or “work from home when you need to”. 100% remote work requires a different workflow, communication mechanism and concept of availability than those other options. Both of the latter options are really about providing flexibility and showing trust. They are great, low cost benefits for any software company to provide to developers.

Here is a one question test for anyone considering remote work. You can ask yourself this question and if the answer is yes, a remote position will likely work well for you. If the answer is no, then I think you’d be happier with an onsite position. By the way, some people are never going to want to work remotely for a variety of reasons, and that is no big deal.

That question is: “Are you comfortable asking a dumb question in public?”

You must ask questions that appear dumb when you get up to speed in any new company. Developers of all levels do this. Often it’s two levels of questioning. The first is “who can help with this?” and then the second is the actual question.

In a remote company you’ll have to accept that you are “interrupting” people and/or asking questions into a Slack channel. I have observed that both of these are more difficult when I can’t see the mental state of other people (as you can in an office).

You’ll need answers. So you have to be prepared to do ask these kind of questions, in public or interrupting someone you think might have the answer, over and over for the first couple of months of your remote job. Public questions are better for the team but harder on my ego.

If that thought of asking basic questions in public makes you uncomfortable, congrats, you’re human. But if it makes you want to run away and hide, then perhaps you aren’t ready for remote work. If you are interested in the flexibility and freedom of 100% remote work, wait a few years, practice asking questions and internalize the fact these kind of questions may feel dumb, but actually are just part of the process at any job.

Sincerely,

Dan

A bunch of career advice from a new developer

Dear new developer,

This post has a lot of great career tips including how to select companies to apply to, what to do in an interview if you don’t know the answer to a question, and how to challenge yourself in a new job. This piece of advice in particular resonated with me:

Show how you think

Most interview questions are there to see how you think. So show that! Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc! Be vocal, and ask clarifying questions. That’s part of being a good developer after all!

When I was hiring, especially for newer developers, I really wanted to hear how people thought through a problem. That process is important in two ways beyond actually solving the problem. The first is that it shows how you handle something tough that you haven’t encountered before (which happens almost every day on the job). It also shows an interviewer how you communicate. Since a lot of the challenge of building software is communication, learning how potential team members do it is crucial.

The whole post, “The Career Advice I Wish I Had” is worth a read.

Sincerely,

Dan

How to start blogging

Dear new developer,

I was asked about how to start blogging during the Q&A portion of a talk I gave. I had offhandedly recommended blogging as a great way to make connections and to be both credible and findable (locatable?) when looking for a job.

I started to spout off an answer using WordPress, and the questioner said “what about medium?”. And I stopped short. The correct answer is was “whatever is easiest”. I realized that this needed a bit more explanation, hence this letter.

So, the first thing to realize is that almost no one will read it, especially at the beginning. Why would you write if no one will read it? Well, to clarify your thought, to provide a written record of what you’ve done, and because, if you keep at it, Google will find it. Google is great at the long tail, so if you write something that is of interest to anyone, eventually people will find it.

Some numbers. This blog had the following stats for the first six months:

  • Sep: 8 posts/5 visitors
  • Oct: 11 posts/20 visitors
  • Nov: 6/15
  • Dec: 9/219
  • Jan: 8/221
  • Feb: 9/223

For the first month, I wrote more posts than visitors! And for the first three months, I had 25 posts and only 40 visitors. If you aren’t ready and willing to commit for a fair bit of time, your blog will become one of those sad blogs that I occasionally run across with three great posts, then one post six months later with the title “I haven’t posted in a while…” and then nothing.

Now, if that’s what you want, that’s ok (everyone can blog for their own reasons) but if you are looking for credibility and locatability, well, that kind of blog accomplishes neither.

So, commit for six months. I do this by:

  • writing out 20-30 titles of blog posts I want to write. If I can’t come up with that many blog post titles, I am not passionate enough about the topic to stick with it. Better to find out before investing the effort.
  • Watch for interesting concepts and mailing myself whenever I have a possible blog post idea. Then I can search my email when I have time to write but no ideas. (You can do the same with a spreadsheet, doc, trello board or whatever. Just capture the inspiration when you can.)
  • Make some posts easy by doing excerpts or commentary (about half of the posts on this blog are excerpts or guest posts).
  • Settle on a consistent schedule. No need to announce it, though. (Some people do it daily, for which I have mad respect.)
  • Write blog posts ahead of time and schedule them out. When the muse is present, it can be easy to jam out a few posts. When the muse is absent, it is a relief to not need write, but still be able to deliver to previously mentioned consistent schedule.
  • Realize that some of the posts will be mediocre. It is embarrassing to put out poor content. Don’t do that, but some posts will be better than others. Volume is key, and the longer you do it, the better the posts will get.

As far as the actual writing tool, use whatever is comfortable and easy. That may be wordpress.com, may be medium, may be netlify + hugo. Whatever it is, don’t let the technology get in the way of the writing. Especially if you are a developer, it can be more fun to be in weeds tweaking your blog deployment pipeline (at least, that’s really fun for me) but that will distract you from the main goal, which is to create good content.

My final tip is to share on online communities. Don’t only share your own work, but definitely share it. Which community? Well, find out where your people are. There are a lot of communities out there, whether tech specific like Hacker News, general purpose and public like Twitter, or focused and private, like the HangOps Slack. (Sharing is how I was able to break through in December above.)

Doesn’t matter what it is, as long as you are engaged in the community and the topic of your blog is of interest to the community. These communities are well aware of the traffic they can bring and are often wary of newcomers. I have gotten a few scoldings when I posted things that I thought were interesting, but were not in line with the community. That’s OK, just accept the community judgement, acknowledge the mistake, and do better.

Blogging is a great way to amplify your voice, display your expertise and share your knowledge. Set yourself up for success when you start one.

Sincerely,

Dan

On surviving your first year as a developer

Dear new developer,

This post covers some great tips on getting through your first year. It starts off ominously:

The first year as a programmer is one of the most frustrating things a homo sapien can experience. You’re thrust from the world of ambiguous human communication into the icy waters of cold, hard correctness. There is no compromise with the machine. It does exactly what you tell it to, no more, no less.

But then moves to some good advice, about advice:

There are very few absolutes when it comes to practical programming. A Technical opinions of developers are based on their experiences, the books they’ve read and the technologies they happened to work with. No one does a thorough survey of the technology landscape before declaring their support for a given tool, application or methodology.

This is so true. Everyone’s opinion is path dependent. I was a MySQL user for years and thought it was the best open source database, until a chance comment from someone I was chatting with at a meetup (see, you should attend a meetup) mentioned that PostgreSQL has transactional DDL. That is, you can alter a table as part of a transaction, and they roll it back. (Happy to report that MySQL has made progress on this, though I don’t believe they are at feature parity yet.) If I hadn’t run into that meetup participant, it is unlikely I would have learned that nuance.

Multiply that experience by the hundreds of decisions a developer makes every year based on their knowledge, their problem space and their work environment and you can see how different advice can be. And to be fair, how it can all be valid, based on context.

The post also covers ego-less coding, what to learn, and the joy of bug hunting. The whole post, “Survive your first year as a programmer”, is worth a read.

Sincerely,

Dan