What Repeated Failure Teaches a Developer Career

Source and AI note: This article is based on Gemini’s Devpractice on YouTube. It was generated and edited with the gpt-5.6-sol model.

Failure is easy to romanticize after the pain has passed. While it is happening, it looks like rejected applications, a role that never becomes what was promised, skills that seem irrelevant, or a move you want to reverse after only a few months. The useful part is not the suffering itself. It is whether the next decision uses information the failure exposed.

This is one developer’s experience, not a route others should copy. Career circumstances differ too much for a universal instruction. Still, repeated attempts reveal a few practical ways to turn disappointment into better selection criteria.

A career can begin with very few good options

Entering software directly from a technical high school meant applying with some programming experience but little of what service companies expected. Several applications ended at document screening; another ended after multiple interviews when the company chose to hire university graduates. The eventual first job came through someone at school who found one more opportunity.

That role involved firmware, soldering, physical debugging, and long travel to a remote workplace. The next role moved closer to application software but still involved embedded systems, SI or maintenance work, and frequent field visits. Attempts to enter product development failed because the experience and technology stack did not yet match what those employers needed.

At the time, those stages could feel like detours. Yet they provided work with devices, networks, CPUs, debugging tools, and software running in inconvenient real environments. That embodied understanding later became useful computer-science intuition. Experience can acquire value after its original context has disappeared; a résumé line that does not open the next door immediately is not necessarily wasted.

Do not build a move on an invisible promise

The desire to work on a consumer product led to roles where a new B2C business was discussed but never became concrete quickly enough. Perhaps the companies intended to build it. Perhaps the decision to leave came too soon. The honest lesson is conditional: a future plan and an operating team are different things.

Before joining for a promised change, separate what exists from what is still intended. Is there already a consumer service or a team doing that work, or is the change still something the company says it wants to do? Ask people who know the organization what work is actually happening. Hope can be part of a career choice, but it should be labeled as uncertainty rather than treated as evidence.

The same discipline applies to a company’s reputation. Joining an affiliate of a respected technology company without asking how that affiliate really worked produced one of the shortest and worst-fitting moves in this career. A group name did not determine the local team’s engineering culture, decision structure, or treatment of developers.

Trusted referrals are information, not weakness

For a while, accepting a referral felt like proof that independent ability was insufficient. That belief encouraged choosing without asking people who could have explained the organization. The result broke the rule itself.

A referral does not guarantee a good job, and a casual recommendation is not enough. Its value is access to evidence. Someone you trust can describe what the company is like and whether people there enjoy the work. If a colleague with whom you worked well also fits in there, that is useful evidence about your own likely fit. Several valuable opportunities in this career came through people met while doing previous jobs seriously—even jobs that had seemed unsuccessful.

That does not reduce the developer’s achievement. Working relationships are part of a career record. People recommend colleagues whose work and effort they have observed. The better rule is to examine the source and substance of a recommendation, not to reject help to protect an image of self-reliance.

Rules made from failure must remain revisable

A bad experience at one affiliate produced a firm rule: never join another affiliate. Later, a newly created affiliate offered a different situation, a meaningful business problem, and the chance to work with a trusted leader. The earlier rule no longer described the decision well, so it changed.

This is the deeper pattern. Failure should create questions and criteria, not permanent superstition. “Do not trust an unverified promise” becomes “verify what is real and understand the downside.” “Do not join an affiliate” becomes “investigate the actual team rather than infer culture from the parent.” “Never rely on a referral” becomes “use credible relationships as one source of evidence.”

Even success remains personal and temporary. One person’s desirable company, salary, team, or role may not be another’s. The point is not to collect failures as badges or assume every setback improves you. A failure becomes career capital only when you recover, examine what happened—including your own impatience or mistaken assumptions—and let the next choice change.

More attempts will still fail. Keeping failures small where possible, getting back up quickly, and continuing to test revised criteria is more realistic than waiting for a flawless move. A career is not proof that every painful experience was secretly good. It is the ongoing work of extracting a better judgment from experiences that were uncertain, discouraging, and sometimes simply bad.