Hacker News Reader

Comment by kareemm | Hacker News Reader

One of the dev failure modes I regularly see when consulting (and have fallen into myself, many times) is believing value is a function of effort spent coding. More of the latter means more of the former.

But it turns out customers don’t care how long you took to build the thing. At all.

There’s a lot of win in finding and plucking low hanging fruit - those high leverage features that seem almost too easy to do that you can do them anytime... but never get around to because you’re always working on something bigger and more interesting.

Related to this if OP is reading, I’d love to be able to drag and drop and upload images into GitHub wikis the way I can into GitHub Images. Between those two changes and uploading to wikis you’d have my vote for employee of the month!

View on HN

> those high leverage features that seem almost too easy to do that you can do them anytime... but never get around to because you’re always working on something bigger and more interesting

Oh 100% this was a major revelation in my career going from hobbyist to professional gamedev. As a hobbyist I would think "Yeah sure the units are spinning randomly on corners because I messed up the rotation math, but I can fix that anytime. I should be working on this yet-another-feature".

When correct process is to fix the biggest pain point: and surprise! There you go, the next biggest pain point becomes obvious. Repeat ad intinitum and you'll have polished yourself a commercial-grade game.

In my niche this is reporting. We agonize for YEARS about what to do.

Just thinking in what I need to do for this do "properly", ie: I plan to make a language as the base!(https://tablam.org).

Eventually I just install https://www.metabase.com and thanks to sane table + view design the end-users are nearly support-free.

Thanks for Metabase... never seen that before, and looks like it could solve a similar reporting hole in my current project.

Out of interest, did you use the Open Source version. Embedded or standalone?

The open source + standalone. Most reporting (of the kind this is needed) is made by selected user with different needs to the main app, so it work for us.

Interesting. Thanks.

did you try apache superset? if so, any reason you went w metabase?

Have recently tried both, my guess is the "sane table + view design the end-users are nearly support-free" is key. Superset is way way more complicated and hard to understand IMO.

I don't know about that option. For metabase, was the UI that our support rep think easier to get ;)

Completely agree! Long ago I worked at a fintech startup that made a Master Data Management (MDM) solution for hedge funds. Usually people would log into the webapp, make changes to the data, and log out. Do it 10 times and it starts to get boring.

A couple of folks hacked together an Excel plugin that could make those data changes in bulk. Voila! Customers loved it!

The amount of happy customers we got for that weekend project was overwhelming.

The power of Excel is underestimated by everybody, except those that use it day in and day out.

Also, just to add to that, customer also doesn't care about your code quality or the fancy new tech you used underneath. In early stage, it is all about getting stuff done fast, creating value, capturing value and repeat.

The business does however care about the marginal cost of delivering new feature improvements.

https://youtu.be/TQ9rng6YFeY

And of course, the devs often care about using new tech since it improves both their current enjoyment of the job and (often) their future job prospects

If you have a stable team, cost of delivering new features are quite low. Tech improvement comes at much larger cost.

Technical debt is the concept that some features of your existing product can actually make it harder to deliver new features. When to address technical debt is quite literally the decision on when tech improvement will be more valuable than the next new feature.

I agree with this, with your caveat of "early stage". Later on we have a responsibility to keep tech debt under control to a degree, even if that's invisible to the customer. (The side effect of faster development pace and higher quality later down the line will certainly be visible).

But in the early stages - I agree with you and tend to take the view that it's better to just throw something together and get it out there and being used quickly - irrespective of how bad the code might be underneath.

Get the system out in front of users, and delivering value to them as quickly as possible. You cannot beat the power of getting early feedback and validation of a concept.

For larger (higher stakes) projects this can be in the form of a "prototype" where the expectation is set that it's not a complete product. For smaller projects, fuck it, call it Version 1 (or a "beta" if you must) and get real people using it quickly :-)

Just be prepared to continue iterating from there.

As a dev I also often fall into the trap of "coding for coding's sake" - I love TDD, DDD, clean code, getting the right abstractions... and yes this stuff (when used appropriately) can lead to good maintainable code with low tech debt and easier feature development... but too often as developers we can end up losing sight of the business need and go too far up our own backsides with this stuff. Perfecting the codebase in the name of maintainability and controlling tech debt, when really it's often unnecessary perfectionism - or premature optimisation at least. Maybe that's just my own experience and I'm projecting - but I do see this quite often with even the best devs I work with. Actually more often with the devs that take the most pride in their work. It's a difficult balance to strike.

the customer doesn't care about your code quality or tech stack, until you're unable to do something like replace an ellipsis with an arrow because your tech debt has become too large.

The customer cares about the code quality when it turns their experience into a slow and bloated one... or not, unfortunately, since the age of webapps and Electron has desensitised most users from telling the difference.

> There’s a lot of win in finding and plucking low hanging fruit - those high leverage features that seem almost too easy to do that you can do them anytime... but never get around to because you’re always working on something bigger and more interesting.

Totally agree. A brilliant piece of wisdom!

These can be good new employee startup projects. Once around the dev cycle but not too complex. Early win, happy engineer.

Reply on news.ycombinator.com