I started a recreational project a while ago: a simple 2D shooter in C++ using Raylib. I'm studying computer engineering and already have reasonable experience with Java, Python, and C, but I'm still trying to bring my C++ skills up to the same level. I created a public code repository so I can track my progress and let others review the project if I need help.
Recently, I've become increasingly anxious about whether I'm making the correct technical decisions. I repeatedly question things like whether I'm following best practices, whether a data structure should be stored directly or behind a pointer, when dynamic allocation is appropriate, and whether the overall structure of my code is good enough. I'll make a decision, second-guess it, rewrite it, then reverse the change again.
This makes it difficult to make progress, and I sometimes worry that a future employer might look at the project and decide that I'm a poor programmer. I'm sure some of this comes from being inexperienced with C++, but I also have OCD, which may be contributing to the repeated checking and uncertainty. How do you handle this kind of anxiety and avoid getting stuck trying to make every line perfect?
5 Answers
If OCD is driving repetitive checking or making it hard to function, generic programming advice like “just stop worrying” may not be enough. It could be worth discussing the pattern with a qualified mental-health professional, especially someone familiar with OCD. For the project itself, you can also keep the repository as a record of your growth; employers generally don’t expect a student’s side project to be flawless.
Try to build a functional version within a reasonable time first. Once it works, consider whether a change is actually justified by performance, maintainability, or the possibility that the system will grow. You don’t need to apply every pattern or optimize every detail immediately; prioritize the changes that have a real benefit.
For C++, ownership is usually a more useful question than simply asking whether something should be a pointer. Store an object directly when the containing object owns it and its lifetime naturally matches the container. Use a raw pointer or reference for non-owning access when the lifetime is guaranteed elsewhere. Use std::unique_ptr for most dynamically allocated ownership, and reserve std::shared_ptr for cases where shared ownership is genuinely required. Avoiding unnecessary dynamic allocation often makes the design simpler.
Code is a learning process, not a permanent monument. Get the project working, and if you later learn a better approach, refactor it. Looking back at old code and thinking you would do it differently is usually evidence that you’ve improved, not that you failed.
There usually isn’t one universally correct design. Real code is full of trade-offs involving clarity, lifetime, performance, testing, and how much change the project is likely to need. A working, understandable solution is often more valuable than a theoretically perfect one. Set a time limit for choosing an approach, document the decision if it matters, and move on unless new evidence shows it needs changing.
That makes sense. I think I need to focus more on getting something working and only revisit decisions when there’s a concrete reason, instead of treating every uncertainty as an emergency.