Stop Writing Good Code

When I first started coding, my standards for code were simple: if it worked and didn't take forever to run, I couldn't care less what it looked like.

Then I learned more fundamentals, read that Clean Code book, and took every memory optimization technique I learned in school too seriously. Suddenly, I started forming opinions about what "good code" looked like.

Now, no longer when I started a new project, would I jam everything into one function. Nope, I would create 20 classes spread across 40 files and try to avoid dynamic memory allocation like it was the plague because that's what "real engineers" do… right?

Then, I'd finally run my "well-engineered" todo app, only to realize that my entire assumption about how the app should work was entirely wrong. Now I had to refactor 10 classes and 20 tests, and after a few days of misery, I would re-run it only to discover that, once again, my assumption was wrong.

Meanwhile, if I had just jammed everything into one messy function like my "naive" old self would have done, I would've figured out I was wrong in like 20 minutes instead of a week.

It took me way too long to realize this, but these "oh-crap" moments are unavoidable in software engineering, and this is exactly why the best engineers write bad code. At least at first…

Being wrong is your job

You may think these "oh crap" moments are skill issues, and some of them very well can be; however, in the real world, these "oh crap" realizations are often entirely outside your control.

Realizing that you're wrong about something could look like:

• Your UI design won't look good with real data
• Your co-worker tells you there is an internal library that does what you just built
• Your data source has an edge case rule that breaks your assumptions

Making your code more generic isn't gonna save you in these instances, despite what you may have learned in school; what will help you though is learning how to realize you are wrong faster.

Improving your time to being wrong

The faster you can identify your mistake, the sooner you'll be able to ship your app.

It's not rocket science to learn how to realize you're wrong about something faster. Try to get the code to run and solve a very minimal version of the problem at hand, and then, and only then, should you clean up some of that code to suck less. Your code quality should scale equally with your understanding of the problem at hand because the more you understand a problem, the more you'll be able to focus on the right abstractions / optimizations and filter out the noise of things that don't.

The real value of AI

AI is really great at creating quick prototypes and getting a minimal viable version of something working. However, it's not great at writing high-quality production code that covers all edge cases and aligns with you or your team's coding standards. If the key metric is optimizing your time to realize you're wrong about something, AI is a fantastic tool for this. You'll be able to focus more on what the actual problem is at hand and what the edge cases are, rather than how you're actually going to write the code.

Don't get attached to code

When you write code, you are typically writing code as a solution to a problem. As time goes on, problems change, and so do the solutions.

The harsh reality is that, because of this, almost all code that is written is eventually rewritten or completely discarded. So, don't get attached to your code, and don't feel personally attacked when you see it thrown away or someone else rewrites it. It's just part of software engineering, and the faster you come to peace with that, the quicker you'll become a great engineer.

Not getting attached to code will also make you a lot more enjoyable to work with, as you won't be trying to defend your code like it's your only child at every turn whenever someone mentions an improvement. The more enjoyable you are to work with, the higher the chance you have of actually moving up in a given job. Career success isn't based on how good a coder you are. It's your ability to make other people enjoy working with you.

How to make your projects less painful

When you start a project, start it the way you did when you first started learning to code. Just try to solve the problem at hand. Only when you get something to work, and your understanding of the existing problem deepens, should you optimize your code and make it look good. Trying to write good code too soon is a recipe for disaster, and you'll probably end up optimizing the wrong things. So don't be afraid to write bad code, and don't get too attached to your code because all code ends up being junk code.