jungler

Wow, not the kind of engineering room I'd want to be in. You have to be able to make claims that the other party does not have a complete picture of the situation, and an external critic is indeed going to be vulnerable to the same criticism.

Maybe you would have a point if it were a Linus-style "only a fucking idiot would" rant. But responding to a sincere attempt to defend a design decision as if it were an insult is some prima donna behavior.

You could ask the interviewer to whiteboard something for you, too.

I'm moving towards an approach of batch processing more things. What this means in practice is that more of my tasks use limited interactivity - e.g. "draft and redraft" vs "draft and edit". This has the effect of the "yes and" in improv, where I make errors but have to keep going regardless. Working within that mode also means that I can activate on a reflexive, pre-flow state level where I flex the project-management muscles, not the problem-solving muscles. Flow means I am challenging myself, and with so many years of experience, challenging myself means that I am overcomplicating it.

As well, I'm more likely to treat looking up docs as a research project where I copy relevant snippets of the text into one place for easier reference.

I'm still unhappy with a lot of aspects of how I code, but most of it isn't on the end of the day-to-day editing, but rather things like, "oh, I switched languages again - time to relearn the string library".

The more I think about the "boredom is good" concept, the more I suspect it's flawed. Bored kids get into trouble, especially as they get older. By 18, a very bored kid left to chance will have found an unhealthy outlet like drinking or property theft.

We have a lot of screens now. But it's what one sees and does with the screen that matters. There is an element of media as pollution in this, but it's contrasted against our notion of "the classics". We always end up with a youth that is a mixture of the misspent and the classics.

I've been converted to the "add peripherals" side, personally. The standards are developed enough and the selection is broad enough to dial in whatever balance of price, portability, ergonomics and device features is desired - at the extreme end, a USB OTG hub connecting your full size mechanical keyboard, MMO mouse, graphics tablet, game controllers, and flash drives, and at the other, pocket folding Bluetooth keyboards and mini mice. It turns a phone or tablet into "just a screen" - a viable entry level workstation only held back by software and processing capacity.

"high-performance" is a qualifier worthy of question, though.

If the goal were to write one algorithm to be the fastest implementation, performance would usually equate to having low level control.

If the goal were to do automatic optimization of a wide variety of similar algorithms, then we're in the "actually writing a compiler" territory and then there is little to be gained from defaulting to low-level control.

I scrolled through https://github.com/dbohdan/embedded-scripting-languages

And there are some options. You could achieve barebones VM protections with Pawn(the language enforces very little otherwise, though). You could use something ref-counted like a TCL implementation, which would allow you to design around linear allocation times. The vast majority are using some kind of tracing collector of course, but I wouldn't say this is a total loss for achieving a combination of real time and memory protection.

My main minus to this is not that it's JS(I'm building a JS fantasy computer too) but that it's a node/react piece, which inspires zero confidence that it will have anything resembling foundational stability in the future.

Everything compiles to JS these days, so it is an easy lowest common denominator.

Lua is a semantically cleaner alternative but it has relatively less mindshare and hence less third-party support.

This is more-or-less the format Bisquit uses in his tutorial videos, e.g.

https://youtu.be/vkUwT9U1GzA

Somewhere he explained that he made a custom tool to make and play back a "perfect recording" of his edits.

It was definitely a thing to run multiple screens in a "one-per-task" kind of setup - the real difference is that hardly anything back then networked or multitasked, and so you had to design the workflow you wanted to use specifically around the idea of using all your displays. In the context of any specific application(coding, document editing, CAD etc.) the possibility of a custom tailored solution existed - it just wasn't the highest priority most of the time. You could get a lot of multitasking mileage out of more antiquated technologies like printed documents and pens in tandem with your computer. "Code review" meant literally printing it out and going over it with highlighters like an exam grader. I'm sure it still does in some shops.

My reaction to customizations that shave off seconds is: "so what, it'll be blown away the next time the tech stack changes." I do automate, but there's a subtle difference in goals.

If I automate my personal toolset, I follow the same procedure I use around automation anywhere else: don't start off doing it to save time, do it to increase reliability. I will write small scripts, sometimes one-liner scripts, sometimes largish hundreds-of-lines scripts. But the outcome I am aiming for is that I have a procedure that is documented and puts all the configuration in a place where I can see it, so that when the situation changes, it is fixable. A productivity boost is a frequent byproduct of successfully automating, but it's usually a side component to "reliable and documented". The boost is perceived as reduced friction and increased conceptual integrity: fewer things to check or to accidentally get out of sync, and thus less stress involved.

Focusing on UI being both shiny and fast is likewise often missing the point - which is the case when discussing new hardware. There are order-of-magnitude thresholds for human attention that are important to keep in mind, but hitting a lower attention threshold usually doesn't solve a productivity problem. It creates a case of "wrong solution faster", drawing the user into a fast but unplanned and reactive feedback loop.

