How my perspective on software development has evolved over the years
Reflections of what I’ve learned during my decade working in tech.
I sat the other day thinking about my career in tech. It still surprises me that I found something that interests me so deeply when I think about how indifferent everything else seemed back then. If something was uninteresting, you couldn’t get me to so much as consider it. Not a single second would I waste on something I didn’t think was worth it. I’ve always been like that, and it’s also one of the things that made school difficult for me. But I found my flame, the thing I wanted to spend my life on.
I remember when I was a junior developer. Everything was so new, and everything was at the same time so incredibly difficult. Just like learning a language, you first have to learn the fundamental principles and then work your way up to becoming fluent and efficient. I remember that back then my standards were much lower than they are today, so if I could get something to compile and subsequently work, I was happy. It didn’t take much, and when I think back on the bugs I spent hours on, it wasn’t so often the logic that failed but more the syntax. Having to think like a machine in order to explain to a machine how it performs a task. Even today it’s something I use when I need to explain to others how to think when programming. I usually use the example that they should first try to explain how they would cross a busy street. When they’ve explained how they would do it, I then explain my way, which would work for a machine. It’s always the same reaction I get: wide eyes, they look like a big question mark, and open mouth. You don’t think about it, but there’s an incredible amount that goes into explaining to a machine how it should do something, because it can’t just connect the last dots like our brain can. But that’s exactly the kind of thing that’s exciting.
I remember one Christmas when my parents came to visit, and because I got a good idea, I ended up sitting and programming most of the time. Looking back, it wasn’t very nicely done, but I was obsessed. I would also sit and spend most evenings when I came home from work on my own projects. As self-taught, you have no other choice. You’re forced to teach yourself everything, but it can also be a gift. Because I learned things in the order I wanted and at the pace I wanted, which meant it went much faster.
The blind spots I overlooked
When I think back, there was especially one big mistake I made, and that was mainly thinking about functionality instead of whether I was writing the code correctly and how it worked. When I was new to the field, I was so excited to be able to get things to work that I forgot to teach myself how things should actually be written. A bit like a language requires a certain syntax, a grammar, and if this grammar isn’t followed, you end up with functions that don’t work fully.
It was winter, and I sat in the evening working away on a side project called “Where Can I”. This was a web application whose task was to make it easier for people who travel a lot to get an idea of the best clubs, restaurants, and parking lots around the world. The idea was that businesses would subscribe, which gave them the opportunity to advertise directly to their followers. When a user then started the app, they would see a map with their precise location, after which they could write in whether it was a restaurant, club, or something else they were looking for. The result would then be the recommended results from residents who live in that particular place, which means that users would quickly be able to learn about the best-rated places based on the locals’ opinions. The idea was simple and didn’t require much, but I still sat evening after evening writing on the same API functions to get them to work. It wasn’t the logic that failed, it was that I didn’t explain things correctly to the computer. Back then there was no AI that could immediately solve the problem. There were books, Stackoverflow, and Google, so debugging took a long time. But it’s also examples like these that made me realize I had to become good at “speaking the language”, because otherwise the logic would never work 100%.
I’ve also subsequently tried to look through the code and found many different security flaws and functions that would only work a handful of times. There are many things I would rewrite if I were to launch the project today, because today I wouldn’t dare let users into the platform at all. But back then it meant nothing, because the only thing I thought about was whether the functions worked.
A funny little side note is also that, for example, in my code I would use wrong loops, and not the most efficient one. I would refer to points in the DOM again and again instead of storing global references, etc. A lot happens in 10 years, and it was an eye-opener to see how far I’ve actually come.
Writing code that others understand
Throughout my decade in tech, there’s one thing I’ve had difficulty with at times, and that’s reading and understanding other senior developers’ code and writing it so they can understand it. However, I haven’t had it easy either, as I’ve always worked side by side with highly educated developers with high standards, so instead of paddling a bit in the shallow end of the pool, I was thrown into the deep end and got to learn to swim from the start. I’m not saying that’s a bad thing, because it has definitely given me an enormous advantage compared to so many other self-taught developers. I sat with these highly educated people every day and could ask them questions so they could steer me in the right direction. I got an “education” on my own terms, and a bit like reading a book where you get to have a long conversation with the author, I got to develop myself and grill them about everything and thus have my “long conversation” with them.
Just as a side note: I’ve worked hard both day and night for the last 10 years to become the developer I am today. But I would never be able to do it if it weren’t for the fantastic people at Initiva AB in Gothenburg. They took me in when I still had all my flaws and invested a lot in developing my skills. I got to learn and ask questions day in and day out, and I’ll never forget that. Thank you Tommy for always giving a thorough explanation of why certain methods in frontend are better than others. Thank you Tobias for always being available with helph debugging and the difficult and heavier questions, and thank you Stefan for always being available with answers and help for the more complicated things.
Looking back, it was easy to learn to write code, but it took years of training to get to where I could read a developer’s code and then adapt my own to a uniform style everyone could understand. Being able to read a project’s code and then know what types of functions I should write and how it should be set up to fit into the existing structure was difficult. Because the logic was still there, but now it had to be done in a way that others found logical, and not always myself. This is a skill I think all developers should learn early, because being able to work with others is a must in our industry.
When sustainability entered the picture
Around the time I discovered how much websites can pollute, it also dawned on me that there was a difference in how code worked. To become more sustainable, I had to learn the difference between functions so I knew whether the code I was writing was the most sustainable version or not. I remember it wasn’t always easy to figure out, because funny enough there’s documentation for many things, such as which type of loop is most efficient, but there are, for example, no direct studies on which types of image files actually use the least energy.
The fact that there were gaps in this category told me two things. One was that it was a relatively new or forgotten area that no one has really spent energy on in recent years. And two, it was something I had to dive into to help create awareness about the topic.
Sustainability became part of who I am. All the code I wrote was carefully evaluated based on the knowledge I had, so instead of jumping to the most well-known loops, I first investigated whether another type would work better. For example, in some cases I could find advantages in using Binary search instead of the usual Find function. I went into the details. For example, I would think about not having to search multiple times in the DOM for an element, and all such things. Discovering digital sustainability completely changed the way I see and write code. Instead of thinking about it as something that just has to work, I now think the same way they did in the old days when they had to squeeze all the power out of the machine they could (I’m thinking specifically of the Apollo missions). Writing code is one thing, but writing it so it utilizes the machine’s power in the best way is a completely different thing. Suddenly you have to know the language inside and out, and suddenly you have to know the machine. It’s a big rabbit hole, but it’s also worth it. Because when you come out on the other side, you write code that you would never in your life have thought you could.
Today it’s fortunately also easier to write sustainable code. Instead of having to read endless documents and books about optimization, you can today take a function and run it through ChatGPT to get it to explain how you can optimize it for both sustainability, efficiency, and security. Understand me correctly, you shouldn’t just tell ChatGPT to do it, because that doesn’t make you a better developer. You should instead ask it to explain it to you, because when you’ve gained that knowledge, you’ll be able to look critically at the choices AI makes for you. Being able to understand and be critical is important if you use AI, because AI isn’t always right.
The senior developer complex
Something happens to you when you’ve worked long enough in the industry. You start to see patterns, patterns in how projects grow, and patterns in how decisions are made. And one of the patterns I’ve seen again and again is how senior developers, including myself, can fall into a trap where complexity becomes a sign of skill. The more advanced a solution is, the more capable you feel. The more layers of abstraction, the more impressive the code seems. But the truth is that complexity isn’t a goal in itself. On the contrary, it’s often a sign that you haven’t taken enough time to think the problem through.
I remember projects where I spent hours designing a system that could handle all conceivable scenarios. I built structures that were flexible enough for everything, but at the same time so abstract that it required a whole manual to understand them. And I felt skilled because I could see how well thought out it all was. But when I came back to the code months later, or when a colleague had to work with it, it suddenly became clear that I had created more trouble than value. The complexity hadn’t solved a real problem. It had just made it harder to work with the project.
Today I focus much more on reducing complexity. Not because I’ve become lazy or indifferent, but because I’ve realized that the best code is often the simplest. The code that does exactly what it should, without trying to be everything for everyone. I ask myself questions I didn’t ask before: Is this function really necessary? Can I solve the same problem with less code? What happens if I completely drop this layer of abstraction? And often it turns out that the answer is that the project becomes better without what I thought was essential.
It takes courage to say no to complexity. It takes courage to admit that the smart solution you’ve spent hours figuring out might not be the right one. But it’s also liberating. Because once you start building simpler systems, you discover how much easier they are to maintain, how much faster you can work with them, and how much more sustainable they are. Not only in an environmental sense, but also in the sense that they last longer, that they’re easier to build upon, and that they don’t break down at the slightest change.
I’m not perfect at it yet. There are still days when I’m tempted to build something more advanced than it needs to be. But I’ve gotten better at stopping and asking myself: Does this make the project better, or does it just make me happier? And if the answer is the latter, I cut it away.
The red thread
When I look back at the last 10 years, I can see a development that in many ways resembles learning a language. In the beginning, it’s about getting the words out, about being able to say something that just makes sense. You don’t think about the grammar, you don’t think about whether the sentence is elegant or precise. You just want to be understood. And that’s how I started programming. I wanted something to work, and that was enough.
But as time went on, and as I learned more, it became clear that there was more to it than just getting things to work. Just as you learn to write beautifully once you’ve learned to write correctly, I learned to write code that didn’t just work, but that others could read, understand, and build upon. I learned to think about how the code would look in a year, in five years, when someone else would take over the project. And I learned to see my own blind spots, the places where I had taken shortcuts or made assumptions that would later become problems.
Sustainability came in as an extra dimension. It was no longer enough that the code worked, or that it was readable. Now it also had to be efficient, both in relation to the resources it used and in relation to the impact it had. And that forced me to think even deeper about how things were structured, about what choices I made, and about what was actually necessary.
And now, after all these years, I’ve reached a point where I don’t just ask whether something works, or whether it’s readable, or whether it’s sustainable. I also ask whether it should even be there. Because the best code is often the code that doesn’t get written. The best function is often the one that doesn’t get built. And it takes more experience to know when to say no than it does to know how to build something complicated.
I’m not done learning. I never will be. But I’ve reached a place where I can see that each phase has had its value. The junior developer who just wanted things to work was necessary to move forward. The developer who learned to write readable code was necessary to be able to work with others. The developer who discovered sustainability was necessary to see the bigger perspective. And the developer who now focuses on reducing complexity is the next step on a path that never really ends.
I don’t know where I’ll be in 10 years. But I hope I’m still learning, still asking questions, and still trying to become better. Not just as a developer, but as someone who thinks about what it means to build something that lasts.