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

51–60 of 105 posts

Re: Technical Excellence Is Not Enough

#51

Post by sgarland »

bossyTeacher wrote: post #31
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?

You are absolutely right! - It is not X. It is Y. - X [negate action] Y. X [action] Z. The titles are giveaways too: Comfort Over Correctness, Consensus As Veto, The Nuance, Responsibility Without Authority, What Changes It. Has that bot taste. If you want I can compile a list of cases where this doesn't happen. Do you want me to do that?

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

Re: Technical Excellence Is Not Enough

#52

Post by tpoacher »

> Nobody disagrees with the technical argument

That's a very strong foundational claim right at the start. And in my experience, a completely false one. Which makes the whole argument that follows it completely unsound.

Also, the author seems to treat the terms "consensus" and "buy-in" as synonymous. They're not, and this distinction can make a huge difference in terms of healthy teams can operate. Patrick Lencioni covers this well in his classic book, "Five Dysfunctions of a Team".

Re: Technical Excellence Is Not Enough

#53

Post by trentnix »

loevborg wrote: post #8
eithed wrote: post #5

I worked for 7 years in a place where my technical insight slowly turned into questioning my decisions and expertise (this was after being 3 years in tech lead and 2 years in staff engineer role). Sometimes the solution is just to walk away

Yeah that's a painful process, as I know from experience. What do you think is the reason for the gradual shift?

“Truly I tell you,” he continued, “no prophet is accepted in his hometown."

- Luke 4:24

It's why people often trust consultants over the people inside the organization. It's why people often want to elect new leaders even if the current leaders are doing a decent job.

The baby almost always gets thrown out with the bath water.

https://en.wikipedia.org/wiki/Don't_throw_the_baby_out_with_...

Re: Technical Excellence Is Not Enough

#54

Post by grey-area »

sgarland wrote: post #51
bossyTeacher wrote: post #31

Earlier quoted context omitted.

You are absolutely right! - It is not X. It is Y. - X [negate action] Y. X [action] Z. The titles are giveaways too: Comfort Over Correctness, Consensus As Veto, The Nuance, Responsibility Without Authority, What Changes It. Has that bot taste. If you want I can compile a list of cases where this doesn't happen. Do you want me to do that?

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.

Re: Technical Excellence Is Not Enough

#56

Post by jonstewart »

sgarland wrote: post #30
jonstewart wrote: post #16

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

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

Re: Technical Excellence Is Not Enough

#57

Post by asa400 »

tripledry wrote: post #41
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…

Side note, this is why I'm not that worried even if AI becomes even better at writing code. The only times I've spent "too long" on features, are times where I basically had an empty ticket. I need to find the right people to talk with, figure out requirements, iterate on changing requirements etc. That's only marginally sped up even if you could generate the code with a click of a button. This was somehow related to…

100%. The thing I'm currently working on has been a pain probably 80% because the work was underspecified and didn't take a bunch of legacy concerns into account and probably 20% because of nature of the code itself.

If it was better specified I'd be done already, but instead I've had to go back and forth with multiple people multiple times about what they actually wanted, and what legacy stuff is worth fixing and not, and how to coordinate some dependent changes.

Most of this work has been the oft-derided "soft skills" that I keep hearing software engineers don't need.

Re: Technical Excellence Is Not Enough

#58

Post by Rapzid »

raw_anon_1111 wrote: post #38
bdavisx wrote: post #27

Earlier quoted context omitted.

And if everywhere they went would do the same thing, then they wouldn't be able to leave. Too bad people have been convinced that unions are bad.

They left for Mexico… How hard do you think it is to get cheaper developers from LatAM?

All the corporations that left Georgia over unions left for Mexico?

Re: Technical Excellence Is Not Enough

#59

Post by sgarland »

louwrentius wrote: post #6

I've seen this pattern play out, and been frustrated by it many times over. > Authority matching responsibility. That's the only fix I've seen work. Either you get decision-making power that matches the decisions you're already making, or you find a place that treats your judgment as an asset instead of something to manage. I don't think the solution is to become some kind of dictator. And I don't think it's about no…

> The key issue is a fundamental misalignment of core values.

Agreed, but my main frustration is what glitchc wrote a few comments down: "No one actually claims their product is crap and quality doesn't matter."

I have never met anyone in management who will admit that they value velocity over correctness and uptime, but their actions do. If you want to optimize for velocity, growing your user base, expanding your features, that's fine - but you need to acknowledge that you're making a trade-off in doing so. If you're a solo dev, or working at an extremely small shop with high trust, it's possible that you can have high velocity and high quality, but the combination is vanishingly rare at most places.

Re: Technical Excellence Is Not Enough

#60

Post by menaerus »

jonstewart wrote: post #16

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

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.
Post reply on HN