Why I Don't Spend My Time Fixing Bugs Anymore

Why I Don't Spend My Time Fixing Bugs Anymore

All I wanted, was to build an app. But what I found was even more amazing.

Back in 2000, I had one goal

I wanted to prove myself that I can do this programming thing. So I decided to build a small but useful application that would help me convince all my friends that I am a lot smarter then they are :) Best goal ever!

And after too much brainstorming (it was more than 2 minutes, I’m sure it was), I’ve decided that my project would be a contact management application. And the main features were going to be the following:

  • Add all my contacts
  • Store them into a database
  • Display them on a web page

Easy, right?

At the time, I was playing with a language called Perl, and I was determined to learn how to use it. And for a little while, I even enjoyed it. Except that if you wanted to build something for the web with it, the process was brutal. You could tell the language was not created with that specific goal in mind.

Also, the community support was not there. Or at least I couldn’t find enough help to move forward. All the cool kids were using PHP, which had the advantage of being a language built with the web in mind. For some reason, though, PHP didn’t appeal to me at all. I don’t know what it was; maybe it was just me refusing to accept the status quo.

So I tried to build a website with this Perl language, and I wouldn’t say I liked the experience at all. So I started to look for something better.

DHH’s blog video got me

Lucky for me, right around that time, DHH’s tutorial on how to build a blog in 15 minutes was just released. So when I saw that, I was immediately hooked.

Not only that, but the language he used looked amazing. It was like reading English, not code. So needless to say, I was sold. I wanted to use this new language right away.

So I was learning Ruby on Rails, and I got to a point where I managed to build a simple contact management application, but it was nowhere close to the ones I have seen all over the web. It looked and felt like a toy project.

But, even that achievement was incredible. It made me feel good about myself. And the fact that I can build something so quickly that others could see and use was just unbelievable.

Digging deeper

So I wanted to dig deeper and learn more about this awesome language that I have just discovered. I managed to get a job at a startup that was willing to let me learn Ruby while I was helping them with CSS.

Now I was able to learn Ruby on a real production-ready project from people who were years ahead of me in every direction.

That opportunity made me realize how little I knew, and how much there was to learn. I wanted to be able to write code like I’ve seen them write.

Their code was incredibly complex, or so it seemed to me at the time. It felt like I was discovering this new world, an amazing new adventure.

But more importantly, I wanted to be seen as a valuable member of the team, and help them build the product.

Startups in general need to use every resource they have to build a successful product in the shortest time possible. And I wanted to be a part of that, I wanted to help them succeed.

Learning Ruby, and breaking stuff

So I kept coding, and learning, and coding and learning about Ruby and all the language features and such but even though I was making progress in that direction, it didn’t seem to make a difference in the overall scheme of things.

Because no matter how many smart things I’ve learned about Ruby, my code kept breaking other people’s code.

I thought if I could concentrate more, work longer hours, get more features done, etc. maybe that would compensate for my lack of skills. But that seemed to make things even worse.

My code was breaking even more often now, and it got to a point where the only solution was to manually check everything after I made a change. That meant going through all the pages (a few hunderd of them), and making sure that I didn’t brake anything.

I had enough

And that was the last straw. I knew there’s gotta be a way I could make sure that my code wasn’t breaking everyone else’s without all that manual labor nonsense.

And then….

As I was looking through other people’s code, I noticed these weird files that didn’t look like code, but were somehow part of it.

So I decided to investigate, only to realize that Ruby had a built in solution for my problem. There was actually a way to test your code in an automated fashion, before you send your changes in.

That seemed to be what I was looking for. If I would write some tests, I could make sure that every time my code gets sent to production, it’s also tested so it doesn’t break anything.

New goal

So now, that was my new goal. Write tests each time you have some code you need to make sure it doesn’t cause any unexpected problems.

So I did write some tests, but it was hard. It made no sense at all, it wasn’t like the Ruby code that I liked so much, and I couldn’t understand how to do it properly, or which parts I needed to test.

But I did write a few tests, and so I was back on track. I was writing new features, sending my changes in and then… guess what.

My code kept breaking. It was like nothing had changed, even though my code now had a bunch of tests as well.

First try

In other words, I spent a lot more time to write the same code, with no real benefit. So instead of fixing the problem, I made it worse.

At this point I was convinced that if I was to write better code, I had to learn how to do this testing thing right. Because I knew there was no way I could manually test everything every time I made a change, the application was huge, it would take me hours of manual testing for even the smallest change.

I knew that the only way I could make it work was to make sure that those tests would give me 100% confidence in my code. So I decided to go all in and learn everything I can about writing tests. I wanted to watch all the courses, read all the books, etc.

I’ve made it

And I did read a lot, and watched a lot of courses, and asked around, and everything else I could think of. Until finally, after a few years, I’ve made it.

I got to a point where I was 90% confident that my code was going to work the way I want it to, and that it wouldn’t break other people’s code in unexpected ways.

But the best thing that happened because of it is the fact that I am now 1000 times more confident that I can contribute to any project in a way that makes a difference.

If you liked this article, please take a moment and say thanks by sharing it on your favorite social media channel.