Own your code!

Paul Heintzelman
Paul Heintzelman
Published in
3 min readAug 4, 2018

Treat all your team ‘s code as if you wrote it.

That garbage code that intern wrote last summer, guess what, it’s yours. Your main application’s architectural problems, those are your architectural problems. That strange technical decision made years ago, also yours.

Why? Because your company isn’t paying you to write code, they are paying you to own it. Your project manager isn’t reading programming books on the side, so that they can fix your code. The CEO isn’t going to pop in and do some critical refactoring. And why not, because it isn’t their job. It’s your job.

Some reasons you may not be owning your code now.

A more senior dev will fix it

In general people love fixing everything while you loaf about. How do you think that dev got more senior than you? It isn’t about years. They’ve been up to their elbows in problems and it’s made them a good engineer. It is past time you jump in and help and become a good developer too. Because if you don’t know how to fix things then you don’t know how to write good code. If you aren’t fixing problems then you are a problem.

Everything looks fine to me

Some people on the team gripe about things but you just don’t see it. Learning to identify problems and finding solutions is a core developer skill. If you aren’t good at it, get good at it. Ask the people who are fixing things what is next on their list and offer to help. If there aren’t any of those people then you need to become one of those people (or find a new gig). Start making a list of everything that could be better, ask your teammates. Prioritize the list and find a way to start making it happen.

If I touch it it will break

If you have this fear then you don’t have enough unit tests. This is what unit tests are for, not only should they tell you what will break if you touch a piece of code, they should also tell you what you need to fix. So instead of fixing that code write more unit test. But you can’t write proper unit tests because the dependencies are jacked up. Great, start by fixing dependencies.

I don’t have time to fix anything

It takes me all the time I have to work on the tasks I have. Bad code slows people down, which means if you don’t start fixing things you will go slower and slower as time goes by. Instead you should fix things as you go, so that you speed up over time. I try to make everything I touch roughly 10% better, that may not sound like much but it is enough that over time the codebase continuously improves.

Also be more of a team player. It isn’t just about what is on your plate but about your whole team. If others on your team are finding time so can you!

The team doesn’t have time to fix anything

There are legitimate times to accrue tech debt. Your start-up really needs that feature done to make a sale. A project needs to start but critical information is still unknown. Pay attention to what problems you and your team are creating. Do your best to mitigate them be using design patterns and following best practices. Most importantly, communicate this technical debt to the business, by going fast now we will be slowed down in the future. Try to explain by how much and why.

--

--