See for example the case of writers who like the Alphasmart, a device that makes doing editing so tedious that you don't do it, you just write the draft and edit later.

Game design allows for a rich exploration of design from a philosophical standpoint.

That is, while most games are utilitarian products first(just as most architecture is made to be inhabited and most software is made to be used) the premise of a "game world" or "magic circle" shares something in common with any fiction - that the contents can be decided in a pragmatic fashion, with arbitrary rules.

Most game designs use this power timidly, just reproducing an existing rule set with a new scenario and more product features, but the most engaging stuff aligns all elements towards a coherent concept[0].

And the real tension of game design comes from the negotiation of what the player thinks the game is about(e.g. "what do I do in this game") and what the resulting product actually enables or encourages. Where we recognize "progress" in games it's generally along the lines of shifts from completely symbolic ideas(e.g. lives, score, turn taking) towards fine-grained representations with fast feedback that corresponds to our expectation of reality(texture mapped 3D, immersive VR, physics sims, etc.), but there's a toolbox of symbolic ideas that tends to stick around regardless.

[0] http://ludamix.com/dive/coherency/

As one SF Chronicle article put it in describing CA Governor Newsom, SF politics are a lion's den that produces strong candidates for the national stage.

Which in perspective says not that SF functions well, but rather that it functions so poorly that you have to have immense skill to survive.

And like other established cities with some history, there is a vein of the upper crust - people whose parents owned property, went to the local prep schools and now own some property themselves. That's a thing that contributes to the quagmire, since it creates more complex entanglements than the basic economics would suggest. A lot of the tech billionaires have made moves to muscle in on this scene, which has perhaps helped it from getting too stagnant, but contributes to its overall incoherence.

In the back of my mind I always hope that a new technology I'm using will fail in a spectacular, obvious fashion as soon as I use it wrongly, because that means that a great number of resources will soon appear to cover all the gotchas.

It's the ones where spotting and debugging the source of the problem depends on fine-grained conceptual understanding, that leads to documentation that gives you a metaphorical blank stare and shrug.

I like to dub this phenomenon the "unnamed skills". There are skills that are categorized and standardized: you can teach someone the poses and movements, the steps to follow, and the concepts to look for. But you can't teach them very much about putting it together into a whole and to apply some techniques in some ways and not others. Direct experience does that, and yet the way in which people interpret their experience leads to the sharp differences in style and overall ability.

Often this comes up in written fiction: authors will describe the characters and their thoughts and motivations in a mode natural to how they perceive things: some authors spin up plots and intrigues at every turn, others focus on raw emoting.

So I tend to view smarts as a personality trait, when we're dealing with healthy folks with no other issues(and realistically, most people are battling something else most of the time without necessarily being aware of it). There's a limited degree of smarter-is-smarter that shows up in testing, and then after that it starts being about personality-driven specializations, the ways in which they overcome problems. The archetypes are easy to spot in school: the student who seems to ignore any lecture or materials and rushes to get help from the teacher or study buddies, versus the student who quietly reads the text and never asks a single question. Both types can get perfect scores in some subjects, but usually not across the board, effortlessly. And as projects grow in scope and cover more skills, awareness of personality-driven limitations becomes more essential to success.

If you haven't yet, try both vitamin D3 and magnesium supplements. They're correlated with generalized mental health issues and some deficiency in both is common.

Comparing difficulty between FM and SID is a bit apples to oranges. The SID has analog variance in its filter, and no two are exactly the same, so a pure DSP implementation has to do rather heavy math to approximate the filter. As a result most people lean on a handful of SID emulation cores because otherwise their emulation is just wrong.

OTOH the things that tend to differentiate implementations of Yamaha's FM are the sample rates, bit depths, and envelopes used, plus any output distortion(YM2612 for example has a well known distortion in its implementation that adds a harsher edge). The core algorithms they use are something a high school student could pick up and do something with, and emulation quality issues are more a matter of it being easy to write an emulation that gets it 98% correct without covering the last steps, since those are details that really need error-for-error reproduction of the original ASICs and boards, including any timing issues - things which frustrate emulator writers everywhere.

The MT-32 sound module(also a Roland creation) was the target device of a lot of PC games circa 1988-1992. The more sophisticated soundtracks would reprogram the built in patches, also using sysex for this operation. Not only that, they would put text messages on the MT-32's display!

