How much to value correctness in solving problems

[okkee]

Resolution for 2025 is to become at least somewhat adept with python, c and javascript. One of the resources I'm using to learn is exercism and I was wondering if simply solving a problem is enough or if I should try to solve it in the most efficient way. I'm still kinda new to this but I also want to get a good grasp on the language. So should I just solve them however and come back later or focus on getting in the best solution now?

[theereal]

This is perhaps the age old question of what is "good code" and what is a "good solution". Tbh it really depends on the project. Generally in short-lived projects, like a single player game, where the codebase is to be written once, then forgotten, and performance is crucial, writing "dirty but fast" code is perhaps the best approach. But if youre working on a system that is supposed to live for years and years on end with different developers coming onto the project and others leaving, its often better to write code that is easy to read but is less performant. Since modern computers in most application scenarios can simply brute force, and most applications arent seriously performance critical, like those running on modern personal computers or smartphones, its better to loose some performance, in return for the code being readable and expandable by others.

 

TLDR: It depends, are you writing a performance critical application like on a raspberry PI or a video game? Or are you working on a more common "standard" computer application that will live for years and be developed by multiple people?

[Avocado Diaboli]

In programming, there's often not a one-size-fits-all best solution. It depends what you're after. An incomprehensible one-liner might perform better, but it's a bitch to debug or get back into if you're coming back to it half a year later.

 

What I'd generally advise is that in order to progress with programming isn't to just solve exercises for their own sake, but to take up small personal projects that you find interesting yourself and figuring out how to create something practical that you think would be neat. And don't worry if a solution to that problem already exists elsewhere, the idea is that it's something you've made and therefore a problem you've worked through with your own motivation.

 

Encountering a problem for the first time and looking up information on how to tackle it is invaluable, because it also teaches you how to navigate documentation and message boards where other people have asked about the same problems as you. That's a skill that exercise sites usually don't train, but one I'd say I use at least once on every day that I program something. 

[BootlessBuck]

“Make it work, make it right, make it fast.”

 

Solve the problem first, by whatever means necessary. Then you can worry about making it more maintainable, more elegant, etc. Then you can worry about making it performant. 

 

How far you go depends on the needs. For some throw away code, just making it work may be enough. For code that needs to stick around and be tweaked and tuned over time, doing some extra work up front is worth it for your sanity later (and the sanity of others if they will also work on it). Making it fast is only really needed if the code actually needs to be fast. I have seen a lot of people stress about the speed of different types of loops or whatever, when their dataset isn't big enough for it to matter, nor is their code run enough for it to matter. Most people aren't coding for large datasets at Google. For my work, if something takes 60 seconds or 90 seconds, no one cares.

 

For learning, going through the motions is still good, and helps build good habits and ways of thinking about problems and solutions. In practice, keep the goal in mind and don't get hung up on trivial stuff that doesn't matter to the big picture.