I've been interested in programming since childhood, starting with interactive PowerPoint projects, Pascal, HTML games, JavaScript, Processing, and later C, Python, and Java. I especially enjoyed tools that gave me immediate visual feedback and let me quickly create interfaces, games, and small utilities.
Over time, though, I became increasingly frustrated. The workflows I originally enjoyed—PowerPoint macros, HTA files, spreadsheet formulas, and similar tools—aren't generally considered suitable for modern software development. More conventional development often means setting up environments, using package managers and terminals, learning several technologies at once, and spending a long time troubleshooting before anything visual happens. I understand why those skills matter, but they make programming feel much less creative and enjoyable.
I've experimented with JavaScript, React, Angular, Vue, and various educational platforms. I also studied software engineering for a while before dropping out during the pandemic. Since then, work and limited energy have made it difficult to maintain motivation. Opening my editor can feel discouraging rather than exciting, even though I still have many ideas for apps, games, and productivity tools. I've also built useful spreadsheet-based tools, including billing software for a family member's business.
I'm trying to figure out what direction makes sense. Should I return to a visually focused tool such as Processing, try a game-development platform like Unity, use something simpler such as Twine or Ren'Py, or commit to learning more conventional development workflows? Would a related path such as UX design, animation, or another visually oriented technical field suit me better? I don't really want to abandon programming, but I need a sustainable way to decide whether I enjoy the work itself—or only the idea of what programming could be.
4 Answers
First decide what you want to make. If the goal is to create small interactive stories or games without spending months learning infrastructure, tools such as Twine or Ren'Py could be a good fit. If the goal is broader programming ability or employment as a developer, then choose one mainstream stack and learn it steadily, including the setup and tooling. Don't try to solve your entire career with one giant project; make a small, complete thing and use it to decide whether you want to continue.
Try thinking beyond individual features and consider the structure of a project: its data, systems, architecture, and reusable components. Building a small, stable core can make later apps or games faster to create. But keep the scope modest—planning and architecture are useful only when they support a finished project rather than becoming another form of avoidance.
You clearly have creativity and problem-solving ability; what seems to be missing is familiarity with the current tools and workflows used for the kind of software you want to build. That isn't a personal failure, just a skills gap. Pick one direction—such as web apps, game development, or desktop tools—and follow a focused learning roadmap instead of trying to learn every technology at once. A structured developer roadmap can help you see which skills are actually necessary and which can wait.
Your preferred tools all have something in common: they provide immediate visual feedback and let you create without much setup. Your frustration with terminals, environment configuration, opaque tooling, and console-heavy work is understandable—but those are also common parts of professional software development, especially on larger projects and teams. If you want to work as a general developer, you'll eventually need to become comfortable with them rather than treating them as evidence that you're doing programming wrong.
At the same time, you don't have to force yourself into a career that consistently drains you. Animation, CAD, technical design, UX, creative coding, or other visually oriented fields may offer more of the feedback loop you enjoy. The important question is whether you want programming as it exists in real projects, not only the idealized version where ideas immediately become working interfaces.
This is uncomfortable but probably accurate. I may have been treating every inconvenient step as proof that the workflow was irrational instead of accepting that real projects involve constraints and preparation. I also need to consider whether I actually enjoy professional programming or whether a related creative field would suit me better.
That makes sense. A focused roadmap seems much more useful than repeatedly jumping between unrelated tutorials, so I'll start by choosing one project direction and mapping out the required skills.