> 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.

Yeah. Random example: I have better "ambient awareness" remotely because with slack I am in every hallway simultaneously, and can skim the conversations and set up highlight words

It's a strange pattern I observe often, whenever an idea gets promoted from organic-natural-human-ritual to official-new-visible-main-idea, it becomes bloated and off point.

Yeah text based beats video a lot of the time.

> 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.

This is sort of the point. Remote tools work great when you have spent a lot of time building relationships and rapport with the people involved. That's hard to do in professional settings, and extremely hard to do in remote professional settings.

Letting teams that know each other well work remotely works great. Building teams remotely is very hard.

I'm a diehard for remote work, but we have to be realistic abouts limitations.

Electronic chat is really not the same as face-to-face communication. Neither are video calls.

now we do the work of 7 projects in half a team paid 50% less and can't get to help anyone as we all drown in 7 tickets we should do in parallel with agents writing docu on the side and assist and some of the easier code on the side because management drank the koolaid of going full into AI and "the Team now can do 300% more right". I miss the old times where making 100k and still could have few minutes to help each other and now we're in this hypercapitalistic garbage AI age were we have to just output, output, output and fuck quality and else they lay you off and get the next guy from wherever.

One of the author’s primary reasonings for why remote work sucks is apparently that they find it difficult to treat other people like human beings without close proximity to them.

That’s pretty weird and uncomfortable and I don’t know that I would want to work with someone like that in or out of office.

My boss actually said that to me once. He said he really appreciated that I would say "I don't know" instead of bullshitting him. Of course I would also try to brainstorm with him or find the answer later on by searching.

For some reason I'm able to say "I don't know" to coworkers and superiors at work with no problem, but I have a much harder time online where it may affect future employers' opinions of me.

I am indeed learning, working to close those gaps.

For automated testing, I'm in the middle of reading Developer Testing by Alexander Tarlinder, with xUnit Test Patterns by Gerard Meszaros coming close behind. I'm also working through Test-Driven Development: By Example with my wife as we have time.

For SQL, I read Grokking Relational Database Design by Qiang Hao last winter, and I started SQL Queries for Mere Mortals by John Viescas this week. Sadly, my flub with "left inner join" was not a joke.

For OOP, I've been on a whirlwind tour: OOA&D With Applications by Booch et al., Object Thinking by David West, POODR and 99 Bottles of OOP by Sandi Metz, Domain-Driven Design by Eric Evans, IDDD and DDDD by Vaughn Vernon, Design Patterns in Ruby by Russ Olsen, Clean Architecture by Robert C. Martin, and Smalltalk Best Practice Patterns by Kent Beck. Still on the docket are Design Patterns by the Gang of Four, PoEAA by Martin Fowler, Smalltalk, Objects, and Design by Chamond Liu, and Object Design by Rebecca Wirfs-Brock.

> confessing that you don't know something and gleefully stopping there is not much better [...] we shouldn't let shamelessness about what we don't know limit us either

I promise you, this was not gleeful and this was not shameless. Shame and fear affected me for months on these issues. And I'm not stopping there... From the end of the article: "I’m going to continue to work on skill building, but now I feel free to write about it. If [...] you’d like to help me fill [my knowledge gaps], [...]"

> 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

A high standard of writing, maybe. But plenty of great stories come from those who are striving for a high standard, not just those already in the upper echelon. It's what makes this place different from academic journals.

Not exactly your main point, but where’d you go to learn calculus? I did the usual classes in high school but none since, and I’d love to develop a better appreciation for it.

> I’m afraid to mention it professionally, given we have a literal policy around “AI doomers” (not the exact term) that has the word “separation” in it.

Dude, your employer is toxic AF. Look for a new job starting today.

I had an old colleague (at various points he was my boss, colleague, and subordinate at different places) that really opened my eyes up to the power of saying you don’t know how to do something.

I used to also fear appearing incompetent if I admitted to not knowing too many things, so I would avoid showing my knowledge gaps whenever possible.

However, this colleague was the exact opposite. He would gleefully tell people he had no idea how to do certain things, would be a ready listener when the person he was talking to explained how it worked, and would heap praise on the person for their knowledge and teaching skills. He would always defer to other people as experts when he didn’t know, and would make sure our bosses and coworkers knew who had helped him and how much they knew about the topic.

What I saw and experienced was that this did NOT, in any way shape or form, make people think less of him. It did the exact opposite. First, it made people REALLY happy to help him with stuff; he made you feel so smart and capable when you explained things and helped him, everyone jumped at the opportunity to show him things. He learned so much because he made everyone excited to teach him, and made his coworkers feel smart and appreciated for their knowledge.

And then, when he did speak with confidence on a subject, everyone knew he wasn’t bullshitting, because we knew he never faked it. Since he gave everyone else the chances to be the expert and deferred all the time, you didn’t get the one-upmanship you often get when tech people are trying to prove their bonafides. People were happy to listen to him because he first listened to them.

