There’s something I wish more employers understood — something I didn’t fully have the words for until I lived through it myself:
when a developer says the work requires a full-time position, they’re not exaggerating. They’re telling you what it actually takes to build the thing you’re asking for.
I learned that lesson from the inside, as the developer whose role didn’t match the expectations placed on it.
Stepping into a system built on shaky ground
A while back, I joined a small Norwegian company as their only developer. They handled services related to cemeteries and memorials, and they had a system that had grown organically over the years. The database was… let’s say “creatively structured,” and every architectural decision seemed to lean in a different direction.
I wanted to do good work, so I began the slow process of rebuilding, refactoring, and trying to bring some order to the chaos.
But I was hired at just 30% employment.
That number quickly became its own kind of constraint. Every task required more context-switching. Every bug meant reacquainting myself with parts of the system I hadn’t touched in weeks. Things that should have been straightforward became long, fragmented stretches of work that never quite fit together cleanly.
Expectations that didn’t match reality
Despite the part-time contract, the expectations were… not part-time.
There was a steady stream of pressure to move faster, fix more, deliver more. “Why isn’t this ready yet?” became a familiar question. I explained — more than once — that the work required more hours. That rebuilding a shaky system isn’t something you can do in small bursts. That software needs focus, not fragmented leftovers.
I was told repeatedly that my position would be increased. “Soon,” or “next month,” or “once a few things settle internally.”
But those promises never became reality.
The quiet feeling of being set up to fail
Looking back now, I can see the imbalance more clearly. They wanted stability built on top of a foundation that needed replacing. They wanted polish when I barely had time to sketch prototypes. They wanted full-time output while keeping me in a part-time role.
At the time, I pushed through because I cared. When you’re the only developer, you carry the work in your mind even when you’re not being paid for it. You want the system to succeed, even when the conditions make that nearly impossible.
And then things fell apart
Eventually, progress slowed — not because of lack of willingness, but because there were simply not enough hours to solve the problems in front of me. The system wasn’t where they wanted it to be. It had bugs. It needed more refinement.
All of that was true.
But the missing piece was the time I never received.
In the end, I was let go — just three days before my parental leave.
It took a while for the silence of that moment to settle.
What I took with me
I’m not sharing this to blame or to vent. I’m sharing it because I know other developers end up in similar situations:
the lone engineer carrying an entire product, expected to deliver more than the hours, support, or structure will ever realistically allow.
If there’s one thing this experience taught me, it’s this:
When a developer tells you the work requires a full-time position, listen.
They’re not asking for more hours for themselves — they’re asking for enough space to build something stable, reliable, and meaningful.
I’ve carried that lesson with me into every role since.
And if it helps even one other developer recognize the signs earlier than I did, then the experience becomes something I can look back on with a little more clarity — and a lot more purpose.
Top comments (0)