I’ve been working full-time as a software engineer for about 18 months now. When I started, I bought a BlueHost domain to write about what I learned along the way. The thought was there. The execution left everything to be desired. I haven’t written a single post since.
A lot of this was because I figured that for anything I learned and wrote about, someone could easily Google and find numerous and far better explanations. I realized after reading a bunch of articles from junior devs that you don’t need to be an expert to offer value. There are tons of people who are at the same point in their journey and your advice can be useful to them. Sometimes it’s easier to learn from people who are closer to where you’re at than from those with many years of experience.
This post is meant to organize what I’ve learned from working on a ~20 person team made up of developers, designers, and managers, most of whom are more experienced than I am. I also want to lay out my learning plans for 2023 so I have a public record of my commitment.
Communication
The first lesson I learned was the importance of communication, which I heavily underestimated coming into the job.
I was hired in June of 2021 and my only prior experience on a team of developers was my internship the previous summer at the same company, fully remote. As an intern, you work on a project that’s very clearly defined and your mentor makes sure you’re on track.
As a full-time engineer, however, you get some more freedom since you’ve already proven yourself as a capable developer. I discovered that my projects were a whole lot more ambiguous and rather than just following a series of well-defined steps that your product manager and mentor fleshed out before you started, I had to figure it all out for myself.
If I encountered a problem, as was quite often the case, I’d just bang my head on it for days without reaching out to someone who could get me through it in a breeze. If I were in the office, I could just turn my head to the side and ask someone on my team to roll their chair over and help me out. Slacking someone a “stupid” question felt entirely different. I thought I’d be distracting that person from their own work and they’d be annoyed by not only the distraction but also the simplicity of the solution to the problem I was asking about.
I learned way later that while there is some value to figuring things out on your own, as a junior dev, getting as much help and feedback as possible is far more efficient. Once you have more experience and confidence in your execution, you can try your hand at something that would’ve taken the less-experienced-you at least 3x longer.
It also turns out that people actually love to help! Software engineers are constantly solving problems and it wasn’t until I started unblocking team members in their work that I realized it’s pretty damn fulfilling! Why would it not be the same for people helping me out?
As you gain more and more experience, the importance of communication only increases. For example, as I approached my 6-month mark I had to design and write a new API endpoint, which I had never done before. I realized that communication didn’t just help me move faster, but that it was absolutely necessary in cases that involve cross-team work. Not only was working with a bunch of people more fun than sitting at my desk coding the day away (which definitely has its moments), but we also released the MVP much faster than I previously thought was possible.
When in doubt, reach out.
Getting Your Hands Dirty
I noticed that when first starting out, many new developers will want to know how best to get up to speed on the tools and technologies that their team uses. Most new devs are coming fresh out of school so what I’ve noticed is that a lot of them, including myself, will enroll in an online course for the language they’ll be writing in.
This sounds like a decent idea. But following along as some dev on the internet codes and deploys a todo list React Native app is very different than working on an enterprise mobile app with a Ruby on Rails backend, to use my experience as an example.
Because I was so intimidated by the size and complexity of our backend, I figured I’d enroll in a Ruby course. Surely after 48 hours of lectures and code-alongs I’d be ready to contribute to any area of the 15-year-old codebase!
It took about 3 weeks for me to learn that was nowhere near the case.
By far the best way to learn how to meaningfully contribute code in your team’s repo is to contribute code in your team’s repo.
Instead of drudging through weeks/months worth of material on the side in hopes of learning how to work with a specific implementation of the technology, it’s far better to just work with that implementation.
In a lot of cases, though, you’ll take one look at a file you’re supposed to edit and have no idea what to do. This brings us back to communication. If you’re trying to add a new parameter to an API endpoint, for example, use git blame to find the person who last worked on it or ask someone on your team who to talk to. More than likely that person will be happy to bring you up to speed and actually help you create your merge request.
From that point on just keep yourself in the following feedback loop: You get help working on a certain area of the codebase, which makes you more comfortable to not only work in that area in the future but also help others to do the same. As you teach others about it, which is as good if not better for learning than working on it yourself, you get more and more confident, which leads to more efficient development and effective software. Just keep riding that cycle.
All of this is not to say that you should avoid side projects and silo yourself in your team’s development work. Quite the opposite actually.
Tools and Technologies Outside of Work
As far as I’m concerned, you can commit to varying levels of time and effort outside of work that brings corresponding value to your team.
As a software engineer, you need to learn as quickly as the field is evolving, which is insanely fast. In order to do this you need to be reading voraciously. So the most basic level requires just reading a bunch of content relevant to your work.
This is where I’m at currently. I subscribe to a bunch of tech-related newsletters and follow a bunch of developer accounts on Twitter. I also listen to a couple of tech podcasts (long drives and runs are the best time for these imo).
I’ve noticed that if you read 100 Tweets and just one gives you a little bit of knowledge that you can share with someone on their MR, it was worth it. Eventually, you’ll unfollow/unsubscribe from the content that doesn’t give you enough value for your time and discover people, accounts, and channels that reinforce what you know and keep you moving in the right direction. As long as you’re constantly adapting and refining what you consume, you’ll be great.
Whereas in this first level, you read to support your development, in the second you develop to support your development.
For example, since I work with mobile development in React Native, my manager recommended that I create and deploy a simple app to Google Play and the App Store. This would give me exposure to full-stack development without having to deal with the decade-old repository complexity. This also lets you experiment with the newest versions of the libraries your application uses. Using the latest version of React Native could give me an edge when our team eventually upgrades our app!
Side projects are great, but the issue is that in most cases you’re not collaborating with anyone besides maybe Copilot. So the next step here is open-source contribution. And the best place to look for open-source work is within your own project. Dive into the source code of a library that you use every day and see if anything (besides spelling) needs improvement or fixing. Collaborating with people you don’t work with on a regular basis can improve your communication and makes you more well-rounded.
Of course, I’m still at step 1. So I don’t really know what I’m talking about with steps 2 and 3. But I think it sounds like a pretty cool direction to head in. I’ll check back in on the brink of the New Year and see how I did.
To be more explicit about what I’m going to do between now and 2024, I’ve written up a very rough…
Action Plan
The lessons I’ve picked up so far were the result of unconscious processing of my daily routine that I turned into words. This year I plan on being much more deliberate in my skill acquisition by publishing everything I learn either as a full blog post or Tweet. If there are any gaps in my knowledge, I’ll see them right in front of me on the screen, or if I miss them I’ll get roasted.
Some goals that I hope to have scored by 2024:
Know pretty much everything there is to know about Typescript and React
Deploy two different side projects: one mobile app and one web app that uses GraphQL (never used it but it sounds cool)
Run through this DevOps roadmap
Find and contribute to at least two different open-course projects (React Native and GraphQL being the favorites here)
Let’s see how I do!