In the DSRC projects I've been across, V2X packets that aren't signed appropriately are dropped by the stack

A happy user since 5.04! A happy Debian user prior to that.

A low-overhead bullet journal (i.e. zero time spent to make it look pretty) works best for me - preaching to the choir, man!

I use the "pyramid format". Conclusion first. Main points with little explanation next. Explanation of main points after that. Details last. That way someone can stop reading at any point and still have a complete view at some level of detail.

Some people find that determining what the conclusion is, is difficult to begin with. Or that there are many conclusions. And, how do you present those details? Chronologically?

A helpful techniques I've picked up (that some people absolutely hate); write down the individual statements on post-it notes. That way you can reshuffle. What would the story look like if A is 'the conclusion'? What if we start off with B? What does it look like if we present the supporting evidence chronologically? What if we present it in a more layered way? ("the colonel couldn't have done it, as on the day of the murder, he was in another city")

Another tip is for the introduction, the lead up to the conclusion; start with listing the facts that are common knowledge, then the fact that raised the question to be answered; then you reach the conclusion. (E.g. Every week, grandma bakes a pie and leaves it to cool in the window. Last week was no exception. But when she went to retrieve the pie, it was half-eaten! The culprit was the cat!) This setting the scene can give the reader some context. In a real-world example, the known facts might include your company's strategy or objectives, underscoring why people should care about your advice.

This approach is also known as the "Minto Pyramid." The website "Untools" has a well-written webpage that explains this: https://untools.co/minto-pyramid/

Untools itself also inspired some good discussions on this forum (2020, 137 comments): https://news.ycombinator.com/item?id=23339830

Nice link, thanks! I was put on to this by someone who had done defence work in their past. They used the "Concept of Operations" for their preferred document style which I also like.

I often print out my D&D maps (say, from a scan of one I've drawn), transcribe important features on to it using coloured pens and run the game from that. Whitespace and simplicity is a feature here... "photo-realistic" maps with stone textures and artistic doodles get in the way of usability.

You'd need to ask the author of the article.

I backed the original DW project and was a user of Google+ in that time and place where the "Old School Renaissance" (my preference) clashed with "Story Gamers" - "you see me now, a veteran of a thousand psychic wars".

From those interactions I could say that preference for DW could range from simple technical preferences to deep-seated politics resulting from trauma.

The "all this debugging was done in assembly language with minimal symbol table information" was basically true in 2009-2011 too. The (non-CrowdStrike, non-Microsoft) team I was on was developing Windows intermediate drivers which did network acceleration. I'm not sure how CrowdStrike works but we essentially MITM'd/proxied in the Windows networking stack (is CrowdStrike observe-only? I don't know). I would end up filling notebooks with register moves and subroutine calls to trace back bluescreens because Windows is closed source. Thank goodness for Windbag disassembly. Interop with other intermediate drivers like popular virus scanners was an interesting problem. I'm pretty proud of our work there in hindsight!

Those who have spent time writing NDIS/TDI drivers are those who know the minefield!

In > two decades I've never set eyes upon someone using Apple hardware for development unless it's as a dumb terminal. I work in embedded, hardware and applications, not mobile, web or scientific. I am sure such users are out there.

Heh, I used to work for a solar PV system manufacturer. Half the office was embedded systems and hardware engineers, who all ran System76 or Framework laptops. All the web devs had Macs. Management all used ThinkPads. You could tell what somebody did there just by looking at their laptops. And well, I guess the oscilloscopes were a bit of a giveaway too :)

In my much shorter 5 years, I’ve seen devs exclusively using Apple hardware.

And in my team, our dev environment has become increasingly local!

If you arent doing stuff that touches low level OS or high performance compute, it doesnt really matter what you use. Ive switched to Samsung Dex with a lapdock, and can easily do python and node dev. For high performance, I simply run a cloudflared tunnel to my home box.

In my decade its been majority MacOS. But Ive worked on the other side of this fence.

Thanks for posting this! I have very fond memories working with/under various ex-INMOS folks including the author while at XMOS. I also read Gries at University :-)