3 ms·
> we spend a very small fraction of our time on building things that are unique to our business. I usually see this in places/cultures that value code-beautifi
by withinboredom 3y ago
> we spend a very small fraction of our time on building things that are unique to our business.
I usually see this in places/cultures that value code-beautification projects rather than delivering value to the customer. Sometimes, they even want to do the latter, but actually do the former.
If you work somewhere that focuses on delivering value, the devs constantly complain about technical debt that will never, ever get fixed. That's the only sucky part.
- nine_k 3y ago"Code beautification" is not the point, but a tool. Smaller and clearer code could be faster to write, and harder to make mistakes using. This is why e.g. Rails can be so good at producing certain kinds of apps very quickly and in very few LOCs. The problem is, of course, that simplicity follows complexity, not the other way around. Because of that, it's mostly "trivial" and "repetitive" tasks that receive polished tools for easy and compact expression. Anything new and non-trivial usually grows ugly and uncouth for quite some time.
- withinboredom 3y agoCode Beautification is a waste of time and ossifies a code base. It's a form of optimization that actually makes the code harder to change and the business less agile. It is pretty though.
- nine_k 3y agoBeauty for the beauty's sake is art, not business. Usually simple, lean, and logical is also beautiful; beauty is not a random quality. But sometimes too simple and too lean is not flexible enough; then that's a case of a wrong abstraction, or of premature optimization.
- davio 3y agoI describe our work as an endless loop of taking data from the screen to the database and back again.
- pseudosavant 3y agoThis reminds me of the introductory scene of the amazing game The Stanley Parable: Stanley worked for a company in a big building where he was Employee #427. Employee #427's job was simple: he sat at his desk in Room 427 and he pushed buttons on a keyboard. Orders came to him through a monitor on his desk telling him what buttons to push, how long to push them, and in what order. This is what Employee #427 did every day of every month of every year, and although others may have considered it soul rending, Stanley relished every moment that the orders came in, as though he had been made exactly for this job. It was a sobering moment when I realized that accurately described most of my job too. https://thestanleyparable.fandom.com/wiki/Dialogue#Introduction https://thestanleyparable.fandom.com/wiki/Dialogue#Introduct...
- IggleSniggle 3y agoThat dialogue is hard to fully appreciate without the audio, and that button didn't work for me, so I'm linking a yt. However, I highly recommend that anyone who hasn't played this game should just go play it, even if you're not especially keen on games. It's absolutely brilliant, and consumed as a played game is absolutely the greatest way to absorb its delightful prodding (or anti-prodding (or anti-anti-prodding)) message. Even just the free demo! The demo is incredible as a standalone experience, and does not have identical dialogue / experience as the full game. It is in fact a meta-experience of the game. https://youtu.be/YzytQUZx4FU?feature=shared https://youtu.be/YzytQUZx4FU?feature=shared
- Chris2048 3y ago> somewhere that focuses on delivering value, the devs constantly complain about technical debt that will never, ever get fixed Value, or short-term value? When the codebase gets hard to manage, the value is there.
- withinboredom 3y agoI generally try to steer any team I work on away from short-term value. It's an addictive drug to managers that eventually gets used up.