Haunted Graveyards in Consulting | Hacker News Reader

Haunted Graveyards in Consulting

datosh.github.io

15 pointsdatosh13 comments

Did anyone else feel turned off by the AI-written writing style of this? (Grammarly claims it’s 13% AI generated, although I’m not sure how accurate that is.)

It's a 30-second read, so it didn't particularly bother me.

I've done consulting in esoteric products, so the content is accurate and a useful cautionary tale.

Imho, the skill gap is the original sin. If the team inheriting ownership is seriously underskilled, no amount of knowledge transfer is going to fix that -- so stick to whatever is dirt simple and most obvious in language du project.

what is rounding error for detecting AI generated text, I would say 13% isn't enough to complain.

I skimmed it; I didn’t think it was ai necessarily, but in between topic sentences it was boring filler no matter how it was written.

Even at a high level though, it’s poorly reasoned. If quality code is not maintainable, what are your criteria for quality exactly? It’s basically an ad for consulting services targeted at people without strong critical reasoning skills.

"I think this is AI" is the least interesting, lowest-signal comment one can make here on HN, beating out perennial contenders "I hate their scroll bar", "this site hijacks my back button", and "why does this site require JavaScript?"

If you can actually make an AI detector that works, do that and print money for yourself. Otherwise accept that all "AI detectors" have massive false positive rates, your intuition included.

If visitors like what they see on the page, they will up vote it. If they don't, they won't. That's how HN works.

Great article, I have I seen this situation too many times to count. It isn't just consultants that generate haunted graveyards. Any person will skills more advanced than their peers will do so. To make matters worse it isn't just the peers you have right now but the peers you will have in the future who you don't currently know and can't predict their skill level.

While the solutions you list can help, it will not solve the haunted graveyard problem, just ask all of the companies with Cobol programs in production.

Underappreciated code comment

// Ugly hack. To fix later {inserts reasons and breadcrumbs here}

Beats naked magic numbers/logic any day of the week.

I consulted at a place where I did that and they said don't put those comments in we don't do that here.

So probably it's been "fixed" and caused stuff to break since then.

Did you try telling them in consultant voice that it's "a generally acknowledged software development best practice"? ;)

I mean I argued with another guy for about an hour but they had a thing against comments, it should be in the git logs. Which I understand but I sort of feel it should be in both places because some people are lazy.

I like to put ugly hacks in a file ugly_hack_xyz.py and then import that. Code comments are easier to ignore afterwards.

This is true even for non-consultants. If you're the only person who understands The Thing you're in for a world of hurt because whenever it breaks it's your problem. I've been at companies where I rearchitected a piece of software and unfucked some key business process, but it made things worse because the number of engineers who understood it went down. And I'm not talking vanity "paying down tech debt" rearchitecting, I'm talking "people get paged because the product doesn't work" went from 33% of deploys to ~0%.

> In the best case, they lead to accumulating inefficiencies (technical debt) as engineers work around them

If that's what technical debt ever amounted to, then the average software developer is stupid, because he doesn't know how to innovate and improve within the meta-system he's functioning in. It's not hard to restructure things when inefficiency becomes a problem. Just do it.

Instead of lionizing technical debt as some sort of boogeyman demon around the Internet forums water coolers.

Reply on news.ycombinator.com