I've been interested in programming since childhood, starting with interactive PowerPoint projects, Pascal, HTML, JavaScript, Processing, and later C, Python, and Java. I especially enjoyed making things with immediate visual feedback, such as small games, interfaces, and useful tools. Over time, though, I've become increasingly frustrated with the parts of modern development that involve configuring environments, using package managers, working in terminals, and switching between several technologies just to create something visually simple.
I dropped out of university during the pandemic and have since mostly worked with HTML, CSS, and JavaScript. I've built a few things, including spreadsheet-based tools for my mother's business, but opening my editor now often makes me feel discouraged rather than excited. I have less free time and energy because of work, and I'm unsure whether I'm struggling because I need better fundamentals, because I'm pursuing the wrong kind of development, or because my motivation has simply changed.
I still want to create games, apps, and productivity tools, but finishing projects has become difficult. Should I return to something visual like Processing, try a game-focused tool such as Unity, use a simpler engine like Twine or Ren'Py, or accept that professional programming requires becoming more comfortable with the setup and tooling I currently dislike? Alternatively, would UX design, animation, CAD, or another creative technical field suit me better? I'm not eager to abandon coding, but I need a realistic way forward.
4 Answers
Try separating the creative goal from the implementation details. Before coding, model the system: identify the objects, rules, screens, and interactions you need. Then build a small reusable core instead of starting a brand-new pile of code for every idea. A stable foundation can make later games or tools much faster to create, but it takes some planning before the satisfying visual results appear.
Your preferences are pretty consistent: you like visual feedback, interactive interfaces, and being able to create immediately. You dislike setup work, opaque tooling, terminal-heavy workflows, and long stretches where nothing visible happens. That doesn’t mean you’re bad at programming, but those tasks are common parts of professional software development, especially on larger projects and teams.
You have two reasonable choices. You can deliberately learn to tolerate and understand the tooling, one piece at a time, or you can choose a field where your strengths are more central. Game tools, animation, CAD, technical art, and UX may provide more of the visual feedback you enjoy. Just be honest about whether you want programming as it exists in real projects, rather than an idealized version where every step immediately produces something visible.
First decide what you actually want to make. If your main goal is creating games without spending months learning general-purpose programming first, try a tool designed around that goal. Twine or Ren’Py can be good for interactive stories, while a more complete game engine can come later if you need more control.
If your goal is to become a general software developer, there isn’t really a shortcut around learning environments, debugging, command-line tools, project structure, and the less exciting parts of development. You don’t have to love those tasks, but you’ll need enough comfort with them to keep moving. Pick one language and one project, keep the scope small, and give yourself time to rebuild the patience you had as a child.
You clearly haven’t lost your creativity or ability to solve problems. What seems to be missing is familiarity with the tools and practices used for the kind of development you want to do now. Your earlier projects worked because they gave you instant feedback, but they also hid much of the underlying complexity.
Start by choosing one concrete direction instead of trying to learn web development, game development, backend programming, and several frameworks at once. Find a roadmap for that path, pick a small project, and build the skills needed for that project gradually. You don’t need to become an expert in everything before making something, but you do need to accept that modern tools and workflows are part of the process.
That led me to look at some developer roadmaps, which seems like a useful way to narrow things down. I think I’ve been trying to keep too many possible paths open at once.
This is uncomfortable but probably accurate. I often get stuck wondering why a process has extra steps instead of learning how to work within the process. I need to decide whether I’m willing to pursue programming as it actually is, rather than only enjoying the parts I imagined.