A Belief I Held as a Junior, Now Clearly Proven Wrong!

As a junior, I had a rule — nobody taught it to me, I came up with it myself, and I believed it for a long time: "Writing good software is enough to make good money." I thought that the cleaner the code and the more solid the architecture, the more successful the product would be. I mistook technical quality for commercial success.

Over time I saw that software that wasn't good also made money — sometimes far more. When I started questioning why, I realized that alongside the software itself, sales, support, and marketing needed just as serious an effort. The proof was right in front of me: you can find 10 pieces of software doing the exact same job, but only a few of them ever stand out — and we learned in the field, past the junior stage, that this gap isn't purely about technical quality.

You can't see this just by looking at the code — you only learn it once you've shipped a product and asked yourself, "why is it the cruder one that's winning, not the one I wrote so well?" The pattern is always the same: the technically strongest solution gets the loudest applause in a demo, but a year later it's nowhere in the market; meanwhile the simpler-looking product, backed by a strong sales and support pipeline, keeps growing.

Here's my confession: at one point, purely because "this is the technically correct way," I spent a long time hardening something nobody had even asked about — while a competitor had already shipped a much simpler version, built a support team, and locked in the customer. My product was technically better. But it was the competitor who moved forward!

Today there's no excuse left to make that same mistake, because the thing that once forced me to choose between speed and quality doesn't exist anymore: AI. Even someone with no software background can describe their problem and move fast with the power of AI; AI is a phenomenal aid for producing code that's both fast and good — our whole proposition can now be built not around "spending months to make it better than the last version," but around reaching fast, working code with AI at our back. But knowing this isn't enough on its own: alongside a fast, good, functioning product, its sales side needs to be planned with just as much seriousness as the code — otherwise nobody ever sees even the fastest, best-built code.

From that day on, the question I ask changed: not "is this product technically good," but "is there someone behind it who will sell it, support it, tell its story?" Code is still necessary — but it was never enough on its own.

Here's the interesting part: unlike law or medicine, software is one of the rare professions that requires no license, no certification to practice. Today, someone with a background in the sciences, engineering, math, or physics can start from zero, with no programming knowledge at all, and learn this — and now they have AI alongside them too. The question is no longer "can I learn this": do you get behind AI's power and build something, or do you resist software that has already reached an entirely different dimension with AI?

I turned this question into a concrete path for people starting from zero: NEBULACT AI Academy's "From Zero to Software Engineering" course. It requires no programming knowledge at all; it's built for anyone from a numerical, engineering, math, or physics background who wants to start software from scratch. Over 72 hours, 4 hours a day, in a small group of 15–20 people — from algorithmic thinking to object-oriented programming, from database architecture to shipping an end-to-end (desktop + web + API) .NET product. The goal isn't just to teach code — it's the first solid step on the road to NEBULACT's AI-era courses.

The rule I believed as a junior was wrong: good software was never enough on its own. But that's exactly why what I teach today has changed too — to someone starting from zero, I no longer just say "write good code." I say, "learn it together with the power of AI, because this train just left, and you can still catch it."