One of the perks of being a developer for over a decade is hindsight.
I can look back and say things like:
- “I’m glad I did that.”
- “Anna, why on earth did you do that?”
- “File this under ‘do not forget’. Like, ever.”
And then there’s a fourth category:
“Why did nobody tell me this?”
These are the lessons I wish someone had shared with me when I was new to web development.
Google Will Become Your Programming Sidekick
Contrary to popular belief, developers do not know everything.
In fact, a surprisingly large portion of software development involves staring at an error message, sighing dramatically, and consulting Google.
Whether it’s a runtime error triggering the dreaded Yellow Screen of Death, a mysterious build failure that worked perfectly five minutes ago, or a debate about whether a HashSet or a List is the better choice, chances are that someone else has already run into the same problem.
Learning how to search effectively is a skill in its own right. Knowing what keywords to use, how to read documentation, and how to separate a good solution from a questionable one will save you from countless hours throughout your career.
The good news? Nobody expects you to memorise everything. The real skill isn’t knowing every answer – it’s knowing how to find one.
When I got my first developer job, Google and Stack Overflow were the go-to sources for whatever technical headache happened to be causing trouble that day.
Fast forward a decade, and our options have expanded considerably for finding answers. We are no longer solely reliant on that dynamic duo. Depending on the situation, we can also turn to official documentation, GitHub issues, blog posts, and AI tools.
There Is Nothing Wrong With Asking For Help
One of my biggest stumbling blocks early in my career was an extreme reluctance to ask for help, especially when I was genuinely stuck.
Instead of reaching out, I would spend hours turning a problem over in my head, being too scared to ask for help, fearing being seen as incompetent. More than once, that meant missing deadlines, falling behind on my work, or staying back after hours trying to untangle an issue that someone else could have helped me resolve much sooner.
It took me a long time to realise that asking for help is not a sign of weakness or incompetence. It’s simply part of being a developer. No matter how experienced you become, there will always be problems that benefit from a second set of eyes.
That said, asking for help doesn’t mean immediately giving up at the first sign of trouble. It’s equally important to develop the ability to work through a problem methodically, investigate possible causes, and understand what you’ve already tried before reaching out.
The most productive developers I’ve worked with strike a balance between the two. They make a genuine effort to solve problems independently, but they also recognise when it’s time to ask for help rather than spending hours stuck in the weeds.
You Do Not Have To Finish Everything Within The Day Or Hour
Another lesson that took me far too long to learn was that not every problem needs to be solved immediately.
Early in my career, I put a lot of pressure on myself to finish everything as quickly as possible. If a task landed on my desk, I wanted it completed yesterday. If I encountered a bug, I felt compelled to keep working until I had found the solution.
The problem with this approach is that rushing often creates more work than it saves.
When we’re in a hurry, we’re more likely to overlook edge cases, miss obvious mistakes, or implement a quick fix that comes back to haunt us later. More than once, I spent longer fixing the consequences of a rushed solution than I would have spent doing it properly in the first place.
Sometimes the best thing you can do is slow down, take an extra hour to review your work, or even step away from a problem and come back to it with fresh eyes.
Software development is a marathon, not a sprint. Most of the time, getting it right is far more valuable than getting it done quickly.
Find A Learning Style That Works For You
As a sprightly junior developer, I was frequently told that professional courses were one of the best ways to learn new skills. Somehow, I interpreted that to mean they were the only legitimate way to learn.
That was a problem, because my own history with formal learning environments is complicated. The idea of committing to a professional course never held much appeal unless it was necessary.
At around the same time, I was also being encouraged to spend my weekends learning new technology or working on a side project. My twenty-something self was not especially enthusiastic about the suggestion that I “had” to sacrifice part of my personal time for something that primarily benefited my employer.
Then I discovered the concept of incidental exercise – the idea that physical activity doesn’t have to come from a dedicated workout. It can come from walking to the shops, taking the stairs, or finding small opportunities to move throughout the day.
It occurred to me that the same principle could apply to learning.
If incidental exercise could help someone become fitter, then surely incidental learning could help someone become a better developer.
Over time, I realised that professional growth can come from all sorts of places: reading documentation, participating in code reviews, solving unfamiliar problems at work, reading blog posts, experimenting with a new tool, or even having conversations with other developers.
Courses and side projects are valuable, but they are not the only path forward. The best learning method is often the one that fits naturally into your life and is sustainable over the long term.
Your Health Is Part Of Your Career
One of the most important lessons I learned in my twenties had very little to do with software development and everything to do with looking after my health.
My wake-up call arrived in my late twenties when my doctor informed me, in no uncertain terms, that my cholesterol levels were in a dangerous place and that I needed to take action sooner rather than later.
Looking back, the warning signs were there. Having my own disposable income had led to more indulgent weekends than was probably wise, and like many developers, I spent most of my working day sitting at a desk. Those habits may not seem particularly concerning in isolation, but over time they started to add up.
That conversation with my doctor was the push I needed to make some changes. I began working with a personal trainer and a dietitian to improve my fitness and clean up my eating habits.
The results didn’t happen overnight. They took time, consistency, and a fair amount of effort. But half a decade later, my health is in a much better place than it was back then.
It’s easy to think that health is something you’ll deal with later, especially when you’re focused on building a career. What I eventually learned is that your health and your career are not separate things. The better you look after yourself, the more energy, focus, and resilience you’ll have for everything else.
If I could leave you with one final bit of advice, it would be this:
No matter where you are in your career, there will always be something new to learn.
Ten years from now, you’ll probably look back at the developer that you are today and think, “I can’t believe I used to do it that way.” That’s not a sign that you’ve been doing things wrong. It’s a sign that you’ve grown.
The lessons in this post are simply some of the things I wish someone had told me when I was first starting out. A decade from now, I wouldn’t be surprised if I had another list.
After all, that’s the funny thing about hindsight. The longer you spend in this profession, the more “Why didn’t anybody tell me this?” moments you collect.
And honestly, I think that’s one of the best things about this profession.