With the gaming scenario some distinction between display latency and network latency is worth reviewing. Network latency is something that software can cover for in some degree(to create online experiences there's always some kind of synchronization of different wallclock timelines going on). Display latency is universal, though. A faster display will let the game give you feedback faster, so long as we are talking about feedback in the local experience(so: aiming, movement are commonly predicted on the client, while hit registration often uses a server roundtrip). This separation of responsibilities allowed people to play Counter-Strike 1.x on 200ms dial-up connections back in the 2000's.

When it's a pure video feed you get the impact of all the latency all the time, and that means the problem has to be solved with brute force reduction of bottlenecks everywhere.

So how much latency is enough for responsiveness? This is pretty easy to derive from the common target framerates: for 30hz display, you need 33.3ms. For 60hz, 16.6ms, for 120hz, 8.3ms. Since perceptual latency is known to keep improving up through 144hz it's reasonable to say that we should be looking for only 5-6ms at most, while most broadband connections are still achieving pings in the 20-100ms range, depending on the game and the specific connection. On the very best connections, that is, we can assume a "30hz transparent" video stream, which is fine for casual experiences but severely impacts competitive ability when tested. In many current popular titles this manifests in mechanics that are both latency sensitive and require a server roundtrip, e.g. building in Fortnite.

For that particular question: They would all be the same speed because the optimization requirement would lead each one to write a compiler in their language of choice that emits a perfectly tuned assembly binary.

What gets overlooked in language performance is that you pick a language for what are, in essence, placeholder constructs. The performance matters only in that you need it to be fast enough "off the shelf" that you don't have to start writing a compiler. But you generally aren't prevented from using that approach to boost your existing code, and high performance systems often converge on that strategy in some degree, because it lets you keep maintainable source code and add toggles for debugging and optimization that you won't get from treating the application and compiler code as separate entities.

That's different from "I do not want a disabled GC baked into my program." It is relevant, especially to embedded coding with its ornery size restrictions.

AMD doesn't have to win in discrete at all to make a killing. They only have to dominate the lower end, which they already are positioned to do with current APUs - these chips can manage 30hz/720p playability in most new games, which is easily ignored if your requirement is competitive gaming minimums or 4k, but in terms of price/performance, it's near unbeatable.

The Radeon VII is ultimately just a repurposed workstation card given flagship treatment. It's not where AMD's business really is, ever since they went down the route of semi-custom and small dies. While pushing RTX could renew Nvidia's advantages, the only game console they're on these days is the Switch - no raytracing to be seen there. Developers accommodate the Geforce cards for PC releases, but AAA going console-first precludes designing most content around RTX. They've made a lot of moves to try to repurpose high end graphics for other markets, but it looks like it's going to be very rough for Nvidia in the next few years if they can't find a "blue ocean" that needs both speed and programmability.

I think the trick is not to regulate total screen time, but to regulate long uninterrupted blocks of screen time.

The "social media loop" that haunts many adults is not really different from whatever cravings kids are going through, and in both cases it can be combated with scheduled activity breaks that involve getting up and doing a bit of housework or going outside for few minutes. It promotes better sleep habits while not really limiting the core activity.

I would definitely not recommend encouraging anyone to go from one sedentary activity(games, Youtube) to another(homework, coding etc.) directly - that's something that makes "screen time" a nebulous timesink.

Although many folks have raised the "not Gettier" objection, I would propose that the premise of applying the test to debugging is wrong. Debugging means that your assumptions were already faulty: otherwise the system would not have bugs.

That is, the act of programming means working on an unfinished thought, something that can reflect some beliefs but compromises on being an exactly true expression of them. And so the weight of philosophical reasoning should appear at design time. What occurs after that is a discovery phase in which you learn all the ways in which your reasoning was fallacious - both bugs and feature decisions.

Bias heavily towards ease of debug and deployment. When you're the one-man-band you need to leverage all the tooling towards realizing the design, and avoid the scaling rabbit hole. That means - simple now, rewritable later as you bring in hires.

You will need a solution for producing front end JS/HTML/CSS. This should probably be your starting point in fact - create a site mockup with static pages and no real backend, use that to gain feedback, then build out the real functionality. For JS code Typescript is a very popular option to aid some additional maintainability. There are also many build systems available for compiling finished pages.

When you're ready to have a backend, you can evaluate it separately later. You need a combination of a language, a web server, and a database at minimum. Again, an early site can avoid horizontal scaling and focus on having one good database doing everything and backing everything up reliably. (Focus backend efforts on reliability first!)

First, make sure each task you're doing fits into a conceptually coherent whole. [0] This saves you time and effort learning that it isn't from the customer feedback. This also creates a motivational point beyond "I need this to make monies", since now building the software means you get to see an abstract philosophy come alive.

Second, design a schedule for yourself that both lets you take out and put away the project. If you aren't hugely inclined to solve programming puzzles that are created by other people's code, it's understandable; the trick is in making it not be the number one priority(because a boring task like this is no longer the fun learning stage of coding), but rather to make it one of many chores on your list. You have a household; there is always something to maintain in it, whether it's dry shoe leather, mildew on the walls, a load of laundry. Allocate 10 minutes each hour to that stuff, then return to the coding with the momentum from that. Huge blocks of screen time never helped anyone. (And yes, overall health matters. Getting more sleep, exercise, correcting a nutritional deficiency, can all be huge for motivation.)

During the coding, aim to finish it badly(placeholder level) and then go back and fix it in steps. These tasks get worse when you have to juggle a whole pile of new abstractions all at once: skip to a preset result and then work backwards from that into something that is configurable. Good code doesn't come out of your forehead fully formed, it takes some iteration.

If you don't have an estimate for how long anything takes, that's also a demotivator. You can calibrate one by finding a similar project, getting its start-to-release dates, and working backwards to get milestone dates. Don't worry about time per task, worry about the overall product coming into shape. Placeholders as milestone goals can help hugely in getting you to dig into the design and make it its best.

[0] http://ludamix.com/dive/

I think my favorite way of describing the 90's internet(I was alive but not there for the 80's version) is that it was unfinished. Things were slow. Things broke a lot. Your computer crashed a lot. You didn't have the space to download a lot of stuff(a lot of people turned to printing out web pages). The number of venues was small enough that they could be listed(I had a 1992-era book that acted like a phone directory of all the interesting things there were to do). But there was a promise of possibility there. Once in a while, things did work. A site did what you wanted it to, seamlessly. You could go on Usenet or IRC or a MUD, and just talk to people. They were roughly as terrible as people today, but with a higher average level of income and education. You could occasionally talk to someone from a foreign country, too. Because the scale and sophistication of everything was small, there were many unlocked doors - limited or no protections. You could reasonably expect to moderate an online community on your own, and not drown in spambots, brigading, or DDOS attacks.

