GrumpyYoungMan

Yes, they are for EEs or at least CompEs, since a knowledge of digital logic and electronics are necessary to use them.

For hardware, a common recommendation is hobbyist/educational boards from Digilent, like the Arty S7: https://store.digilentinc.com/arty-s7-spartan-7-fpga-board-f... It's inexpensive, supported by Xilinx's free tools, and has a fair bit of tutorials written around it.

As for learning to use it, there's really no getting around the fact that you'll have to acquire an understanding of digital logic, which is more like Factorio than programming. Make sure you pick a textbook whose focus is on teaching digital logic and happens to cover a HDL; there are a few out there which focus on the HDL and presuppose a knowledge of digital logic, which will not be of much help to you.

"Windows Internals" 7th ed. part 1 and 2 by Mark Russinovich would be the definitive current reference on how Windows itself works but assumes knowledge of how operating systems in general work already.

For general OS knowledge, I second the other poster's recommendation of Tanenbaum's "Modern Operating Systems"

I'd recommend gaffer's tape instead: https://en.wikipedia.org/wiki/Gaffer_tape. It's similar to electrical tape but it's designed to leave no residue when peeled off.

It needs to be understood that any kind of new engineering project has a risk of failure, often quite high. For example, in software, there's the infamous CHAOS report from the Standish Group that comes out every couple of years. A casual Google for the 2018 results has this quote from someone with a copy (https://hennyportman.wordpress.com/2020/01/03/review-chaos-r...)

> "The Standish Group started with a traditional metrics of success by looking at: “on time, on budget, and on target”. This means in this CHAOS Report 2018 for the year 2017: successful: 36%, challenged: 45%, failed: 19%. If they use their “modern” definition of success: “on time, on budget, with a satisfactory result.” You get almost the same results (33%, 48%, 19%)."

So, about 1/3 of IT projects are successful, including being on-time and on budget, and about 1/5 are total losses that fail to deliver any value at all. Not great odds and I'd expect the numbers are likely to be broadly similar in other engineering fields.

The decision on whether or not to embark on an engineering project (and whether to do it in-house or hire a third party) is among the most challenging duties executives have.

You want the Susan Dephillips one. Very eye opening, if you've never worked in a big corporation before.

Apollo 13 was a much better movie to point to with regards to STEM types saving the day, despite the artistic license it takes.

If there's another edition, it won't be from him, sad to say.

> "In September 2018 I retired from my 34-year career of writing, speaking, and thinking about application programming interfaces."

https://www.charlespetzold.com/about/

Whenever I look at my pile of shame, I keep promising myself I'll sit down and play every one of them when I retire.

