DEV Community

Cover image for I Used to Think Getting Better at Coding Meant Writing More Code
nocklock
nocklock

Posted on

I Used to Think Getting Better at Coding Meant Writing More Code

For a long time, I thought becoming a better developer mostly meant knowing more things.

More Java.

More Spring.

More libraries.

More tools.

So whenever I felt like I wasn't improving fast enough, my answer was usually the same.

I needed to study something new.

Lately, I'm starting to think I had the wrong measurement.

I used to care mostly about whether the code worked

When I was building something, getting the feature to work felt like the finish line.

The API returned the response I expected.

The button worked.

The data showed up on the screen.

No errors in the console.

Good.

Next feature.

I don't think that way was necessarily wrong.

When you're trying to build something, you need to make things work.

But while building my recent project, Security Lens, I started noticing something.

The questions I was asking had changed.

Instead of only asking:

Does this work?

I started asking:

Why does this work?

And sometimes:

Where will this stop working?

That second question has caused me a lot more trouble.

But I think it has also taught me more.

Deployment made this painfully obvious

I've written about this a few times recently because deployment exposed a lot of assumptions I didn't know I had.

My Spring Boot application worked locally.

Then I tried to move it outside my machine.

Suddenly, things I barely thought about became important.

Ports.

Environment variables.

External services.

Configuration.

Build behavior.

All the little differences between localhost and a real deployment.

At first, each one just looked like another problem to fix.

Fix the port.

Fix the configuration.

Deploy again.

But after doing this repeatedly, I noticed my behavior changing.

Now when something works locally, I'm less likely to immediately think:

Done.

I start wondering what made it work.

Is there a local configuration I'm depending on?

Is something running on my machine that I forgot about?

Would another person be able to run this project?

What happens if the environment changes?

I definitely didn't ask all of those questions before.

I also started reading errors differently

This one is harder to measure.

Before, when I saw an error, my instinct was often to get rid of it as quickly as possible.

Search the message.

Find a similar problem.

Try the solution.

If it works, move on.

I still search error messages, of course.

Probably always will.

But now I try to spend a little more time understanding what the error is actually telling me.

Not because I've suddenly become extremely disciplined.

Mostly because I've learned that fixing something without understanding it has a strange habit of bringing the problem back later.

Sometimes in a slightly different form.

And usually when I don't want it to.

Even README files started looking different

I used to think of documentation as something you wrote after development.

The code was the real work.

The README explained the real work.

That changed when I tried to write a README that someone else could actually use.

I had to explain how the application starts.

What configuration it needs.

What services it depends on.

What someone needs before running it.

And while writing those things down, I found assumptions in my own project.

Things that were obvious to me only because I had built it.

That was uncomfortable.

But useful.

Documentation wasn't just explaining my code anymore.

It was testing whether I actually understood the environment around my code.

The strange part is that I'm writing less code sometimes

This is probably the biggest change.

There are moments now when I spend more time checking logs, reading documentation, looking at configuration, or trying to understand a failure than actually typing code.

A few years ago, that probably would have made me feel like I wasn't really developing.

Now I'm not so sure.

Writing code is obviously part of being a developer.

But maybe the job isn't measured by how much code I can produce.

Maybe it's also about how many assumptions I can notice before they become someone else's problem.

I'm still learning this.

And I still have plenty of moments where I change something, see that it works, and think:

Great. Don't touch it.

So I'm definitely not claiming some dramatic transformation here.

But something has changed.

My questions are different now

I don't know if I'm a better developer than I was a few months ago.

That's difficult to measure from inside your own head.

I still get stuck.

I still search things that I feel like I should already know.

I still break things.

But the questions I ask while coding are definitely different.

It used to be:

How do I make this work?

Now, more often, it's:

Why does this work?

What am I assuming?

What happens when the environment changes?

Could someone other than me run this?

Maybe getting better at development isn't always about knowing more answers.

Sometimes it's noticing that you're starting to ask better questions.

And lately, that feels more like progress to me.

Top comments (0)