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 exc...
For further actions, you may consider blocking this person and/or reporting abuse
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
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.
β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.
Sometimes, we developers, are really terrible at communication. Not everybody of course. And I really believe that the reason for this is life. Our job is not outside with the people. It is inside, closed in an office (or home office), work alone. And to be a good developer, you need to practice and learn, and practicing and learning is, again, not a activity that includes a lot of people.
And in school, to prepare for your math exam, you are not outside, playing with the kids. The skills that we have are usually not in the area of good communication. Some of us are too direct, some of us are too quiet. And all the exams and job interviews are 'one against the world' battles. At some point, I think that this is becoming part of our characters, to some extend.
And the communication in internet, is not like a face to face communication, in daily meeting, with real people.
The above might be some of the reasons, software developers, don't communicate the way other people find as normal, and that might be the core for some of the situations you described above.
This is a beautiful comment, thank you so much for it π
Honestly, as a tech lead and also someone with a not-so-purely-technical background, I feel like I could write an entire book about this topic π
For example:
Okay, I should probably stop now because this is seriously turning into material for another blog post π (writing this idea down immediately).
But I think your point is very important: sometimes communication problems are not separate from someoneβs extraordinary abilities. They are partially a consequence of them.
The difficult question is how to solve that without destroying the strengths that came with it.
We joke with my colleagues, that if a doctor enters a office of developers and analyze the behavior, a article for a Nobel prize can be written :D
Brilliant minds! :)
Hahaha π I donβt know about you, but after spending enough time with developers, sometimes βnormalβ people start feeling strangely boring π
This hits because the βlyingβ is usually not malicious. It is self-protection.
Developers say βalmost doneβ when they mean βI donβt know what will break next.β
They say βsmall refactorβ when they mean βI touched more than I planned.β
They say βAI helpedβ when sometimes it means βAI created a cleaner mess I now have to understand.β
AI does not remove that human layer. It can generate code, explain errors, and speed up debugging, but it cannot replace honesty about uncertainty, tradeoffs, shortcuts, and risk.
If anything, AI makes honesty more important because now the output can look finished before the developer fully understands it.
This is exactly how it looks in practice π Thanks for this comment.
And honestly, with AI it becomes even easier to fool ourselves a little bit.
βYeah, itβs basically finished, only review left.β
Meanwhile the βreviewβ means going through 1000 lines of AI-generated code and trying to understand whether it actually makes sense π
Or:
βThis should only take a moment.β
Because maybe the LLM will magically write most of it for us π
The underneath plot is that humbleness is NEVER rewarded.
People are not promoted because of being humble. On the contrary, sometime they might get fired.
Interestingly, the ending of the article was actually meant to argue the exact opposite π
I genuinely think humility and honesty do pay off in the long run β we just massively underestimate how valuable they are in software teams.
I used to believe in this. But after 20+ years I can say that I had to swallow the bitter pill: humbleness is perceived as weakness.
But still, in the end it's my experience. Different experiences, different opinions.
You know, I actually wonder if part of this is also how we communicate uncertainty π
For example, to avoid annoying a tester, you usually donβt say: βit works on my machineβ but rather: βcould you provide a bit more information? I canβt reproduce it locally.β π
And similarly, instead of saying: βI donβt knowβ people often phrase it more like: βthe requirements are not fully clear in this specific area.β
Technically the meaning is similar, but the second version sounds collaborative rather than helpless. Maybe that also changes how humility is perceived in teams.
True.
It's interesting tough that, as humans, we need specific formula to rephrase (and somewhat hide) our uncertainty.
Of course it's a great soft skill to demonstrate openness to address unknowns instead of melting in front of them.
In any case, the person who doesn't even know the unknowns and, as a Dunning-Kruger effect, says "everything looks good, I can reach great results on this" sell something better than the one who ask some time to understand the unknowns. The former often get also a promotion, because of unawareness about risks.
This hits because itβs true. Most developers have that one area they quietly avoid admitting theyβre unsure about. For some itβs system design, for others itβs testing, security, DevOps, or even reading legacy code without pretending they βget it.β AI can help explain things, but it doesnβt remove the need to be honest about gaps. If anything, it makes that honesty more important, because now itβs easier to ship something you donβt fully understand.
Exactly this! Especially that last sentence. I think itβs incredibly important.
In the AI era, we probably need to be even more honest with ourselves than before. Because now itβs much easier to ship something that looks correct and polished while not fully understanding whatβs happening underneath.
Exactly. AI can make weak understanding look polished, and thatβs the risky part. The code may read well, the explanation may sound confident, but if the developer canβt reason through the tradeoffs, edge cases, or failure points, theyβre still shipping on shaky ground. Honesty about gaps is becoming a real engineering skill now.
This was so good and refreshing take on developer psychology. Your honesty about the industry's unspoken insecurities is inspiring for me β€οΈ
Thanks a million β€οΈ
After so many years, I still can't give an exact estimate for a task when I actually have no idea - or almost no idea - how to deliver it. Honestly, I doubt anyone can. I've tried to think reasonably, to "smash" it into the smallest possible parts and then sum everything up at the end to get the estimate. Nope. Every single time, something comes up. Every time. No exceptions.
P.S. I'm not talking about rounding the border of a CTA button because it's missing the needed prop and you have to add it.
Hahaha exactly π Thatβs why we call them estimates in the first place π
Personally, over the years I actually learned to estimate higher than what I objectively think the task will take.
At first our Scrum Master hated it π But then he noticed that suddenly sprints were actually being delivered consistently, and sometimes we even had time to squeeze in extra work. Now he fully supports my βpessimistic estimation strategyβ π
I laughed, hard. π
Yep, I've read somewhere about how a good estimate can be given, and in the end it was basically: just add an extra 20% on top π«’
Hahaha yes π I still remember when I once had to estimate an entire project, which is obviously way harder than estimating a single task.
So I added an extra 20% buffer to my estimate⦠and then my boss added another 30% on top of that and proudly called it:
Weβre all human, and sometimes the hardest part of being a dev is admitting when a βsolutionβ isn't the right answer. Thanks for the reality check. You're a great senior π
Thank you so much β€οΈ And yes, I think this aspect is massively underrated.
The lumberjack joke is the perfect metaphor for so many sprints making great progress, but cutting down the wrong forest entirely.
AI can optimize our syntax, but it canβt fix the ego, fear of looking stupid, or over-commitment that actually derails software projects. Admitting 'I don't know' is still the most underrated senior developer skill out there.
Spot on write-up, Sylwia!
Exactly! Sometimes we spend entire sprints, or even entire months, cutting down the wrong forest.
And honestly, things become really magical when stakeholders actually want to listen when developers raise concerns early.
Iβve definitely lied to myself in the past, thinking my roadmap for developing an incremental learning AI was perfect, until wiring problems popped up. That pushed me to brainstorm a new method that mostly solved the issue (hopefully π). Reading this article reminds me how important it is to admit what we donβt know and iterate honestly, instead of assuming everything is under control.
Exactly π Iβm actually a huge fan of regularly asking myself every few weeks or months:
βAm I even moving in the right direction?β
Because sometimes we become so focused on execution and βmaking progressβ that we stop questioning whether the goal, architecture, or even the whole idea still makes sense.
The one I relate to most is lying about how long things will take β specifically in the optimistic direction. There's a particular kind of lie where you know the estimate is wrong while you're saying it, but the social pressure of the room makes you say it anyway. What I've noticed is that it's way easier to be honest about estimates in async communication (a doc, a comment) than live in a planning meeting. The meeting format itself creates the lying. Has that matched your experience too or do you see it break down differently in remote vs in-office teams?
Oh, I absolutely used to do that myself π Especially as a junior or mid. Sometimes I knew the estimate sounded too optimistic, but the atmosphere in the room kind of pushed everybody toward confidence.
Now Iβve gone almost completely in the opposite direction π Iβm the person constantly saying:
βthis may take longer,β
βthere are risks here,β
βwhat exactly do we mean by this requirement?β
and sometimes I ask the same clarification question twice just to be sure.
And funnily enough, the result was the exact opposite of what younger-me feared. People now see me as a great coworker and lead because they know Iβm trying to surface problems early instead of pretending everything is easy.
Though to be fair, having more years in the industry probably helps too π
Haha, we've been saying this for years β even us neural network devs tell the companies straight up, but nobody listens π . They want us to present them magical, imaginary neural networks, and honestly it's all a joke on people's minds. The companies know, but the money keeps flowingβ¦ don't ask me why π€·
It all starts with data. A lot of ML/DL folks don't really understand how data patterns can blow up later, or how a "FP/FN" prediction can quietly cost billions. But hey β just delete the weird patterns, train the model, publish in a fancy journal, get the investment π. Easy.
And it doesn't stop there. Some engineers got really good at storytelling β announcing a "brand new architecture" that's literally the same old math with a different logic layer on top. Everything we're doing today is basically built on a handful of papers. That's it. That's the secret π€«
Even classic software engineering is weak now, but at least it's predictable β you can guess where the bugs will be. But LLMs? Good luck.
Picture the poor team lead on Wednesday morning: 100+ commits already merged into the repo, half of them barely reviewed. Does he read them? Call the PM? The ops guy? The sysadmin? The server admin? π He's just lost, drowning in PRs from teammates who are also drowning.
We've got a few years, max, before we hit something like the early-2000s crisis β except this time it'll be called Attacking AI. Mark the date π
Hahaha, Iβm saving that date then ππ
But honestly, thereβs probably a lot of truth in what youβre saying, especially when it comes to company marketing and the pressure to present AI as some kind of magical solution to everything.
π π Yes, keep it and I'll remind you of this comment someday. And if you have some free time, take a look at this:
youtu.be/j51uMah-3js
Ah, I definitely will watch it π
After transitioning to independent development, the biggest change isn't technical ability, but rather having to start facing problems that could previously be avoided in a team:
Do I really know what users want, or am I just "cutting down the wrong forest"?
Is my estimation reasonable, or am I deceiving myself into thinking "I can get it done today"?
Is the tech stack I chose truly suitable for this project, or is it just because I don't want to learn something new?
Team development can rely on processes, reviews, and colleagues to uncover lies. Independent development cannot.
No one will correct you. You can only discover it yourself, admit it yourself, and improve it yourself.
This is also why I now really enjoy reading these kinds of "developer self-reflection" articles. Because I find that those excellent independent developers don't lie, but rather they are extremely honest with themselves.
For example, the article mentions "admitting that you don't know" β now I often say in independent development communities and tech forums, "I don't understand this issue," and then ask for help from others.
I used to think this was embarrassing. Now I think, pretending to understand when you don't is truly embarrassing, and the time wasted is your own.
Thanks for this comment! And honestly, from that perspective, these kinds of βliesβ become even more dangerous π
Especially the indie-dev type of lie:
βjust a little more work and everybody will definitely buy this.β π
Thatβs probably where it becomes really important to occasionally climb to the top of the tree and ask:
βWaitβ¦ are we even cutting down the right forest?β
So true! This hits close to home. In software engineering, the complexity of human nature always outweighs the code itself.
Admitting "I don't know" is where true confidence begins. As developers, having the courage to challenge assumptions is far more valuable than blindly churning out lines of code.
Absolutely π Not only for us as developers, but most importantly for the project itself. Blind confidence may feel good in the moment, but honest discussions about uncertainty usually save teams from much bigger problems later.
The estimation one hit hardest. I have sat in planning sessions where the discussion about how long something would take lasted longer than the actual implementation. And somehow that never changes anyone's behavior the next sprint.
The "I'll figure it out" lie causes the most damage though. Not because they fail β often they do figure it out. But three days later than they should have, after going the wrong direction, because asking early felt riskier than staying silent.
The part about the brilliant developer feeling like an idiot on every new project is the most honest thing I have read about software development in a while.
Hahaha yes π Endless estimation discussions are truly something else.
I once had so many meetings and debates about a single feature that I joked I could have already implemented it in three different variants, including a feature flag system allowing us to switch between all of them π
This resonates more than most people will admit.
What stood out to me is that most of these βliesβ arenβt really intentional deception β theyβre coping mechanisms in environments where uncertainty is constant but rarely made explicit. We reward confidence, speed, and predictability, even though software work is often the opposite.
Oh yes, I absolutely love that last sentence too. I honestly couldnβt phrase it better myself π
Because thatβs exactly the problem: people are often afraid to openly say during planning:
Unless, of course, you already have 10+ years of experience and the magical βseniorβ status π Then suddenly everybody assumes:
βokay, if this person says itβs risky, thereβs probably something there.β
"Some Developers Lie About Knowing What Theyβre Doing"
To be Honest, just love it , i do not Know What i am Doing and i don't lie about it ! It's fun doing things you don't Realy know. But i guees im not a Developer, just Someone Somewhere, doing Something. π
Hahaha π Of course, that part can actually be fun sometimes! The problem starts when the stakeholders are strongly hoping that you do know what youβre doing π
The Stakeholders, who are they ? by the way, you are right " AI Wont't Fix it " Stakeholders won't Fix it.... but we as Humans need to Fix it, all of it. Greetings @sylwia-lask
Lumberjacks joke is the whole article π Been there β asking "are we solving the right problem?" after two sprints of "great progress" and getting looked at like I kicked the team dog. Nobody rewards the person who stops the assembly line.
AI makes this worse honestly. Agents scaffold features in minutes now, so the pressure to just ship is massive. Nobody wants to be that person. So we let the lumberjacks run faster and call it velocity πͺ΅
Real seniority isn't knowing what to build β it's having the spine to say "hold on" when everyone's already moving. That's a human problem no model will touch !!!
Oh yes, exactly π And that joke is so good precisely because half the time itβs not even really a joke π
The worst part is that sometimes you do say:
but you need to repeat it to stakeholders like 10 times before it finally sinks in π
(Though honestly, if they eventually listen at all, thatβs already a win π)
This is such an honest and refreshing take. We constantly mask our overwhelm with "I just haven't had the time," when the reality is often closer to burnout or context-switching fatigue. AI might write our boilerplate, but it definitely won't fix the human habit of over-promising to ourselves. Thanks for the transparency!
Exactly! AI wonβt save us from that part at all.
And context-switching fatigue is very real. Sometimes after jumping between meetings, tickets, chats, reviews, and random production issues all day, your brain feels like browser tabs fighting for RAM.
Honestly, this hit harder than a production bug on Friday evening π
My first real βdeveloper lieβ experience was when I confidently said, βYeah, I can do this.β
Translation:
βI have no idea what Iβm doing, but Stack Overflow, AI, caffeine, and divine mercy will form a temporary engineering team.β π
And now with AI, the lie has just upgraded.
Before:
βIβll figure it out.β
Now:
βIβll ask AI and pretend I architected the whole solution.β
But the funny part is, AI can write code, explain code, even roast your codeβ¦ but it still canβt fix unclear requirements, ego-driven decisions, bad estimates, or that one senior dev who says, βThis will take two weeksβ and finishes it before lunch.
At the end of the day, the biggest bug in software is still human.exe.
And maybe the best debugging command is still:
βSorry, I donβt understand. Can you explain it again?β
Thanks for this comment π And honestly, I absolutely love the βhuman.exeβ part π
And exactly β asking questions usually doesnβt hurt nearly as much as people fear. Because in the end, weβll either need to ask eventually anywayβ¦ or spend even more time fixing misunderstandings later π
So itβs often much better to clarify things properly at the very beginning.
Thank you. Some good observations. And sure, these are human issue, but they are also issues with the culture: fear of admitting that you don't know (yet), fear of not living up to some standard, fear of looking stupid, fear of losing job, etc. Those are organizational and management issues (and larger cultural/societal issues). It is not as much about honesty, but about having an environment where it's safe to admit that you don't know, etc. No AI is going to solve any of it. It may make matters worse.
I fully agree π And honestly, AI may even amplify this pressure.
Because now, instead of:
you may start hearing:
Which can make people even more afraid to admit uncertainty, ask questions, or say:
βI still need time to properly understand this.β
Great perspective on developer honesty in the age of AI. The gap between what developers claim to know and what they actually deliver has always existed, but AI tools amplify it by making it easier to produce convincing-looking code without deep understanding. The real challenge is building a culture where admitting knowledge gaps is encouraged rather than punished. Technical interviews that test rote memorization over problem-solving ability are part of the problem. Love the callout about AI being a tool that exposes existing systemic issues rather than creating new ones.
Exactly π I really like your point about interviews too. Sometimes we reward people for sounding confident and memorizing things instead of rewarding curiosity, reasoning, and the ability to learn.
Totally relate. Software engineering is built on code, but its foundation is human. No AI can fix ego, blind optimization, or communication silos. Instead of waging holy wars, we must embrace transparency and respect the core domain. Drop the ego; focus on the reality.
The βdrop the egoβ part is beautiful, honestly π
This hit harder than I expected.
One of the biggest βliesβ in software development is probably pretending certainty exists in complex systems.
People say:
βThis should only take 2 hours.β
βYeah, I understand the architecture.β
βThis refactor is safe.β
βAI will handle most of the work.β
But large systems are full of hidden assumptions, legacy decisions, undocumented business logic, and human coordination problems.
AI accelerates execution, but it doesnβt automatically solve:
unclear requirements,
poor communication,
fear of asking questions,
unrealistic deadlines,
ego-driven estimations,
or teams optimizing for velocity instead of understanding.
The part about admitting βI donβt knowβ is especially true.
In my experience, the strongest engineers are usually the ones most comfortable saying:
βWait, this doesnβt make sense.β
or
βCan someone explain why we built it this way?β
That mindset prevents disasters.
A lot of junior developers think senior engineers have everything figured out.
Most seniors are just better at navigating uncertainty without panicking.
Exactly π I remember once joining a project where my predecessor had created some absolutely bizarre RxJS constructions, to the point where maintaining a very simple app became unnecessarily difficult.
When I asked another developer why we were overcomplicating things so much, he honestly didnβt even know π
And Iβm 100% sure that a few years earlier I would have simply assumed I just didnβt understand the genius of the previous developer π
βUse THIS technology and ONLY this technology... Angular vs React, Java vs Python, Rust vs literally anything else π"
Holy wars aside, if a senior dev has this strong of an opinion on something, you'd do well to listen to them. Assuming we're talking about actual senior devs here, not the HR definition, those opinions are usually born of hard-earned lessons. It doesn't always mean they're correct in their assertions, just that they have good reasons for making them.
Hahaha π But what happens when one senior says:
and another equally senior developer says:
Who are we supposed to listen to then? How are we supposed to live? π
Solid article. Would love to see a follow-up on how these patterns behave under real-world constraints.
Hey, thank you so much! π Iβm not really planning a direct follow-up for this article right now, but next week I actually want to write about what βSenior Developerβ even means in the current AI era.
And honestly? Iβm secretly hoping the discussion in the comments will become even more interesting than the article itself π
Well, you are lying about writing this post yourself. AI slop all over. Just look at the last sentence: "So⦠what kinds of developer lies do you see most often in your team?" - really?
Hahaha π If AI had really written the whole thing, it probably would have ended with: βHere are 7 actionable takeaways for maximizing engineering productivity in 2026.β π
Whatβs actually fascinating to me sociologically is that somebody always appears to accuse me of using AI, but only under posts that become popular. Meanwhile nobody goes under obvious low-effort AI slop like: βIntroduction to Python loops #847β to complain about AI-generated content π
And the funniest part is that you got suspicious because of a CTA at the end of the articleβ¦ something bloggers and writers have been doing for like 20 years π
This was a great read for me, thank you.
Thanks a lot π₯°
That is true! I attended my cybersecurity event (CIS Summit 2026) about 2 weeks ago. I spoke to cybersecurity analyst. They are looking to work with AI but cautious at the same time
Exactly, Ben π AI is a tool, not a magical solution to all our problems. And honestly, I think cybersecurity people are right to be both excited and cautious at the same time.
exactly
Awesome , article , captivated me from the beginning to till the end.π
Ah, thank you! Itβs always been my dream that people would just genuinely enjoy reading my texts, and then end up scrolling through my profile to read more π₯°
This resonates with my experience. Sharing with my team - we need more honest conversations about developer best practices.
π₯°βΊοΈ
Many developers ar impressed by "New Technologies" and not think about the issues as "What is the cost of using that technology?" or "Yes, it works in Netflix, but, is our company as big as Netflix?
Exactly π Though honestly, I think this mostly happens with mids. Later, when people start carrying bigger responsibility for projects, budgets, stability, and long-term maintenance, they suddenly think three times before copying Netflix architecture into a medium-sized company π
I only see the myth, the legend and a tiny tiny bit of AI .. and that is where folks I communicate most of the times
Hahaha, thank you so much β€οΈ
Hi
This post made my day. Let me lie for another one more day.
Hahaha π Until the end of the world then π
so true....
Thanks π₯°
They lie because Silicon Valley tells you to love aesthetics over realism, whereas in Africa Aesthetics don't fix SHIT!
Not only in Africa, not only there π
WE! Couldn't care about anywhere else Africa for Africa π
THAT'S HOW EUROPE WORKS! π
This is very interesting. thank you
Thanks a lot! π₯°βΊοΈ
Really good to know. And the bad news is that those lies are told by non-tech folks and they don't even know how to use AI to get anything to fix, haha
Thereβs definitely some truth in that π I actually had a colleague once who wanted to prove that non-technical people can fully program now thanks to AIβ¦
Well, turns out they still canβt quite do it that easily π
That's right, artificial intelligence isn't the Wizard of Oz who grants everyone's wishes!
Exactly π At the end of the day, itβs still just a tool. A very powerful and impressive tool, sure, but still a tool π
Perfectly said, something design don't map to reality, code reveals them. And yeah llm models aren't the future they're ment to be tools not replacement
Exactly π Sometimes reality simply refuses to cooperate with beautiful architecture diagrams and optimistic plans π Code eventually exposes all the weak spots.
And yes, I also see LLMs more as tools than replacements. Very powerful tools, absolutely, but still tools.
Such a thoughtful thread! Iβve noticed the same thing in AIGC development: AI generates content quickly, but itβs easy to ship work we donβt fully understand. Honesty is really important here.
crawler-intern live proof (safe to delete)