Yes, all of us are lying. And you are probably lying too. Let me prove it 😉
Oh, I have so many article topics in my head right now. The really exciting kind. But this week absolutely steamrolled me 😅 I finally finished preparing my JSNation talk, and at the same time two other amazing opportunities appeared — one professional, and one that feels more like a childhood dream coming true ☺️ But I don’t want to jinx it yet.
And just so it doesn’t sound like everything magically works out for me — I’ve also had a few CFPs rejected recently. The ones I actually cared about! But honestly? That’s just part of the game. One conference may reject your talk this year and happily accept another one from you the next.
So yes, the really big topics will have to wait a little bit longer 🙂 Which doesn’t mean this one is trivial.
We talk about AI everywhere now, as if it’s going to solve all our problems. But as we’ve already noticed, there’s no AI without humans, and behind every “smart” model there’s still some human being — at least for now 😉
Which is probably why, in practice, coding agents do speed things up… but not nearly as much as many people expected. Some studies even suggest they slow developers down.
Because the real problem is often not the code itself. The real problem is the people writing or generating that code.
And unfortunately, all of us lie in one way or another. Sometimes to others. Sometimes to ourselves.
Some Developers Lie About Knowing What They’re Doing
One of the best developers I know once confessed something to me.
This guy is genuinely brilliant. The kind of engineer companies fight over. He currently works on optimizing drivers for LLMs, gets promoted constantly, and even in this lovely “tech crisis” era, he still had multiple job offers to choose from when he considered switching jobs.
And yet, every single time he joins a new project, he feels like a complete idiot.
Everybody else seems productive. People are delivering tickets. Writing code. Moving confidently through the project. Meanwhile, he sits there staring at the codebase wondering:
What exactly is happening here?
What are we even building?
Why does this work like this?
Why are we implementing it this way and not differently?
And then he starts asking questions.
Usually, it turns out nobody really knows what they’re doing, why they’re doing it, or whether they’re even solving the right problem in the first place.
It reminds me of that old joke about lumberjacks cutting down a forest. Eventually, the team leader climbs the tallest tree, looks around, and screams:
“Guys! We’re cutting down the wrong forest!”
And the workers below shout back:
“Who cares? We’re making great progress!”
And honestly, no LLM will save us here. Especially if we never even ask the right questions.
Others Lie About Knowing How To Do Something
This is basically an extension of the previous problem.
A less experienced developer picks up a task and confidently says:
“Yeah, I know how to do this.”
Unfortunately, what they often mean is:
“I hope I’ll somehow figure it out.” 😅
In reality, they may not know how to solve the problem, which tools to use, what architecture makes sense... or even what prompt to write to get useful help from a coding agent.
But they’re afraid to ask.
Because how will they look in front of the team? What will the manager think? The tech lead?
Best-case scenario: they eventually ask questions… just way too late.
Worst-case scenario: they never ask at all and deliver something completely wrong. Which often isn’t even caught properly because…
Someone Else Is Lying About Having Time
Now we’re entering senior and leadership territory 😅
The motivations differ. Some people build their self-worth around being “the reliable one.” Others are terrified of losing status, influence, or even their job.
So they keep taking on more:
- the hardest tasks,
- endless meetings,
- refinements,
- estimations,
- discussions with support,
- discussions with business,
- code reviews,
- architecture decisions,
- documentation.
And let’s be honest. Something eventually has to break.
Human beings are not made of steel. Nobody can operate at 100% forever.
So what happens?
People start half-listening during calls. Code reviews become rushed. Documentation quietly dies in a corner somewhere.
But they still refuse to admit — either to others or to themselves — that they’re simply overloaded.
Some Developers Lie About How Long Things Will Take
I see this constantly with more advanced juniors and mids.
They throw around hilariously optimistic estimates with absolute confidence.
And sure — if they could work uninterrupted for eight straight hours, the application contained no legacy code, edge cases didn’t exist, and other humans never interacted with the system… then maybe the estimate would actually be correct 😄
Then sprint review arrives, and suddenly everybody is shocked that the team didn’t deliver everything.
But this is not the only problem with estimations.
I once worked with an especially funny senior developer.
He treated estimations like sacred truth. He would aggressively defend his numbers during planning sessions, insisting that this specific task was definitely extremely complicated. The rest of the team usually suspected it wasn’t that bad, but eventually we’d surrender just to end the discussion.
And then — at least three separate times — he personally picked up the exact task he had massively overestimated… and finished it in about an hour.
Which basically meant the estimation discussion itself took longer than implementing the feature 😅
Did this experience change his behavior?
Absolutely not.
And Some Lie About Knowing Everything Best
These are probably the most dangerous ones.
I avoid people who say things like:
“Use THIS technology and ONLY this technology because everything else is garbage.”
Insert your favorite holy war here:
Angular vs React, Java vs Python, Rust vs literally anything else 😄
I never write like that myself. Even when I publish something titled “I Love Tailwind. Sorry Not Sorry”, I still talk about its downsides and explain where it absolutely doesn’t make sense.
If one day I start claiming some technology is objectively perfect for every possible situation, please leave a comment saying:
“Sylwia, go touch grass immediately.” 😅
Honestly, I’ve always wondered where this sense of absolute certainty comes from.
Because not all of these people are even paid influencers. Some genuinely seem emotionally attached to technological holy wars. Others maybe only know one stack deeply, so everything else automatically feels “bad.”
And while this behavior is very common among tech influencers, you absolutely see it inside companies too.
The problem is that this kind of certainty can seriously damage projects. People stop questioning decisions. Other developers become afraid to speak up. Stakeholders assume “the confident person” must be right simply because they sound convinced.
Best-case scenario: you end up with an annoying developer who knows more about frameworks than the actual business domain.
Worst-case scenario: you end up with a terrible stack choice and spaghetti architecture held together by ego.
People Are Just… People
Of course, I’m not innocent either.
I’ve used many of these lies myself in the past. Maybe I’m older now. Maybe slightly wiser. Or maybe I just recognize these patterns more easily.
But I’m definitely still lying somewhere too. Maybe not to others — maybe to myself.
Because a lot of our problems in software development aren’t really technical problems at all. They’re deeply human problems:
- ego,
- insecurity,
- fear of looking stupid,
- fear of admitting mistakes,
- fear of saying “I don’t know.”
And honestly, I don’t have some magical solution for this. We’re not going to require three years of therapy from every developer before allowing them into a sprint planning meeting 😄
But I have noticed one thing.
Very often, admitting you don’t know something, openly discussing uncertainty during planning, or simply saying:
“Sorry, I still don’t understand this. Could you explain it one more time?”
doesn’t make people see you as a worse developer.
Quite often, the opposite happens.
Suddenly communication inside the team improves. Other people start asking questions too. Conversations become more honest. Problems get discovered earlier.
Seriously. Try it at least once. You might be surprised 🙂
So… what kinds of developer lies do you see most often in your team?