Getting Started

I’ve been doing coffee chats with people doing the #100dev group lately. It’s been really interesting and the common thread among them is that they’re looking for what they should be doing to get into the industry.

I always point them to roadmap.sh because it’s amazing and the person running it has added sections for front-end, back-end, devops, and everything in between. There are even a few of them at are coming soon that cover things like AWS.

The other thing I tell them that they should be doing is posting to a blog. Learning out loud or posting things along the way as you grow is the best way to turn around at the end of the year and see 200+ examples for a prospective employer that you have the ability to have a problem, research, fail several times, and eventually get the result that you’re looking for. And on top of that you’re willing to share that journey with the public.

I hear people say “do something with open source” and get your name out there! That’s a way to go about it but it’s not the only way. I’ve been doing this since shortly before I left high school in 1995 and it’s been the same process over and over for the last 25 years…

Synthetic Mileage

You can only make so many mistakes on your own. It’s good that you’re making them because it means there’s a little bite to the information you’re cramming into your brain and because your brain wants to avoid pain it’s going to remind you the next time you paste a code snippet from Word that’s converted all your quotes to “fancy quotes” that cause your programming language to puke.

What I’ve been doing since 1993 is spend time in the common spaces where people are talking about their problems. And then watch for the helpers who come along and move them out of being stuck. What was the problem? What was the solution? Write it out in your own notes in your own words. You don’t have to understand either totally and it’s probably better that you don’t (that means that you’re stretching) but the rate at which you can see the problem/solution pairs when they’re not generated by you is so much quicker.

Document, Don’t Teach

When you’re writing in that blog (like I do here mostly), the goal should be to document what you did, not teach. If someone learns from your experience, great, but the bar is so much lower to get posts out if you’re simply writing down what happened. It happened. All the details are there. All you’re doing is reporting on them. There’s no boiling down, there’s no reformatting, there’s no building up a hypothesis, testing it, and then having a conclusion that wraps it up neatly. Just document what you did. Make sure you write about all those dead ends you ran into and what path eventually worked. I see you with those 25 tabs open with not-quite-right answers. What’s in them? How did you get there? Was it your Google query gone awry? Something else? Maybe you just clicked through links on each page you read until you decided you’d hit a dead end?