But the barriers to entry were high, as well. A state-of-the-art build consistently ran in the $2000 range - you could go cheaper but it often meant being several years in the past at a moment when Moore's Law was steamrolling every assumption in 18 month cycles, and software that kept pace with more and more features. Games in particular heavily targeted the enthusiasts. Many people got into PCs upon experiencing Doom for the first time. And running a server - well, most people were on dial-up lines, and in the early part of the decade, shell accounts, not the PPP connections that gave you full TCP/IP connectivity. If you ran a server, it was most likely part of a school or business connection. And then you had to maintain all of it yourself. The onset of free hosting - first with Geocities style static HTML, and then webpage builders and even PHP scripting, was a kind of early example of Internet commercialization. It allowed lots of folks to make their own web site for the first time, which they promptly filled up with "about me: i am 13 years old and have two dogs. sorry ill finish this later"

There were no real expectations around early Web content, after all. It was whatever you thought you needed to put there, and a consumer-branding mindset hadn't sunk in yet among Web surfers. You explored Web sites because there were no places with upvotes and newsfeeds, just pages you bookmarked and checked regularly in hopes of an update. If you wanted the drip feed of news, mailing lists and Usenet worked better. But gradually publishing and aggregation came into play on the Web, with both traditional news players and the likes of Slashdot, and web forums took up the baton from Usenet of allowing you to engage in topical discussion, except that over time all web forums turned into meta-communities defined by their off-topic discussion.

Then as now, the single most useful thing you could do in most circumstances was to send someone an email.

The money incentives have changed things too. People stream their gameplay for cash, and that has led to a rapid professionalization of gaming that wasn't there in the era of demo recordings and an occasional LAN event. It makes for more incentives to hide cheating or gatekeep your game sessions behind private Discords etc.

Since the rise of Minecraft the games themselves have also gradually shifted towards being long-term platforms for streamer content, vs simply providing a fixed experience. Free-to-play economics likewise aim towards maximizing total lifetime value of each user(with a built in expectation of user turnover) instead of marketing towards the initial purchase.

I am actually going the other direction, I used to build my own, went to laptops-only for a while but then got a mini-tower prebuilt. That one died after about 18 months so I recently ordered an even smaller Gigabyte Brix, with a 10W CPU (Celeron J4105) instead of 65W, but better I/O, and compatible with my existing RAM and storage options. Small enough to mount on the back of the new monitor I'm also getting. I have gone smaller with every desktop I built.

Basically, I now use laptops for games and the desktop for storage/office tasks. The single board desktops are quickly growing out of the RPi-type niche and look increasingly competitive with the traditional ATX platform for this role, and opting for them means that I define my system around the storage and RAM, rather than the multitude of PSU/motherboard/CPU/GPU/case combinations, which is both easier for me and eliminates most instances where components push each other out of their tolerance range. So long as I'm on the same memory and storage, I can replace everything else in the case for <$200. This is really what sold me on the idea; since my existing system fell out of warranty after one year, repair would be the cost of a new board. But if the whole system is the board, then a failure is a forced upgrade.