I keep having this conversation about how to break into the development world. Some of these people have gone to developer boot camps or spent years learning new skills. A lot of the advice seems to be the same, stop being a junior developer and learn how to contribute to a team.

What do I mean by stop being a junior developer?

I mean, a junior developer is someone that learned a few skills and is waiting for tasks to struggle through. They are hoping the next problem is like the one they’ve done recently, because this is all a bit overwhelming anyway.

I’ve been at this for 20 years, and things can be overwhelming for me any day of the week. The difference is that somewhere along the line I learned how to see the bigger picture and break down the problem into things I can understand.

For example, say I needed to authenticate users. Instead of finding a tutorial on how to authenticate users with the technologies I know, I start asking questions. “Do they want to be authenticated from Facebook or Google instead of giving us a password?” “Do we have a database on the site already?” “How many users will there be?” “What happens when someone gets into the system that shouldn’t be there?” Now I can start to make some decisions about the things that we need to use to handle the situation.

After that, it’s nice if I know possible solutions to the problem. If I don’t, though, I can still look for mid-level questions like, “What are the different ways to authenticate users?”, “How secure is my website?”, or “Is Facebook a smart authentication solution?” These types of questions help me bridge the gap between the problem I understand and the solutions I might need to understand better.

People aren’t taught this in the boot camps. They are given a specific problem with specific tools to apply and a team to deliver a solution. This leaves them feeling overwhelmed and lost when their trainers aren’t around. One unfortunate developer I spoke with today is going back to a boot camp almost 2 years after he first had his experience to refresh his knowledge. He hasn’t been able to do much more than a few side gigs with all the time and energy he’s put into becoming a developer.

That’s not to say that it isn’t difficult. It always is. Most would-be developers get lost between following a tutorial they found online and making something like that for themselves. A seasoned developer will actually learn how to do this a dozen times a year in a dozen different technologies.

How can I make this work easier?

I’m not sure that I can, it takes grit to get through the hard parts. Usually there’s some sort of motivation that has to keep the dream alive. Here are a few things that every seasoned developer I’ve met has learned to do.

Have an opinion. About how long is this going to take? Is this the right tool for the job? What problems are likely going to come up? You might not be right about these things, but seeing where you think you are helps you see the bigger picture.

What IS the bigger picture? People need to be able to see what parts are coming together and why they’re there. They usually need to be able to think about other ways they could have solved the problems. Or, things they could try if this doesn’t work out.

Know how to check your work. This could be learning to write automated tests or figuring out how to use a debugger. Often it’s how to engage another developer in a succinct code review. There are also a lot of tricks you can pick up for learning how to debug your code.

What are the basic building blocks of this project? One way to figure this out is to comment out a whole file and then bring it back to life one chunk at a time. When you get through this process, you’ll know how the building blocks are combining to make something bigger. You should also develop an opinion about whether that’s a good solution to the problem or whether the way things are organized is the reason nothing is working.

Learn to timebox. Timeboxing means getting a task done within a specific amount of time (usually an hour or two). I can spend hours on the smallest task. Junior developers generally do. I can often do a task in very little time as well. There is an art to knowing how to do things simply. Usually it means cutting out things you wanted to do but later realized were less important for the task at hand. It usually is pretty uncomfortable work, but it’s a sign of maturity that you’re willing to do it.

Find ways to stay interested. For me, this usually means I have a piece of paper next to my computer that I’m making lists or diagrams on. I need to make sure there’s something I can actually do at any given moment and not just some awful task that I don’t quite understand.

Learn as you go. Most of us can’t remember most of what we’ve learned. Once we are confident in our ability to code, we learn to forget quickly and not try and figure everything out first. We just work from task to task. If you met me for the first time and asked me about projects I’ve done, I might sound like a complete idiot. That’s because I’m actively forgetting what I’ve done and try to just stay focused on one thing at a time.

Make friends. It isn’t enough to learn how to code. Delivering working systems means working well with others. It also means having someone that can pair with you or give you new ideas when you’re stuck. Nobody said that you have to be smartest person in the room, you just need to be a dependable contributor to the team.

Embrace the supporting tools. You’ll need to learn quite a bit about the command line. You’ll need to learn your operating systems package manager. You’ll need source control. You’ll need to be able to edit files on other servers. You’ll need to be able to login to other servers. There’s a lot of little things that you’ve got to figure out how to do. You’ll need to learn all the tricks about your text editor or IDE. Make sure you’re embracing some of this all the time. Make sure you have a go-to person around for this kind of thing until it gets easier (so you don’t lose your motivation when something like this gets in your way).

Meet with the community. Local users groups are incredible at demonstrating the bigger picture. You’ll see the same problems differently. You’ll be able to pull someone aside and discuss something you’re having a hard time and get their take on things. The burden of addressing all there is to handle is a lot easier with a piece of pizza and drink in your hand.

Keep moving. If you’re in a job for too long, you may want to move on. We all plateau when we’ve been at the same project too long. If you’re able to continue taking on new challenges and projects at the job you’re at, you don’t have to change jobs. It’s just important to have challenges that push you forward. It’s not just the main day-to-day work that you need to improve, but also confidence with the supporting tools. A new project means reacquainting yourself with the uncomfortable.

Learning to code can be a rewarding and worthwhile thing to do. It’s not easy, and it’s not done very quickly. Just remember that all those tutorials and quick answers on StackOverflow aren’t your quickest path to becoming at least a mid-level developer.

Thanks to Brian Broderick for notes on this post.