Scout APM helps PHP developers pinpoint N+1 queries, memory leaks & more so you can troubleshoot fast & get back to coding faster. Start your free 14-day trial today.

Honesty

You can listen to this post

If you prefer listening over reading, you can listen to this post on YouTube or by subscribing to my podcast feed on Apple Podcasts, Stitcher or Spotify

Do you sometimes lie?

Perhaps that's a too confrontational question. Do you sometimes bend the truth a little for the benefit of others or yourself? Do you still consider it a lie if all parties involved benefit from it?

Studies show that all humans lie to a certain extent. It's a natural part of how we interact with each other. Still there's a category of lies that's not accepted by society: lies that intentionally deceive others for your own benefit, sometimes even causing harm.

This is a story about those kinds of lies. Not the ones you and I tell, but the ones people close to us might. The ones that, when witnessing them makes you feel uncomfortable, makes you want to step in and tell the truth. But you don't, because if you do, it might cause you harm instead.

I was a junior developer, straight out of school. I was working at a company that made websites for small to medium sized businesses. Think your average marketing site with some added complexity like CRM or lead management, stuff like that.

I'd been working with a team of developers on one of the larger projects for half a year, maybe eight months. The project was already in production by this time, but there still was lots of new functionality to build.

One day, the client makes a somewhat angry call to my project manager — the one who's directly above me, who I work with every day. They tell her there's a bug in a recently deployed feature and they ask her to get it fixed immediately. My project manager tells them she'll review the matter internally and get back to them within the hour.

Fast forward an hour; I can see her nervously picking up the phone. By the way, we're in an open office, so everyone's able to hear whatever others say.

She tells our client that the colleague who built that feature is sick for the rest of the week but we'll put another developer on the issue. It might take a bit longer and probably won't get done until tomorrow, maybe even the day after that.

I gave a puzzled look to the guy sitting next to me, that's the colleague our PM is talking about and he's just fine, not sick at all.


Let me paint you the broader picture for a moment. The relation with this client, remember: our largest up until then; it had been a little… tense. Ever since the application was deployed to production — or maybe ever since it became clear that the project estimates weren't as accurate as the client had hoped; they were noticeably frustrated.

We did those estimates together as a team, with our PM and boss. The boss was the one who actually made the sales pitch and had contact with the client before the project started.

We roughly estimated — if memory serves me right — that we'd need a year to deliver the project. Of course, it's a rough estimate on this timescale, no one is able to accurately estimate a project this size. So naturally we told our boss that we'd need to consider enough margins.

That answer wasn't satisfying though. Our boss knew the expectations of the client, they were half of what we proposed. They would surely go with another party if we kept to this estimate. So our boss promised what we, developers and project manager said was impossible: he cut the estimate in half, and gave it to the client. Same features, just half the available time.

We knew from day one this wasn't anywhere near achievable. But "we'll see", our boss said when we voiced our concerns. "Right now it's most important to win this pitch, we'll worry about the practical details later."

Naturally, our client wasn't happy when we told them it would take a little longer than "anticipated" to get an initial version running on production. I'd say we did a pretty good job after all: only 2 months over time instead of the 6 we expected.

But you can imagine the toll these things take on the team. There was a constant atmosphere of stress, and we — as a company — were piling lie upon lie upon lie.


I talked with our PM in private after that phone call, actually I stumbled upon her crying in the hallway. After the client initially called, she went to discuss the situation with our boss.

The colleague in question was currently working on another project (which was also under-estimated by the way) and it would have a significant impact if he'd need to spend an extra day back on the other project again. The boss told our PM to simply say the colleague is out sick, and that it would take more time than strictly required to fix the issue because of this. In his mind it was a win: the colleague can continue working on the other project, we get a few more days to fix the issue and we could invoice more work than actually needed — making up for the losses we made because of our wrong estimation in the beginning.

This situation, together with other reasons, is why I quit that job shortly after. The PM handed in her resignation as well, a month after I left.

These days, I'm fortunate to have found a workplace that does value honesty between them and their clients. I now realise this is not the case for every company. In the end, that company I used to work for did take a turn for the better; I believe they realised there's little to no value in relationships based on lies. Even though a lie might serve you right now, it's never a long lasting solution.

Thanks for reading! This post is part of my "Dev Diaries" series where I write about my own and personal experiences as a developer. Would you like to read some more?

If you want to stay up to date about what's happening on this blog, you can follow me on Twitter or subscribe to my newsletter: