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

Oh my poor business logic

rednafi.com

Post reply on HN
Print view View original

31–40 of 154 posts

Re: Oh my poor business logic

#31

Post by gedy »

lmm wrote: post #22

Developers can focus on the business logic when they're close to the business. Look for places where you sit close to the business people, talk to them a lot, maybe even talk to customers. Where you're part of a team that has a responsibility of delivering product X to customers rather than a team that has a responsibility of doing things that use technology Y. The more organisational layers you have between you and…

You'd think this is non-controversial, but have worked at places where product and UX act as gatekeepers and don't want engineers involved with the problem solving. They'll "figure it out for you" and then spoon feed Jira tickets and Figma mockups to devs.

Re: Oh my poor business logic

#32

Post by koliber »

There is no perfect balance. If you have the awareness of the extremes you can adjust course. A little goes a long way.

If you are see that your organization is too chaotic, you should put some structure and discipline in place to curb the tech debt and chaos. You’d be surprised by how far adding in basic listing and teaching the team to use it will get you. You can add automated testing after that, and move on to other initiatives.

Similarly if you are in a resume-oriented development organization, bring attention to business outcomes through little initiatives. Make your engineers attend at least one sales or support call per month. Explain the company budget. Show the true costs of going with the flavor of the month.

You can foster change bit by bit. Things will get more balanced if you continually do it.

It is tough though. You are fighting a culture battle. Changing peoples mindsets and habits is a long process. You won’t get overt support and you won’t see immediate results. But it’s worth it.

Re: Oh my poor business logic

#33

Post by granshaw »

gymbeaux wrote: post #27

I’m on a sabbatical because I find myself very jaded by the industry, more or less for the reasons stated in this article. What I tell people is something like “I LOVE building stuff with code, but lithe EVERYTHING ELSE.” Writing code may be better suited as a hobby for me… after all, I have the most fun with side projects… but then, as most of you can probably empathize with, how will I make the sweet, sweet six fig…

Sounds like freelancing/consulting might be right up your alley. Maybe building mvps or working on relatively new products or codebases. Charge for your time and no pretend work.

Yes, you’ll have to find clients. No, there is no perfect alternative to the “sweet six figures”, something’s gotta give, but you gotta start somewhere

Re: Oh my poor business logic

#34

Post by JodieBenitez »

gedy wrote: post #31
lmm wrote: post #22

Developers can focus on the business logic when they're close to the business. Look for places where you sit close to the business people, talk to them a lot, maybe even talk to customers. Where you're part of a team that has a responsibility of delivering product X to customers rather than a team that has a responsibility of doing things that use technology Y. The more organisational layers you have between you and…

You'd think this is non-controversial, but have worked at places where product and UX act as gatekeepers and don't want engineers involved with the problem solving. They'll "figure it out for you" and then spoon feed Jira tickets and Figma mockups to devs.

> They'll "figure it out for you" and then spoon feed Jira tickets and Figma mockups to devs.

Been there... never again. If I can't speak to the people that use the software, I'm out, period.

Re: Oh my poor business logic

#35

Post by yeswecatan »

cavisne wrote: post #19

There is a new paper out from Google which seems like an interesting approach to get out of microservice hell https://sigops.org/s/conferences/hotos/2023/papers/ghemawat....

This is an interesting paper and one I would never have found on my own. How did you come across it?

Re: Oh my poor business logic

#39

Post by closeparen »

DLQ and retry are complementary strategies. DLQ is where the message goes after retries are exhausted. Whether you need one depends on your SLA, whether the message is still relevant later, whether the data is going to be reconciled through some other channel, etc. It's not an aesthetic preference.

Re: Oh my poor business logic

#40

Post by zharknado »

lmm wrote: post #24
simonw wrote: post #7

Earlier quoted context omitted.

An interesting challenge I've found with the term "technical debt" is that engineers can use it as an excuse to work on all kinds of things that might not genuinely be paying down technical debt, taking advantage of situations where the people making the prioritization decisions don't have the hands-on technical experience of the codebase to evaluate if the proposed "improvement" is a good investment of effort or not…

The most effective place I've worked had a fixed allocation to technical debt work (25%) and let engineering agree how to prioritise that. Want to rewrite it in Rust? If you get buy-in from the rest of the technical team to say that that's more important than sorting out the database schema or whatever you can do that, but you'd better be able to do it piece by piece and keep delivering business value the whole time.…

Worked in a similar setup as a PM and really liked it. As you said, it can be somewhat apples-to-oranges comparing new functionality with a stream of tech debt opportunities, so it’s helpful to target a ratio, more like stocks/bonds in a portfolio.

We called it “product health” so it could encompass tech debt but also UX debt, performance, cosmetics, etc.

Post reply on HN