A good reminder that everything we say/hear/write/read exists in the unseen context of all the things we believe we should not say.
Unlike OP though, I cannot be as open about these companies as we would definitely not have any clients left after.
(obviously it's not but it is super nice that main in Rust is just:)
fn main() {
} void main() {
}A “Confessions of a Software Developer” website where devs can come in and make anonymous confessions.
Without making judgment on the actions of any involved party, I do wonder why the author would choose to bring up this incident and submit it as part of a story to a site where there is a significant overlap in readership.
Being bad at problem solving with people far away is just another problem you can solve with practice. Same as being bad at problem solving even when help is right next to you.
Yes, "remote work sucks" is reductive, but I elaborated beyond the heading. Also, I wouldn't disagree with "office work sucks." Remote work simply has its warts, too.
> just another problem you can solve with practice
Perhaps, but practice alone clearly isn't enough. I've been working remotely since 2020 and it hasn't gotten more enjoyable. I would love to solve that problem, though. I read Remote: Office Not Required by Jason Fried in the past, but that was written a long time ago. I've added more recent works (Effective Remote Work by James Stanier and The Async-First Playbook by Sumeet Gayathri Moghe) to my reading list.
Work sucks in general. Remote work is of course not perfect, but its problems need to be compared against non-remote work problems..
And this is my biggest complaint about arguments about remote working. People turn it into something that’s evidence-based when actually it’s a deeply subjective topic and thus different personality types thrive in different working environments.
We were doing remote work effectively decades ago. Don't have hallway conversations to fix bugs? Easy, just post your problems on the team chat and someone (often one of several people) would love to drop by to help.
I'm not sure exactly all of the forces that have led to this changing so much, but I'm certain that merely blaming "remote work" isn't it.
Somehow we were better at using remote tools while literally in the same office than some teams are at using them now while fully remote.
I couldn't agree more. I pushed to get the place I worked for to use Slack when it first launched, moving us off AIM (ha!). Our use of Slack when we shared an office in the twenty-teens was so much better than the use I've seen of Slack/competitors on fully-remote teams.
I wonder if it's because the failure mode was, as you said, to "drop by." Now the failure mode is... just failure.
Taking a switch statement and spreading it out over 3x classes is not a general improvement, it is very context specific. It makes the code difficult to navigate because what used to all be in one spot and easy to read is now spread out who-knows-where and there might be a special case lurking somewhere.
While I do appreciate this joke (and I do hope this is a joke), I've recently had a project majorly held up because a lead dev didn't understand SQL. It's great to admit gaps but it's equally important to close those gaps.
> As a hiring manager I interviewed software engineers and tried to filter for object-oriented knowledge. Retroactively, it’s clear I was hypocritical.
As some one who has been on the other side of "rejected by an interviewer who didn't understand the thing they've interviewed you about" I, again, appreciate the transparency, but I'm not entirely feeling that the lesson has been learned in the case.
There was a time in my life where I felt ashamed that I didn't know calculus... so I learned calculus and my life has been better for it. While refusing to admit ignorance of a topic is particular problem in tech, confessing that you don't know something and gleefully stopping there is not much better. Holding people up to a standard you do not hold yourself to is a major problem in this field. The technical people I've learned the most from hold you to a high standard and hold themselves to an even higher one.
Of course not every engineer has to hold themselves to a high standard, but if you want to write a blog about a topic, then part of the requirements here is that you do hold yourself to a high standard. Yes, we all have gaps, and we shouldn't let shame get in the way of learning, but we should be shamelessness about what we don't know limit us either.
NikxDa•1h ago
I wish we'd be more open about our flaws and knowledge gaps in general. I think we'd all benefit.