(All the while, there's a little voice in the back of my head snickering and calling me a liar.)

> "I simply cannot "decompose" a single feature into 500 different sub-task Jiras."

Nobody can; that's the primary failure mode of waterfall. Anybody who is telling you to decompose a feature into that many subtasks might claim to be doing agile but they really are trying to do waterfall.

Definitely needs DeMarco and Lister's "Peopleware".

> "The three-dimensionality introduces logistical insanity that is startlingly difficult to wrangle, and the first person viewpoint makes planning the factory floor very difficult."

As a former player of the Tekkit mod for Minecraft, the three-dimensionality is what I miss. As good as it is, Factorio is so disappointingly planar, despite the tools they give you to manage belt intersection and materiel transfer.

> "the word 'agile' is almost worthless, these days, so I prefer 'flexible'

It's kind of sad, though. What you said above ("I’ve learned to adopt an 'organic' project process, based on the assumption that it’s impossible to know the end result when I start.") is literally what Agile was trying to convey when it started out.

First and foremost, relax and recharge. The hard work will come again soon enough. Go out to a long lunch or have a team lunch or something, for example.

Second, take some time to take care of yourself professionally. Now's a good time to network with former colleagues and other people you haven't talked to in a while, to spend some time learning about something that will enhance your skills or to make sure your résumé is up to date.

Lastly, take some time to clean up your workplace. Take care of old tech debt items, update documentation, and, in general, take care of any part of the systems you work on that have been neglected for a while. There's always something that needs maintenance.

Build the tools and infrastructure necessary to make FPGA accelerator programming accessible to the average programmer. Moore's Law is mostly dead; we are getting more cores but we are not going to get significantly faster cores in the near future. What will bring us next big jump in computing performance is unclear but FPGA acceleration seems like one of the few promising directions.

I'd suggests the ones from Ergomart, e.g. https://www.ergomart.com/monitor-mounts/monitor-arms/saa2415.... They have options on some models that support up to 55 lbs as well as other models with extended reach.

> "How do you consistently say no without appearing oppositional?"

A flat "no" comes across as oppositional.

On the other hand, "Well, that depends..." followed by an analysis of options and possible roadblocks (this is where the "no" is subtly injected), that's construed as thoughtful and methodical. I would even venture to say that "It depends" is the only correct answer for an engineer to give to any question.

Mathematica seems to have support for units: https://reference.wolfram.com/language/tutorial/SymbolicCalc...

I'll forever remember his delightful performance as the snooty Clayton Endicott III, the foil to the main character, Benson, of the '80s sitcom of the same name. The byplay between him and Robert Guilluame as Benson never failed to get a chuckle.

Farewell, Mr. Auberjonois, and thanks for all the laughs.

Guaranteed to be unpopular: Text-based serialization formats (e.g. XML, JSON) are utterly wasteful of bandwidth, processing power, and memory when used for services with a high request volume and should be dropped in favor of binary protocols.

> "Scrum is meant to help estimate based on real work by developer."

Sure, but the problem is that, aside from one job, I've never seen any organization that actually does that. Instead, agile/scrum is used as a micromanagement tool and developers get hammered if they don't close their Jira tickets in a timely fashion. It's an total perversion of what agile was intended to be.

The jack of two trades is the master of none. Yes, other disciplines will inevitably learn to code out of sheer necessity but it will be a secondary skillset for them. They will not have the depth of knowledge of software development and the inner workings of computers that a dedicated software engineer would and their code will mostly be at the level of a one-off or prototype.

Software engineers will still be around as the people who will take code from other professionals and work with them to turn it from a prototype into a production ready codebase. That means unit tests, fixing performance issues, building in security, building proper UI/UX, adding things necessary for regulatory compliance (e.g. accessibility, GDPR, etc.) and so forth.

I almost always wind up finishing up games with a huge pile of resources left over. It's only natural; even hardened adventurers need to keep their retirement in mind while saving the world.

> "So serious in fact that in May, the World Health Organization (WHO) announced that the next version of its handbook of diseases, the International Classification of Diseases (ICD11), will recognize [burnout] as an official “occupational phenomenon” that could drive people to seek medical care."

Eh, what? I thought ICD-10 already had a code for occupational burnout: Z73.0. (https://icd.codes/icd10cm/Z730)

Read David Tribble's "Go To Statement Considered Harmful: A Retrospective" instead: http://david.tribble.com/text/goto.html . It contains the entire text of Dijkstra's paper and goes over its meaning in a modern context on a paragraph-by-paragraph basis. It's very well written and makes clear the "encourages spaghetti code" argument, while true at the time, applied in a era where basic control flow constructs that we now take for granted did not exist in commonly used languages.

Elegant, tight, and efficient code mattered back in the days when a machine with a 20 MHz processor and 8 MB of RAM was considered a high-end workstation. You really had to understand what your hardware, your OS, and your compiler was doing in order to produce decent software.

Nowadays, such esoterica is relegated to the tiny niches of systems and embedded development.

Giant beard? Fond of telling people that one of his grad students was the chief architect of the Pentium III? Yeah, I remember his comp. arch. classes fondly.

The only game I can think of that was similar to the model you suggest was the long ago "Spaceward Ho!" series, which was uncomplicated but fun. There was no tech tree; putting money into each of several categories of research yielded incremental improvements in that area over time but occasionally one would get a "breakthrough" that would boost that area dramatically or provide a new capability.

I thought it was an interesting idea but it seems fundamentally incompatible with having a tech tree at all.

It has been researched: Alessandro Forin's eMIPS research project was on integrating FPGA fabric as an execution unit.

Project page: https://www.microsoft.com/en-us/research/project/emips/

Research paper: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Back then Moore's Law was still going full steam so there wasn't much interest but, who knows, maybe that will change in a few years.

> Having a discussion with someone who quotes Dijkstra can be frustrating.

Agreed. Most of the time, it seems the pithy quotes are the only thing that the quoter knows about Dijkstra.

> You end up having to explain why blanket bans on goto don't make sense

For Dijkstra's GOTO quote specifically, there's a wonderful document by David Tribble named "Go To Statement Considered Harmful: A Retrospective" that does a line-by-line analysis of Dijkstra's paper and explains what Dijkstra's meant in the context of his time and examines where usage of GOTO still makes sense today.

http://david.tribble.com/text/goto.html

You're talking about a GPS repeater. Such systems are commercially available to rebroadcast a GPS signal within a building where the signal wouldn't penetrate, but require a license to operate, IIRC.

As for countermeasures, well, whoever's holding the receiver is bound to get suspicious if they move and the reported position doesn't. :) Jokes aside, there is work being done integrating other sensors (inertial, compass, gyro, etc.) to do dead reckoning to detect errors in the position and motion reported by the GNSS receiver.

As an aside, "GPS" technically refers only to the positioning system operated by the United States. The generic term is "GNSS" (global navigation satellite system) and encompasses GPS, GLONASS, Galileo, Beidou, etc.)