Back in 2013, just one year shy of being ten years ago, I was a clueless freshly minted University graduate with a weird eclectic mix of English Lit, Commercial Law, European Studies, and Information Systems majors. Looking back, it was a bit of an overkill with the overtime studies and none of it involved any actual code.
I did try a ComSci class once, but it went horribly wrong. In part, it was because I rebelled against the idea of spending a year or two learning a discontinued technology (*cough* Silverlight).
Retrospects are always fun to do. They’re good at helping you find the good, the bad, and the bits that can improve in your journey towards wherever. Here are 12 lessons learned from reflecting on my junior dev days.
1. You think you know everything but you don’t
Here’s a quick diagram I found that basically sums up the learning curve experienced as a programmer. You think you know everything, but you don’t — especially with JavaScript where libraries and frameworks age at the half-life of dog years.
2. It’s easy to overload yourself by saying yes to everything
As a junior dev, I struggled with saying no. The thing is, I thought I had to say yes to everything — to prove that I could do it all. This stemmed from my academic days. The school didn’t prepare me for reality — that it is ok to say no and not overload yourself. Sometimes, it's better to just slow down, learn and give yourself the chance to be curious rather than taking on so much that you don’t have time to simply think. Sometimes, the manager, boss, agile team lead simply don’t know how accurate their time estimates are against your skill level and knowledge.
3. Kon Mari isn’t just for your house, it can work for your job too
Burnout happens when you priorities everything else first and put yourself last. When you commit yourself to a job that you don’t feel passionately about, it can lead to you wasting your life away unnecessarily.
Kon Mari is all about holding an object to your heart and asking — does it bring me joy? Deep down, you know the answer to this question when it comes to your job.
View your jobs as a learning space and community. But once the job and people cease to challenge you, it’s a sign that you’ve outgrown your pond.
4. There is no such thing as perfect code
When it comes to code, you can’t just crack open a textbook, read it from cover to cover to say you know it all. Code in the workplace is much wilder, with tendrils that extend back five, ten, or even fifteen years ago.
What made sense then may look to you like gibberish. Don’t be angry at the person that created the code. Anger stems from expectation and fuels irrational emotions. Rather, accept and grieve its existence before moving on to do what you need to do.
Perfect code is a myth. It ceases to be perfect the moment it ships.
5. Late-night over date night shouldn’t be a common occurrence
It’s easy for your job to take over. It’s also easy for that tinkering, reading, exploring, and console errors to take over your nights.
Don’t sacrifice your human relationships for an urgent bug fix every week. Bugs come and go but your other half is forever.
6. Degrees don’t matter as much as you think
It’s easy to feel unworthy or suffer from a bad case of imposter syndrome because you don’t have a ComSci degree. The reality is, everyone is a learner and they’re constantly learning.
Someone with a ComSci degree has a bit more learning than the complete newbie. The complete newbie might also be a 30-something going on a career change down the coding route who has 10 years of experience in whatever sector they’re coming from.
A degree is just one pathway. Online certs and a solid portfolio are another. Once you get that first job, nobody really cares — and if they do, then they might not truly understand the nature of software development in general.
7. The best senior devs are the ones that let experiment and learn
It’s easy to get carried away with the latest and greatest tech. The best senior devs are the ones that give you the space to experiment and learn and trust that you’ll still be able to deliver your part of the ticket on time.
They will also listen to you because chances are, they’re also learning whatever new tech you’re diving into.
8. The client/boss/non-technical manager will hook onto something they saw on the Internet and run with it
Sometimes, the client, boss, or non-technical manager gets sold an idea they encountered online or through a conference. Sometimes, they will demand that you switch to it based on their ‘research’ — which, a lot of instances involves reading a lot of non-technical marketing pitches.
It happens and it happens quite a lot. The trick is not to get annoyed. Rather, pause and try to understand the root reason why they want to change. If the solution they’re proposing isn’t the best fit, come up with an alternative that has a higher probability of succeeding.
9. Learning to code now is easier than learning to code 10 years ago
My toddler has games that teach pre-coding skills. The beginning of my code learning journey was much slower during my dial-up days than it is now.
In the beginning, I envied the new generation of junior developers because they didn’t have to struggle with lack of documentation, tutorial, and wealth of freely available Internet posts. Nowadays, I’m grateful because, despite the number of years, we will always be a junior at something.
10. No code, low code, and everything that promises the world will bite you later
No code and low code are solutions that are supposed to help create MVPs. However, it should be treated as the permanent solution. Anything that promises the world will find its way to bite you back.
I once worked on a system that was made using a no-code solution. The database resulted in table names that only made sense to that particular software. No one bothered to refactor before they extended it — which left subsequent teams with a highly duct-taped system.
11. Agile code doesn’t equate to bad code
Agile gets a bad rap. Just because it’s associated with speed doesn’t mean it has to be bad. Good workflows and robust code are conducive to creating good code.
Bad code happens when sloppy practices are allowed through the gate. Good agile code requires discipline, clarity, and conviction not to change the requirements mid-sprint.
12. Learn patterns
Learn patterns. Code patterns are the collection of knowledge and learnings of every developer that’s experiencing the pains you’re experiencing. Don’t try to rediscover the wheel. You can change the size, cosmetic appearances, and features but don’t reinvent what is already working — unless it breaks under pressure.
Only then should you start to experiment to create a new kind of wheel. Why? Because the pressure on the pattern reveals to us its weak points. You can’t fix a problem if you don’t understand the problem.
Final thoughts
The major lesson I've learned from almost ten years of working is to not rush through life.
Code is a tool and there will always be some sort of update, new release, framework, or library that comes out. What you know can quickly become legacy stuff. The reality of it all is that if you know how to make things with what you know, you are doing well. Fine-tuning is a process that involves understanding how to weld and mold what you’ve created to the conditions. The conditions are also likely to change on a quarterly basis — so it’s easy to feel like you’re falling behind.
The truth is: you’re not.
It’s just the nature of the industry. Everyone’s experience is different. This is only an instance of a journey — or more specifically, learnings from my experience.