Dark Theme | Category:
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.
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!
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:
- Competence in the shell – you don’t need to be a shell-scripting savant; just the basics will do. Knowing how to navigate through the file system, list files, create a file, delete a file, etc. will prove very useful very fast. When it comes time to access a server via SSH, you’ll be glad you’re comfortable operating in the shell.
- Multiple IDEs – a tip I received early on from one “learn to code” article or other was to try out multiple IDEs and get familiar with their similarities and differences, options they offer, optional plugins, and themes. This makes switching IDEs easy if your job uses a different one than your boot camp, or if you want to use language-specific IDEs like PHPStorm, PyCharm, etc.
- Git skills – create a GitHub account and start getting comfortable making branches, committing and pushing code, and cleaning up any git-related mistakes. You won’t experience a whole lot of advanced git maneuvers on your own such as merge conflicts, rebasing, etc., but the sooner you start to get a feel for the process the less overwhelming it will feel when you do run into those things. Visualizing Git is a great tool for my visual learners.
- VIM fluency – I know, I know, but I procrastinated when it came to learning VIM and I lived to regret it. If you do get stuck in there, it’s i to get into edit mode (i for insert), esc to get out of edit mode, and :wq to write (save) and quit (or just :q! to gtfo without saving). Just play VIM Adventures and you’ll acquire the skills you need in a fun, low-stress, low-stakes way.
- A rubber duck – Rubber-ducking is real, and it works (not all the time, but often). My rubber duck is a metal flying pig that doubles as a slightly crooked cell phone holder, but yours can be anything you want – an action figure, a bobblehead, your cat, etc. I’m a firm believer that your rubber duck should bring you joy when you see it, to help cancel out the frustration you’ll probably be feeling when you need to use it.
- A package manager – package managers are so useful for installing and managing all the different tools you’re going to need. Homebrew is a popular choice for Mac and Linux, and Chocolately is great for Windows users.
- The Book of Secret Knowledge – this GitHub repo is absolutely overwhelming at first, but such an incredible resource and so much fun to explore.
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.
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.
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.
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.
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:
- Write down one new thing, big or small, that you learn every single day. You can write it down physically in a notebook or type it somewhere, but keep a written record of what you know now that you didn’t know yesterday so that you can physically see the progress you’re making, or feel it if you use braille, or hear it if you use a screen reader.
- Determine what non-technical skills you bring to the table. Think about what soft skills or transferrable skills you have that you’re proud of. Even if you can’t see how they’re directly applying to your role, rest assured that they’re informing how you think, learn, build, and interact with code and other people, and that developing those skills throughout your life has been in service to your journey so far.
- Help someone else. It can be someone at work (which may be difficult in the very beginning when you’re still getting up to speed), someone in a new cohort at your coding boot camp, someone on r/CodingHelp on Reddit, or even anonymous readers by writing a post on dev.to or medium about what you know best. You may not feel like you have anything to contribute that hasn’t been said better by more experienced people, but the thing is, there are people (myself included) who can have something explained to them 10 different ways and still not get it until finally the 11th explanation clicks. Get out there and be someone’s 11th!
- Talk it out. Maybe you have a tight team at work, or you stayed close with your boot camp cohort, or you joined a Slack study group during the pandemic. Let your support system know you’re struggling with confidence, and give them the opportunity to build you up. You know you’d do the same for them.
Note: For me personally, this works best with people who are familiar with and can speak knowledgeably about my work. I appreciate the encouragement from my husband and parents, of course, but since they love me/can’t be objective, my bad wolf can sometimes drown them out, whereas my tech lead can point to specific, objective examples of my growth and progress.
Bite-size morsels of wisdom to munch along any excursion:
- Keep a water bottle at your desk and fill it up as soon as it’s empty – this will ensure you stay hydrated and get some movement regularly throughout the day.
- Get a keyboard cover! They’re less than $10 on Amazon and worth it for the peace of mind alone.
- Invest in blue light blocking glasses. Your eyes will thank you!
- When you start comparing yourself to others (because it’s inevitable, especially if they started at the same time you did), repeat after me: “They’re on their journey and I’m on mine. They have their strengths and weaknesses and I have mine. This isn’t a race or a competition. We all bring unique and valuable gifts to this party. We learn from each other and make each other stronger.”
- Keep your notes (API keys, steps to do things you only do once in a blue moon, pretty much anything you need to keep track of) where you can access them from multiple devices. For example: your own personal DM on Slack, a OneLogin Secure Note (especially handy for sensitive info), Google Drive, OneNote, any note-taking app of your choice that syncs to multiple devices.
- By all means do personal projects and study/practice on the side, but maintain non-code-related hobbies as well to avoid burning out.
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!
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]