I'm a third-year computer science student and feel stuck about what to do next. I'm reasonably comfortable with algorithms, data structures, and coding interview problems, and I've built a few projects in different languages. Still, I don't feel confident solving unfamiliar, open-ended problems without relying on patterns I've already practiced.
There also seems to be an overwhelming amount to learn: languages, libraries, frameworks, tools, algorithms, software design, testing, and computer systems. I'm trying to figure out what the next stage of growth should look like. Should I build larger projects, focus deeply on one language, study how computers work, read more experienced developers' code, practice without looking up solutions, or simply build something meaningful and learn what I need along the way?
I'm especially interested in improving the practical problem-solving skills involved in taking an ambiguous idea, breaking it into smaller pieces, researching unfamiliar topics, and gradually producing a reliable working solution. I'm not looking for an algorithms study plan; I'd like advice on becoming a stronger programmer beyond interview-style exercises and on managing the feeling that there is always too much to learn.
5 Answers
Build something that has real constraints, such as a small application where multiple users have separate accounts and data. That forces you to think about permissions, authentication, databases, validation, failures, testing, and what happens when a second feature changes the first one. These are problems that coding exercises usually don’t ask you to handle, and solving them teaches a lot about reliable software.
The overwhelmed feeling probably never disappears completely. With experience, though, you get better at identifying what matters for the current problem and ignoring everything else until it becomes relevant.
You don’t need to master every language or framework in advance. Pick a practical stack for a project and learn new tools when the project gives you a reason to use them. A useful approach is to start with the highest-level problem, identify the ambiguous or risky parts, and make small prototypes to answer those questions. Break the work into milestones instead of trying to design the entire solution perfectly from the beginning.
Try to get an internship or another opportunity to work around professional developers. Seeing how people prioritize requirements, divide work, review code, test changes, and deal with production problems gives you context that isolated exercises can’t provide. A small team project with friends can help too, as long as you treat it like a real project with planning, version control, and shared responsibility.
The best next step is to build more serious projects rather than more tutorials. Choose something you genuinely care about and take the time to understand every part of it well enough to explain it. You’ll run into unfamiliar problems, make mistakes, research solutions, and gradually build the practical pattern library that experienced programmers use. Looking at established open-source projects related to your work can also show you how real systems are organized.
Don’t rush to finish just to add another project to your list. The difficult parts—debugging, changing an earlier design, and understanding why something failed—are where most of the learning happens.
Interview exercises are useful for recruitment, but they don’t cover most of what makes someone effective at work. Build software that is readable, testable, maintainable, and safe for other people to change. Pay attention to design, documentation, error handling, testing, and how code is reviewed. Working well with a team is a major part of becoming a good programmer.
That makes sense. A project with a server, database, login, user-specific data, and permission checks sounds like a good way to encounter several of those real-world concerns in one place.