I have really tried to emulate him in my career. I go out of my way to praise and thank people who help me, always try to immediately admit where my skills and experience lack, and don’t try to prove myself in subjects I don’t really know that well. It has worked well for me in my career, as well.

The "why I was afraid to admit it" is by far the best part of this. It gives a lot more insight and ideas to combat it.

All the confessions are highly subjective. If someone tried a refactor like the one at https://refactoring.com/catalog/replaceConditionalWithPolymo... there is a decent chance it should get picked up and reverted on code review.

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.

I suppose I included the last section as a "confession" because I spent years pre-pandemic wishing I could go remote, talking loudly about how open office spaces were bad, etc. That, plus it's embarrassing to admit that I dislike remote work even though I am a remote worker. And not just a remote worker, but an enfranchised remote worker living 3 hours away from the nearest city with an international airport. I made the mistake of rebuilding my life around remote work before I had experienced it long-term.

No purpose in memorizing something that doesn’t meaningfully improve your understanding of the language, you only need it every now and then, and you can find it nearly instantly.

So many things like that!

I don't know if I could tell you with confidence the proper way to get a string length in any language. Is it a global function or an object method or property? Is it length or count or size? I have to look it up or rely on intellisense every time. I do too much bouncing between languages.

Well, I know it in BASIC. Len().

With Java 24 it’s now:

    void main() {
   
    }

I’ve spent so much time in both the .NET and JS worlds that I can't even begin to count how many times I’ve typed `Where` when I meant `filter` or vice versa.

What, `def main():`? Or do you mean the __name__ == "__main__" thing for distinguishing whether the code was imported?

I set up some .NET services years ago. Since then it was just adding new stuff. If I was asked how to set up another service, I would have no idea how to do it

Continuing the confessions: I do php.net/<function_name> at least twice a day

It's the main benefit of Rust ;)

(obviously it's not but it is super nice that main in Rust is just:)

    fn main() {
    
    }

In python, it's trivial:

def main(): # code

The dunder syntax you see around isn't required.

LLMs are wonderful for this. I can't write hardly a line of shell script without looking something up. And then there are three different ways to do <thing> so I spend time beard-tugging as to which way to do it. Now I just tell the LLM what I want changed about this shell script and look at what it comes up with. 100% of the time it's fine.

"Knowledge means knowing where it is written down."

I was as curious as you were. Turns out there are only so many popular threaded discussion sites in the vein of HN on the Internet, so an educated guess is all it takes.

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.

  So your original comment that you "didn't want to hype up AI" was a lie, you really just wanted to pretend it was your own work and didn't want the project to be able to make a choice about it. There are good reasons why projects may not want to accept code generated by AI. They may not care. But by consciously choosing not to disclose that, you took that choice away from the project. That's pretty lousy behavior if you ask me.

It would attract the humble-braggers. ;)

Probably already a subreddit for it like r/programminghorror.

> made me roll my eyes, and it's reductive in the same way as saying office work "sucks."

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.

Add most of what Martin Fowler said to that list.

Agreed. The quote from him in the article reads like a caricature of a comically overzealous SWE.

Remote work isn’t for everyone. Their point of view is just as valid as your point of view.

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.

Or work with a random programmer at a random company for a bit. We had to do some audit/estimate for a company with huge tech issues (race conditions causing data corruption, huge slowdowns with just small usage spikes etc) costing them clients/money. The company runs around $50m/year or so selling software to enterprises. Anyway; software backend written with Java/Spring, deployed/updated on EC2 manually, no automated tests (zilch). Frontends with Vaadin. Almost no processes are used, just Jira + tasks and then 'start at the top every morning'. No one knows sql anymore (Hibernate), no one knows html/js (Vaadin) and, even though most people are senior and there since the beginning, no-one has done anything high level on the job in the past 20 years or so. They have just been inside this 'ecosystem' writing code and it works. Old Java with some modern updates just to satisfy the compiler/linter (but not fully understanding why that nonsense is needed). None of the core seniors I interviewed touches computers outside of work, they had 0 tech courses since working there etc. They are all 9-5 code producing robots. I want to bet they can mostly/all be replaced today by Claude Code, of which existence, of course, they are not aware (they did chatgpt but not Codex or Copilot). We have since found so many issues in the code. Yeah, I do feel very much uplifted about my own skills after encounters like this, and these are by no means rare, i would rather say; extremely common.

Unlike OP though, I cannot be as open about these companies as we would definitely not have any clients left after.

I don't know that it is necessarily sick ... I suppose it depends what you do, how the people respond, and if you are playing a useful role in the interview process for your organization.

Tell us more?

On the positive side... Seeing how people respond to pressure (done within some bounds) might be useful information. Watching people dig deeper into their problem-solving toolkit (and even their determination and resolve) might be informative. But I have not recently reviewed interviewing research, so I don't know how strong the causal connections are between observing these things in an interview and on-the-job performance.

On the negative side: If one is primarily interested in finding flaws as some sort of intrinsically valuable thing or to boost one's own ego, these are probably hints to look closely at oneself and reflect and make sense of what is going on inside.