When you first start working as a software developer, it’s natural to want to show off your newly learned coding skills. It may be tempting to tear up that nasty code and lay down something beautiful in its place. Don’t do that. Instead, just work on what you’re assigned.

There’s a really simple reason for this. If what you end up working on doesn’t line up directly with the business goals, it will look like you’re slacking off.

Even if you think you’re doing the right thing, and even if what you’re doing is useful, other people you work with might not see it that way. To illustrate this, I have a slightly unfortunate story for you. A story in which I was wronged by a combination of doing the right thing at the wrong time and supervisors having no management training.

When I was 18, I was a delivery driver at Round Table Pizza in Colton, CA, and one evening I was wrongly written up. I don’t really blame some minimum wage supervisor whose name I don’t recall being poorly trained by the restaurant manager who was also not a well-trained manager, but it still illustrates something important. Here’s what happened.

It was a busy night and several people were working in the kitchen. I was between deliveries, so my job was just to work in the restaurant doing whatever needed to be done — take calls, clean, make pizzas, and so on. At the time in question, I saw that things were busy and there were several people on the pizza line making food. I looked around for something that wasn’t being done and decided to clean the cooking trays.

We had these round and square trays that pizzas were cooked upon, and they sometimes got all nasty and crusty with caked-on cheese bits. They needed to be cleaned before being reused, and there was a big pile at the end of the cutting station. I worked scraping them because the pizza line would need more soon.

After a while, I heard one girl say, “Are you going to write him up?”

The supervisor that night said he was going to write him up. Being naturally curious, I thought it was amusing that someone would get written up, so I asked who. I thought his one-word response as he walked by was quite odd. He said, “You.”

At the end of the evening, when everyone was starting to clean up and the customers were trickling out, the supervisor sat me down and formally wrote me up for slacking off. I just sat there and nodded as he told me why I was in trouble — I should have been on the pizza line. I told him I saw work that needed to be done, several people were already on the pizza line, and nobody had assigned any other task to me. He either didn’t care or hadn’t thought of it that way because my words fell on deaf ears. I did what I thought needed to be done, and then got in trouble.

Being young and inexperienced in such situations, I signed the paper. The next day when I came in, the store manager called me into her office — one of those tiny restaurant offices with room for only a chair and a calculator — and told me it was important to be a team player and not to let the slacking off happen again.

As she was saying this, I was thinking something along the lines of, “What is she even talking about? This is dumb.” And then I nodded and went on with my shift.

I quit that job just a few weeks later, and to be quite frank, those people were idiots. OK, maybe that’s a bit harsh. They were severely untrained.

This whole situation could have been avoided if the supervisor had simply said, “Caleb, work the pizza line.” I was young and eager and would have gladly worked on any task assigned. I was not slacking off in the slightest, and I would have moved over to making pizzas (they’re kind of fun to make on a line). I was doing work that needed to be done, just maybe not right then. The fact that at least one other person besides the supervisor thought I was slacking off — yet nobody said anything or asked why I was cleaning the trays — means that maybe it appeared to others that I wasn’t working on what was the most important at the time.

The same thing can happen at your software development job if you don’t work on what’s assigned to you. While I got in trouble at my pizza job because nobody assigned a specific task to me and I found work to do, that likely won’t happen to you while writing software. You’ll be assigned a task. When you’re working on that task, you might see something else that needs to be done, because it’s going to cause an issue in the future. Don’t work on something else just because you see something else to do.

The Code is a Huge Mess!

I know how it can be…you get assigned a task and the code you look at is a huge mess. The desire to fix it can be strong, and sometimes the motivation to fix messy code comes from a place of survival.

You see the technical debt introduced years ago. You see the problems you’ll face months down the line as you have to maintain, expand, and improve the code. You just want to dig in right now and get it done. That will give you a nice, clean codebase to work with. A place you can work your magic.

Don’t do that. Don’t lay waste to the codebase.

Looking at the code as a mess is the wrong way to look at it, even if it’s a huge, gross pile of almost-cobol. It’s important to remember that what you’re digging into is working production code that serves a business purpose. That’s not something to just rip into with abandon because you think you can refactor the code into something better.

Is Refactoring Really the Right Thing to Do? Why Not Rack Up Some Wins Instead?

When you’re starting a new job, you’ve gotta rack up some wins. You’ve got to instill confidence in your boss and your team that you were a good hire. Do you want to appear to be a good decision or a bad one?

Even the smallest job in the messiest bit of production code is a chance to familiarize yourself with the codebase. Use that chance to knock out fixes and improvements and show everyone you can complete tasks quickly and correctly.

Even if you start off working in the development section of the code pipeline, you need to do the same thing. Treat it like live production code. The end goal of development is to create a production-ready product, so you need to approach the code as such.

Production code solves a business purpose, so it’s there for a reason. Do not break it. That’s not a good use of your time, and likely not what you’re being paid to do. It might be tempting to refactor that mess into something elegant, but if you’re new and you don’t know the whole system, you run the risk of accidentally breaking something. Just from a practical standpoint, breaking things isn’t the best way to start a new job. Go for a bunch of little wins instead, because they add up to you looking like you know what you’re doing. And that will keep the paychecks flowing.

Talk to People About Issues You Find

Instead of just working on something you think needs to be done and getting written up at a pizza delivery job, talk to your team lead about the code. Communication can stop potential problems in their tracks.

If you find code that could cause problems in the future, or even if it’s just so messy it’s hard to follow and a nightmare to maintain, talk to your boss about it. Ask why it’s the way it is, and if you could have the opportunity to clean things up a little bit. Maybe it’s a known problem that is already in the project pipeline. Maybe there’s a security hole nobody has seen until now and your boss will want it fixed right away. Let the team put it into their workflow using the normal process. Don’t just fix things willy-nilly.

There are several reasons why code is the way it is, and even the worst bit of code you come across can be perfectly fine if it serves a business purpose. Your job isn’t to fix everything you come across, so communicate the issue and then stop worrying about it. Move on to your next assigned task.

You weren’t hired to lay waste to the codebase and raise it up anew. You were hired to make the business more money. You’re not there to write elegant code, make pizzas, or cast wizardly spells at the server. You’re there to make the company more money. If you want to stand out, ripping apart the codebase isn’t a good way to do it. Find ways to provide value within the standard framework, and you and the code will be fine.

Besides, refactoring isn’t all it’s cracked up to be.

Feel free to subscribe to my YouTube channel for more content like this and also not like this.