a lot of people need to read and understand the message here. Very, very well said!
Good software knows when to stop
231–240 of 304 posts
Re: Good software knows when to stop
#232> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…
>Ignore feature requests — don't build what users ask for; understand the underlying problem instead
That sounds like good advice on the surface but it should be "understand what the user is asking for" then see if it is a valid thing, after which you can decide how to accomplish it. Users usually come to you with the last bit. They ask you to do it in a particular way.
Re: Good software knows when to stop
#233Earlier quoted context omitted.
Ha yes, learning vim was one of the best things I ever did. I can SSH onto a Juniper router and fix up config using vi. I still try to instill in juniors these days "Learn vim!" but everyone just wants to use nano (which I understand but nano isn't preinstalled on many network devices)
> everyone just wants to use nano (which I understand I do not understand. I have a very capable colleague/friend who uses nano. Unix hacker type, so I think it is what he is used to from growing up. I still find it strange, but such is the nature of preference.
Nano not powerful, but it is friendly, it shows you its keybinds.
Vim is very powerful, but also very unfriendly.
The difference in effort required to pick up Nano vs Vim is HUGE
Re: Good software knows when to stop
#234In 2020 I became a full time Java developer, coming from a infrastructure role where I kind of dealt with Java code, but always as artifacts I managed in application servers and whatnot. So when I first started dealing with the actual code, it scared me that the standard json library was basically in maintenance mode for some years back then. The standard unit test framework and lot of other key pieces too. I interpr…
I remember we made a switch to redis because java's memcached library was unmaintained. I made I joke that it's just feature-complete and cannot be improved upon, people chuckled, but we still did the switch.
Honestly having looked at the memcached clients available for Java recently, I don't think any of the options could be considered feature-complete. None of the main ones support the meta protocol at all, meaning most of the advanced features aren't possible (and these are things that can't be emulated on the client side).
Hell, the main feature I needed (bulk CAS get) didn't even require the meta protocol or recent memcached features - spymemcached just never bothered to implement it. I ended up abandoning the change I was working on, because the upstream never looked at my PR and it wasn't worth forking over (bigco bureaucracy etc).
There are also quite a few legitimate bugs open for years that haven't had so much as a comment from maintainers.
Re: Good software knows when to stop
#235Earlier quoted context omitted.
> Vanilla WoW really did have a different design ethos than the later expansions did, and some people prefer that experience. Right, and that's my point. When you take away the nostalgia for the content, you reveal what players are asking for, which is a reversion to what is effectively a previous game as modern WoW lost all of what made it a good game, to those players, in the first place. So yeah, there was definit…
Yes. I've watched some videos on wow by Kevin Jordan, who was on the original team. He said the original game was built on 3 pillars: 1. Advancement over time. 2. Player interaction. Hard content should be hard in order to push players into working together to overcome challenges. 3. The world is a character in the game. Even when you eventually got mounts later in the game, they made it so mobs can knock you off & d…
> And the LFG system.
The LFG system basically killed most social interaction in WoW.
So if you played for that, you got excluded.
They also sort of killed build diversity, but there was no build diversity in classic either, at least if you wanted to raid.
The grinding... I don't miss it. That could have used toning down.
Re: Good software knows when to stop
#236In 2020 I became a full time Java developer, coming from a infrastructure role where I kind of dealt with Java code, but always as artifacts I managed in application servers and whatnot. So when I first started dealing with the actual code, it scared me that the standard json library was basically in maintenance mode for some years back then. The standard unit test framework and lot of other key pieces too. I interpr…
I think there's a huge "it depends" caveat. In the JS world I remember browserify, it did what it was meant to do and it was extendable. A really nice Unix-like minimal software.
The reality is that it was just a small piece in a larger ideal build chain. So for the past 10+ years, we've seen an explosion of more complete build tools that do everything.
Browserify now sits there "finished" and receiving bugfixes. Nobody uses it anymore, even if it popularized npm for the frontend.
Re: Good software knows when to stop
#237Earlier quoted context omitted.
I dislike spotify but weirdly enough I can never point out exactly what's so frustrating about it...
App is slow. It plays music video content as default. Gui has many non interesting parts. I just want a list of albums and songs. I guess I just want it to be "boring but functional. :)
and messaging etc. making it a social network
Re: Good software knows when to stop
#238Good blog posts know to stop before recommending books by a fascist.
Re: Good software knows when to stop
#239Good blog posts know to stop before recommending books by a fascist.
The opinions on DHH on some subjects don’t invalidate his expertise on some other subjects. See also Musk or Ford.
Re: Good software knows when to stop
#240the problem is that user interface does not belong to user