[deleted]
When users never use the features they asked for
21–30 of 228 posts
Re: When users never use the features they asked for
#22I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so I reached over and showed him the feature that he had been demanding I add and he said, "oh, wow, that's awesome, that's going to be such a huge timesaver for us!"
Re: When users never use the features they asked for
#23Great article, but I disagree with the premise. Code review is too late for most automated analysis (at the level of: "parameter isn't validated" as seen in the screenshot), it should ideally be done as a compiler/lint check in the IDE, and at worst as a git pre-commit hook. In most cases it's not worth sending a code review if there is automated feedback which can and should be addressed before a human sees it. It s…
Your comment is more true today than it was back then, not that I disagree with you posting it. Back then linters were a twinkle in the hopeful eye of software devs. Now they're battle hardened.
Back then was 2018. Lint dates from the seventies. I doubt it was the first static analysis tool, either.
Re: When users never use the features they asked for
#24I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so…
How subtle was the update message letting the users know about the new feature?
Re: When users never use the features they asked for
#25Great article, but I disagree with the premise. Code review is too late for most automated analysis (at the level of: "parameter isn't validated" as seen in the screenshot), it should ideally be done as a compiler/lint check in the IDE, and at worst as a git pre-commit hook. In most cases it's not worth sending a code review if there is automated feedback which can and should be addressed before a human sees it. It s…
There's nothing more frustrating than a stupid machine telling me it knows better when it doesn't. I used to work on a team where the build defaulted to fail if something wasn't used and debugging was a fucking nightmare because the moment you comment out a block of code there's a cascade of warnings into errors that is just never ending (it was typescript so it leaked all the way back to module definition). I had to…
Well, don't turn warnings into errors. Doubly so on your development environment. That's not a good reason for not running a linter while developing.
But, of course, if the decision was out of your hands, people that do that are usually the same that enable all linter rules. Neither decision makes for a good development practice.
Re: When users never use the features they asked for
#26thanks for this great write up and I wish I could read this 10 years ago :).
Re: When users never use the features they asked for
#27I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so…
How subtle was the update message letting the users know about the new feature?
Yeah sounds like the lesson here is that nobody reads the update messages.
Re: When users never use the features they asked for
#28One of many things I learned from writing software just for myself is that I'm just about as bad as anybody at figuring out what I really want, even when I'm talking to myself. I've even had one or two cases where I ignored a feature I asked myself for, and much later realized: Hey, I could actually use that. The worst is asking myself, "How many times do I have to ask for this before you quit procrastinating and jus…
The challenge there is when people start using your personal project. Yes, you remain in control and you remain the primary user. But… now regression and features become a much greater concern because the last thing you want to do is harm other people even if they are only a secondary audience. As the project grows this becomes the most pressing concern regardless of who is the primary user.
That begs the question: Why bother growing the application beyond the smallest set of explicit use cases? When you are the primary user AND the only use environment or input samples are written by you life is simple. The moment you must analyze something not written by you, even if this usage is only for you, the problem cases blossom. If your application refuses to solve for those cases then you need to add more features or use a different application.
Those two scenarios seem to feed each other which becomes evident by traffic or usage numbers as you pull your hair out keeping up with some hobby application.
Re: When users never use the features they asked for
#29A fine post and I'm sure a fine tool, but why is an internal linter tool the subject of a proper academic paper?
I can't imagine writing an academic paper for any of the projects of similar complexity and general interest that I've worked on.
Re: When users never use the features they asked for
#30I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so…
How subtle was the update message letting the users know about the new feature?
I mean, they stopped demanding the feature every day. Clearly they were aware that something changed.