Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Excellence Is Not Enough

raccoon.land

Post reply on HN
Print view View original

61–70 of 105 posts

Re: Technical Excellence Is Not Enough

#61

Post by quotemstr »

james_marks wrote: post #18

I find OP's communication style abrasive and off-putting, which tracks with them saying they've been coached on this, and found that advice lacking. Maybe it's still insufficient advice, but it hasn't worked for them at least in part because they haven't figured out how to apply it. From the post, I see low empathy and an air of superiority, (perhaps earned by genuinely being smarter than their peers-- doesn't make i…

> I find OP's communication style abrasive and off-putting

Your comment is hilarious on a meta-level: it's an example of exactly the sort of socially-mediated gatekeeping the author of the article (machine or human, I don't care) criticizes. It is, in fact, essential to match authority and responsibility to achieve excellence in any endeavor, and it's a truth universally acknowledged that vague consensus requirements are tools socially adept cowards use to undermine excellence.

Competent dictatorship is effective. Look at how much progress Python made under GVR. People who rail against hierarchy and authority, even when deployed correctly, are exactly the sort of people who should be nowhere near anything that requires progress.

Imagine running a military campaign by seeking consensus among the soldiers.

Re: Technical Excellence Is Not Enough

#62

Post by sjamaan »

Rapzid wrote: post #44
mmsc wrote: post #40

Earlier quoted context omitted.

That's because it was generated by an LLM.

I simply cannot believe people in this post are discussing this as anything other than a complete bot job. Pure clanker vomit.

I realize it's been "written" by an LLM, but the content could have been written by someone I know. It's eerie how this person thinks exactly the same way. It's never their fault, always the others', and they are always obviously right and no amount of arguing can change their mind.

Re: Technical Excellence Is Not Enough

#63

Post by watwut »

MrJohz wrote: post #37
james_marks wrote: post #18

I find OP's communication style abrasive and off-putting, which tracks with them saying they've been coached on this, and found that advice lacking. Maybe it's still insufficient advice, but it hasn't worked for them at least in part because they haven't figured out how to apply it. From the post, I see low empathy and an air of superiority, (perhaps earned by genuinely being smarter than their peers-- doesn't make i…

Yeah, a lot of the examples made me think "wait, there's something else going on there, right?", which would make sense if the author has difficulty communicating or negotiating their proposals. In the first example, for example, they suggested a new metric to track added warnings in the build, and then there was a disagreement in the team, and then as a footnote someone went and fixed the warnings anyway? That sound…

> In the first example, for example, they suggested a new metric to track added warnings in the build, and then there was a disagreement in the team, and then as a footnote someone went and fixed the warnings anyway? That sounds like the author might be missing something from their story.

I do not find anything missing here. This is how things often plays out in reality. Both your retelling of it and what was actually written in the article.

Your retelling: Some people agree and some disagree with new metric. That is completely normal. Then someone who agree or want to achieve the peace or just temporary does not feel like doing "real jira" tasks fixes warnings. Team moves on.

Actual article: the warnings get solved when it becomes apparent one of them caused production issue. That is when "this new process step matters" side wins.

Re: Technical Excellence Is Not Enough

#64

Post by sgarland »

miningape wrote: post #49
sgarland wrote: post #30

Earlier quoted context omitted.

> 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 contin…

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.

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

Re: Technical Excellence Is Not Enough

#65

Post by dogleash »

medi8r wrote: post #3

Ouch I don't want to work there! It seems extreme. A decent place to work let's you do your thing. There will be guardrails. But my current job my boss has never told me not to do something. Getting the time to do it is another story and there are solutions. Sometimes picking the battle and lettung it go. Sometimes driving a decision and agreement. But if you do that people like it. And I work somewhere pretty well m…

> my current job my boss has never told me not to do something. Getting the time to do it is another story

I’m confused. The polite way to say no at work is to make it about not having time.

Re: Technical Excellence Is Not Enough

#66

Post by watwut »

pverheggen wrote: post #36

