I thought I'd write a small post about something that can both hinder and help a beginner programmer: wanting to write perfect code.
It may come across as obvious when I say this is impossible, we've all heard the saying "don't let perfect be the enemy of good", but it's easy to forget these things when we are in the middle of learning a new language, especially as a beginner. After all, you want to make sure you're doing things the proper way. If not, what's the point in following tutorials and coming to sites like this one if we are just going to ignore the advice we come across. I think what sparked me to write this post was seeing this thread on Reddit. It seems that there must be a balance between clean code and meeting deadlines, whether those deadlines are set by ourselves, an employer or a client.
1. Make It Work, Then Make It Pretty
Okay so I think this short phrase has really helped me out over the last few days, I've been learning a new language and really engaging with the course I'm following. Whilst it's super motivating and nice to follow a structured course, it can also be frustrating to see examples on codepen that are so much cleaner than mine, doing the same job in half as many lines of code. But that's when this saying needs to be remembered! If you find yourself comparing the code to your first project in a new language to something you have found online, remember this.
You're still in the "make it work" phase. They're in the "make it pretty" phase.
You can be forgiven!
2. Practicality
This phrase can also be applied in a practical sense. If you find yourself spending a lot of time on each section of code to make it run as efficiently as possible, that's a good thing, it means you have an eye for detail and don't want to produce projects to a lower standard than what you've personally set. But you might find that separating concerns out, into first getting the code to work and then making it efficient and readable might be a faster way of working. It's usually easier for us to focus on one thing at a time, so it we spend a long time cleaning up code we might lose track of what we were doing in the first place. Dividing up your work flow and accounting for time, perhaps at the end of each session, to tidy everything up could work to your benefit if you have an eye for detail but also have deadlines.
3. Subjectivity
When you're in the "make it pretty" phase, there's a lot you could do to achieve that end. In other words, don't get stuck in a paradox of cleaning up your code, because there's a lot of ways to do things. You can divide code up in quite few different ways and it will still be readable and concise. There is a level of personal preference when it comes to coding: which naming convention you use, which reset you use, which preprocessor you like, which library is better. Find what you like, which does the job for you best and work with it for a while. If limitations come about, do some research, but don't get stuck. These tools are here to make coding easier and more powerful for us, after all.
Top comments (6)
Speaking from personal
experiencemistake, make sure to commit (or otherwise save) your working, non-pretty code!More than a few times I've had perfectly working (albeit sloppy) solutions that break after cleanup, and then I just have to just re-solve a problem.
So true, plus its satisfying to see your progress over time
Follow this advice in small increments. Fully completed projects that work never get cleaned up and become the thing no one wants to touch.
This advice is as great for beginners as it is for very experienced people!
I was thinking this, almost more so
An experienced developer might have too high standards for themselves or be anxious that their code isn't good enough for someone at their level
What really helps me with this is TDD. You just make it work until the tests pass, then you can make it pretty and have the confidence that it still works.