undefined | Better HN

0 pointsbennyschmidt2y ago0 comments

> people who want to write beautiful code, spend lots of time on it, and don’t care if it actually does what it was intended to do

There was a funny React framework a while back that has all kinds of cool state management and this and that, but it renders nothing. For the developers who spend more time theorizing, migrating, refactoring, than shipping.

It's funny when people go back and forth about the time complexity of a click handler (that is debounced anyway), and they arrive at the optimal solution, but when you use the app the entire thing is super clunky lol where is the concern for time complexity of me using the product xD

0 comments

asveikau2y ago

I feel it's much more common to create abstractions without regard for performance cost of the abstraction. So keeping time complexity down, even for a piece that doesn't matter much, is above average for this sort of thing.

Gibbon12y ago

Also creating abstractions without considering the mental overhead of reasoning about what the code is doing.

Not enterprise: event --> action.

Enterprise: event --> abstraction --> abstraction --> abstraction --> abstraction --> abstraction --> abstraction --> abstraction --> abstraction --> action_parta --> abstraction --> abstraction --> abstraction --> action_partb abstraction --> abstraction --> abstraction --> action_finalizer.

The_Colonel2y ago

I sometimes wonder if people believe that enterprise devs create abstractions for "fun" without having any rational reason.

imoverclocked2y ago

A paycheck and a re-org are pretty rational reasons. Maybe they aren’t the ones that create concise software but they can certainly be the ones taken en masse.

tonyedgecombe2y ago

In my experience enterprise devs don't really like what they are having to create either. They feel boxed into it because of all the petty rules that large organisations create.

dragonwriter2y ago

No, but they often do it out of cargo culting (sometimes by the individual dev, sometimes by the bureaucratic conmittee of ex-enterprise-coders and managers-who-have-read-about-coding that adopted the mandatory coding standards) without any rational reason.

Source: seeing it from the inside.

hock_ads_ad_hoc2y ago

Creating abstractions without considering performance is probably the correct approach. It’s much better to at least start with a program with enough abstraction to allow reasoning about how things should work. Save performance concerns for when optimization is seen to be necessary.

KerrAvon2y ago

This is how you wind up with fundamentally slow systems that can’t be easily sped up. You need to take some account of performance in systems design. Just don’t micro-optimize too soon.

geodel2y ago

This is how we get software that run ten times slower consumes ten times more resources and this happens on occasion when software works, more often it doesn't.

eru2y ago

Big-O notation lets you conveniently ignore constant factors like 'ten times'.

(I'm only half joking. A system that's always ten times slower than the optimal solution, can still be beneficial to one that's quadratically slower than the optimal solution. Or it can be worse, it depends on how big your instances are.)

regular_trash2y ago

Hard disagree. Abstractions are nice when they match the mental model of a problem domain, but the odds you have the right set of abstract primitives in mind from the outset is practically 0.

kykeonaut2y ago

This is why TDD is not good when starting from scratch.

Your abstractions might change in a way that they break your tests in a major way, and not only do you end up re-writing a great part of your code but also of your test set.

3 more replies

taneq2y ago

> people go back and forth about the time complexity of a click handler (that is debounced anyway)

This is the modern software world in a nutshell.

twism2y ago

Re-frame?

gemstones2y ago

This was immediately what I thought of, too.

j / k navigate · click thread line to collapse