https://www.dreamsongs.com/RiseOfWorseIsBetter.html
It doesn't explain _why_ simple implementation is more important than having a simple interface, but it just makes an observation that simple implementation usually wins.
In my experiments simple implementation won for velocity, because quite often I need to change small parts in all the implementation no matter how modular / reusable code I'm trying to write.
As my velocity increases testing becomes more important as well (especially integration testing), as there are more features interacting in a small amount of code.
> .. simple implementation won for velocity ..
How do you specifically define velocity in this context?
(I am asking because I tend to favor speedy velocity in quick iterations; which is another story, than say velocity for change...)
Kind regards
I am throwing in my Plotly.js-based weather display, based on OpenWeatherMap and hand-drawn graphics: https://github.com/quimoniz/ophelia?tab=readme-ov-file#-ophe...
(by default it also displays the Hacker News newsfeed)
Also see [Big Five personality traits](https://en.wikipedia.org/wiki/Big_Five_personality_traits).
Tesla might have been more likely to focus on having the tech working at the expense of everything else.
Maybe this applies more often when the one giving advice has more experience than the one receiving it, or when the person who is stuck has habituated a narrow perspective or some form of learned helplessness.
But I recoil at something I think I see more often, which is when several people stand around pointing out the obvious and congratulating each other on their fresh ideas and wondering what’s so hard for the guy who has lived the situation and would love to find a way forward if there were the right resources or the right change in policies or the right change in politics. The peanut gallery loses interest pretty quickly when faced with questions about the real constraints and it turns out their answers are not fresh at all.
But now we have someone who’s “marinating in the stuck,” surrounded by people who still agree with each other that they know how it should all be done but have now also been embarrassed.
It’s an ugly, toxic cycle that bottoms out at everyone constantly having their knowledge and competence questioned over things they know and can do, by people who don’t and can’t.
If someone is stuck, ask if you can help, sure. Ask what seems to be the trouble. Ask what has been tried so far. But maybe don’t lead with your advice.
That rings so true in my head. Being too open and transparent got me quite a lot of misery already. More than once, I got the work of months discarded, because some other (shiny or new) approach was deemed to provide a better solution -- only to the effect that it was later discovered that it was the worse approach.
Apparently it is very easy to miss in the pursuit for the best solution, in unfortunate favor of one's preconceived notions.
My brain immediately goes like: You nitwit, base64 comes back from E-Mails, where you would work with Mail-Server's conception that your mails were all written, legible characters. Of course you should expect newlines, potentially whitespaces and tabs in it.
But that would be stupid of me. There's so much old knowledge and know-how we carry along for many decades - around 50 years in case of mail and SMTP. Unix and Linux are a specially egregious example, with so many conventions.... just ran into a long standing bug a few days ago, with some GECOS implementation (that's 62 years old stuff). We do a lot of good in throwing out the now unnecessary old stuff and separating the wheat from the chaff. Again and again.
In so far: Thanks for the pointer on that Base64 appears strange (also please do not let us talk about groff).
> Do It Scared
True. I've deep dived enough topics and technology to confidently say that pretty much everyone is just cooking with water as they say. .... The special specialist doing super professional job with X? - well they are probably just using this or that standard tool. Resolving problems with some very sound approaches (which they probably taught themselves through experimenting, through practice).
Especially with software: Just have a go at it. The worst that could probably happen is that you need to reinstall your Operating System (and please don't ask me, how I developed some kernel-patch-performance-evaluation)
Using Chrome on Android and also on my computer, the annoying pop does thankfully not appear between music tracks with my Simple Music Player, called JUkebox with Php and Html5, short JUPH: https://github.com/quimoniz/juph
I tried to make it dead simple, using the HTML5 Audio element.
Now it's been lying around for 4 years... does anyone else know of a similarly non-sophisticated audio player?
The obvious solution would be, just don't send data to the player's client about enemies that are behind walls. But this is a surprisingly hard thing to engineer in realtime games without breaking the player experience (see: https://technology.riotgames.com/news/demolishing-wallhacks-..., and then notice that even in the final video wallhacks are still possible, they're just more delayed).
With respect I'd like to disagree on this subtly. A lot of games have the client send their cursor position at relatively frequent updates/packages (i.e. sub-second). So the server knows pretty precisely in which direction and to which object a player is looking.
This in turn can be readily used upon when using wall-hacks, as most players, who use wall-hacks tend to almost faithfully follow objects behind walls with their cursor, which good moderators can usually spot within a few seconds, when reviewing such footage (source: I was involved in recognizing Wall-Hacks in Minecraft, where players would replace textures, to easily find and mine diamonds underground).