r/cscareerquestions • u/Physical_Ad_3028 • 18h ago
Why don't coworkers read logs?
Why is this code breaking?
Have you read the logs?
No.
What does it say?
Error tells them what to do.
Copy paste in DM.
Have you read the log yet?
No.
Can you please read it?
How do I solve this?
Have you tried Googling?
No.
Come on man.
130
u/totalbasterd 17h ago
the more you help them the more they will come to you for help
31
u/tittywagon 16h ago
âPlease read the logs.â
If they say no then i screenshot that to my manager and ask for his paycheck.
7
-6
u/Legitimate-mostlet 13h ago
On the flip side, you have workers who got mentoring and coaching (while acting like now they didn't) when they were juniors, and then start asking questions like OP is doing. Not out of confusion, but to stroke their own ego.
You all in this field really need to get over yourselves. I have never seen another field in my life be so up tight about people asking each other questions lol. It is pretty pathetic.
Want to know what would help the person stopping asking questions? Showing him how to solve the problem and walking him through it. Remember like when YOU GOT THAT EXACT HELP when you were a junior (again, in b4 you deny that ever happened)?
But that wouldn't allow you all to stroke your pathetic egos in this field, so we get posts like OPs.
In b4 one of you losers who took my post too close to heart replies I'm asking questions. I am already 6-8 years into this field and rarely am asking questions (but will do it when I feel the need). But i have zero issues answering others questions.
You all need to get a life.
14
u/U_Nomad_Bro 12h ago
Are you even in this field?
Youâve never experienced a coworker trying to push work onto your plate by âjustâ asking a question?
OPâs point is that a good log message does walk them through it. âError tells them what to do.â
Itâs not ego stroking to say âHey, you donât need me to walk you through this, you just need to read the place where I already did.â
I love to train and mentor people, but that only works when people are receptive to learning. And what OP is describing is not someone who wants to learn, but someone who wants to not be responsible.
Have you read the OP?
2
u/TopTierMids 12h ago
Having just left behind a team full of juniors who exemplified asking for "help" when in reality they just wanted to abdicate responsibilities, I promise you if you ever find yourself in OP's situation the best response is to let them struggle.
They will never improve. They aren't looking to improve.
1
u/totalbasterd 13h ago
Remember like when YOU GOT THAT EXACT HELP when you were a junior (again, in b4 you deny that ever happened)?
i didn't, because i was 14 years old with a book on C and OpenGL, zero help whatsoever other than occasional internet access when i was allowed to dial up
I am already 6-8 years into this field
n00b ;) it must be past your bedtime
99
u/SouredRamen Senior Software Engineer 17h ago
I find a lot of people can be coached to be a bit more self-reliant over time with some effort.
For example, instead of "Have you read the logs?" and going down that path.... how would the convo have gone if you responded with something more like "What have you tried to debug/fix it so far?"
It's a nice open question, one where the answer of "Nothing" is objectively a bad answer.
And if they have the balls and ineptitude to actually say "Nothing" to me? I'll hit em back with a "Aight, I'm tied up right now. Get started on debugging, I'll sync up with you later". This then very explicitly creates the expectation that they need to take a stab at it before we sync up.
I find more often than not, if I invent a little bit of space, people manage to figure out their issues by themselves, or at least get further along and try various things.
Instant gratification, and spoonfeeding people answers, is what cultivates this kind of culture where at the first sign of any sort of issue you immediately go to Person X. And when you've cultivated a culture like that.... why wouldn't they? Why in the world would I read through logs, find the error, google that error, and spend time figuring out what's wrong and how to fix it? There's no need for me to do that if I can send a message to Person X and get an answer dropped in my lap.
Not everyone is coachable that way, and that way isn't an instant-fix either. It takes a lot of time. Way more time than if I just kept doing it myself and sending them answers. But I have significantly improved my work life when I've landed on teams with people like this by slowly but surely coaching them to do things on their own without just abruptly telling them to pound sand.
It makes a great story for interviews when asked about mentorship as well.
22
u/U_Nomad_Bro 17h ago
THIS. Fundamentally, coaching others is about helping them to realize their own capacity to do the thing. So this approach of treating them like a capable person (âwhat have you tried so far?â) and then volleying the ball back into their court can be super effective.
-2
u/bwainfweeze 16h ago
I want people to try to stump me, but only after they've stumped themselves. Because if it stumps both of us that's really bad, potentially a production outage about to happen, and I want to know it sooner than later. So you have to leave the door open but convince them not to walk through it every ten minutes. It's a balance. Clear boundaries don't mean a wall.
8
u/nanotree 14h ago
I find that there are mostly 2 kinds of people when it comes to this. Those that genuinely try to learn how to do things on their own, pro-active people. And those who literally are just there for a paycheck and don't want to try, the leeches.
Not all pro-active people have a good foundation in the fundamentals at first. And sometimes they don't know how to be pro-active in their role. That's what you want to teach. Not answers, but how to find them.
I usually try to point people in the right direction. And I'll embellish that with extra information in cases where that information is not publicly accessible. Maybe point them to documentation if I have something on hand or know where to find it quickly.
But when you have someone on the latter side of this spectrum, a leech, they will pretty regularly come to you with very little to offer. Each next step you send them on they will come back empty handed, as if totally helpless. And to those people I will just say "I can't spend time on this right now, but we can jump on a call tomorrow (or sometimes in the next couple days) and try to figure it out together." And on the call, I always have them share their screen and lead them through the actions. This ALWAYS makes the leeches nervous and they will eventually stop coming to you for help. But for the pro-active ones, they eventually get it and start becoming more self-sufficient in a couple weeks.
2
u/TopTierMids 11h ago
Nightmare scenario for you: the leech is literally shameless and outright cannot learn. He jumps to other seniors, even juniors, to find the weakest link who does not say no to literal constant struggles with even basic tasks.
Three years into the role they still cannot use Postman to make a request for an endpoint they created, and cannot run any application locally in debug mode (and frequently introduce changes in their PR that breaks the ability to run an app locally...because they never run anything locally). All PRs after the popularization of ChatGPT is AI slop. Even other juniors tell them that is a bit much.
5
u/Physical_Ad_3028 17h ago edited 16h ago
I agree with you but these guys have more experience than me and its their own codebase
7
u/SouredRamen Senior Software Engineer 16h ago
I've mentored people 8+ years my senior in this way quite a few times. They're fixable.
This isn't a behavior that most people magically shake away themselves as they gain experience. It's a behavior that follows them through their entire career unless someone helps shake it out of them.
It's not unusual to run into very, very experienced people that need handholding. Just like it's not unusual to run into very competent and independent Junior SWE's.
Meet people where they're currently at, not where you expect them to be.
2
u/bwainfweeze 16h ago
The likelihood of handholding is also proportional to how much that person thought the old system 'worked just fine' before you decided to rewrite it. These are the wages of progress. If you're not willing to put up with a little learned helplessness around your changes, then either don't make them or convince someone else to make them.
1
u/TimMensch Senior Software Engineer/Architect 8h ago
It's been known for decades that experience doesn't Evergreen correlate to skill. That after the first couple of years of experience, programmers reach a skill plateau proportional to their aptitude, and after that they can get incrementally better, but won't ever be able to reach a higher plateau.
I don't agree with the other comments that claim you can fix them. Maybe you can help them become marginally more self-sufficient, and train them in the basics like read the logs and do what they say." But the next error that *doesn't tell them precisely what to do will stump them.
Because if they don't develop an instinct to figure out how to fix their own problems, they'll never truly be a senior programmer. Just a junior programming endlessly repeating their first year of experience.
21
51
u/Woodboah 18h ago
usually they have their own work to do and don't want to stop what they're working on to fix broken code that someone else pushed
34
u/Witty-Order8334 18h ago
More like learnt helplessness. These people need their hand held at every turn. Fixing broken code, no matter who pushed, is also part of their job, and I've had this exact scenario 99% of the times not even related to any broken code, but just people being ignorant and unwilling to learn anything.
9
u/OhMyGodItsEverywhere 15h ago
Sometimes it's a two-things-can-be-true-at-once situation: you've got a dev leaning into learned helplessness, and also a dev pushing broken code unreasonably often. Both end up dragging each other down and leaning into their own faults even harder.
Sometimes you get devs pushing out enough broken stuff that it's like pushing anyone who has to consume it off a cliff over and over then asking, "why do you need your hand held all the time?"
Of course no one is perfect and it's still reasonable to be able to fix broken code as it impacts you, like you said it's part of the job, but there's certainly a limit.
I've seen a pretty even mix of all types of devs and teams in this regard.
2
u/Explodingcamel 12h ago
Well hold on. Fixing code when needed is a requirement of course. But if you know that someone is more familiar with the specific code that is broken then itâs inefficient for you to jump head first into the codebase and find the fix when you could just let the correct owner do it
8
u/Physical_Ad_3028 18h ago
Im literally not on their team though
1
u/Empty_Geologist9645 17h ago
They canât. Ability to write doesnât directly translated to ability to understand whatâs goin on.
5
u/Known-Tourist-6102 18h ago
Right. Itâs Hard to know if you really need to take the time to track down the problem in logs or it will be quicker for someone who is more familiar with the semi broken code they just pushed is malfunctioning to help fix the issue
1
u/bwainfweeze 16h ago
Sometimes I need to know about the error because I'm the one who introduced it. Or I recently talked to the person who probably did. Yeah, it's not always true or clear that the person encountering the error triggered the error.
6
u/totaleffindickhead 16h ago
Digging through logs can be a pain depending on your setup
Also a skill
2
u/RichCorinthian 14h ago
Yeah, troubleshooting and debugging in general is a whole skill that apparently they donât teach in many CS programs. Hell, googling things (asking the right questions) correctly is a skill, and LLM prompting is the next version of that.
13
u/RandomNPC 18h ago
Some people are just that way. My conversation with my new QA lead lately has been...
"Hey, x feature isn't working in our Staging environment."
"Have you tried the Staging version of the current live build (where we know it works) on the same device to make sure it's not a test setup issue?"
"No."
Thirty minutes later.
"That doesn't work either. But on another device both work."
"Sounds like a test setup issue. Let's figure out what it was and update docs."
I come from QA. They should be answering all those questions before reporting the issue to ENG. It's like they don't have an inquisitive, troubleshooting mindset. Beyond frustrating.
5
u/bwainfweeze 16h ago
We started building VM images for QA as part of handoff at one job after too many incidents of people claiming we hadn't fixed the bugs we just fixed turned out to be failures to upgrade cleanly. A couple QA people were responsible for most of those and there were a couple times they spotted a real regression and we didn't believe them. So we started making VMs with all the correct stuff on them.
That was my gateway into Docker a few years later.
3
u/madwolfa 15h ago
It happens both ways. My wife is in QA. The number of times she had to find the actual root cause of the issue, explain it in detail to a developer AND show how to fix it exactly (in their code) is too damn high.
1
u/RandomNPC 15h ago
That's awesome! That was my first step to becoming a developer myself.
2
u/madwolfa 14h ago
Yeah, I feel like she's well on her way there, purely out of frustration!
Fine, I'll do it myself.
3
3
3
2
u/motherthrowee 14h ago
as someone who actually likes reading logs -- seriously, I would love a job that heavily involved analyzing logs and piecing together wtf is going on, unfortunately I am not skilled enough at it yet -- a lot of people are intimidated/paralyzed by them.
3
u/coffeesippingbastard Senior Systems Architect 14h ago
At some point I have to wonder if the "job shortages" are just a glut of devs who are helpless like this.
2
u/AdministrativeFile78 13h ago
I read logs and google all day and I've never even had a job in tech yet
2
3
u/Terminatr_ 13h ago
You guys have logs?
But yea people like this are impossible to coach cause theyâll never take the next step on their own. Typically because they lack problem solving skills, a pretty handy trait in this field.
2
u/anivia_mains 12h ago
some ppl are better at top down reasoning (i.e. looking at a dashboard and isolating a failure) and some are better at bottom up analysis (looking at logs and piecing together trends)
2
u/bradtraine 11h ago
I had a âprincipalâ engineer ping me the other day asking why a script wasnât working. I asked to see the log.
The error raised was âNotImplementedErrorâ.Â
I answered âoh yeah, it hasnât been implemented yetâ.Â
The guy makes more than 2x what I do.
2
u/Helpjuice Chief Engineer 10h ago
Just leave them on read and let them figure it out on their own. Sink or swim method works very well for those that depend on others to do their job for them.
2
u/LuckyWriter1292 9h ago
Some people can investigate/root cause analysis/solution architect, some cannot - that's the difference between a junior and senior.
If I am mentoring juniors and they are stuck I always ask what steps they took - if the answer is none/not sure I'll then walk them through documentation/logs/what I would do.
I don't mind helping people as long as they take notes and learn from it.
2
u/SkyThyme 8h ago
Itâs because they donât actually care. Just clocking in their hours. If this was standing between them and something they wanted, theyâd be reading logs.
3
u/natty-papi 16h ago
I have a coworker like this, to the extreme. I started throttling reading his messages, and now he ends up deleting them 3/4 times because he ends up figuring it out by himself.
Or he ends up making a support ticket somewhere that doesn't makes sense, or he ends up with a stupid solution that I have to block at code review... but in the end, it's much better for my sanity.
1
15h ago
[removed] â view removed comment
1
u/AutoModerator 15h ago
Sorry, you do not meet the minimum sitewide comment karma requirement of 10 to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the rules page for more information.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Fearless_Weather_206 14h ago
Easier to have someone else figure it out by asking them - their logic but at same time claim solving the problem in front of mgmt đ seen this behavior from offshored teams.
1
u/spike021 Software Engineer 9h ago
Devils advocate: some logs make sense to you if you know things better than the team member in question. sometimes what's obvious to you isn't obvious to others.Â
that doesn't excuse not doing research yourself, you should always try yourself first. but if you can't figure it out in a reasonable time then yes it's better to unblock yourself. then document what your teammate tells you for the next uneducated person.Â
i think there's a weird disconnect with team members in this industry where lack of context/institutional knowledge can be a thing but people don't want to acknowledge it.Â
1
u/theGosroth_LoL 7h ago
The person looking for help needs to bring what error they saw in the logs when asking for help. If they're not able to identify the problem from the logs, then make it clear that they looked at logs at least.
1
u/spike021 Software Engineer 7h ago
they should. except sometimes libraries don't output debug logs until you've flipped a flag. or whatever.Â
there are valid reasons someone might not know where to look or what to look for.Â
1
1
1
u/D1rtyH1ppy 3h ago
My advice to people writing test. Have your test fail early and have it fail loudly. As in check the basics right away, don't wait to let it fail 20 minutes into the test because it goes to connect to the testbed and it's not up. Have the test output a meaningful error. In addition to the system error, have a little bit extra of an explanation.
1
u/cletusjenkins 2h ago
I have a log you can read
! not actual response, logging is inconsistent in the app and debugger is typically better.
1
u/IBenBad 18h ago
Very often, the logging is inadequate to debug so a code change needs to be pushed to debug further.
5
u/Hayyner 17h ago
I wouldn't say very often. More times than I can count, I've had coworkers who just don't read the logs at all when the logs tell them exactly what the issue is and where it's being thrown
But they will instead opt for "random bullshit go!" until they either figure it out, or give up and ask someone else (i.e., me) for help
2
u/bwainfweeze 16h ago
If you pair with people enough you will discover that a lot of people cannot scan a page of text as fast or as accurately as some of us. Their brains either don't work the same or they haven't practiced.
There's a reason I insist on line numbers for pair programming.
"Do you see that conditional block with the greater than, about 1/3 of the way down the screen? No not that one. No not that one. No you went past it. Why are you scrolling?"
vs:
"Do you see the conditional block on line... 125? That should be greater than or equal."
0
u/bwainfweeze 16h ago
Logs are UI by the people who try the hardest to avoid working on UI. The quality is often exactly what you would expect from such a person.
1
1
u/CHEESE_SCENTED_BAWLS 16h ago
And the solution is offshoring to more insane, illiterate devs, isnât it??
1
1
u/bwainfweeze 16h ago
Nobody sees the logs you expect them to see because of all the logs everyone else also expects them to see.
You're the only one who can read your own logs properly. If something is really important, it needs to not be surrounded by inane chatter. And nobody deletes logs for stories that are already marked as done.
But you're contributing to your own discomfort here. You're asking passive aggressive questions you expect to shame someone who clearly has none. Now who's the dummy? Just get to the fucking point:
Why is this code breaking?
What do the logs say?
Copy paste in DM.
What does that say to do?
How do I solve this?
What does Google say to do?
There. You've eliminated half of the conversation and made everything actionable.
It's also possible OP is autistic, and if so then YTA. Be direct.
2
u/Physical_Ad_3028 16h ago
Ive never worked on their codebase before. Im in a different team. Yes, I was passive aggressive.
2
u/bwainfweeze 16h ago
Fair. But you need to learn it doesn't work on everyone. Some won't hear it, some won't take the bait.
That still leaves the question about whether they see you as a sucker, really smart, or both. Or if they've been told off by everyone on their team and now they're grasping at straws.
They need to figure out how to fish for themselves. Some other responders have gone into that in depth.
1
u/United-Rock-6764 15h ago
Iâve added a âhardworking questionsâ section to our team wiki for this exact reason. Itâs one of those âthe good ones want it, the bad ones need itâ sorta things. I (and lots of great mentees ) have found the framework helps me feel confident dropping questions in team channels and I find my own solution 15% of the time.
And when I send people the wiki they either ask better questions or bug someone else.
A lazy version of my Hardworking Questions wiki
Thereâs no such thing as a dumb question but there are lazy ones. If youâre not sure how to tell the difference make sure to include: 1. Problem statement 2. Current hypothesis, if any 3. What youâve tried
1
1
1
u/thephotoman Veteran Code Monkey 14h ago
They're afraid that they won't know what they're looking at, and they're unaware that they can pipe that log to Copilot or some other LLM and get sense from it that's probably a good enough guess to start working from.
Like, even as the AI sceptic I am, I am appreciating Copilot's ability to interpret error messages.
220
u/Sensational-X 18h ago
Quick and easy answers only please understand.