I remember the first few days of my first software engineering job out of college. There was no receptionist at the office, so I blindly walked up to the first person I saw and introduced myself. I was lucky the company was small and they knew who I was, so they showed me around, provided me with a computer, introduced me to my team, and off I went.
When I got into the codebase, I quickly realized I was out of my depth. It was React, but it was also so much more. We were using GraphQL, React Router, Create React App, Styled Components… and the list goes on. The list of technologies I needed to learn, and fast, scared me.
The terror of that first week on the job was so intense I almost lost hope. I thought I would never ramp up enough to just work on my own. I remember calling my dad that week and describing the situation. He’s not a software engineer, but he’s a hard worker, business owner, and he knows what’s expected of a good employee. He told me, frankly, that being a great employee requires more than just eight hours a day.
He was absolutely right. I wasn’t going to do reach my potential if I only put in my eight hours and went home to goof off with video games or TV. He told me about how when he was a new attorney he was spending hours upon hours reading and studying outside of work. He made it clear that the same was likely expected of me.
So, I came up with a plan. I was going to ingest web development content until I could hold my own at work.
Dialing Back
At first, I studied web development with a David Goggins-like intensity. I gulped it. I inhaled it. Perhaps more accurately, I drowned in it. I found podcasts which I listened to on my way to and from work. I bought books (with my own money) and read them. I bought online courses and worked through them. And, for a while, aside from exercise and eating, that was all I was doing when I was not at work. I would drive to work in the morning listening to a podcast. I would work the day as best I could and then drive home, listening to another podcast. Then I would exercise, have a meal, and sit down for an evening of reading, coding, learning, and studying. To be honest, I studied then more than I ever did at school. Occasionally, I'd spend the evening in the office, working late, figuring things out on my own. In the quiet hours after most people had left, I was able to test my understanding with minimal distractions and some free snacks.
Eventually, within 2 or 3 months, I started to hold my own at work. The list of technologies I needed to understand shrank until I knew the stack well enough to not need help on any of my tickets.
It was at this point that I decided to scale back my learning efforts to a more maintainable level. I decided on the following rule:
At least twice a week I spend the evening improving as a developer.
That meant that two nights a week were now dedicated to my career, a balance which I felt was very manageable. I still follow this rule. And in my opinion, it’s made all the difference.
I didn’t realize it at the time, but I had decided on a sacrifice.
Sacrifice Your Time
Most people do little more than what is necessary to maintain an acceptable performance level at work. They have reasons, and those reasons are valid. I believe it’s wrong to look down on an individual for prioritizing something above work. Many things deserve prioritization above work. But, there’s a notable side effect of this pervasive apathy: anyone who puts in extra effort, in the form of hours in the office or at professional development, is going to stand out. I can’t speak for all industries, but in software engineering, my own experience indicates this is true.
Performance at work generally follows a normal distribution.
For me, I was willing to sacrifice a few months of life in order to get up to speed. And from then on out, I was willing to sacrifice several nights a week. I believe that this sacrifice has placed me one or two standard deviations up from the center. In my opinion, this sacrifice is small relative to the payout.
Others decide that they are willing to sacrifice nearly everything to their careers - their families, all of their time, their health, and all of their energy. They would fall into the highest standard deviation. Others decide that they don’t want to sacrifice anything, and so they only work the required hours and they go home. This, in my opinion, is the mean. The standard deviations below the mean, are those employees who would rather not work at all and actively harm the business interests of their employer.
For those who are a bit more ambitious, I find it helpful to realize that the mean distribution here are the 9-5 workers. They work, and they go home, they do what is necessary to keep their jobs and that’s it. They are adequate employees. All you need to do to rise above the crowd is to work slightly harder than the mean distribution. For me, that was one or two nights a week.
Notably, it takes little sacrifice to get away from the mean.
How to Use Your Sacrificed Time
Once you’ve decided how much time you’re willing to sacrifice to stand out as a developer, you need to decide what you’ll do with that time.
As I said earlier, I started my career diving headfirst into web development by necessity. Do what is necessary first, but don’t neglect to learn what you’re passionate about. It’s easy to sacrifice your time, and you’re more likely to do it, if you use that time on something that grips you.
At some point after I had finished catching up on web development, the question “how do I do this job best?” started to interest me. This was a question that truly gripped me, and I still spend evenings researching it. It has no simple answer, to my knowledge, which makes it all the more intriguing. Spending time studying this topic is easy for me to do, because I love that question - even if there is no one definitive answer.
In addition to studying what grips you, you should focus on things that don’t change, as I’ve written previously. The techniques, disciplines, and practices created by those developers who came before have often stood the test of time.
If nothing in software engineering engages you to the point that you want to spend an evening with it, consider reading more. Pick a book about software engineering and dive in. Even if it doesn’t immediately interest you, you may find a sentence or two about a different topic that does engage you. If there are citations on that topic, you now have another book to read. Software engineering books often lead to one another in this manner.
Recently, I’ve been working on two books: Scientific Method in Practice and Linear Algebra & Its Applications. The content you read does not have to be limited in scope. Read widely.
Books are not the only place to find wisdom in software development. You can scour YouTube, podcasts, and online articles as well.
But study without practice makes for a weak developer. Practice what you learn by coding small projects until a topic clicks. You may even wish to try the project again with a different technique or technology. This is the surest way to understand something deeply. However, this takes time, and reading is much faster. Reading (and writing) acts as a filter, making sure you don’t waste valuable practice time on bad ideas. Don’t worry, you’ll still try out plenty of bad ideas, but you don’t need to try all of them.
Share What You Learn
There is one more step to standing out as a new developer - sharing what you learn. If your goal is to stand out, you won’t do that unless your manager knows you’re putting in extra time. So, during your one-on-one's with your manager, tell him what you’ve been learning about in your extra time, tell him how you think it might help the company. And if what you’ve learned is completely unrelated, tell him anyway! He may find it impressive that you dedicate more time than necessary to improving yourself as a developer. This discussion is absolutely essential.
To go the extra mile, write about what you learn. Writing is thinking. Writing about a topic shows you can, at a minimum, form a coherent thought about it. Writing can help you stand out. It filters your ideas, rejecting the bad ones, and keeping the good ones. Share what you write. This can be as simple as posts on slack or a personal blog. People with different experiences than you will help you see mistakes. Be open and willing to consider their points of view.
If you feel like putting your foot forward even more, take what you write and turn it into a presentation you can share at lunch-and-learn or other work-sponsored professional development activities. These moments are a sure-fire way to show management you are a keeper. They will not want to lose you because you clearly think things through, you bring new ideas, and you are good for morale and culture.
Now, you are beginning to stand out.