To become a better software developer, first look at yourself

Did you ever receive some bad feedback on your code? Did you think “why me?” Have you struggled with accepting that feedback?

In this article, I will describe part of my way of becoming a better developer.

It’s 2017. I have started my professional career as a Software Developer in 2008, even though I wrote my first lines of code at an age of 11 back in the 90ies. That doesn’t count in the job, but it’s very important to me. Given that I never attended university, nor did I do an apprenticeship in informatics — I’m completely self-taught. All of what I learned was hard work.

Today I had a look at some code that I had written in 2012, so 5 years ago and already 4 years into the job. At that time I was developing a 3D MMO shooter game. While inspecting what I had programmed, I traveled back in time and talked to my old self. What I had discovered, took my breath …

When you reflect on yourself, when you question your past, you can learn a lot of things. Like the road, you’ve traveled over the past years.

What I learned today was that I had a weird impression of my skills back at that time. If someone would’ve said “Daniel, your code is a mess”, I would strongly have disagreed with them. I would probably have gotten angry because I had put so much effort into it. As a matter of fact, the code I discovered today was a mess! Not all of it though — I got the naming right, at least — but there were enough problems that I didn’t realize back then.

The piece of Software I’m talking about was a text file parser. The files, it was supposed to parse, were LightWave Scene (LWS) files, which held information about a 3D scene, like camera and object positions, lights and so on. Truly, the task wasn’t too trivial. It included not only reading the documentation and putting it into code, but also understanding the concepts behind the file structure and LightWave itself. LightWave, by the way, is a 3D modeling and rendering software used in many great games and movies.

When I wrote that code in 2012, I was OK with it. I knew it wasn’t the best code I’ve ever produced. But at that time it was good enough for me, given the knowledge, I had at that point. Today, as you can imagine, I feel different about it.

In 2012 I didn’t know of SOLID or even the Single Responsibility Principle (SRP). I wrote classes to do a certain job. If I had written a job description for this parser class, it would be something like this:

The parser would read the text file.

And build an object tree.And load objects.And put them into a scene.And set their position.And in the end, I would have a complete scene.

Failing being strict or not knowing principles like SOLID, DRY, YAGNI, and more can lead to a disastrous state of your software.

As you might guess, every “and” in this task description is an indicator of breaking the SRP, developing bad architecture, a nightmare for the next developer and many more things I don’t want to name. Failing being strict or not knowing principles like SOLID, DRY, YAGNI, and more can lead to a disastrous state of your software. A state where it’s almost impossible to keep the code clean of technical debts or to add new features easily. Of course, you can always add new features, add more code to a project. But as the project gets more complex and the more features are added, the harder it gets. Adding new functionality will require more and more time and this scale is only getting bigger, never smaller.

If you change a single instruction in untested code, you might break something you’re not aware of.

On top of this, if the requirements are not verified by tests, you will lose on the long run. If you change a single instruction in untested code, you might break something you’re not aware of. It will get back to you, be it at compile time (if there is such a thing in your technology), be it a bug report or a call by an angry customer.

My LWSParser class was not unit tested. It contained about 1,800 lines of code (LOC), while the longest method had about 500 LOC and a nesting level of over 10 (meaning if-if-while-if-while and so on). It included logic, calculations, and even asynchronous loading of files.Once I had to change something, it took me quite a while to figure out the right way to implement the change.

Today I’m a different type of developer. I learned so many things in the last years and I took them to the heart. If I had to accomplish this task today, I would split it into several classes. I would be very strict about what each of those classes should do — exactly one simple, distinct task. I would rethink my routines, once a nesting level of 3 is reached. I would try to keep each class as small as possible. Why? Because it keeps not only your code clean — having small classes and methods keeps your brain clean!

You know what, I’m proud of it! I really am, because I know how difficult it was back then to do all of this on my own. I’m proud because I know what I have achieved, what way lays behind. I’m proud because today I can see that I was wrong back then. One day, I realized that I wasn’t on a senior level, as I had thought. To never surrender and getting the job done alone won’t get you there. I was doing OK, not more. I’m proud — and happy — because I can share this experience with you today.

I have made a lot of mistakes and I acknowledge them. Only by accepting that I’m not always right, and by trying to perceive myself from a different point of view, had I given myself the chance to improve. Not only did I improve my programming skills. Also accepting and handing critical feedback, as well as giving feedback to others, so they can grow and get better.

Always be open to feedback. Don’t think of yourself as the best person in your job. Be humble. Accept to be wrong.

If there’s one critical advice I can give you, it’s this: Always be open to feedback. Don’t think of yourself as the best person in your job. Be humble. Accept to be wrong.

People tend to take it personally when they receive feedback on their work. Senior developers don’t give feedback to blame you or make you feel bad! They do it for you, so you can learn from their mistakes, leverage their knowledge and become better step by step.

What did you take away from this article? Please let me know in the comments!

My next article will be more tech-focused, as I want to write about how to clean up such complicated code. I love refactoring and I will share my tips and tricks with you, to become a better developer and deliver clean code (and keep your brain clean).