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

Imaginary problems are the root of bad software

cerebralab.com

Post reply on HN
Print view View original

331–340 of 511 posts

Re: Imaginary problems are the root of bad software

#331

Post by testacct22 »

zerbinxx wrote: post #303
jongjong wrote: post #291

Earlier quoted context omitted.

With developers, incentive misalignment is just insane at all levels. - There is bias towards rewarding more lines of code or more code commits (which is often the exact opposite of what characterizes good software design). - There is bias towards rewarding speed of initial implementation (which often goes against medium-term and long term maintainability and ability to handle requirement changes which is usually far…

Mega agree with this. It was really bad for my personal/career growth to get a ton of praise for doing things fast: granted, a lot of people doing the praising had precious little experience in tech themselves. I probably have 2-3 whole dead years where I could have been learning/improving a lot more but got put in “10x developer” expectation projects where I’d churn something out, get a big shiny star sticker for it…

> but got put in “10x developer” expectation projects where I’d churn something out, get a big shiny star sticker for it, and then 2 years later it would be abandoned

I feel like I've fallen into this hole at my current gig, where I just churn shit out to solve a problem as quickly as possible

I get away with it just bc general code quality was already not good to begin with

Biggest mistake was going fast the first time, now I'm getting assigned way more shit

Word of advice to readers: don't make the same mistake I made. You'll just get taken advantage of

Re: Imaginary problems are the root of bad software

#332

Post by Sakos »

SanderNL wrote: post #297
pavlov wrote: post #90

Earlier quoted context omitted.

> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scienti…

That sounds expensive AF though. Was that really necessary? I’m all for craftsmanship, but having four top guys fiddling with design.. it all depends on the domain I guess.

Uh ... plenty of companies have a UX team. They're mostly all graphic designers. "four guys fiddling with design" is nothing. Either you care about having a well-designed UI or you just want a pretty one with a high conversion rate, and who you hire reflects what you really value.

Re: Imaginary problems are the root of bad software

#334

Post by whizzter »

pydry wrote: post #185
davidmnoll wrote: post #175

Earlier quoted context omitted.

All of these definitions are fuzzy... refactor versus upgrade versus feature. When the people wrote it the way they did, they were almost certainly thinking that they don't need to overthink or over-engineer, and that they should discount hypothetical future concerns. I can give you an abundance of examples. We were creating a page that was going to use state in a certain way. I was trying to insist that we address t…

>I can give you an abundance of examples. We were creating a page that was going to use state in a certain way. I was trying to insist that we address the way state will be handled across pages ahead of time. These concerns were dismissed as premature optimization. A few months later we had 5 pages with the state being handled in 5 different ways. The right time to address this was probably a bit at a time after the…

Rule of 3 is often correct, first time just do it, second consider if it'll very likely happen a third time and when the third time happens it's darn well time to do it!

HOWEVER, this only works if you have the agency at an organization to allocate time for doing something. Contrary to this when you are in an organization of management that doesn't understand technical debt (or is fine with it because it just means more consulting hours) then it's absolutely the correct choice to stall and/or fix things "prematurely" (iff you can see what product they are trying to create without knowing it) if you'll be holding the shit-can of duplicated crap down the line getting knuckled because things aren't going fast enough due to technical debt.

Re: Imaginary problems are the root of bad software

#335

Post by temikus »

I do agree with the general premise but there are a lot of passages that kinda trivialise a lot of complicated phenomena, e.g.:

> Much like victims of childhood hardship or abuse can find escape in fantasy books, victims of enterprise programming or freelance web development can find their escape in solving imaginary problems.

Re: Imaginary problems are the root of bad software

#336

Post by sirsinsalot »

siilikuin wrote: post #322
sirsinsalot wrote: post #100

Earlier quoted context omitted.

> No engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high. I'm not saying this is a common situation, but it certainly isn't…

Confirming a hypothesis I put forth in a different comment: Would you say you and your team have ownership of the product? That is to say, there isn't one team doing what you're doing and then another separate team trying to graft new features on all the time, is there? Maybe there is, and maybe that causes issues down the line.

We do have ownership, and I try and structure the development such that every engineer has ownership, decision making power and accountability. I aim for a flat responsibility structure as much as possible. We have lots of work to do, lots of changes in process and despite the constraints we have a steady stream of features we do add.

The trick is to ensure the culture of solid engineering goes right through the organisation and informs everything from commercial/financial through to QA.

Re: Imaginary problems are the root of bad software

#337

Post by sirsinsalot »

wruza wrote: post #261
sirsinsalot wrote: post #100

Earlier quoted context omitted.

> No engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high. I'm not saying this is a common situation, but it certainly isn't…

For that to happen, two things must match: a product guy who knows your job and you who know how to make products. It doesn’t even have to be stable/featureless, in my experience. New developers tend to worship some new paradigm that focuses on “how” instead of “what”, which is all paradigms can do. And once they’re in, it goes downhill because the how dominates the what. Add a clueless product guy into the mix and i…

I'm fortunate enough to be both the lead engineer and the person making product/design/feature decisions with the engineering team.

Re: Imaginary problems are the root of bad software

#338

Post by sirsinsalot »

abhibeckert wrote: post #302
chubot wrote: post #118

Earlier quoted context omitted.

What kind of software do you work on? At what company? I have seen low level parts that are managed well, because employees have skin in the game But I’ve also seen a lot of what this post is talking about

I work at a consulting firm. Our salary is loosely linked to what percentage of our work is billable (with leniency for inexperienced staff, who aren't expected to be profitable while they're learning their craft). If you spend three hours figuring out why things fall apart on the 31st of the month... that generally can't be billed to the client, and therefore it's bad for your salary. On the other hand, if you spend…

I would argue the billing model, client relationship and everything else commercial isn't running effectively at that firm.

If I were a client, I wouldn't want these perverse incentives to exist. I would want a razor sharp focus on _my_ needs, and assurance that _my_ needs are modelled in the billing.

And for that, I would pay more.

Re: Imaginary problems are the root of bad software

#339

Post by sirsinsalot »

wruza wrote: post #263
sirsinsalot wrote: post #239

Earlier quoted context omitted.

Am GP, it is finance based, but not commercial finance. Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so. It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it…

Interesting, I believe there is something to finance that allows or forces things this way. There’s much less fidget spinning and much more business in it for some reason.

Regulation and risk. The same applied to government too.

The cost (financial, legal, reputation) of certain classes of bugs is so high that avoiding those risks becomes top concern.

One calculation issue, one buggy float operation means millions or billions in damage and the loss of your clients ... never to return ... because your name is tarnished.

I actually think this is _wrong_ and we need better resiliency in finance to being able to roll-back transactions and rewind and replay with adjustments.

Re: Imaginary problems are the root of bad software

#340

Post by mavhc »

noisy_boy wrote: post #280
pdntspa wrote: post #193

Earlier quoted context omitted.

Even better, every app is doing their own styling so they can all look like Discord

Is it just me or there are others who find discords handling of threads terrible?! I mean Slack is far from my favourite but at least they treat a thread like a thread where I can see the entire conversation in one place instead of visually parsing questions and replies while frantically scrolling up and down.

Threads in Discord appear in the sidebar usually. Are you thinking of replies?
Post reply on HN