August 27, 2017 · 6 min read
Without realizing it, I’ve just surpassed two years working professionally as a software developer. Over the course of that two years I have held three different jobs, doubled my salary, worked in multiple frameworks, and learned a lot along the way. Here are some things I wish I knew during my journey.
I stayed at my first development job for seven months. I knew from the beginning that it wasn’t a good fit and that I wasn’t going to be challenged but I stayed anyways, out of fear. I stayed at my second development job for a year. I was the only developer working on the project and I knew working on a team would help me progress much faster than working alone but I stayed anyways, less out of fear and more out of not being labeled a job hopper.
I’ve been at my current position for about six months and have no plans on leaving anytime soon. I’m working on an awesome team, with a great development process, and I learn something every day.
Don’t stay in positions where you know you’re stagnating out of fear.
One of the fastest ways to get better as a developer is to get feedback from more experienced developers. Get over the fear of putting your work out there.
When I started my current position I I set out to be fearless when it came to doing work. During a sprint planning session in my second week with the company I volunteered to work on an issue that I had no idea how to accomplish. I was terrified as I was still learning the codebase but I volunteered anyways and was able to do the work. This was a huge confidence boost and gave me momentum in the coming weeks and months as I was still getting my feet under me at the new position. I looked at the issue as an opportunity to prove my self and I think it worked out well as my manager and peers were pleased with my work. So be fearless when it comes to doing work you’re not sure you can do. You will figure it out.
Another thing I still struggle with is asking for help. This may stem from the fact that I programmed in a silo, all by myself for a couple years. Once I started interacting with other developers at work and via open source I became a much better developer. Asking for help doesn’t necessarily mean asking for the answer either. It can be as simple as explaining the implementation of a feature you’re considering or a code review. The important thing is get feedback on how to improve your code. This will make you a better developer.
If you have an idea that you think would benefit your company or team don’t be afraid to speak up. We were using a less than optimal development process when I started a new job and I knew things could be way better so I proposed my ideas to the team. To my surprise they were accepted and implemented during my first few weeks with the company.
Related to the previous point… If you get your team to adopt something that you proposed you also have to be ready to own your idea. The change I proposed to my team required the API team to switch from using surround to git for version control. Some of the group had no prior experience with git and it was a rough transition for them. Owning your ideas means helping out during the transition. I spent a lot of time the first couple weeks of the transition helping my co-workers with git questions / problems and I was happy to do so since I proposed the change.
Finding a community of developers is important as well. Go to meet ups or start one if there isn’t one close to you in the language of your choice. Attend conference and talk to other attendees and speakers. Engage with other developers online via twitter, reddit, and github.
I’ve tried pretty much every learning resource there is and wasted a lot of time along the way. Try to figure out what kind of learner you are early. I learn best by reading books, building something on my own, then teaching others what i’ve learned. You may find videos are more your style. Find out what works best for you.
The best way I’ve found to solidify learning is to put it into practice as soon as possible. Building things is a great way to accomplish this.
Another great way to solidify your knowledge, as well as finding holes in your understanding, is to teach others. This can be to a group or even in a one on one setting.
Burnout is real and can happen to anyone. It’s important to have downtime where you are doing something other than programming. Taking breaks is not a bad thing and doesn’t make you a bad developer.