11 things I wish I could tell myself as a Junior Software Developer
We’ve all been Junior developers at some point. Do you remember that long ago? I sure do. I remember the excitement when I could make something work. I remember the fear when faced with a task I had no idea how to even start. And I remember how impressed I was the “pro” developers and the bulk of their knowledge.
I also remember all the mistakes I made, the wrong approaches I took and all my bad decisions. This article is all about what I could’ve taught my younger self. All the lessons I learned the hard way over the years. So, here are 10 of them:
1. Plan before coding
This is one of those lessons I had to learn repeatedly many times. I would think of solutions to my tasks in under 2 minutes and started coding away, just to eventually hit a brick wall and realize that the solution is no good.
Sometimes I would forget some edge cases or limitations. Other times, I just didn’t think the solution all the way through. The problem was that I was just too eager to start coding. Too confident in my great mind that spent less than a minute thinking on the challenge.
Think before starting to code. Think for a while. Take a 10-minute break and think of it in the hallway. Draw the solution on a whiteboard. Walk through the existing code one more time, just to make sure you’re not missing something. Ask yourself: What problems can this solution have? Is there a better way? No, really, is there a better way?
2. Take breaks
As a younger developer, I used to be glued to my chair, constantly coding. While it impressed my managers, it wasn’t very effective. A lesson that I learned, later on, is how valuable taking breaks is. Even though I’m spending less time in front of the computer, I’m actually more productive now. I’m also not getting as tired from my work and there’s no risk of burning out.
There are several reasons why taking breaks makes you more productive, which I’m not going to get into. For me, the Pomodoro Technique works best. It’s the one when you work for 25 minutes, then take a break for 5 minutes. I use the simple Focus 10 timer app for that.
3. Keep Calm
Programming can be stressful. Especially when working under deadlines – whether they were set by your manager or by yourself. Sometimes you evaluate a task will take 2 hours, and it ends up taking 2 days. Even though during those 2 days, it seems like it’s about to finish any minute now.
It doesn’t help when you make promises to deal with other stuff right after the task. Or when you have context-switches midway. Or when something randomly stops working in your development environment and you have to take a 3-hour detour to fix that other thing.
So back to the point – programming can be stressful. The one thing that helps is to keep calm. Getting angry and frustrated will cloud your mind and you’ll end up spending even more time on the
Keeping calm is easier said than done though. Experience helps. For me, just keeping in mind that things tend to take a long time in software and lowering expectations usually does the trick. And remember, this happens to everyone.
4. Talk to smart developers
I can’t stress enough the value you can get from just talking with smart developers. Every one of us has tons of knowledge gained over the years, which you can easily get just by talking. This might be
So my advice is to find smart developers, get them to talk about code and listen. There are probably a couple of good ones in your own team. If there aren’t, perhaps it’s time to switch teams.
5. Tap into the wealth of internet Content
In my first job, I was a one-man team. My boss was a product manager and I really had no-one to learn from. As a result, I didn’t know some of the basics of software engineering. I didn’t know such a thing as Unit Tests existed, I wasn’t aware of any frameworks and technologies and had no clue of all the great tools in my reach. That may sound strange to you, it definitely sounds
The internet is a wondrous source of information. Besides googling your specific problems and finding answers on Stack Overflow, there’s a world of knowledge. My advice is to read blogs, listen to podcasts, and spend some time on Reddit and Twitter.
With time, you will gain awareness of the software world. Which technologies are getting popular, which tools are available, what’s hot. You won’t learn how to use Kubernetes, but you will learn that such a thing exists, and that’s half of the solution right there.
6. Go to Meetups & Conferences
Meetups and conferences are something blog posts and podcasts can’t ever replace. There’s something special about physically getting together, listening to speakers live and mingling with other programmers. There are numerous advantages to this. Firstly, there’s usually free pizza and beer. In addition, you get to meet other developers, listen to their motivation and challenges and create connections.
Listening to another developer telling excitedly how he redesigned his system, or how his team created their new product will add to your own excitement. In addition, the professional connections you make in meetups can lead to great things: Job opportunities, personal help from top experts and inside knowledge.
7. Code is the means, not the destination
As software developers, we tend to think of our code as a piece of art. Something that needs to be tended, perfected and admired. The sanctity of the code. We all want to do our job as best we can, which means writing the best code possible.
But, this is not really our job as developers. Our job is not to write great code. That’s right, I said it. Our job is: Write code that gets the job done, as quickly as possible and with as little complexity as possible.
What does it mean in practice? Just that you need to write
8. Know what’s significant and what isn’t
This is something I see as a team leader a lot. Developers that can’t separate the significant from the insignificant. They might spend hours, days and weeks to make something work just right. But, they could have changed the requirement just a bit and spend 30 minutes on the task.
You might work in a startup, getting close to a crucial deadline, and yet spend half a day making that Login Dialog look exactly right… A senior developer will leave polishing that dialog to a later date, moving to that special bug that makes the server crash once an hour.
9. All Bugs are eventually solved, scary as they may be
Did you ever feel scared as you get a Bug that seems impossible to solve? I’m talking about those bugs where you don’t even know how to begin. Perhaps a bug that you can’t even reproduce properly. Or maybe a piece of code that’s so complicated there’s just this one guy who understands it and he isn’t working here anymore.
I’d like to tell my junior self that in 10 years, there wasn’t a single bug I didn’t eventually solve one way or the other. Even bugs that seem extremely scary, are eventually conquered.
(I will admit that some of those were solved by adding a workaround, with the help of others or by convincing the product manager this isn’t really important. But, those details shouldn’t interest my junior self).
This is true to all developers, not just me. I saw it a thousand times. A problem that might seem impossible and a frustrated developer turn within a few days into a problem solved and a happy camper. In the end, it’s just code, and everything is solvable (see Gain Mastery at Solving Bugs ).
10. Make in-house tools
One of the things that I’m proud of the most are the in-house tools I created. These also benefited me the most – whether it’s the respect of my colleagues, company appraisals or promotions. Working on the in-house tools are also the most fun I ever had at work. There’s something special about creating your own application from scratch.
Whatever company you work for, there’s probably a need for some kind of in-house tool. This tool might be a Log-retriever, Automatic localization tool, or an Environment configuration manager.
11. Invest in a good chair
This might be the single most important advice here. Buy a good chair, it’s worth every penny. As programmers, we sit all day in front of the computer. It takes a toll on our backs, shoulders, and wrists. A good chair will make you more comfortable, healthier and less tired. Jeff Atwood agrees with me .
A couple of the best chairs in the world are Herman Miller chairs and Steelcase Leap – you probably won’t go wrong with those. I ended up with Wagner AluMedic 5 myself, spending about 800$. My only regret is not buying it sooner.
Summary
This is it, the wisdom acquired in about 10 years of development. The chosen bits I would tell my younger self. People are inherently stubborn though and me especially. If I had a time machine and would go 10 years back in time and tell myself all those pieces of wisdom, it probably wouldn’t help very much. The best way to learn is from our own mistakes.
I’m guessing that while most people will agree with the above tips, they would give entirely different tips if asked. The reason is that we’re all different and needed to learn different lessons. Some things that were hard for us, were easy for others. And vice-versa.
What advice would you have for the junior dev you once were? I’d love to hear your feedback in the comments section!