OP's dismissiveness of soft skills is a big red flag. Unless you're a solo dev, software development is a social activity, and understanding the social dynamics is key to effecting change. Your efforts to improve quality could be vetoed by your coworkers for a variety of reasons: they don't care, they don't trust your judgement, they see other things as a higher priority... the list goes on and on. Some of these thin…

They do not dismiss soft skills. But, they do not know how to play the politics and were given bad advice. I would even say that their observations are entirely correct, they accurately described how teams function. What they do not know is how to influence people.

Bad advice given to them:

> The standard advice is always "communicate better, get buy-in, frame it differently." [...] The advice for this position is always the same: communicate better. Get buy-in. Frame it as their idea. Pick your battles. Show, don't tell.

That sort of naive kindergarten advice is how people want things to work, but how they rarely work. Literally the only functional part of it is the "pick your battles" part. That one is necessary, but not sufficient. The listed advice will make you be seen as nice cooperative person. It is not how you achieve the change.

So OP comes to the "the problem isn't communication. It's structural." conclusion.

Re: Technical Excellence Is Not Enough

#67

Post by JCDenton2052 »

k33n wrote: post #9

OP’s experience is all too common. If he keeps trying to do the right thing, he’s going to run afoul of “the no assholes rule”.

You have to be able to pick your battles. Sometimes people are in the wrong teams. Sometimes they are just assholes who think they are always right. Too often the "right thing" is subjective.

Re: Technical Excellence Is Not Enough

#68

Post by quotemstr »

grey-area wrote: post #54
sgarland wrote: post #51

Earlier quoted context omitted.

As someone who thinks very much like TFA, I often write like that. I swear I'm not a bot.

Maybe fix your writing then. This is not good writing.

It used to be. That's why LLMs adopted it. How do you think they got their preferences? A Magic 8 Ball?

Re: Technical Excellence Is Not Enough

#69

Post by sgarland »

jonstewart wrote: post #56
sgarland wrote: post #30

Earlier quoted context omitted.

> 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 contin…

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…

> Sometimes such team members learn to adapt their approach while holding onto their ideals, and they become valued colleagues.

What's frustrating (I've said that a lot, I know) to me is that my skills are seen as valued, but my opinions aren't. I also have a pathological need to help people, and so when someone asks me, I can't help but patiently explain for the Nth time how a B+tree works (I include docs! I've written internal docs at varying levels!) and why their index design won't work. This is usually met with "Thanks!" because I've solved their problem, until the next problem occurs. When I then point out that they have a systemic issue, and point to the incidents proving this, they don't want to hear it, because that turns "I made an error, and have fixed it" into "I have made a deep architectural mistake," and people apparently cannot stand to be wrong.

That also baffles me - I don't think I'm arrogant or conceited; when I'm wrong, I publicly say so, and explain precisely where I was mistaken, what the correct answer is, and provide references. Being wrong isn't a moral failing, or even necessarily an indictment on your skills, but for some reason, people are deathly afraid to admit they were wrong.

Re: Technical Excellence Is Not Enough

#70

Post by Terretta »

Rapzid wrote: post #28
armchairhacker wrote: post #22

Earlier quoted context omitted.

The first two sentences > Organizations don't optimize for correctness. They optimize for comfort ...do I need to say it?

> One number, never measured before. It doesn't change rules or add warnings, just makes the existing count visible. Stopped here. That pattern. I recognize this pattern from this AI "companion" my mate showed me over Christmas. It told a bunch of crazy stories using this "seize the day" vibe. It had an animated, anthropomorphized animal avatar. And that animal was an f'ing RACCOON.

LLMs originally learned these patterns from LinkedIn and the “$1000 for my newsletter” SEO pillions. Both accomplish a goal. Now that's become a loop.

There is a delayed but direct association between RLHF results we see in LLM responses and volume of LinkedIn-spiration generated by humans disrupting ${trend.hireable} from coffee shops and couches.

// from my couch above a coffee shop, disrupting cowork on HN. no avatars. no stories. just skills.md

Post reply on HN