Dark Theme | Category: Code, Educational

New Software Dev Survival Guide

Hello Gentlefriends and welcome to the journey into tech! My name is Gina, and I’ll be your guide on this expedition into your first programming job, sharing with you the wisdom I have gained in my first 2.5 years as a professional programmer.

Guidebook:
Pack Your Bags – a roundup of useful skills and resources
Follow the Signs – why reading the documentation is actually important
Don’t Stay on the Beaten Path – how to learn on the job
Take a Hike – how to handle getting stuck, and when to ask for help
Use the Buddy System – notes on mentorship
Encountering Wildlife – how to deal with imposter syndrome, really
Trail Mix – quick tips that go beyond your first programming job

About Your Guide

Allow me to introduce myself. I started out, as most folks do, with self-teaching code using free online resources like Codecademy courses and YouTube videos. Then I worked for a year as a Project Manager at a boutique web design company in which the developer served as my very first coding mentor. In 2019 I enrolled in a 12-week full stack web development boot camp, followed by a 1-month internship. I then joined a local late-stage SaaS startup as a Tech Support Engineer in late 2019, and in September of 2021 I was promoted to Jr. DevOps Engineer. My current mission is to learn as much as possible about infrastructure as code (IaC), site reliability, automation, and architecture best practices – and, of course, to lead all of you safely through the forest of Getting Started in Tech!

Pack Your Bags

It’s always good to be prepared. There are some things I wish I’d known to pack when I first set out, and some things I packed that proved especially useful. Here are those things:

a river in the foreground with mountains in the background

Follow the Signs

The trail we’re following is well-marked by those that have come before us. Take advantage of the signs they left behind, from documentation to README’s, examples and comments in the code, and especially error messages. Many new developers start out in tech support/QA roles, so getting comfy with error messages early will give you an advantage and you’ll feel more comfortable and capable when you land that first job. You’ll also find it easier to orient yourself in an existing codebase – even one that’s written in a different language or framework to ones you’re familiar with – if you’re in the habit of reading documentation.
Note: I don’t mean reading every line of the documentation from A to Z, because that would be a very tall order indeed. I mean familiarizing yourself with the table of contents so you know what’s in there, and using it as your first line of inquiry when you come upon something in the code that you don’t understand or want to learn more about.

When you’re early in your career, no reasonable person will expect you to be able to dive into code that is brand-new to you and start fixing bugs or building features with no training or support.  Reading the documentation is just one resource at your disposal that will provide a solid foundation for the other resources, and it is like reading the back of a book before you buy it: it’s not going to tell the whole story, but it will give you a good idea of what you’re getting into and what to expect along the way. Even if you don’t understand everything you read, it’s important to put forth the effort. You will of course still need to ask questions of your more experienced colleagues; the goal is to avoid wasting their time by asking questions that you could have answered yourself with just a bit of reading. If you can reach out to someone and say, “My question is X, I looked at the docs here, but I still don’t understand why they said Y or how they explained Z,” you’re golden.

Don’t Stay on the Beaten Path

On this particular journey, side quests are highly encouraged. While you’re strolling down the trail, you may notice a narrow path leading off into the undergrowth. If it intrigues you, take it! Don’t worry about taking longer to arrive at camp each day, because you’ll arrive with valuable information, knowledge, skills, tools, and resources you would not have otherwise come across. When it comes time to sit around the campfire, you’ll have different stories to share. You’ve heard that everyone learns at their own pace and in their own way, and that holds especially true in programming – and that learning doesn’t stop just because you’re programming professionally. Many companies even build in time specifically for personal development. For example, my first company had an expectation of six hours of mobbing time with your team and two hours of individual research and development time per day.

If your company doesn’t set those expectations, make sure to ask about deadlines so that you know how much time you can devote to exploring those “what happens if I change this” or “that sounds cool, tell me more” types of questions you encounter in the course of your everyday work. It will probably vary: some days you’ll be so busy with focused work that you may not even have the time or energy after work to look into that cool-sounding tool someone mentioned in passing; other days you might finish your assigned tickets before lunch and have the rest of the day to experiment in your local environment, or you might need something productive to fill your time with in the event that you’re stuck on a ticket and can’t get help right away.

You’ll probably have a long list (definitely keep an actual list so you don’t forget) of topics and tools and side projects you want to dive into, and it will grow faster than you can get through it. That’s okay! If you need help prioritizing, ask your manager what will be most immediately beneficial for you to learn, or ask a more experienced colleague what they wish they’d studied earlier.

lush green hills with blue mountains in the background

Take a Hike

