I've mostly been learning by building projects, making mistakes, and trying to improve the next version. That has helped, but I'm wondering what else I should be doing to develop better coding habits. Would reading open-source projects, getting code reviews, or submitting pull requests be useful?
I often learn a new language or framework while working on something complex, so I use "I'm still learning" as an excuse for messy code. I'm also not sure what parts of a project are useful to show someone for feedback, especially when the code seems random outside its original context. I'd like to get better at breaking code into sensible sections and understanding what makes a design maintainable.
I've recently gone deep into building my own operating system, but I've barely studied other people's code. The project is interesting, yet I'm starting to feel locked into it and worried that I'm avoiding broader practice. Reading other projects sometimes feels like time I could spend learning concepts directly, and I'm not confident enough to contribute to open-source projects while I'm still learning the fundamentals.
This concern was triggered when someone said my code was bad but gave no useful explanation when I asked how to improve it. I know my code isn't perfect, but I'd like practical ways to evaluate it, learn from criticism, and gradually write clearer code.
5 Answers
Revisit your own code after some time has passed. Code that seemed perfectly clear when you wrote it may look confusing months later, and that contrast teaches you a lot about naming, structure, and unnecessary complexity. A book or guide on design principles can provide useful vocabulary and examples, but treat its advice as a set of ideas to evaluate rather than strict rules.
Regular peer review is one of the most effective ways to improve. Having to explain why you chose a particular structure or abstraction makes you notice whether the decision is actually justified. Try finding a study group, programming partner, or project where people review one another’s work. Reading open-source code can help too, but finished code doesn’t always reveal the problems or trade-offs the authors faced.
Writing tests can reveal design problems. Code that is difficult to test is often doing too much or has tightly coupled pieces. Start with small functions, clear and consistent names, and code that has one obvious responsibility. Also, criticism without examples or suggestions usually isn’t very useful, so don’t treat an unsupported judgment as a complete assessment.
I hadn’t thought of tests that way, but it makes sense. Improving my testing is probably a good way to expose awkward designs and make the code easier to work with.
There isn’t one universal definition of clean code. A practical process is to write a first version, use it, then revise it when you understand the problem better. Over time you’ll recognize useful patterns and language features. Studying examples, experimenting, and refactoring are all part of the process; you don’t have to produce perfect code on the first attempt.
I agree that cleanliness is more of a spectrum than a fixed standard. I’m mainly worried about missing techniques I wouldn’t discover on my own, so examples and reviews would probably help fill those gaps.
A useful resource is Robert Martin’s *Clean Code*, although some of its recommendations are debated. Take the principles that improve clarity for your situation and question the parts that feel too rigid. The important thing is to combine reading with practice: apply one idea to a real project, then see whether it actually makes the code easier to understand and change.
That makes sense. Explaining and defending a design would help me understand what holds up, while also making criticism feel less personal. I’ll look for a group or partner that does constructive reviews.