I'm a third-year computer science student and feel stuck about how to become a genuinely good programmer. I'm reasonably comfortable with data structures, algorithms, and coding interview problems, and I've built a few projects in different languages. However, I still struggle with approaching unfamiliar problems that don't fit a pattern I've already practised.
There also seems to be an overwhelming amount to learn: languages, frameworks, libraries, tools, architecture, testing, and computer systems. I'm trying to figure out what the next stage should look like after learning the fundamentals. Should I build larger projects, focus deeply on one language, read more existing code, learn more about how computers work, practise without looking up solutions, or simply build something useful and learn whatever I need along the way?
For experienced programmers, what helped you make the transition from solving exercises to designing and building real software? In particular, how did you improve your ability to break down unfamiliar problems and decide what to do next without feeling like you need to learn everything first?
4 Answers
Choose a problem that matters to you and work on it slowly enough to understand every part. Let it break, investigate why, read documentation or existing implementations, and fix it. That repeated cycle teaches more than endlessly completing isolated exercises. You don’t need to master every language or framework in advance; learn a tool when your project gives you a reason to use it.
Try to get an internship or work alongside developers if you can. Seeing how a team plans work, reviews code, prioritizes trade-offs, and maintains software over time gives you experience that exercises can’t provide. When facing a new project, define the broad problem first, identify the ambiguous parts, and build small proof-of-concepts to answer the riskiest questions before committing to a full design. The feeling of being overwhelmed may not disappear, but you’ll get better at deciding what can safely wait.
Build a few serious projects instead of following tutorials. Pick something that genuinely interests you and take it far enough to deal with authentication, persistence, deployment, testing, failures, and changing requirements. While you work, study established projects that solve similar problems. A lot of unfamiliar problem-solving is pattern recognition built from seeing many real examples.
Interview problems are useful for learning efficient algorithms, but they don’t cover most of what makes someone effective at work. Spend time on readable, maintainable, testable code: clear design, documentation, error handling, and safe changes. Good programming also involves communicating with teammates and writing code that other people can understand and extend.
A useful project would be a small multi-user application with a server and database. Make sure users can log in and only access their own data. That forces you to think about permissions, SQL, security, validation, client-server communication, and how to test cases where things go wrong.