9 Hard Lessons I Struggled to Learn During My 18 Years as a Software Developer

I started writing code in my bedroom at my parents’ house when I was 14 years old. I remember reading everything I could get my hands on via my very slow internet connection. Then when I was 20, I signed my first contract as a web developer, learning PHP and JavaScript at the time.

And it’s taken me over 18 years in this field to figure out that coding is just a fraction of our profession. I still enjoy it, mind you. I don’t think I’ll ever stop coding — even if it is for fun in my spare time — but there is so much more.

That is why I want to share with you my experience and what I think are nine lessons that developers tend to learn a bit too late in some situations.

1. Leave the Ego at the Door

Developers have huge egos. That’s a fact.

Why, though? I would argue that anyone who takes our profession seriously would consider themselves to be somewhat of an artist. Yes, we might not be singing in front of millions of people or painting the Mona Lisa, but we’re sometimes writing code that solves very complex problems in such an elegant and efficient way that we can’t help but be proud of our work.

I would argue that a developer is just as much of an artist as a mathematician is through the way they solve their problems.

Because of this, we tend to crawl around our code — just like a mama bear looking after her offspring. We made it, we love it, and we can’t stand when people start arguing about how wrong it may or may not be.

Then again, this is not helping anyone. We love our work, but we need to understand that we’re solving problems. By discussing our ideas and our solutions with others, better alternatives might arise. There is nothing wrong with that. In fact, cooperation is normally what yields the best solutions.

I’ve seen all kinds of egos in my time, and I’ve never seen a case where that ego worked in the developer’s favor.

So my advice here? Leave the ego at the door the minute you start working as a dev. Just swallow it and hear what others have to say about your work. Accept that better ideas might come from outside your head and that they will only help you improve your skills. You can only win if you listen to feedback.

2. Languages Are Tools. If You Only Know JavaScript, All Problems Will Look Like Nails

Stop calling yourself a Java developer or JavaScript developer. Yes, there might be languages that you favor because you like their features or syntax. That’s perfectly normal.

However, you’d benefit hugely if you were to learn something else for a while. Learning new languages — especially if they follow a different paradigm than the one you’re used to working with — will help you open up your mind to different ways of solving problems.

I can’t stress this enough: Learning multiple languages and using them for a while is going to benefit your skills. I read this book called Seven Languages in Seven Weeks several years ago and it opened up my mind to so many options just because it showed me the types of options available out there. Options I had never even considered because I was so focused on my daily tasks and daily tools that I never stopped to look anywhere else.

We’re developers. We know how to solve problems through code. Don’t put yourself inside a box. You’ll be limited by the size of that box. Look outside of it, think outside that box, check out other options, other languages, other ways of solving problems. Even if it’s for a little while, you’ll come back to your weapon of choice with fresh ideas and a bigger mindset.

3. It’s Not About Memorizing Algorithms, It’s About Knowing How to Google Them Fast Enough

Sometimes new developers think they need to know everything by heart, so they start feeling bad the minute they realize they start forgetting how to write a simple for statement.

This is not only normal, but I would argue it’s also healthy.

There is simply too much out there to have it memorized. We don’t need to either. We need to embrace the fact that the internet is just another tool in our arsenal. Just like we need our IDE, we need internet access to look for answers.

We all do it, and if you’re just starting out and feeling bad about it, don’t waste time on that feeling. Just search for your answer and figure out your problem.

Think about it this way: Every language will have a similar yet slightly different way of implementing the Observer pattern. What do you think is more realistic? Understanding what the Observer pattern is good for and what kind of problems it solves or remembering how to implement it in every language you work with?

If you know it’ll solve your problem, then you literally solved your problem. The rest is just a matter of Googling the best way to implement it. That is not taking any credit away from your work or from your experience.

And the same goes for every other search you do. Just focus on the important, problem-solving side of our profession and let Google jog your memory. That’s what it’s there for.

4. You’ll Be Learning Your Entire Career

Or rather “You should be learning your entire career.” It’s really up to you to decide whether or not you stay up to date with the latest developments in our industry. But if you want to stay relevant, then you’ll have to do it.

Technology evolves, languages evolve, and that’s completely normal. Granted, some ecosystems change faster than others and keeping up with them might seem like a titanic task. But focus on the important things, remember that you’re just a person and you can’t know everything. So if you have to learn one thing, my suggestion would be to learn how to learn.

I know it sounds silly, but that’s probably the #1 skill a developer needs. We have to get better at learning new skills fast. Otherwise, you run into the risk of being labeled as obsolete.

And here is where some of the other lessons in this article come into play. Variation, change, new challenges, no egos — those are all things that will help you learn and broaden the spectrum of your skillset. The more you do it, the better you’ll get at it. Eventually, you’ll realize all languages are similar. You’ll start seeing their common roots and you’ll be able to work with any of them. All you’ll have to do is read up on a few key things.

You’ll be learning your entire career about:

New languages
New (and old) programming paradigms
New ways of working
New ways of solving problems
New ways of interacting with your teammates
New ways of reviewing and testing your code

If you’re not ready to be the eternal student, consider if this is the career for you. Mind you, I don’t mean “Quit right now,” but rather consider if you’d be willing to open up your mind to be always learning.

