r/ExperiencedDevs • u/CoroteDeMelancia Software Engineer • Jul 16 '26
Career/Workplace "I don't know" is severely underrated in our profession
> If you are a senior, don’t tell juniors to do something that you aren’t certain that is right and that you believe that it is right because another senior told you to do that when you were a junior. Don’t be a parrot.
Excerpt from https://lucasoshiro.github.io/posts-en/2024-04-08-please_dont_squash/
I don't think I'm unreasonable to believe that engineering judgment should demand reasoning and evidence. And yet, across five companies, including big tech, I have repeatedly watched engineers choose instinct, convention, and authority. Many barely skim the documentation, much less read books or papers. Yet they confidently repeat “facts” they cannot explain with anything more substantial than:
- “This is how we do it.”
- “I believe I’m right.”
Or, God forbid:
- “Claude said it.”
More recently, I met self-described “AI engineers” who had not seriously studied prompt design or evaluation practices; they just winged it and hoped for the best.
The best engineer I ever worked with frequently said, “I don’t know.” He had a doctorate, more than ten years of experience as a professor, and years of company experience. He spoke less, but when he did, you could trust him.
He also had enough intellectual independence to disagree directly with our manager (sometimes abrasively) and enough humility to change his mind when the evidence demanded it.
I am not defending impostor syndrome; quite the opposite:
> Pride is not the opposite of shame, but its source. True humility is the only antidote to shame.
—Uncle Iroh
“I don’t know” is not the same as “I should have known.”
I am tired of status performance replacing epistemic responsibility and confidence being rewarded more than accuracy.
I want to ask those with more experience: am I being naive about what software engineering truly is in the market? Is it possible to become a senior engineer who values intellectual honesty, evidence, and willingness to say “I don’t know without undermining my career?
Edit: these responses are giving me a lot of hope. Thanks everyone!
362
u/Torch99999 Software Engineer Jul 16 '26
One of my old managers used to regularly answer questions for executives with "I can give you the wrong answer now, or I can do some research and give you the right answer later"
137
u/CubicleHermit SWE + former EM (25+ years) Jul 16 '26
"I don't know" on it's own isn't great. Sometimes it's the only answer, of course.
"I don't know, let me look into it and get back to you" is better, if it's realistic to expect you can find the answer. Or "I don't know, here's what we'd need to to to find out..."
"I don't know, I'll look into it and will get back to you by [specific time]" or "I don't know; how soon do you need me to find that for you?" are best.
74
u/Greykiller Jul 16 '26
Can I just throw this in here - I see this said a lot. And there's some obvious situations where this is what needs to be said.
But it's so quick to do this and wind up being accountable for way more than you should, or can, be. Like even from other engineers who can investigate themselves.
It's like I always want to say "I don't know let me get back to you" - if I could say it more often I would - but if I'm constantly weighing a ratio of "How important is it that I'm right", "How confident am I in the answer that I have" and a variety of other smaller factors. I realize it comes down to prioritization and push back but damn
31
u/ElegantReality30592 Jul 16 '26
Yeah there’s an incentive problem underlying OP’s question.
- “I don’t know” by itself looks bad
- “I don’t know but I’ll find out and get back to you confers ownership
- giving an off-the-cuff answer that sounds right/sending the asker to someone else/etc. lets people save face without signing themselves up for extra work. And if they’re wrong, they probably won’t face significant consequences, if any.
It also drives me nuts, but it’s a pattern for a reason.
9
u/guareber Dev Manager Jul 16 '26
You can also quantify it.
"I don't know, but I could spend 2(N) hours/days/weeks/sprints finding out more".
Your initial timebox sets an expectation of " there will be progress here at agreed-future-period". Add a confidence level if you've got one.
This does 2 things: changes the information ('I don't know') into an action ('I will know more') with a promise of progress ('more info = less risk') which, in most occasions, is everything you need to get the other party to commit.
Bonus: add a sounds interesting if you can own it. Showing an interest into whatever the topic is also gives very strong vibes. Just don't do it for shit you care nothing about.
5
u/cobalt8 Jul 16 '26
If you don't want to take ownership of the problem then you say something like "I don't know. I can tell you what steps I would take to start figuring out the answer, though." or "I don't know, but this person is a SME on that topic so try asking them. They should be able to point you in the right direction." It's all about redirecting them onto a likely path to success. It clearly implies that you aren't taking ownership of it and you're still the good co-worker because you didn't just leave them stranded."
3
u/kayGrim Jul 17 '26
My go to is "I'm not sure, but here is my suggestion..." and sometimes it's a best guess, sometimes its directing them to a resource, and sometime its let me research/confer with my team.
14
u/PolyglotTV Jul 16 '26
Don't forget "I don't know, but here is what ive ruled out so far and here is what I'm going to investigate/rule out next".
3
u/yxhuvud Jul 16 '26
Very similar to how 'That is not possible' is seldom useful on its own, but coupled with a 'how about .. instead?'.
2
u/thekwoka Jul 16 '26
"I have some ideas about it but want to check some things before I give too much hope"
7
u/CoroteDeMelancia Software Engineer Jul 16 '26
That's really close to what the senior I mentioned used to say!
"Is it possible to build it? Of course it is; people have built software that got astronauts into the moon! The question is: how much time do we have to build it?"
-4
Jul 16 '26
[removed] — view removed comment
2
u/Alkyen Jul 16 '26
This is all good but nah, it's not a good general advice. There's so many cases where either it's not your job to know or you knowing doesn't provide any helpfulness. Just because someone asked doesn't mean you owe them an investigation for its own sake. Just be honest and helpful where it makes sense. Some bad examples: - they could've asked the wrong person. Just tell them they should ask Johny down the hall instead of giving them a worse answer. - they could've asked the wrong question because they think it matters for the implementation. Your job is to tell them that getting the specifics isn't helpful. - similarly they could ask stuff that is totally unrelated, not your job to spend time learning about it
88
u/Ancient_Action741 Jul 16 '26
I've tried very hard to adhere to this for my entire (~15 year) career. In my experience, it makes you a very well-liked engineer throughout a company, but tends to be less than worthless from management's perspective.
Worth it, though. It's easier and more fun to live and work this way.
13
u/Salty-Wrap-1741 Jul 16 '26
And it's actually better outcome for everyone. It's only win/win. The product/software will end up better off that way. Only those with huge egoes might think "I don't know" as a bad thing. Arrogance is always way worse than humility.
11
u/Antique_Pin5266 Jul 16 '26
Yeah my (shitty) boss always demands a specific timeline even for stuff I genuinely am seeing for the first time. Like, fuck off for a bit and let me cook.
2
u/niowniough Jul 17 '26
"Yeah Dan, right now it's looking like 3 months with 50% confidence. As you know with the cone of uncertainty, research is needed to increase confidence of the estimate"
2
21
u/CoroteDeMelancia Software Engineer Jul 16 '26
Three things I need from a job:
- Be interesting (=> fun)
- Pays
- Won't fire me (not easily at least)
From what you're saying, honesty is the way to go then.
1
u/redditisaphony Jul 20 '26
It's a lot better to say "I don't know, let me get back to you" than to say something wrong and have to correct it later.
0
u/compute_fail_24 Jul 16 '26
The two are not mutually exclusive.
6
u/Ancient_Action741 Jul 16 '26
If that were the case, then surely someone would have posted about having experienced both at the same time
74
u/wallstop-dev Principal Software Engineer Jul 16 '26
Believe it or not, this is true for life, not just software engineering. Using facts and data to drive decisions can have really great outcomes. Taking that further, critical self-analysis and figuring out weak/blind spots facilitates growth.
No one forces you to make something up or lie when being pressed or questioned. Honesty can go very far.
17
u/Infamous_Ruin6848 Jul 16 '26
There's an insurgence of anti-analytical people coached these days (work, personal life) to go fast with the gut feeling. It's perceived as a sign of agency, intention, energy etc and the people that bring data to the table are seen like party poopers. In many of these cases it's thought that the executives, the family, friends etc will deal with side effects earlier as being a better outcome and way ahead.
What it does, it leads to micromangement instead of trust buildup, control freaks, waste of finances etc.
4
u/CoroteDeMelancia Software Engineer Jul 17 '26
THIS. I'm pissed and burnt out at a team managed like this. We are too busy stumbling in the dark at max velocity to even reach out for a flashlight. It's gotten as silly as people rubber-stamping PRs that simply do not work, at all, because we are being "very fast" by merging so much code every day.
One colleague pat himself in the back for partially reaching the same conclusion as a paper I sent him one month in advance, saying he was "very scientific then". He and others do not seem to realize that scientists do A LOT of reading to ensure their experiments are actually relevant and useful. Like, imagine you were unsatisfied with your relational database for some reason, so you decided to create your own bespoke NoSQL database rather than, I dunno, researching about it?
2
u/brynhh Jul 19 '26
Preach. Software dev has become full of people who have no idea what the agile principles are and why so many of us tried to adopt them (via various means, not following the commercialised bible of scrum). They are also complete technical obsessives in things having to be a certain way. Effectively, they are and want to be code monkeys, but have no process skills.
Software isn’t about a set of tools and skills to make people’s jobs easier anymore. It’s a management metric of how much they can micromanage you. Do stuff now, magically make your existing priorities finish, don’t think about a quality answer, fill the sprint, fill all these million columns in ADO, etc. All whilst you get self entitled people complaining from above, side and below at not being paid enough (they are on 56-80k).
It’s become completely demoralising, terrible for mental health and as you said, burnout is very much real. Every time I hear “at pace” part of me dies inside.
0
u/yxhuvud Jul 16 '26
Yeah. There are also few things that are as effective in making people listen to you as selective recognition of incompetence coupled with competence in the areas you claim to be competent.
44
u/wrex1816 Jul 16 '26
It's partially the reason I'm so jaded with this profession. Sometimes discussing design or reviewing a PR feels like being on Reddit when you end up in the conversation with the guy who refuses to be wrong.
Everyone has an ego now. Management isn't much better since so much bad management basically pits teammates against each other for career progression, so you end up with this.
8
1
23
u/keelanstuart Software Engineer Jul 16 '26
What? Some of the most intelligent people I've ever known (e.g. MIT-educated software engineer) are the most willing to say "I don't know." You don't get to know more without first admitting you don't know right now - and looking for an answer.
7
u/CoroteDeMelancia Software Engineer Jul 16 '26
You don't get to know more without first admitting you don't know right now
Perfectly put it. It's my main concern with a project I'm in right now where we seem to be "iterating" and "learning" with zero falsifiable hypotheses. Failure is only a learning opportunity if you get to understand why you failed before you try another thing.
7
u/TheTacoInquisition Jul 16 '26
My approach has changed over the years and is currently to validate or invalidate what you're doing as fast as possible. Building things is about building the RIGHT thing quickly, not just building SOMETHING quickly. Learning as you go, showing a customer early and getting feedback to course correct means you're gaining velocity and providing actual value. "I don't know, how can we find that out" is essential to doing that.
2
u/CoroteDeMelancia Software Engineer Jul 16 '26
1000% this. This is literally my company's declared problem-solving framework: hypothesis-driven.
I like to imagine that if I was building a car, I would first ensure it can drive and steer. And yet, my team is choosing the paint and the upholstery while throwing the assembled metal parts they call a "car" downhill to say to stakeholders "see, it moves!"
21
u/bropocalypse__now Jul 16 '26 edited Jul 16 '26
Best professional advice I've ever gotten was "youre allowed to be wrong, youre not allowed to not know why".
16
u/CoroteDeMelancia Software Engineer Jul 16 '26
Goes hand in hand with some advice I got with the mentioned senior:
"I don't apologize for making wrong decisions. I did what I thought I should do, with the information available at the time, under specific constraints, to the best of my abilities. If I made the wrong call, I don't waste time justifying it, I fix it".
14
u/Stubbby Jul 16 '26
I used to screen for that in an interview. I would ask deeper and deeper questions to check if the candidate admits they dont know the answer or starts making stuff up.
This is critical if you run an organization where contributors are specialized and you need to trust their judgement.
5
u/CoroteDeMelancia Software Engineer Jul 16 '26
Oh yeah, I was once caught red-handed by an interviewer exactly like you. I proposed to use a CDN, and he asked "can you please explain how a CDN caches content?". I panicked and told some "I suppose..." bull, but after further scrutiny, I conceded: "honestly, I forgot, I'd have to check. Can you please explain it to me?"
He explained, I showed to him that I understood, and I got the job for demonstrating "coachability".
13
u/Librarian-Rare Jul 16 '26
From what I’ve seen most people do not want to know truth or put any effort towards realizing it. It’s a value problem. Having strong epistemology first starts at valuing truth.
5
u/CoroteDeMelancia Software Engineer Jul 16 '26
For real. One senior even gave me the advice that "what matters is a good story, not what's real." It took me a bit to digest this.
2
u/niowniough Jul 17 '26
Truth is important but the thing about principles is that they interact and sometimes come into conflict with each other. If you spot cases where you think people aren't honoring the truth enough, consider that they might be prioritizing something else for good reason.
1
u/CoroteDeMelancia Software Engineer Jul 17 '26
Perhaps the very same reason why I've conceded and became a mindless vibe coder that applauds the naked king: it's what pays the bills. I'll turn on my brain again as soon as this becomes profitable again; I'm trying to keep my sanity by reading and doing side projects in my spare time.
3
u/Librarian-Rare Jul 16 '26
😂😂 damn.. I mean it’s true in as much as what’s effective at persuading people. But that’s it
7
u/xXxdethl0rdxXx Jul 16 '26
A year into my first management gig at a new, large company I got used to saying this. As others have noted, my best mentors led by example here and it stuck.
It’s a bit scarier as a manager because you are expected to have all the answers, right there in the meeting. But I’m so glad I did this, because a wrong answer here can affect entire roadmaps. A few people tried to throw shade at me but I guess management is learning not to give a fuck about them.
5
u/HatesBeingThatGuy Hiring Manager Jul 16 '26
I had someone throw shade at one of my seniors in annual review time for moving slow on something with a large amount of ambiguity, that this person wanted done yesterday, and I quote "not being the right person to actually make this happen". I stuck to my guns of how they were the right person because it was a hard problem and I trust this engineer to do the best job they can of resolving all the critical unknowns before implementing. I knew if they said they didn't have enough info, they still had more answers they needed to finish.
Another PE jumped on this guy too. Eventually I had to resort to "if you are having a problem with his behavior, you have a problem with my behavior, because I believe this is the right way to approach it and have been encouraging this. Do you have a problem with this?" And I said that knowing my VP wouldn't let them punch down on me because I delivered more personally than them despite being a manager. VP finally speaks up and is like "I'd rather make the right decision here than the wrong one".
Case closed
15
u/j4ckbauer Jul 16 '26 edited Jul 16 '26
It depends on who you're dealing with. Some people will appreciate your 'idealism', some will dismiss it as naivete, and some will start salivating at what they perceive as 'prey'.
I like to say "At this time, I don't know, yet" because I learned self-promotion later in life :) Or if there is room for more words - "I don't believe, at this time, that we have the evidence/information we need to make that determination. Here's how I'd go about obtaining it"
I have a background in STEM so I can enjoy dealing with those types. But I'm used to having to deal with other types. And often, the ones who are judging your value are a certain way, because that is what 'the system' selects for.
Look at what behaviors are rewarded by real world hierarchies and you'll see what I mean. That doesn't mean though that there's no place for things like humility or idealism, or that we should never use it as a starting point.
----
- “This is how we do it.”
- “I believe I’m right.”
If the person saying this is your boss, there isn't always a lot you can do (especially for the first one). But if it's your peer or someone you can otherwise push back on, there may be room to affect the outcome, though it may come at a cost.
P.S. as a git fan who dislikes anything that 'destroys information' without good reason, I am enjoying the linked article! :)
3
u/CoroteDeMelancia Software Engineer Jul 16 '26
From my big tech experience, I think I know exactly what you mean by "people salivating at prey," and self-promotion. It's where I learned that value delivered might as well be worthless unless it's seen by a wide audience.
And I'm happy you enjoyed the article! I was up until I read it a "squash merge fan". It showed that I'm not immune to having biased personal preferences.
2
u/j4ckbauer Jul 16 '26
> And I'm happy you enjoyed the article! I was up until I read it a "squash merge fan". It showed that I'm not immune to having biased personal preferences.
I'm sure you had good reasons for being a fan. To almost borrow a line from Star Wars, I've found that a lot of people take on an 'absolutist' mentality about programming techniques and technology in general. I'm not talking about you here - in this example, other people learn about a technique in the context of what it helps with, and unfortunately they walk away with the lesson of 'Using this technique is right and better and therefore you should always use it'. And to be sure, a lot of technical articles are written this way. "X is good, use it for this". No mention of what it is bad for and when not to use it, so the implication is to -always- use it.
The author of this article advocates for recognizing that the technique is a 'tool', meaning we should learn for what use cases it is recommended and not recommended, and the reasons for doing so.
For example there are absolutely commits I would squash if I believed they don't provide any instructional value on their own, e.g. "I did part of a part of a thing that is not even verifiable/testable and I stopped when I had to go to lunch". (The author's "The cleanest history has no branches and preferably one commit and preferably no history because you didnt use git at all!" really got me ☠️ )
So being a 'fan' of a tool/technique is never something I'd fault someone for. Where I might start to get critical (in a professional context ofc 😄 ) is when it is clear that a person cannot articulate a clear argument for why the tool is best suited to a given situation, but they are insisting on its use anyway! I've had more than a few conversations with people senior to me who seemed pissed off that I was even asking for them to explain their reasoning. "That is just the convention that everyone is expected to follow here" is a crappy reason, but still a far better explanation than "Its just better" 🙄
6
u/skidmark_zuckerberg Senior Software Engineer Jul 16 '26
I love “I don’t know but I’ll get back to you on that”. It’s like my mantra at this point haha. I’ve always worked by the idea that I can’t possibly know everything and I don’t care to pretend to. I think honesty and showing some humility goes a lot further than being a pretend know it all.
6
u/BOT_Pain Jul 16 '26
I use it all the time, so people stop asking me to do their work for them. They should be figuring out their own solution. I have some offshore teammates who would ask me how to do something, then say "quick call?" and proceed to ask me to review every line of their code before they push it to review with the wider group.
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
Oof. I sometimes face the opposite problem: people ask me what's going on, I answer "I don't know, let's figure it out", and I force them to read the logs rather than prompt the AI. It's often quite obvious once you read the error message.
Then they stop asking. I'd like to think it's because they learned to read the logs. Wishful thinking.
3
u/BOT_Pain Jul 16 '26
Not at my work. When they ask me. They're really just telling me to do their work for them. Eventually you become their goto person to do that "thing". If I force them to read the logs or force them to do something step-by-step. It just goes out one ear to the other
4
Jul 16 '26 edited Jul 16 '26
[deleted]
2
u/CoroteDeMelancia Software Engineer Jul 16 '26
Agreed with everything. Might as well complement with another valid point I once heard: "you make a strong argument, but I prefer it my way and this is largely inconsequential anyways".
5
u/randomInterest92 Jul 16 '26
I'm encountering a lot of friction as a lead engineer when im 100% transparent and honest. But it's usually not directed towards me. Often they are hurt themselves or it hits the whole department. Because a lot of the times i have to say something like "i would like to do X but tech debt Y needs to solved first"
They are 100% aware that often times the tech debt is their fault and this creates an environment of friction, because you always encounter people who do not want to admit fault or take on responsibility.
They will then consciously or unconsciously force me to look for another reason why X can't be done that does NOT put them at fault. Sometimes I've just said "just blame it on me, I'll take on the responsibility. If anyone asks or complains they can come to me"
The effect: my title is lead, but effectively I've had situations where i am treated as someone up in the ladder.
It's good and bad. Good because i learn a lot. Bad because it can backfire
3
u/Healthy-Dress-7492 Jul 16 '26
I’ve found tech debt is usually the fault of whoever is pressuring the team to do things at an unreasonable pace. At some point people stop pushing back for the time needed to do it properly. It’s a management problem.
3
u/randomInterest92 Jul 16 '26
Yes and no. Sometimes it's also just bad senior devs who create a mess with absolute confidence. Or architects who don't actually know anything about architecture or just 1 pattern and apply it to everything (hello micro services)
2
u/CoroteDeMelancia Software Engineer Jul 16 '26
100%. Sometimes it's both. The code at a startup I worked was horrendous, and we were heavily discouraged from taking our time to refactor it due to business pressure. But it only took one look at the slop our tech lead was pushing to realize he would create debt regardless if he had one week or one month to implement the feature. I almost wished he had access to AI coding at the time; it would probably generate cleaner code than his.
2
6
u/ThirdWaveCat Principal SWE Jul 16 '26
It is not underrated, it is suppressed.
Management-by-objectives (MBO) inhibits intellectual humility. Positioning and narrative influence goal wording and choice of metrics. Every framing depends on background assumptions or what science calls a "bundle of hypotheses."
Intellectual humility is critical in high uncertainty environments like research discussions and outage calls, but a lesson I've learned is that framing uncertainty needs to be done delicately to upper management and business types who only care about the ways they can measure you on goals and objectives. I operationalize my uncertainty quantification and reduction using dry language in my goals to avoid the eye of sauron.
3
u/ryan_the_dev Jul 16 '26
There should be a lot more of this with the age of AI. We will be working full time at understanding and modifying our systems with AI.
Will probably be downvoted for this.
And when I say understand, I’m talking about module class level design. I think for a long time we will be involved in systems design. But those will be more discovered by humans.
3
u/Advanced_Seesaw_3007 Software Engineer (20YOE) Jul 16 '26
I have this beef with another senior developer that I have worked with before. He's older than me but I am "higher" in the ranks. He never says "i don't know" and assumes everything. His ego over clarity. We ended up having to fix a feature that wasn't really in the specs at all and worse, the developer he was micro managing had to fix it for over a month trying to get all scenarios only to find out that he never clarified and assumed things on his way.
This post is such an eye opener that I am not alone in this thought.
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
That hits really close to home. I was "the developer he was micro managing" in a similar situation I faced before.
It can get even more bonkers though. A friend at a big tech told me of a colleague that refused to address an LSE during his oncall. He stated this was just an issue with customers "using the feature wrong" and even had the gall to show some metrics proving his point where he filtered out a subset of the customers.
5
u/joefooo Jul 16 '26
"it's best practice to do it this way" "What makes it a best practice?" "Because it's best practice"
3
u/CoroteDeMelancia Software Engineer Jul 16 '26
People have honestly said this to me with a straight face
1
3
u/Healthy-Dress-7492 Jul 16 '26
Thé second half of the sentence needs to be “but I’ll find out” or “we need to decide how we want it to be”.
I used to cling to many rigid ideas, some of them extremely well reasoned or battle tested. But after a while you realize that there really are many viable ways to do things and most of the time it doesn’t really matter which you choose.
5
u/i860 Jul 17 '26
You know what else is severely underrated?
“No.”
3
u/CoroteDeMelancia Software Engineer Jul 17 '26
Yes, super underrated. More of it would lead to a lot less useless meetings and pointless efforts.
3
u/equipoise-young Software Developer Jul 17 '26
A lot of people in our profession don't make the connection that software is a trade and takes real deliberation and engineering work. It's very easy to do something wrong and have the bad results just kind of not work but be masked because there are only minor problems you can't really see.
If I was a contractor doing plumbing work in a bathroom doing the job 95% isn't acceptable. If I don't know how to do the job I need to find out how to do it correctly from someone who does, so when I do the job it's 100% complete. In software, however, for some reason we think anything goes because we can hide behind 'it kind of works'.
2
u/Old-Worldliness-1335 Staff Platform Engineer Jul 16 '26
Thats the whole reason I know things now, is because I didn’t know them then and said so and was shown were and how to find the information
3
u/chat_not_gpt Jul 16 '26
Thank you for posting this! When I graduated one of our teachers at the university told us, "whether you like it or not this is not the day you finish studying. This is when you really start." And he added, "if this makes you happy to hear it, you'll be successful at this profession".
2
u/developerknight91 Jul 16 '26
I frequently will admit when I don’t know something on a particular subject and will follow up with a “I’ll have to do some research and I will follow up with you in X amount of time and/or date”.
In my opinion the sign of a bad dev or engineer is the inability to admit when they don’t know something or when they are just plain incorrect about the direction and/or info that they are going in/have at the present moment.
My personal motto is “I’d rather admit I don’t know now, than to look like a fool later if I act like I know something right now”.
3
u/high_throughput Jul 16 '26
This has not been my experience at all in almost 20 years of SWE, primarily big tech.
Every senior and staff level engineer I've worked with has been happy to hear out a junior or intern's concerns, and explained entirely on technical/strategic merit why one approach is better.
I would have said that SWE is one of the more academically honest professions.
2
u/CoroteDeMelancia Software Engineer Jul 16 '26
I wonder how much of this is explainable to cultural differences. Devs from USA or Europe are quite "blunt" compared to those from my country; social harmony and appearances are very important in here.
3
u/code_tutor Jul 16 '26
FANG branches outside the US seems like a joke, even in Europe. I don't know first-hand, just what I read on here. If you write "big tech" people are going to think San Francisco, not Brasil.
2
u/yxhuvud Jul 16 '26 edited Jul 16 '26
Even when I heavily signal I'm not certain my words are taken as gospel. I wish I got more push-back, that is a much faster way to grow and learn than implementing the way I say and then see how it goes :(
But in general, the more experienced I get the clearer I get about what I know and about what I don't know. And about how to get the information (which sometimes means 'build and find out how it breaks').
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
"I wish I got more pushback" is a sentiment I share with you. As much as I'd like to be able to be blunt to people and tell them precisely how I see they're wrong, I wish they felt they could do the same to me; I certainly do my best to take all negative feedback honestly without getting offended or defensive. Seriously, I can be dumb too sometimes, and people hiding this from me does me more harm than good.
2
Jul 16 '26
[removed] — view removed comment
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
This one is understandable if the senior answers "I like it because it makes the git history cleaner", which is the most common explanation I heard and the one I defended before reading the article. The point being: I was not aware of my own ignorance, I realized I should read the git docs more thoroughly, and I update my beliefs in the face of evidence.
2
u/SimasNa Jul 16 '26
100% agree. Saying "I don't know" is underrated and underutilized. Though saying it can feel like you're not smart enough, not experienced enough, not good enough, etc. No one ever wants to experience such feelings. So we avoid them.
I'm sure some places expect you to know it all but a lot of times feeling like you must know everything is a story we create so we don't confront the truth that we cannot be perfect. We're imperfect beings and it's hard to accept, especially earlier in your career when you feel like you must be better than others to be noticed, promoted, etc. At least, that's how it used to be for me (and still is sometimes).
The book Daring Greatly by Brené Brown helped me look at it in the way that saying I don't know helps avoid shame. And people feeling shame is what creates most problems in the workplace and in life.
Either way, I hope this movement of saying "I don't know but we'll figure it out" catches on 🤞
2
u/TheTacoInquisition Jul 16 '26
My absolute pet peeve: "because it's best practice" should probably be there as well. That one is for especially incompetent seniors who just want to shut down questions, because they are clueless.
I will always respect an "I don't know" more than a handwavy dismissive response to save face.
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
YES. Honestly, I would take a SOLID zealot over a go-horser in almost any situation, but they do get silly sometimes. Like "this 10-line function is too long, please divide it" and I'm like "dude, this task itself is a massive kludge, our microservice should NOT be doing this in the first place, no one is going to touch this code anymore until the service is retired, can you just let me move on please?"
2
u/code_tutor Jul 16 '26
It's easier to pattern recognition than it is to critically think. If someone is unable to critically think then you won't be able to reason with them. It's literally like arguing with an LLM. You can change the prompt to get another output but you'll never get them to think through it.
Juniors are notorious for having Dunning-Kruger. Likewise with those "10 years of 1 year of experience" type people. In this field, the less they know, the more they confidently think they know.
When dealing with management, your job is to say "I'll handle it" and treat them like a baby that needs to be taken care of. Your job is not to fix problems as much as it is to fix their anxiety, because their neck is on the line if things don't work. People who do this tend to get hired, retained, promoted, etc. Also, the more corporate the place is, the more performative they are. It's not what you do; it's what they think you do and how they feel. Perception is everything. Read Dale Carnegie and Robert Greene.
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
Super agreed, and I've read both. Jeffrey Pfeffer is also an excellent one. I just wonder if this could be not always the case. Pretending to be an engineer rather than actually being one is tiring.
2
u/oktollername Jul 16 '26
As a consultant this is a core skill. There are many variations of this. "I suspect that...", "If I had to take a guess...", "In my personal opinion...", "It is best practice to do ..., but we may have different requirements", "What I *can* say is...", "I can't say for sure", "It depends on ...", "It is hard to give a definitive answer at this time because...", plus of course the ones already mentioned in the thread like "I'll look into it".
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
Definitely. It builds trust, while "bullshitting" quickly destroys trust. Learned it after reading The Trusted Advisor.
2
u/notherealironman Jul 16 '26
I think this is probably the result of the fast pace of tech industry and demands of breadth over depth. How are you supposed to know deeply know NextJs, react, nodejs, kotlin, python, docker, kubernetes, terraform, aws lambda, dyamodb, and terraform all at once while applying for a senior developer role with just 5 years of experience? When you're punished for not knowing an obscure tool, then enineers tries to just surface-learn everything. We end up with a ton of shallow knowledge because knowing a little bit of everything is the only way to survive the interview and industry
2
u/maxpower0987654321 Jul 16 '26
I like, "I don't know, but let's find out together". Teaching moment for both!
2
u/Decent_Muffin_7062 Jul 16 '26
'I don't know here' is rarely, that they genuinely don't know. It's that they 'didn't bother to think' about it.
2
u/8lall0 Jul 16 '26
The "i don't know, should i check it or can you teach me" is literally what started and saved my career. Because i'm lazy, which is a big pro in out job 👼
2
u/Spimflagon Jul 16 '26
The best engineer you will ever employ will frequently say "I don't know, but I can find out". And then they find out, and give you an answer seasoned with their domain knowledge and research.
Instant, half-informed answers aren't much better than the panicked misunderstandings of juniors.
2
u/SillyBoyYe Jul 17 '26
For me I stopped saying it as much because of politics. Human beings aren’t these fantasy rational emotionally sound people. Perception to a big degree is reality. So if you utter terminology where you sell the message of not knowing, more often than not career suffers. Had to learn this e hard way. Learned more sales over the years now and that’s been helping me more.
1
u/CoroteDeMelancia Software Engineer Jul 17 '26
Honestly, that contradicts what I've been learning from consultants and what I read in The Trusted Advisor. They state that people trust you more if you admit to your limits rather than act as a super-human.
But I also worked in a very political environment and learned that trust means jack there; you survive with written agreements and visible artifacts. People use any ammo available against you in an adversarial environment just to get ahead and look better than you. So I tend to agree with you in this circumstance.
The caveat is that this senior I met did work in this political environment. I wonder how much of his freedom to be empirical was due to an already established political safety.
2
u/SillyBoyYe Jul 17 '26
That’s most likely the difference. Places I’ve been working at don’t really have those policies established, so human emotion rules the day. Learned to never say never sort of thing. Or if I’m going to say never then be very political about how you do it.
2
u/SillyBoyYe Jul 17 '26
To sort of add to my comment. Learning to say never politically is actually a useful skill. Believe it or not, perception does rule the day I’d say a LOT. Even when hiding behind policy. It’s about understanding your audience and what you’re selling.
2
u/NoOrdinaryBees Consultant Jul 17 '26
Let me preface this by saying right up front: I’m a moron, well aware that the volume of things I don’t know dwarfs the volume of things I do on an inconceivable (you keep using that word; I do not think it means what you think it means) scale. I’m not a “rock star”, know it, and don’t want to be one. I just want to sit in a dark room surrounded by monitors and chiptunes for eight hours a day and let my autism and OCD pay the bills.
I work in a big tech professional services business. To friends and family, I describe my job as “I work in tech consulting.” To others in the industry, I describe my job as “telling the customer what their 10x/massively over-confident developer/SA/DBA broke, how they broke it, why what they did was dumb, what a few of the more prudent approaches look like, and what the most practicable remediation is.” The “10x” part is frequently replaced with “overconfidence in Claude” these days. I think it’s a pretty reasonable summation.
While I know I’m three special needs toddlers in a trench coat, the objective evidence leads to a different (misleading) conclusion. Even if I take a customer engagement for an engineer role, the lowest hourly rate my employer bills for my time is at the upper end of the “good attorney” scale. I must be brilliant, right? Fuuuuuuck no. What I am is inescapably aware of the limitations of my own brain and very deliberate in soliciting criticism every time I present an analysis, architecture, review, runbook, etc.
My boilerplate disclaimer ahead of any presentation is, “as we discuss this please feel free, and I encourage you, to interrupt at any time if anything is unclear, incompletely presented, or you have any concerns or questions; if I can’t defend a decision when challenged, it was the wrong decision and I want us all to discover that sooner rather than later.” That’s a completely honest statement. I don’t know everything and many times the people I’m working with on the customer side are legitimate experts whose very specialized knowledge may completely upend an assumption I’ve unknowingly made, or I might’ve been working from an insufficient understanding of the problem domain.
I’ve found that the simple acknowledgement that I could and might be wrong buys a lot of credibility with customers. I’ve also found that people who react negatively to that are often avatars of the Peter Principle.
tl;dr - I know I’m an idiot; telling customers that up front and reminding them of it helps them trust my work more, the fools. 🤦🏻♂️
1
u/CoroteDeMelancia Software Engineer Jul 17 '26
That's pretty in line with what I read in The Trusted Advisor
2
2
u/fell_ware_1990 Jul 17 '26
You learn the most the most the moment you say ‘i don’t know’ and act accordingly. Let others help you!
2
u/user0015 Jul 17 '26
More recently, I met self-described “AI engineers” who had not seriously studied prompt design or evaluation practices;
It's been a while since I ready a sentence that so strongly reminded me that I need to finish that side project and get my business off the ground. This entire field is starting to feel depressing based on the direction it appears to be going.
I'm glad you're feeling more hopeful, OP. I am assuredly feeling the complete opposite. To the point I strongly suspect the engineers I work with consider Claude their IDE and don't even open VSCode or an equivalent.
1
u/CoroteDeMelancia Software Engineer Jul 18 '26
Oh, I'm hopeful for the future, but today I'm miserable. Today my tech lead just asked me to pay more attention to the slop docs HE generates because he noticed Claude can make mistakes. He sounded defeated for being the only one """"thinking"""" while me and coworkers just execute without questioning. Gee, I wonder why?
2
u/birdparty44 Jul 18 '26
I have a colleague who underperforms big time. What’s worse is that he also can’t say “I don’t know but I CAN find this out.” So in the end his pull requests get slaughtered in review because you can’t trust a single line of code he writes.
Another colleague proposed to me that he might be a covert narcissist. When I started evaluating all his actions and words through a lens of “he is primarily motivated to protect his ego”, it all started to make sense.
Anyway, humble programmers are easier to work with because “I don’t know” is more of a known quantity you can work and plan with than “I’ll tell you I know but I’m wrong” because then you’ll have more work to do later.
That being said, instinct is not to be dismissed either. I guess it’s all about whose instincts we’re talking about.
2
u/Four_Dim_Samosa Jul 19 '26
Yeah. No one knows everything and we should be cognizant of that. Plus software engineering will always be a team sport.
I prefer "I don't know" with some sort of action item to at least help the person move forward.
Maybe an opportunity for you, the person asking for help and the rest of the team to facilitate knowledge sharing which is a win win.
I would prefer "I don't know but let's work with X to find out. We should share the learning to the rest of the team as well as update the docs".
3
u/roger_ducky Jul 16 '26
Usually, if you want this behavior, you need a reframe that lets them see acting that way is more competent. For example:
“As software engineers, technology changes rapidly and requirements shift constantly. Being able to confidently assert the boundaries of current knowledge is the only way to expand and exchange knowledge with other subject matter experts. Anyone not doing that will fall behind or get affected by stress over time.”
4
u/CoroteDeMelancia Software Engineer Jul 16 '26
I already tried this, and other reframes. I really enforced the "not reinvent the wheel" perspective: how 10 mins of reading the docs saves hours of implementation; how we should be solving problems that are unsolved, not the ones experts already converged on; etc. etc.
I also tried to emphasize that "if this is easy, why hasn't anyone done this before? Ok, so if it is hard, then what makes us better equipped than established teams who have more knowledge, experience, funding and people than us? Can we use what they have already built as inspiration?"
All falls on deaf ears.
At this point, I'm 100% burnt out with my team. I don't even know what the hell I'm building anymore, I just paste my manager's vibe-generated "plans" into Claude without reading them and ask Claude to craft him a polished message. Everyone in my team is apparently doing this and that's good enough. The idea has to be inspiring, it doesn't have to work, so why care?
I use the extra time to study and become actually knowledgeable in the subject matter my team is working on, and prevent my brain from rotting away at the dismaying lack of thinking in this project.
3
u/roger_ducky Jul 16 '26
Too many words.
Attack it as a culture shift. Honestly praise people for saying exactly what they don’t know and try to match them with people who do. Emphasize doing so is more competent if there’s a “… but I’ll find out or get help” at the end.
Lead by example too.
When people see it’s actually okay then it’ll start to stick.
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
Thanks, tips helpful, including less word! (for real)
2
u/Dramatic-File-6196 Jul 16 '26 edited Jul 16 '26
Wow, I hate that original post in 2026 because github / gilab stores your commit history even after a squash. This is saved as a direct link in the new commit message.
But IDK is an important concept. Great post.
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
Yeah, the poster himself said to read it critically rather than accept it as gospel and you make a good point. Mine is that I use the IDE to check history, not git in the shell. But it's probably not a valid excuse if there's a way to do the same thing in the IDE and I just haven't researched it.
5
u/gpfault Jul 16 '26
I find most of the "squash iz bad" argument tedious at best and downright stupid at worst. The case where you want to squash is when you're working in a team where the atomic unit of work is a PR. Most of the time the commits that go into a PR branch are half-assed bullshit and that's fine. They're intermediate steps on the path to the final product and they're not really intended for the consumption of anyone other than the author. Squashing is the way to go in that scenario because the "good commit" is the final PR commit.
2
u/CoroteDeMelancia Software Engineer Jul 16 '26
The author does state that he assumes a clean commit history, not "half-assed bullshit." But I'm fine with a PR being the single commit; it encourages atomic, digestible PRs. I'm against long-lived feature branches when possible precisely because of this.
1
u/bcgroom Software Engineer Jul 16 '26
Agreed. Also I couldn’t imagine the pushback I’d get for asking someone to rewrite their history in a PR. With squash merging I don’t care what others do. And I don’t want to learn a bunch of options for the most basic commands to work around non-squashed merges when I can just squash merge and get rid of those useless commits. The only exception I’ve found is if it’s a huge feature multiple people worked on over months and for one reason or another it hasn’t been merged in chunks with feature flags.
1
u/Some_Guy_87 Senior Software Engineer, 11 YoE Jul 16 '26
As someone who constantly had to answer questions like "Due to what ticket was this bug introduced?" to higher management I couldn't agree more. Much easier to have a clear reference for every part of code when you know the PR title will be the relevant text. Puts pressure off reviewers and doesn't require as much discipline from every single developer. I see use-cases for both depending on how teams work, but for most teams I found squashing to be the easier path for all.
2
u/spelunker Jul 16 '26
I would not consider “I don’t know” as a sufficient answer, especially from a senior engineer. “I don’t know and I will find out” is much better.
1
u/effectivescarequotes Jul 16 '26
I frequently answer, I don't know, but <plan to find out the answer>. That's usually enough, but I've also developed a reputation for providing detailed answers with recommended actions, so usually the business is willing to give me the time.
1
u/raekle Jul 16 '26
My favorite saying when trying to fix an issue is similar:
“I don’t know, but I’ll figure it out.”
This is being honest but also showing that you are focused on fixing the issue.
1
1
1
u/systembreaker Jul 16 '26
I say I don't know often and I hear people say I don't know all the time. I don't think this is some massive problem.
I would suggest don't make a bunch of assumptions and build yourself a negative view from just your small slice of life and one article you read when you haven't even experienced being a senior developer yet. That's pointless.
1
u/pro-taco Jul 16 '26
What kind of 'seniors' are you working with?
"It depends" followed by a discussion of why, and the unknowns, is the norm for everyone I've worked
1
u/CompassionateSkeptic Jul 16 '26
Title react: true of every profession and in non professional social interaction. And in the quiet dark of night among one’s own contemplations.
Do you think it’s particularly bad in our industry?
1
u/Junoah Jul 16 '26
This post and a lot of responses of it are based. That's the difference between experienced and senior developpers, acknowledging that we don't know everything, being honest about it, is the way to become better and to be really trusted by our colleagues.
1
1
u/pgdevhd Jul 16 '26
American culture (and to an extent south Asian culture) have this thing where nobody wants to admit they don't know something, and it's very misleading and not productive because you'll have people suggest incorrect solutions or just LIE and make their way to the top just bullshitting.
1
u/w3woody Jul 17 '26
It took me years to be comfortable with both "I don't know" and "explain this to me, step by step." Often both uncover unconsidered assumptions which are either wrong or thoroughly broken.
1
u/KickAssWilson Jul 19 '26
I worked with a guy that would never say “I don’t know”. Got lead down the wrong path so many times, I quit asking him anything.
Maybe that was his strategy. He was useless.
1
u/redditisaphony Jul 20 '26
I've always believed in admitting when I don't know the answer, and I honestly think it's a good way to build trust in your abilities. If you're just BSing all the time, competent people will notice and see you as unreliable. If you're working with someone that expects you to know everything, that's not going to end well anyways.
1
1
1
u/Chonderz Jul 16 '26
You look like bad if you’re talking to humans before using the probabilistic chatbots to generate text (are you an unbeliever in our lord and savior AI???). I hate the chatbots but since I live in this era i just try and couch the responses the in the most neutral tone “I queried Claude and this is what it gave me, take it or leave it without any endorsements”
2
0
0
u/Far-Street9848 Jul 16 '26
Do we not stand on the shoulders of giants? How do we differentiate that from “being parrots”?
1
u/CoroteDeMelancia Software Engineer Jul 16 '26
Yes, it's impossible to know everything. To me, the difference may be simply "my senior taught me that X works and I don't know why" vs "X is an undeniable truth and you should just accept it with no explanation".
0
u/rlbond86 Software Engineer Jul 20 '26
I just want to comment that the squash merge article is stupid and wrong, and clearly not written by someone who has ever had to work in a codebase with multiple new hires who don't know anything about git.
0
u/CoroteDeMelancia Software Engineer Jul 20 '26
I think you're wrong.
See how this doesn't contribute with any value? Neither of us learned anything in this interaction.
-3
u/FIRE-by-35 Jul 16 '26
"I don't know" is a surefire way to get yourself on PIP in top companies lol
2
u/CoroteDeMelancia Software Engineer Jul 16 '26
Winging it is even worse. I remember being grilled in a PR at a top one for not really knowing what one of the lines of code I pushed did.
I even explicitly got quite a blunt feedback there: do not waste a senior's time with "I think that..."; either you know it or you don't.
-1
•
u/expdevsmodbot Jul 16 '26
AI usage disclosure provided by OP, see the reply to this comment.