I've been learning programming on and off for years: Basic as a kid, Python through online courses, Java in community college, and some C and assembly. I'm currently working through a structured programming course and practicing algorithm problems, but I keep falling into the same pattern of studying without actually building anything substantial.
I'd like to create a Dungeons & Dragons character-building tool that tracks things such as races, classes, attributes, spells, and character progression. The idea interests me, but I have no idea how to break it down or decide what to build first. I also struggle to understand larger codebases because the architecture, naming, and number of moving parts feel overwhelming.
I'm transferring to a university to study math and computer science, and I want to develop practical skills that will help me qualify for internships, build interesting projects, and eventually contribute to open-source software. How do I start turning an idea like this into manageable steps? Are there books or other resources that can help me transition from academic exercises to real-world software engineering?
4 Answers
There is no universal architecture that you have to discover before writing the first line. Make a simple version that works, even if the design is rough, and let actual problems guide the next improvements. A small game such as Pong or Snake is also good practice because it gives you a clear set of requirements without requiring a huge system upfront.
For the character tool, begin with the data rather than trying to design the whole architecture. Represent one character with a few fields such as race, class, ability scores, hit points, and perhaps a list of spells. Write a tiny program that can create and display that character. Then add one feature at a time, such as calculating modifiers, changing hit points, or adding spells. As new requirements expose weaknesses in the design, refactor it. Most projects are built through that cycle rather than perfectly planned from the beginning.
You don't need to understand an entire large codebase before learning from it. Pick one small feature or file, trace what calls it, and research unfamiliar pieces one at a time. At first you may understand only a tiny part, but repeated exposure helps you recognize common patterns. Large applications are complicated because they contain many individually manageable components.
Start much smaller than the complete character builder. For example, make a basic dice roller first. Once that works, add multiple dice, common skill-check shortcuts, roll history, statistics, or a simple browser interface. The project doesn't need to be original or immediately useful; the point is to practice finishing small features and extending working code.
That makes sense. I was thinking about starting with one class and a few fields, then expanding it. I hadn't really considered that refactoring and redesigning as the project grows is a normal part of development.