/Technology

Every tech community knows this character. Shows up in forums with infectious enthusiasm, shares an empty GitHub repository, talks about complex architectures for a product with zero users, and disappears for three months. When they come back, they bring a new project. Equally revolutionary. Equally unfinished. It's not a lack of talent. It's not a lack of resources. It's a cultural dysfunction that the industry itself helped create: the idea is worth more than the execution, potential matters more than results, and the meeting is more valued than the code that actually works. ## I. The beginner who knows everything except how to do it There's a specific type of tech newcomer who is very hard to convince to change: the one who learned the industry's vocabulary before learning the actual work. Talks about microservices (breaking a large system into smaller, independent parts) without having built even a simple system that works from start to finish. Discusses scalability for a product with zero real users. Asks which technology is best for a problem they still can't properly explain. It's not a question of intelligence. It's a question of order. In practice, this newcomer skipped the hard steps: the two in the morning error that makes no sense, the form that simply won't submit, the database that corrupts data in production. They went straight to the philosophical side of engineering. And that creates someone who can criticise an architecture they never designed and abandon a project they never truly started. `Choosing the perfect technology for a product that doesn't exist is like buying a Ferrari without a driving licence. Impressive in conversation. Useless in practice.` The solution is simple, almost brutally simple: finish something. It doesn't have to be pretty. It doesn't have to handle millions of users. It doesn't need sophisticated tools. It needs to exist. A form that works, an API that responds, a page that loads. Deliver that first. The sophisticated architecture comes later, and only makes sense when you have something real to architect. ## II. The "investor" who never risks enough to learn The tech community also created a curious character: the pseudo-investor. Someone with enough money to fund projects, but so afraid of risk that they end up never funding anything truly interesting. They only invest in ideas already validated by the market. The problem is that, in practice, this means always arriving late. This type of investor shares a trait with the eternal newcomer: they prefer the safety of analysing to the difficulty of deciding. They spend months studying projects that die during that process. They ask for elaborate presentations when they should be asking for real products. They value the slide about market size more than the first functional version of the product. And when the project fails, they blame the founders. Never the process that suffocated them with meetings and bureaucracy while the market moved on. The complete profile: - Asks for more data when they already have enough data to decide - Funds the presentation, not the product - Confuses prudence with paralysis - Shows up at success, disappears during the building - Treats risk as an enemy instead of a necessary condition Investing in technology without tolerating ambiguity isn't prudence. It's simply incompatibility with the role. Risk isn't a flaw in the process. It is the process. ## III. Programmers solving problems nobody has This is probably the most common profile. And the hardest to confront. It's the technically competent programmer who spends months, sometimes years, building elaborate solutions to problems that only exist in their own head. The code is elegant. The architecture is solid. The tests are written. But when someone asks "who uses this?" or "what real problem does this solve?", the answer is vague, defensive, or points to a hypothetical user who was never interviewed, in a market that was never verified. Well, building for the joy of it is completely legitimate. It's even noble. But there's a huge difference between an honest learning project and a project disguised as a startup. The first doesn't need users. The second has no excuse for not looking for them before writing the first line of code. `The most important conversation before any project isn't 'how am I going to build this'. It's 'is there someone who would pay to have this problem solved?' If you can't answer that, you have a hobby, not a product.` The problem gets worse when the programmer uses technical complexity as a shield against real feedback. Adding features is more comfortable than hearing that the product isn't needed. Rewriting code is less frightening than talking to potential users. And so the project keeps growing in sophistication while shrinking in relevance, at the same time. ## IV. The cycle of eternal restarts There's a pattern that shows up across all these profiles: chronic restarting. The project is abandoned not because it visibly failed, but through a mix of boredom, fear of launching, and the seduction of a new idea that promises to be different this time. Each restart is easier than the last because the person has accumulated ready-made justifications: "the previous technology was wrong", "the market wasn't ready", "a key feature was missing". What's rarely admitted is that the problem wasn't technical, wasn't about the market, and wasn't about timing. **It was about commitment to the discomfort necessary to finish something.** The cycle always has the same five phases: 1. Genuine enthusiasm and ambitious architecture 2. First real obstacles and loss of momentum 3. Adding features to postpone the launch 4. New idea and quiet abandonment of the previous project 5. Repeat, this time in a different programming language ## V. What separates those who deliver from those who don't It's not talent. The graveyard of abandoned projects is full of talented people. It's not time, because people with full-time lives, children, and demanding jobs build and launch products. It's not money, because some of the best personal projects were born with costs close to zero. What separates them is their relationship with the imperfect. People who deliver tolerate launching something that isn't quite how they wanted it. They know the initial version will be embarrassing and they launch it anyway. They know they'll receive criticism and they actively seek it out. They know they'll get some things wrong and they use that mistake as information, not as identity. The tech industry has a responsibility here. We glorified garage stories for too long without honestly talking about the systematic, repetitive, and often boring work that precedes them. We turned changing direction into a virtue when, most of the time, it's just another way of not finishing what you started. ## Verdict If you have a project that has been "almost ready" for more than six months, it's not a project. It's a hobby that refuses to accept its own identity. If you have a portfolio of five private repositories with activity from two years ago, you're not a programmer with projects. **You're a collector of beginnings.** If you fund ideas but never talk to the users of those ideas, you're not a tech investor. You're a patron of PowerPoint presentations. The solution isn't more motivation, more productivity, or the right technology. It's a simple and uncomfortable decision: **Either you deliver this week. Or you admit you never intended to deliver.**