5. Working Is Better Than Perfect

As a manager, I’ve heard myself say this too many times. But as developers, we tend to think our code needs to be perfect before release. And that’s not only untrue but potentially a problem.

Early optimization is an issue because you end up spending a lot of time and effort on something that perhaps doesn’t need to be optimized. And in some situations, when performing that optimization, you make assumptions that break the feature.

So focus on the work it needs to do and the problem you’re trying to solve. Once it’s fixed, test it out, iterate over the results, and see what your team thinks about your solution — even if you can already see ways to improve it. If you’re going to take two more days just to have it perfect, but it could go to production right now, chances are it should be in production right now.

At the end of the day, you’re solving a problem. The faster you solve it, the better it’ll be for your users.

6. Make It Work, Then Optimize

In line with some of the previous points, don’t fall into the early optimization black hole.

Even if you think you’ll do it quickly, once you come out of it — if ever — you’ll realize the time dilation effect is real.

Your first task as a software developer writing a new feature or fixing a bug is to make it work — no matter how ugly the code might look or how inefficient your solution might be. If it works, you’ve just proven it can be done. That’s half the battle right there.

The second step is to optimize it. This is an optional step. A detail that some people tend to forget. The time you have available to optimize your code depends on a lot of variables that sometimes are not under your control. So focus on making it work, then figure out if you actually have the time to optimize it.

Early optimization means optimizing your code while writing it. This is a dangerous practice because when we’re optimizing, we’re making assumptions about execution time, data requirements, memory needs, and other factors that we haven’t yet seen in action. Any such assumption might be wrong and you’ll end up introducing bugs into your logic.

Think about the TDD workflow:

Write your test to understand everything your feature needs to do (it’ll fail).
Write your code to have the test pass.
Worry about optimizing your code now.

Step 2 is a must. You first need to worry about passing the test, which translates to having the feature working. The test doesn’t care about the algorithm you used or if you used three nested if statements. That comes later, probably as part of a code review process.

7. The Last 10% of a Project Takes 90% of the Time

This is especially important if you’re working alone, but teams also suffer from not having this little math detail correct.

Anyone who has finished a project will tell you the same thing (and honestly, this doesn’t just apply to our industry): You first rush through a lot of details just to have to take care of them at the end.

And it’s completely normal. We tend to focus on the big features first, leaving out smaller details or even known bugs to the end. But they need to be tackled nonetheless, which is where the extra 90% comes in. The fine work takes time. You need to test, fix, re-test, write documentation, perform user training, present the final solution, and more.

Of course, it’ll depend on your context, who your client is, and on a lot of other factors, but there is always something. So remember: When you think you’re almost done with your code, you’re probably forgetting about something.

8. If You’re Doing It More Than Once, It Needs to Be Abstracted

Coding is about abstracting behavior. By abstracting common logic, we can reuse it in other places, but in the beginning, we sometimes fail to notice the importance of abstraction.

This is my personal rule of thumb: If I have code repeated in two places, then it’s going into a function (or a method, a module… you get the idea).

Even if the number two seems low for you, consider that in the future you might find other places to use that abstracted code. And by moving it into a commonplace right then, you now have access to it.

Abstraction is about scale. A piece of abstracted logic can be used many times with minimum effort, while copy-pasting code all over the place — although easy to do — will require a lot more effort the more you use it. Consider what would happen if you had to change a piece of logic that was repeated five times across your project due to a bug. You’d literally have five chances to make a mistake while fixing it.

The same logic can be applied to your day-to-day tasks. If you find yourself doing something more than once, then it probably can be automated somehow. This is key to efficiency, so don’t only look for repeating patterns in your code but also in your actions. If you can automate a task that only takes you ten minutes a day, you’re saving five hours a month.

9. Side Projects Aren’t a Must, but They Do Help

Some people say that if you want to be a successful developer, you need to create side projects. I don’t think that’s true. I personally know a lot of great developers who only code when they’re working on their 9-5.

And honestly, I admire them. They’re able to be great at what they do while also enjoying their free time doing other things. There is absolutely nothing wrong with that.

However, sometimes you need the extra practice. Sometimes you feel like you’re falling behind other colleagues. And that is where side projects can help.

I’m not saying to build a new framework that gets used by millions and revolutionizes the industry. Go for it if you like, but I’m talking about copying others’ projects in order to learn from them. I’m talking about contributing to other people’s projects by solving bugs or adding extra features.

You can use side projects to experience aspects of development that you don’t get to see often. If you’re writing unit tests eight hours a day, maybe consider creating something from scratch and developing some features. If you’re tired of working alone, consider contributing to an existing project and experience what’s like to coordinate your work with others.

You can use side projects to strengthen whatever areas you identify as weak to help you improve your skills. But again, don’t think you need to work on them or have a green GitHub activity chart in order to be considered a serious developer. That’s just silly.

Conclusion

Those are nine of the hardest lessons I’ve learned as a developer over the last 18 years. I hope that by sharing my experience, I was able to shed some light on your new (or already existing) career.

Do you have any other lessons you’ve learned that you’d like to share? Leave a comment below. I’d love to learn from you.