3 ms·

It’s a trust issue. There’s no one more of a PITA than a new team member who joins and starts questioning every little thing and demanding it be changed (the in

It’s a trust issue. There’s no one more of a PITA than a new team member who joins and starts questioning every little thing and demanding it be changed (the initial questioning is fine, so long as you accept “because” as a reason). OF COURSE any team that’s shipping software will have things that don’t make sense prima facie, because they’re accumulated tech debt or historical accident. Go beyond identifying all these problems towards solving them. Choose a small problem, where you won’t have to fight and argue, just a little dust bunny you can sweep out of the way. Do it again, and again, and again. This is how you build trust. As you build trust, it becomes easier to seek change. Additionally, you may also find that not all the little problems are worth solving, and what’s more interesting are the bigger problems around product-market fit, usability, and revenue.

sgarland 8mo ago
> Additionally, you may also find that not all the little problems are worth solving, and what’s more interesting are the bigger problems around product-market fit, usability, and revenue. TFA author (and me), and you have wildly different motivations. I don't know the author, but have said verbatim much of what they wrote, so I feel like I can speak on this. Beyond the fact that I recognize the company has to continue exist for me to be employed, none of those hold the slightest bit of interest for me. What motivates me are interesting technical challenges, full stop. As an example, recently at my job we had a forced AI-Only week, where everyone had to use Claude Code, zero manual coding. This was agony to me, because I could see it making mistakes that I could fix in seconds, but instead I had to try to patiently explain what I needed to be done, and then twiddle my thumbs while cheerful nonsense words danced around the screen. One of the things I produced from that was a series of linters to catch sub-optimal schema decisions in PRs. This was praised, but I got absolutely no joy from it, because I didn't write it. I have written linters that parse code using its AST before, and those did bring me joy, because it was an interesting technical challenge. Instead, all I did was (partially) solve a human challenge; to me, that's just frustration manifest, because in my mind if you don't know how to use a DB, you shouldn't be allowed to use the DB (in prod - you have to learn, obviously). I am fully aware that this is largely incompatible with most workplaces, and that my expectations are unrealistic, but that doesn't change the fact that it is how I feel.
- miningape 8mo ago
  Don't really have anything to add but I do want to say you're not alone - I feel very similarly about AI tooling, the level of satisfaction I get from using them (none), the need for interesting technical challenges, etc. etc.
  - sgarland 8mo ago
    There are dozens of us! Re: AI, that's not to say I don't use it, I just view it as a sometimes useful tool that you have to watch very closely. I also often view their use as an X-Y problem. Another recent example: during the same AI week, someone made an AI Skill (I'm not sure how that counts as software, but I digress) that connects to Buildkite to find failed builds, then matches the symptoms back to commit[s]. In their demo, they showed it successfully doing so for something that "took them hours to solve the day before." The issue was having deployed code before its sibling schema migration. While I was initially baffled at how they missed the logs that very clearly said "<table_name> not found," after having Claude go do something similar for me later, I realized it's at least partially because our logs are just spamming bullshit constantly. 5000-10000 lines isn't uncommon. Maybe if you weren't mislabeling what are clearly DEBUG messages as INFO, and if you didn't have so many abstractions and libraries that the stack traces are hundreds of lines deep, you wouldn't need an LLM to find the needle in the haystack for you.
- jonstewart 8mo ago
  I’m a development manager and senior developer. I have seen the described behavior from TFA play out on several different teams. Sometimes such team members learn to adapt their approach while holding onto their ideals, and they become valued colleagues. Other times they don’t and they leave out of frustration or are fired or spin their wheels. I have no doubt there’s a great deal of truth in the author’s description, but there’s also maybe some truth in the feedback they’ve received. I also share some of your philosophy — life is too short for us not to find joy at work, if we can. It’s a lot easier to find that joy when the team’s shipping valuable software, of course.
  - 8mo ago
menaerus 8mo ago
So basically you get hired with 10-15 years of experience and you start nothing but by earning trust fixing small problems for how long? That sounds like a great way to get into the "does not meet expectations" territory very quickly.

sgarland 8mo ago

> Additionally, you may also find that not all the little problems are worth solving, and what’s more interesting are the bigger problems around product-market fit, usability, and revenue. TFA author (and me), and you have wildly different motivations. I don't know the author, but have said verbatim much of what they wrote, so I feel like I can speak on this. Beyond the fact that I recognize the company has to continue exist for me to be employed, none of those hold the slightest bit of interest for me. What motivates me are interesting technical challenges, full stop. As an example, recently at my job we had a forced AI-Only week, where everyone had to use Claude Code, zero manual coding. This was agony to me, because I could see it making mistakes that I could fix in seconds, but instead I had to try to patiently explain what I needed to be done, and then twiddle my thumbs while cheerful nonsense words danced around the screen. One of the things I produced from that was a series of linters to catch sub-optimal schema decisions in PRs. This was praised, but I got absolutely no joy from it, because I didn't write it. I have written linters that parse code using its AST before, and those did bring me joy, because it was an interesting technical challenge. Instead, all I did was (partially) solve a human challenge; to me, that's just frustration manifest, because in my mind if you don't know how to use a DB, you shouldn't be allowed to use the DB (in prod - you have to learn, obviously). I am fully aware that this is largely incompatible with most workplaces, and that my expectations are unrealistic, but that doesn't change the fact that it is how I feel.

miningape 8mo ago
Don't really have anything to add but I do want to say you're not alone - I feel very similarly about AI tooling, the level of satisfaction I get from using them (none), the need for interesting technical challenges, etc. etc.
- sgarland 8mo ago
  There are dozens of us! Re: AI, that's not to say I don't use it, I just view it as a sometimes useful tool that you have to watch very closely. I also often view their use as an X-Y problem. Another recent example: during the same AI week, someone made an AI Skill (I'm not sure how that counts as software, but I digress) that connects to Buildkite to find failed builds, then matches the symptoms back to commit[s]. In their demo, they showed it successfully doing so for something that "took them hours to solve the day before." The issue was having deployed code before its sibling schema migration. While I was initially baffled at how they missed the logs that very clearly said "<table_name> not found," after having Claude go do something similar for me later, I realized it's at least partially because our logs are just spamming bullshit constantly. 5000-10000 lines isn't uncommon. Maybe if you weren't mislabeling what are clearly DEBUG messages as INFO, and if you didn't have so many abstractions and libraries that the stack traces are hundreds of lines deep, you wouldn't need an LLM to find the needle in the haystack for you.
jonstewart 8mo ago
I’m a development manager and senior developer. I have seen the described behavior from TFA play out on several different teams. Sometimes such team members learn to adapt their approach while holding onto their ideals, and they become valued colleagues. Other times they don’t and they leave out of frustration or are fired or spin their wheels. I have no doubt there’s a great deal of truth in the author’s description, but there’s also maybe some truth in the feedback they’ve received. I also share some of your philosophy — life is too short for us not to find joy at work, if we can. It’s a lot easier to find that joy when the team’s shipping valuable software, of course.
- 8mo ago

menaerus 8mo ago

So basically you get hired with 10-15 years of experience and you start nothing but by earning trust fixing small problems for how long? That sounds like a great way to get into the "does not meet expectations" territory very quickly.