This expedition is challenging! You will encounter obstacles, and sometimes you will hit a wall and you won’t see a way around or over it. It’s going to look like the end of the line, even though it isn’t. My first coding mentor told me that when I get well and truly stuck, the best thing to do is walk away, have a beer, and come back to it later. The idea is to get some space from the problem, clear your head, lower your inhibitions so that you’re not overthinking the answer, and come back with fresh eyes. That’s still okay to do on the job! Maybe not the beer part, depending on where you work, but the principle of the thing: step away from your desk, do some stretches, meditate, scream into a pillow, and come back to the problem when you don’t want to set your computer on fire.

If you’re mobbing with a team and everyone’s stuck, or you’re just feeling overwhelmed by all the information coming at you, it’s okay to say that you need to take five or ten minutes to regroup. If you’re an individual contributor, be mindful of your deadlines but don’t use them as an excuse not to take a breath when you need to. The truth is, it’s possible to reach a critical point where you’re so frustrated or burned out that it’s actually counterproductive to continue banging your head against the problem; you’re just wearing yourself out more without getting closer to an answer, and you may not even have the capacity to absorb the lesson if you ask for help. Put on your favorite song and have a three-minute dance party to reset.

Speaking of getting stuck, a lot of new developers want to know how long to stay stuck before asking for help. Some companies, especially ones with a lot of experience hiring people early in their career, will actually have a process around this, so it’s okay to ask if yours does. If it doesn’t, then it really depends on the urgency of the task and the timeframe in which you have to complete it, plus the availability of those who could help you. If you have a ticket that needs to get done by EOD and it’s noon, but the only person who can help you is in a different time zone that’s three hours ahead, I would at the very least give them a heads up that you’re going to bang your head against a wall for another 30 minutes and then you’ll probably need their help. If you don’t have a definitive deadline and the person who can help you has a lot of availability, you can afford to exhaust more avenues of inquiry. As much as possible (time allowing) do your due diligence first: search documentation, Google, Stack Overflow, all that fun stuff.

Keep in mind that you can ask for different types of help, from “I need a subtle hint about only this one confusing piece” to “I need to be hoisted in the air and carried like an infant through the valley of shadow and doubt”. Over time you’ll start to get a feel for “how stuck” you are, and based on context, how much hand-holding you will or won’t need.

Use the Buddy System

It’s dangerous to go alone! Take a buddy. In my experience, you don’t need to stress about finding a mentor. Most people like helping other people and sharing their knowledge, and the mentor-mentee relationships I’ve had have arisen organically. Someone more experienced will say, “If you ever have questions, feel free to ask” and I will respond: “Are you sure you want to make that offer? Because I will 100% take you up on it.” I have never had someone reply in the negative at that point. Conventional wisdom states that you should know up front what you want from a mentor so that prospective mentors can decide whether they can commit to that. If you already know and you want that formal relationship, great! If you don’t know yet what you need out of a mentoring relationship, that’s okay – you don’t need to wait to find a mentor until you have it all figured out. You can start out informally, just asking questions as they arise, and figure it out from there.

For me personally, my mentor is a last resort, someone I can go to when I’m stuck and truly can’t see a way forward, or when I need to know why and not just how. Sometimes a quick exchange via Slack is all that’s required, and sometimes I need to ask for an hour on their calendar to pair program through a sticky code problem. A lot of the time, just the act of writing out my question and what I have tried so far will reveal new avenues I haven’t yet pursued, or I’ll even figure out the answer before I hit send. It does help if your mentor is at your company because you can ask specific questions and work on code together without violating any non-disclosure agreements, but they don’t have to be. You can also have multiple mentors by area of expertise: I have a mentor on the DevOps side and the Development side.

Ultimately, the most important thing is finding someone you feel comfortable with so that you can be vulnerable and admit when you still don’t understand something. If you feel like you can’t press for deeper answers or a different explanation when something isn’t clicking because the person will get frustrated/annoyed/etc., it isn’t going to be a productive relationship.

a field full of trees with mountains and blue sky in the background

Encountering Wildlife

Hostile wildlife is native to this area, and sooner or later you will encounter your Bad Wolf. That’s the name my tech lead gave to the voice in your head that tells you that you suck, you’re stupid, you don’t know anything, you can’t do this, you’ll never learn that, etc. There are going to be times that you are absolutely mystified that you managed to get hired, that you’ve managed to keep your job, and imposter syndrome/your bad wolf will have you fooled into thinking that your boss has no idea how incompetent you are and if they ever find out you’re gone-zo. Here are my best tips for fending off your bad wolf and actually dealing with imposter syndrome:

Trail Mix

Bite-size morsels of wisdom to munch along any excursion:

Thus concludes my guide to getting started at your first job in tech. Congratulations on embarking on this exciting journey, and I wish you well on your merry way!

</ XOXO>

Enjoy my content and want to show your appreciation? You can share this post, pay it forward by teaching someone else, or buy me a coffee!

[Photo credit: All photography in this post is my own]

Back to the Blog