Every now and then, I’ll be having conversations with fellow developers about various things we’re working on, working through, and looking to focus on in the coming days, months, or weeks.

And sometimes, when doing this, it seems like there’s a pattern where some developers are facing some of the same set of challenges as other developers (or they’re facing challenges that other developers have once experienced or maybe even yet to experience).

Case in point: Last week, I had several conversations in which I was talking with some others about the feeling of never feeling fully satisfied with code that you’re writing, or with that feeling that comes with wondering if you’re architecting a project correctly.

I think we’ve all been there at some point. Personally speaking, I don’t know if the feeling ever goes away. I think we get better at what we do, and I think we become more aware of what we don’t know, but I don’t know if we’re ever completely happy with what we ship.

With that said, I think there is something to learn as it relates to writing good code, and reaching milestones in our projects.

I can’t speak for how it works everywhere, obviously, but whenever we’re growing up and going through school in the United States, we’re normally taught that for each question, there’s a right answer and there’s a wrong answer.

This is usually true in most classes, too. It doesn’t matter if you’re talking about History, Literature, Math, Physics, and so on. We’re conditioned to have this binary mode of thinking where we either know something or we don’t, and if we don’t then we lose points.

But if you get into the field of computer science or computer programming (and other fields, as well but I can only speak about what I know :) and you carry that mentality with you, then you’re always going to wonder about what it is that you’re writing. By that, I mean we take that binary mode of thinking and we either think that we have the correct way to write the code, or the incorrect way.

Your Code Is Not Wrong (Or Right)

I think that we can do a better job of stopping to think about the varying degrees of correctness, for lack of a better term, that comes with writing code. That is, sometimes it’s enough just to get something working, other times you have to optimize for speed, and/or for scalability, and/or for maintenance.

I think it’s really hard to actually achieve an optimal level of all of the above (and for those that I’m missing). I will say, though, that settling for just getting something working is rarely acceptable in large-ish production environments.

We should aim write code that reads well, scales, that is able to be maintained over time, and that can be handled by a team of developers.

So if you’re a developer who’s currently struggling with the “is this code right or not?” Don’t worry about trying to find the right answer. There’s rarely, if ever, a single right way to achieve something.

Instead, focus on learning better practices, reading code and articles by seasoned developers, striving to refactor code that you touch, and aiming to write the best code possible given what you currently know.

Then aim to do it all again.