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?
Top comments (145)
This was and still is me, the only difference is that i just figure things out faster over time haha.
and btw when i say i know x-y framework, I don't mean that I'm completely fluent, able to blindly build something perfectly with it but more like, i know how to google this and get an answer faster haha
Everything mentioned here is a universal trait with all developers and it's too brutal that it's unsaid.
Hahaha, honestly, same 😄 When I say I “know” some framework, I rarely mean I’m completely fluent and capable of building everything perfectly from memory.
For me, frameworks are more like tools or hammers, not religions 😄
And about not fully knowing how to do something: oh, I absolutely still have that too. But I still remember my junior days when sometimes I had no idea what I was doing and instead of asking for help, I would produce spaghetti code so horrifying that seniors were probably reconsidering their career choices 😅
when i was a junior, i mostly didnt wanna ask for help because of my ego and also i was afraid that i'd make them waste too much time on me. when i do ask for help, it's when my deadline's near and all of my google search results turned purple all the way to page 15.
surprisingly, most of the time, my seniors weren't as harsh as i expected they would be haha.
another funny thing is, being a backend, i also usually rely on the frontend to memorize some of the business logic haha
Hahaha yes, exactly 😄 But you see, you were the type who eventually asked for help near the end. Meanwhile junior-me would sometimes deliver spaghetti so terrifying it didn’t even survive code review 😂
So eventually I learned that asking earlier was simply less painful for everyone involved.
And then later I reached another funny stage: often I already knew the solution, but I still wanted to quickly validate the approach with a senior before starting implementation, just to avoid endless review battles later.
But in my first job, this sometimes triggered full-on mansplaining mode 😅 Instead of simply saying “yeah, your idea makes sense”, the guy would spend 30 minutes explaining things I already understood and showing off his knowledge… while my original implementation idea was perfectly fine from the start 😂
So honestly, that discouraged me from asking sometimes too. But still, it was WAY better than getting destroyed during review afterwards 😄
Yes you are right, haha. I am an over-confident (common in teens my age) programmer, and somehow I have managed 10 man operations myself (not a pretty thing), And I felt joy reading your comment, all you said is probably true. And one more hottake: We dont need to google search everything, Ai does the job, BUT BUT BUT AI has also made our lives harder, while other devs use AI do do some shit, we usually code and we (honest) guys get trashed for being slow, LOL.
So me
Haha welcome to the club 😆
🤚
At the end of the day you still figure it out,after so much tension 😂
Yeah, developers usually deliver in the end 😄
The real question is: what exactly are we delivering? 😂
not sure that framing holds - most developer gaps between what they say and what is real are just context collapse. different stakeholders, different abstraction levels. that is not dishonesty, it is scope mismatch. AI does not fix scope mismatch.
I actually think our points of view are not contradictory, they complement each other 🙂 Thanks for adding that extra context.
A lot of what we call “developer lies” probably is partially caused by scope mismatch, different abstraction levels, and context collapsing between teams and stakeholders.
And on one thing we definitely agree: AI won’t magically fix that 😄
fair synthesis. and yeah, context collapse is probably the root of most of it.
small pushback on the AI part though - there are spots where it actually helps, specifically the translation layer. same requirement written for devs vs execs ends up as two different documents, and AI does that switch reasonably well. doesn't fix the upstream gap, just makes the communication less painful.
Totally agree 🙂 And I’d even add that sometimes AI helps very literally with translation too.
A lot of teams today are distributed across different parts of the world, and not everybody feels fully confident communicating in English all the time. Sometimes a requirement or message is written in a confusing way, and people may hesitate to ask another human for clarification.
Asking an AI to rephrase, simplify, or explain something can genuinely reduce communication friction there 😄
right, the translation layer is genuinely underrated — a requirement rewritten into clear English often surfaces ambiguity that was always there, just hidden by politeness or hedging. non-native speakers sometimes catch that gap better because they're already translating twice.
Oh wow, this reminds me of something even broader than language translation: cultural communication styles 😄
For example, I’m from Poland, and here we usually talk about problems quite directly. Maybe still politely, but very straightforwardly. So when someone from England starts communicating an issue in a super subtle or heavily softened way, I sometimes genuinely can’t tell whether they actually have a problem or are just casually discussing something 😂
In that sense, AI can also become a surprisingly useful translation layer between communication cultures, not just languages.
…or maybe what we really need is communication workshops for developers 😅
Honestly, that could be an interesting topic for another post.
the Poland/England gap is a perfect example — clarity norms are cultural, not universal. AI has the same bias baked in: most models default to hedged, softened phrasing because that is the training baseline. sometimes that makes requirements even blurrier than before the AI touched them.
Oh yes 😂 Sometimes I literally give the model prompts like:
“say it directly, no sugarcoating.” 😄
Ah yes, my simple Polish brain apparently prefers communication without five layers of diplomatic fog 😂
haha yeah. the default model voice is "american email hedged" - you have to explicitly break that every session. polish directness turns out to be the correct baseline, not an edge case
“Guys! We’re cutting down the wrong forest!”
... instead I feel in the company works we are cutting a wrong path in the forest.
I am lying to myself many times to even worth to creating a new things. When I sure to know nobody will use it. Maybe my next lying to myself is that worth to write a book about Bible and technology relation.
You don’t even know how much I understand this 😅 I’ve cut down that wrong forest many times too… endless technology arguments, stressful releases, months of work on products nobody actually used. It can genuinely destroy you mentally after a while.
Eventually I changed jobs, and now I work on a project for the European Commission that is very much used. People use it because they literally have to 😂
Of course it’s still far from perfect, but at least it doesn’t feel like the work disappears into the void anymore.
Maybe 'everyone lies' is overstatement. The real issue is incentives and feedback loops, not morality. AI won't fix culture; it surfaces gaps. If we want truth, redesign incentives and honest signals, not pretend honesty is dead.
Yeah, that’s fair 🙂 But at the same time, we’ve been talking about “redesigning incentives” for at least 15 years, and honestly I’m not seeing massive changes yet. A lot of companies still reward confidence more than honesty, speed more than reflection, and “everything is under control” more than “we may have a problem here.”
And now we also have the new management explanation for everything:
“AI will handle it.” 😂
Maybe a bit of an overstatement but the idea is true
Hahaha, I don’t know 😄 House MD has been telling us for years:
This is SO true. However my experience is from fields other than development. Nobody knows why we do things when I ask. There is always some multi-layered human trinketing going on. It bothers me on a very deep level when I see people doing things, for reasons they don't know why, and to make matters worse, unquestioningly doing so.
This matter of lies is in human behavior.
They say you should care about what work you are doing. I think people's motives get in the way. Or they only think there is one way of doing things and "it's not broken so don't fix it." But what if you could double your speed? What if it could be more elegant? Do these people not care? Why are they here? People should care about their job. Unfortunately many do not hold the same virtue of advancing mankind to the next level. Some just want money, some want to just survive.
If a company is lucky enough to find someone with passion, like your inquisitive friend, they themselves must also be intelligent and open minded enough to hold on to such an individual.
For example, if someone works for a company that prides itself on innovation to its customers, but use practices internally that are passé by todays standards, I feel that an intelligent person may feel like they are living a lie. Now that's a big lie! haha.
Your friend is indeed a very smart man!
Yes! Thanks for this comment, it’s a really beautiful reflection on bureaucracy and human nature.
My friend was lucky in a way: he’s both very intelligent and works on low-level technical problems, where deep questioning and innovation are still genuinely valued. But honestly, I can totally imagine him dying internally in some super bureaucratic environment like a city office 😂
And I fully agree with you that most people simply don’t care much about innovation. Some even actively block it while simultaneously branding themselves as “innovative”.
The environment in which we are living currently, is filled with expectations!
The moment we admit, we are isolated, people remove us from that discussion or talk.
They think we are of no use to them for that task at hand!
The time we need to understand the context or learn some thing, especially for slow learners like me, we don't get it normally!
What I normally do is, in the beginning itself, like you said, I admit that I don't know anything and put the hands up!
Then when everyone's concentration goes away from me, then I try to do my slow learning.
Exactly 🙂 And honestly, learning slowly doesn’t mean someone is less capable. What matters is that they do learn and eventually understand the problem properly.
I’ve met people who learned very fast but stayed shallow forever, and others who needed more time at first but later became incredibly solid engineers.
And I think openly admitting “I need some time to understand this” is often much healthier than pretending to know everything immediately 😄
True but what happens if you don't have the luxury of time in said situations?
Honestly, you rarely have that luxury 😄 Especially at work, at some point you do need to leave your comfort zone for a while.
But I’ll also say this: when I started working in IT, I was very slow at first. It took me quite a long time to really understand what was going on.
But once I finally “got it,” things suddenly accelerated a lot 😄
You nailed it right here. Software development relies heavily on good communication and as you said, we are humans after all. Even back when I was in school, I really appreciate classmates that ask questions about the project. It makes leading the group SO MUCH EASIER. Usually, those projects that discusses knowledge gaps are the ones that gets better results.
Oh yes, 100% 😄 Honestly, the more I think about it, the more I feel this probably applies to almost every area of life. It’s just much more visible to me in software engineering because that’s the environment I work in every day 🙂
the part about 'knowing the codebase' hit different. i used to nod along in standups like i understood the legacy auth module. spoiler: nobody did. AI didnt fix that — a 2 hour pairing session with the one person who wrote it did. the lying stops when someone actually walks you through their mess. what's the one thing you pretended to know for way too long?
Oh damn, classic! I’m actually planning to write about this soon, how even LLMs can’t always save you from hardcore legacy code 😁
What did I fake for too long? I think I relate most to the point on my list about pretending I could handle everything, just because I wanted to feel important! And then came a million calls, and everyone was reaching out to Sylwia with every single issue, because 'she’s got this, obviously!' Eventually, I had to set some boundaries because I just couldn't keep up anymore 😅
Please explain this a little, thank you.🙂
Please wait for the next post 🙂 I’ll probably describe all of this around Wednesday.
And I’m very far from the whole “subscribe to find out” style 😂 I just genuinely need a bit more time to organize these thoughts properly in my head and describe them nicely.
Thank you so much, you're a wonderful person.
💖
Great post as always!
Nice story about estimation and developer, it reminds me of a theorem about devs:
😄😄
Hahaha thank you 😄 This reminds me of another story.
We once had a company hackathon where we built a small project prototype in about 8 hours. I was responsible for the frontend there, helped the backend guys a bit, and also pushed hard on the visual side so it actually looked polished 😄
Then the company voted for the winner… and not only did we lose, but a few days later I got criticized by the CEO because I estimated a real project on the same topic at at least one month of work.
And the CEO literally said:
“But guys delivered it during the hackathon IN ONE DAY!” 😂
Then I reminded him that I was actually the person who delivered that hackathon frontend too.
And suddenly his reaction changed to:
“Hmmm… maybe we should just improve the hackathon demo then?” 😅
🤣🤣🤣
This was such a painfully accurate read 😅
The “I know how to do this” vs “I hope I figure this out before anyone notices” part hit hard. So much of development seems to be pretending to be certain while quietly fighting uncertainty.
Honestly, “I don’t know yet” might be one of the most underrated skills in tech.
Exactly 😄 And the funny thing is that many developers eventually discover that saying:
actually makes people trust them more, not less.
Because uncertainty is normal in software development. Pretending certainty where none exists is usually what creates the real chaos later 😅
Exactly, that’s the part I am slowly learning too 😄
“I don’t know yet” sounds risky in your head, but in reality it’s probably one of the most honest and useful things someone can say. Fake certainty feels productive for a moment, but it usually just delays the confusion until it becomes more expensive to fix later.
Exactly 😄 You’re often just delaying the moment of judgment until the retrospective, when the PO eventually asks:
Haha exactly 😂 The retrospective is where all the hidden uncertainty finally asks for a meeting.
I am slowly realizing good planning is not about sounding certain but about making it safe to say “this part is unclear” early enough.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.