How I prepared for my first dev role, and how I didn’t freak out…much.
Starting a new job is always a scary step. This is multiplied by a thousand when you are starting in an industry very unlike anything you’ve experienced thus far. You see, before taking the plunge into computer science and software development in the Spring of 2021, I was an actor. Of course, because of the nature of the acting trade (namely there being little to no sustainable income), I’ve worked many different jobs. However, these jobs almost uniformly included talking to customers or involved some other soft-skills interaction. Save for the pressing the GO button on a lightboard and some light troubleshooting of lighting fixtures, I’ve never been paid for my technical aptitude. This all changed after I was offered a role as a software developer at a mid-size moving company that has lofty goals of transforming an industry.
It is the night before I begin my new role as a software developer, and to be honest, I could not be more terrified. I’ve heard of imposter syndrome of course, and all of the self-doubt that accompanies the condition, but I have not had the pleasure of experiencing it that deeply as I’ve progressed through the program at OSU. Well, tonight I can confidently say that the syndrome has hit…hard. Due to this, and the need to calm my nerves, I’ve decided to use my first blog post to lay out what I have done in order to prepare for my first day and the mindset I hope to cultivate as I get oriented to the company. So, strap in and listen to the ramblings of a junior dev on the verge of jumping off the precipice…
Mindset
I’ve read a lot about preparing for life as a junior dev, and the one thing that repeatedly jumps out at me is having the right mindset going in. Some senior devs complain that newbies think they know everything, and that the new guys or gals always have opinions on what the best technology to use, how to use it, and why to use it. These opinions often come off as snarky or cocky to the seniors that have been around awhile and can really hamper the teaching process. Fortunately, I don’t believe I will have that problem. Being new to the industry, I know my place, and that place is to listen and shut up. I am self-aware enough to know that I know very little about how the codebase works, and when a senior tells me something is the way it is, then I assume it is for a very good reason. This is where my second goal comes in: asking very dumb questions.
Going into the office tomorrow, I plan on wearing my ignorance proudly. I plan to make it very apparent that I am the new guy on the block, and despite being one term away from graduating, I know that I am far behind the people that have been working on this codebase for years. These people are the people that I should be learning from. I must not be afraid to ask questions that might seem dumb to the seasoned programmer because how will I ever learn if I do not ask questions. Pretending to know the answer to something or pretending that I have experience with a new piece of tech will only disappoint my team when I inevitably walk to their desk, hat (laptop) in hand, and ask them if they can explain something to me. My main job is to listen without judgement and ask questions in a way that would glean the most knowledge from the answer I am given. Below is a list of the types of questions that I will ask when given a task.
- “When would you like this delivered by?”
- “If you were to start on this, what would be the first thing you would do?”
- “If I get stuck, how long should I take to try to figure it out?”
- “If I get stuck, is it okay if I come to you for help?”
- “What is the ultimate end goal of this functionality?”
- “What will it look like when I have finished the task?”
- “How can I test the work out as I progress and when I finish?”
- “How would you like my debugging process presented to you?”
Hopefully with these questions in mind, I will set myself up for success without annoying the senior devs too much.
Technology
Equipped with the right mindset, I then focused on brushing up my computer science concepts to ensure that once I am presented with the codebase, I won’t be a deer in the headlights waiting for the car to crash into me. I will be able to identify the core points of the codebase and decipher what the code is supposed to be doing. So, below is a list of things that I did to ensure that I am ready to tackle technical problems.
- Looked over class projects, and ensured I understood every part of them
- Reviewed git and the common git commands such as branch, push, pull, commit
- Leetcoded the fundamentals of the languages that I said I knew during the interview process. It would be foolish not to know how to create a for loop in a language I claimed I was proficient in
- Listened to tech podcasts to hear how people in the industry spoke to each other about technology. A shared vocabulary goes a long way in communicating effectively
- Gathered as much knowledge about the company as I could. This helped get some idea as to what they may want to do in the future in terms of the tech projects I might work on
That’s pretty much it. Fortunately, the other devs know that I’m new to the industry, and from what I gathered they do not expect much for a junior in the first week. So I will listen as much as possible, soak in what I can, and ask questions when I get stuck. Wish me luck!
Leave a Reply