Qberry

Qberry was an outsourcing and outstaffing company. Other firms came to it to get a project or a product built for them, and those client projects were the whole of the work. I was there from 2019 to 2020, as a full stack developer who also carried the DevOps and SRE side.

It came right after the Cropman startup, and it was my first real company job. It was also the first company I worked in that wasn't built around developers. Until then I'd only ever worked beside a small group of them, and this was a bigger and stranger place.

I got in through DAN.IT, the IT course school where I was a student in 2019. One of the instructors there had a company that was looking for a junior, a strong junior, and he pretty much said: if you want, just go and start working with them. So I did. After about a week of waiting I had my first job interview, the first one in my whole life, and I passed it clearly. I was literally a student, everything I knew was fresh from the course, and nothing had time to fall out of my head yet.

The work itself was plain outsourcing: through Qberry I got to Platon, a Ukrainian payment service provider, and worked on its peer-to-peer card transfer product. Inside the company there was its own internal CMS and CRM, a big store back office with Vue and Nuxt on the front of it, and my part of it was migrating the CRM and speeding it up. Around that sat a couple of WordPress sites, the company's own among them, and a few small commerce sites. One of those ran WooCommerce, the others were hand-built catalog sites, and one client also got a standalone price calculator page. The server side ran through every one of these projects, at the same time as the feature work and mostly on machines that belonged to the clients: Apache, and tooling to migrate sites.

The part I really remember is one of those strange and fun situations I still carry around after all these years. A colleague and I each got a task, two different ones, each with its own deadline. Mine was the bigger one, its deadline was underestimated from the start, and I missed it. My colleague made his on time, but he was wrong about the implementation though.

Then came a very fun conversation with the bosses and the team. Obviously, I was the bad guy who missed a deadline, and everybody kept holding my colleague up next to me. So I said yes, he did it on time, but he didn't do it correctly. And the answer to that still fascinates me to this day.

"But he did that on time."

So yeah, that's the main reason I left.

Of course it's better to hit a deadline, and setting one right, expectations especially, turned out to be mostly about an experience. The more of it you have, the more accurate the deadline you name each time. Over the last year I don't remember a single deadline I named at the start that had to be moved further. More often it got delivered early.

What got me there is the standard approach of any estimation work. Before a job starts, each project or task gets a rough estimate, a "golden" one (the most likely) and a max one, and then you work through those in combination.

After Qberry came Mobilauto.