It’s official: I am an employed software developer. It’s been official for a little bit now, but I started work this week, so now it feels real.
I’m working for a consulting firm, but will be spending most of my time onsite at a client, so I actually somewhat had two first days this week. I’m not going to go through a blow-by-blow account of the week, but I do want to share a few tips and thoughts from my first week.
Setting Up Your New Dev Environment:
Many (probably most) developers get new computers as part of their job. I was given a brand new MacBook Pro (the kind with the touch bar … I’m super excited about that) and had my whole first day to set it up. Here are some thoughts about that:
- Know what you need. For me, I knew I was going to need Node, git, a good terminal (I like iTerm), and my favorite text editor, Sublime Text (I have also since downloaded VS Code, which has a better built-in terminal, but I prefer Sublime … and not just because I can switch between files using the Touch Bar). Because I am going to be doing end-to-end testing of a website, I also wanted to make sure that I have all of the latest browsers, which also involved downloading Oracle’s VirtualBox so that I could install Microsoft Edge.
- Have a guideline to help you with the installations. I used two things to help guide my through the installation process. One was an article written here on medium by my friend and fellow Fullstack WDF Grad, Trevor Storey, about how he set up his machine from scratch. The other was a workshop from Fullstack Academy about setting up your dev environment in preparation for the bootcamp. Between those two resources, I was able to figure out how to set up the things I wanted set up with minimal struggle.
- Know what your job requires. At Fullstack, the recommended code editor was VS Code, and I was one of very few people using Sublime. When I went in for my interview with this company, I asked some of the devs what code editor people use, and I was told that people just chose their favorite editor. This is probably the norm, but be aware that your company may have a preferred editor. They may want you to use yarn over npm (my company seems to use both for different things). One of the first things I had to install was nvm so that I could switch between node versions. The more information you can get upfront about what you’re expected to be using, the easier things will be later on.
What To Do If You’re Not Busy:
Monday and Tuesday were spent in my company’s office, and I spent that time setting up my computer, studying up on some things I wasn’t 100% familiar with, and getting to know the company. Wednesday was my first day onsite at the client … and it was also my first day with not much to do. I haven’t been assigned to a project yet, so my first few days were not really full of things to do. Here’s what I did:
- Got myself set up. I had to sign up for a BitBucket account and send that info to my boss so that he could get me access to our team’s repos. Once that was done, I followed some instructions written out by one of my awesome new coworkers to get myself set up with our codebase and running whatever I needed to be running (I’m still having some trouble with that, but hopefully once I start working on a project I’ll get everything figured out).
- Starting looking at helping out with a project. One of my new coworkers knew I wasn’t working on anything, so he asked me to work on something he had on his plate. Unfortunately, I got bogged down on something stupid and didn’t get as far as I wanted with the project, but I may try to go back to it if I finish the testing I’m working on now and I have some time.
- Studied the codebase through testing. A large part of my job, at least in the first few months, will be testing, so I decided to look at the tests that already existed in the codebase. I started trying to break tests and writing additional tests when I thought they were needed. I even fixed a few broken tests! I still don’t feel like I fully know what’s going on in the codebase, but I do think I understand a bit more.
Another option for filling your time is asking some of your new coworkers if you can work with them on a project. Whether you’re pair programming with them or helping them with a project they’re working staron, this gives you a chance to see how other members of your team work and what’s expected of you.
Getting To Know Your Teammates:
If you’ve read any of my posts before, you know I’m not very comfortable in social situations, especially with new people. I didn’t want to sit at work every day feeling lonely and isolated, especially because I knew that I was going to be doing some fairly solo work most of the time, so I tried to make an effort to get to know my teammates. Here are a few tips for getting to know your new teammates:
- Start a conversation. If you have some downtime, start a conversation and try to get to know your teammates. It may seem daunting sometimes, but even something as basic as “how long have you lived in the area?” can be a great conversation starter.
- Go out to lunch. I’m a “bring lunch from home” kind of person. Part of that is my dietary restrictions, but a lot of it is also that it’s easier and cheaper. But I still went out to lunch with my coworkers every day this week. I generally brought my lunch with me, and either sat and ate it wherever everyone else was eating or just ate it when we got back to the office. Just being out and sitting (or walking) with my new coworkers gave me a chance to get to know them a little bit and made the day less lonely.
- Talk about yourself. If you really don’t know what to talk to your coworkers about, talk about yourself! If you share a little bit of your journey, your coworkers may take it as an opportunity to talk about their own journeys. Or you may end up having something in common with someone else. It may sound self-centered, but really, when you’re trying to get to know new people, it never hurts to give them a chance to get to know you.
Pack Your Patience:
I was hoping to hit the ground running when I started work. That hasn’t really happened. So far, I don’t know what project I’m working on, I don’t know where I will be sitting, and I don’t know what time I’m expected to show up in the mornings (the hours are flexible, but I have to be there for my scrum … and I don’t know what time that is). At first, I was frustrated. I’m still a little annoyed. But … it is what it is. Nothing I can do about. I decided to just do what I could to stay busy and get familiar with the codebase, and when they’re ready to assign me to a project, I’ll be ready to give it my all.
If you only take one piece of advice from my experience, make it this. Hopefully when you show up everything will be ready for you. But it might not. Just be patient, do what you can to make sure you’re ready for when you do get into the “meat and potatoes” of your job, and just let things happen when they’re ready to happen.
While my first week wasn’t exactly what I was hoping for, it was a decent start, and I’m looking forward to what the coming weeks will bring. Being able to go into work every day and know that I’m a software developer is a great feeling, and I hope to continue to enjoy that feeling and share it with all of you as a continue my journey as a developer.
