Last November marked my five year anniversary in the software development business. It feels crazy to me to think back on that period and to who I was back then, even though it’s only a couple years ago. In these years so much has changed. The first time I actually had to push a button that would put my code in production, or heck, even writing that code the first time scared the living hell out of me.
I can’t say I’m exactly a veteran in the field now, but it’s fun to reflect on the last five (and a half) years and see what I’ve learned. I’ll highlight some learnings I picked up, mostly as advice to myself. Hopefully this will keep me growing in the years to come.
I think this is the most echoed piece of advice I’ve read in several similar posts on the internet. Although a mentor might sound like someone like Yoda to you, find someone that’s just a couple years more experienced than you are.
Although the difference in knowledge and skill can still be pretty big, having someone that’s a couple years ahead of you helps you form an idea of what would be possible for you as well. It gives you something to aim for. This does mean that this person needs to have a way of working you identify with. It’s going to be a difficult match if you’re planning to be a database guru, but the person you turn to for help is the senior frontend developer in your team.
It also makes it easier to level. If someone is just a couple years ahead, there’s a good chance they still remember what it’s like to be new. During my years in the field I’ve met quite some people that were nice enough to care about me and saw enough potential to put the time and effort into my development. Besides that I got a lot out of this in the form of knowledge, I’ve formed meaningful friendships with people I look up to.
It might feel like everyone around you has way more experience in everything. You might feel unqualified because you’re not an expert in your field. And that’s completely okay. You don’t need to be an expert in git to teach your coworkers how to get out of a detached HEAD state. And you don’t have to be an expert on Docker to show off your docker-compose setup that makes your life easier.
Chances are there’s a lot of people that know a lot less than you in certain fields. Teaching your own learnings helps you remember them better yourself. It makes you think about the information you’re consuming, instead of just reading it and hoping it sticks.
For example: For some mysterious reason (it’s not mysterious, you know who you are) I was way more advanced in VIM and git than some of my direct colleagues when I started working as a developer. So as I was taught the ropes of software development, I had something to teach of my own. Learning as a two way street is just way more fun!
When you do things the same way for a while, you stop asking yourself why you do it like that. This is a very human thing, this also happens to the people around you. Even though people might sound very certain on how to pick up a task, make sure to ask them why if you don’t understand the thought process. You’re in the very fortunate position that people expect you to not understand everything the first time (spoiler alert: This never really changes and that’s okay). Make sure to use that advantage as much as possible, making sure your rate of learning will keep increasing.
It also helps your environment in their learning, since they’ll have to go back to first principles and figure out if what they’re feeling so confident about is actually still the right way to go. Another win-win situation.
Change is the only constant. And people telling you that phrase, that’s also pretty constant. Especially if you work in software development. Every couple days there’s a new hype, every day there’s new technology on the homepage of Hacker News or the likes which is going to change the world and make everyone’s life even better.
You don’t need to keep track of all these things. But you do need to keep up with the things that interest you. If you’re into a programming language, make sure to read up on the latest changes in each new version. Maybe try it out on a side project and see how far you get. Dive deep into the technology behind the technology and stay curious as to all the amazing stuff that’s out there. Most companies you will work for don’t adopt every bleeding edge technology from every hype (and good for them), but it can be very refreshing to step outside of your daily nine-to-five every now and then and see what’s out there.
Are you building beautiful screens in React all day? Try figuring out some backend work in Ruby. Working on very complicated distributed backend systems that have to be performing 24/7? Try your hand at building a game or an app. It’s fun to build some stuff for yourself and you’ll be sure to pick up a thing or two that will broaden your horizon in the process.
A good software developer writes as little code as possible. That’s a weird statement, huh? And still I strongly believe this. Something you’ve been putting so much effort into since college is apparently not even the most important part of the job. Now why is that?
Because the code we write solves problems. And these are people’s problems. We don’t write code for ourselves. We write code for others. In business jargon these would be called stakeholders. In plain English these people are your fellow developers, analysts, customers, and whatever other people you work with. Figuring out the problems they run into and communicating your ideas on the solution are crucial skills to master.
I’ve seen plenty of developers picking up a ticket and just assuming the contents are correct and the ticket’s writers know exactly what they want. Don’t do this. They usually don’t know the codebase as well as you do. And you don’t understand their domain knowledge as well as they do. I’ll come back to one of my previous points: Ask questions! Don’t assume.
Having a good mutual understanding of what is asked and what is possible saves a lot of frustrating round trips and a lot of time. Invest in your presenting skills, asking questions, writing clearly, and networking (not just the one between computers, the one between people). A lot of developers don’t like doing this. “I just want to write code” is a commonly heard phrase. Investing in your non-technical skills gives you an advantage.
Writing a post like this brings back impostor syndrome. It feels very know-it-all to be writing up advices like this. But it’s been fun to reflect on the last couple years and see how far I’ve come. I don’t pretend to be an expert on any particular technology. I still Google error messages every other day. But I can confidently say that I never expected to be where I am today professionaly. Curious to see what the next years will bring.
Anything that resonates with you? Or do you have some other piece of advice I should know of? Feel free to reach out!