Getting Started as a Software Developer

Someone recently asked me for advice around getting started as a software developer. I started writing a response, then realized I could turn it into a blog post (conserve them keystrokes), so here we are.

This advice isn't from a place of "this is what I did to get started" (although I am continuously trying to get better at all these things). This is more like "if I was interviewing someone for a software dev position these are the things I'd be excited to see them doing."

This isn't meant to be absolute advice, there are many paths to an enjoyable career in software development. Take whatever is helpful for you in your unique situation, leave the rest. Onward and upward.

Summary

• Ship
  • Blog posts, apps, components, pull requests, whatever
  • You don't need permission from anyone
• Write
  • Forces you to organize thoughts
  • Shares your thoughts with others
• Blog
  • Combines writing and shipping
  • Future you can reference your own posts
• Contribute to OSS
  • Another opportunity to "ship"
  • Code reviews are like free training from domain experts
  • Helps others
  • Grows your network
• Form Habits
  • Motivation fades, habits stick
  • Establish healthy habits/boundaries around work and side-work

Ship

When I worked at Microsoft there was this phrase I kept hearing: "always be shipping". Ironically, I didn't really appreciate that idea until I started working on side projects. You don't need to be at a big company (or any company) to ship.

You can write an app for the open web, host it on a CDN, tell all your friends and family on whatever social media platform you want, and experience the satisfaction and struggle of shipping something - all on your own, without permission from anyone.

It doesn't have to be an app either. It can be a blog post, a simple component, a small pull request to an open-source project... whatever, doesn't matter. The point is to put something out there, get feedback, iterate, and figure out what to ship next. Get the reps in on shipping and you'll gain invaluable experience.

Write

You have unique thoughts and ideas. Sharing them with others in written form lets others take their time to understand and build on those ideas. Writing lets you asynchronously coordinate with colleagues without requiring time-sucking synchronous meetings.

Not currently working with other people? Writing is still worth your while. Writing down your thoughts naturally helps weed out the bad ones: it's hard to clearly write out a half-baked thought. Writing helps you solidify your ideas and understandings.

Also, writing helps your future self. A well-written README allows me to almost immediately gain context when I come back to an old project I haven't touched in a while. If there is no README (or a poorly-written/sparse README) it takes a while to pick that project back up, and I don't trust it as much. Similarly, if I come across an open-source project without a good README or good documentation I'm less likely to consider using it or trusting it. Good writing instills confidence, both for others and for your future self.

Blog

A blog combines "shipping" with "writing", so it's kind of a win-win. And it provides value to others (a win-win-win).

A blog is your own personal learning archive - if you forget how to do something but you've written it down you can search your own blog on how you did it.

If you have a blog that you write to on any sort of rhythm then you'll be a better writer and shipper. It doesn't have to be that often, once a month, once every other month, doesn't matter. Just some sort of consistency.

And the posts don't have to be long, in fact the shorter the better. Get practice in being clear and concise. Convey the right amount of information that would be valuable, but no more.

Blog about whatever you are learning. That will help solidify your learnings while also providing value to others in the same stage of learning. Think of it like this, if I'm new to git a short blog post about "how to change a git commit message" is more helpful than an exhaustive post about "how to use git commit amend". Both posts have their place and purpose, but if you're learning git it's easier to write (and read) the former.

When I'm searching how to solve a technical problem and I don't find an obvious, concise answer amongst the first few results then I will write down the search words I used. Once I figure out the solution to whatever I was searching I will create a blog post with that phrase in the title or description or at least in the first paragraph of the post. That way future folks (including me) who face the same problem will find my post.

An opinionated tip about the blog: keep it simple at first... get the reps in shipping, get it out there, write a few simple posts, then iterate later. You don't need fancy server-side-rendered React components with a multi-megabyte javascript bundle and parallax scrolling effects and whatever else... at least not at first. You don't even need javascript at first. Just find a simple static site generator. I use hugo and eleventy for various static sites, both tools are fairly straightforward to use and produce static sites with excellent performance.

One more opinionated tip: don't put Google Analytics on your blog. Google's tracking code is in enough places on the web, it doesn't need to be on your site too. There are a lot of simple, lightweight, privacy-focused analytics options out there. I use fathom analytics and I'm a big fan of its simplicity and focus on privacy. (Note: that's an affiliate link - I'll earn some money if you use that link and you'll get $10 off, here is a non-affiliate link if you'd like).

Open Source Contributions

Contributing to open-source projects (sometimes called "OSS" for open-source software) is another way to "ship" and grow as a software developer. Make a pull request to a project you are interested in and get a code review from an expert in that codebase.

Just remember to read the contribution guidelines (usually in the README or in a CONTRIBUTING.md file) and be patient with maintainers. A lot of popular OSS repos are really only run by a few maintainers and they get a lot of contributions, so it takes a while to sort through all the issues and PRs. And smaller OSS repos are sometimes maintained by folks in their spare time (👋).

You can search topics on GitHub for repos you'd like to contribute to. Look for the "Good First Issue" label in any repo you find. Or check out one of the many sites trying to aggregate Good First Issues, like GoodFirstIssue.dev.

One last tip related to OSS contributions: if there is a company you want to work for (or are about to interview with) then find an open-source repo of theirs and make a contribution. Something like opening an issue for a bug or thoughtful feature request, or making a PR for a doc bug or some small bug fix. Then when you go into the interview you can say you've contributed to one of their projects. If I was interviewing a candidate and they did that then they would immediately stand out in my mind.

Habits

I've kind of laid out a lot of things to do in this post, and if you tried to do them all at once it would be pretty overwhelming. Start a blog, practice writing, ship stuff, and contribute to open-source. And maybe you've got a day job and a family and life is overwhelming as it is. That's why I say this isn't absolute advice - take whatever is helpful, leave the rest.

One thing that has been a huge help to me in terms of growing as a software developer (despite having little time/energy margin) is to form habits around some of these things. While motivation might fade, systems (habits) seem to stick.

I don't get particularly jazzed about brushing my teeth and flossing, yet I do those things each night before I go to bed. Habits are powerful like that.

So when it comes to blogging or working on side projects I have a pretty simple habit. Three days a week I wake up an hour early and go right to my computer to either work on a blog post or a side project for an hour. It's not much time per week, but if I stick to it that time adds up over the year. And the amount of learning and growing that happens in those 3-ish hours each week makes me a much better software developer.

A Quick Thought on Imposter Syndrome

"I don't know what I'm doing."

"These people are so much smarter than me."

These are thoughts I have fairly often... and for good reason. A lot of the time, I really don't know what I'm doing. But that means I'm in a good place to learn something new and perhaps bring some fresh perspective to something.

And the people I work with are really smart, while I'm just a run-of-the-mill dude. But that doesn't really matter. I still have unique knowledge and experiences that I can share with others that can be valuable. And so do you.

So if you ever feel like an imposter and you don't know what you're doing, that's ok. You're not alone in feeling that and your knowledge and experiences are still valuable. Keep learning, keep growing, keep creating.