The earliest I've used was Protracker, which was the most popular tracker in the early heyday of the format (late 80s - early 90s), but the earlier Soundtracker was the OG "tracker", and probably used the same layout, but I'm not sure. https://www.exotica.org.uk/wiki/Soundtracker_History
But if FL Studio (formerly FruityLoops) and Renoise use the same layout, as others have said, then those are probably going to resonate with a wider modern audience :D Or maybe just call it "FL Studio / Renoise / tracker layout"?
I don't do computer keyboard note entry any more, but I still have the muscle memory for that 4-row layout from hours spent with it in the late 90s :D And I'd totally use it in your game. (My MIDI keyboards are kinda too far away from the mouse and monitor.)
I broadly agree with the author’s point there, but disagree with the specific language he used. In my view, engineering includes those pesky non-technical considerations, like the business context and the human factors, which bring their own tradeoffs and priorities to the engineering decision-making.
That is, his “pure engineers” are not really doing engineering, at least under my understanding of the term, whereas (some of) the impure engineers actually are! :)
I love vintage computers, have a vintage computer collection, and have enjoyed visiting computer museums, but does this computer museum website really need to send me desktop notifications?
I had a "reverse" system design interview at Amazon back in the 2000s. Possibly before the modern "forward" system design interview became so popular.
I also remember circa 2012-2014 being required to conduct what are now considered typical modern system design interviews (i.e. as an interviewer) while employed at Amazon, and 90% of (even senior) candidates had no idea how to even begin to approach the "design a system to do X"-type questions. I think this is partly because far fewer people in typical software jobs were building distributed systems back then anyway, and partly because all the YouTube videos and guides like yours didn't exist yet, so nobody was doing the kind of dedicated prep and rote-learning that seems increasingly expected nowadays.
Back then, when the problem was too far from the candidate's real work experience, and they weren't willing to make educated guesses and ask clarifying questions in order to move forward, it was often a struggle (for both of us) to pivot the interview towards something the candidate could tackle and demonstrate their design experience. ("Tell me about a system you designed", i.e. the "reverse" approach, wasn't an acceptable alternative in our rubric.)
Now, just like what happened with coding interviews vs. Leetcode, it seems that a more common challenge for the interviewer is telling the difference between a candidate who is applying real experience and understanding vs. regurgitating/performing what they read in a system design interview prep guide. But that's assuming one is actually more valuable than the other, and I don't have proof of that.
Indeed. Thinking is not the same as experiencing thinking.
> there’s no way to know if any other people, much less machines, are conscious.
Or even ourselves :D
"Consciousness is just an illusion" "If so, who's experiencing the illusion?" "Yes"