First and foremost, if you like dark mode, if you like light mode; you do you, friend. I do not want to persuade you to change your aesthetics. I'm just always trying to learn more about the world. To better understand what's going on and what we think we know about it as a species. Easily one of the best things from this talk is knowing about the terms positive and negative polarity when talking about this. Using those terms to search for information really seems to help.
That out of the way, hope you find the talk fun and informative.
First of all, love this design. Retro-web is such a fun metamodern punk aesthetic. Every one of you make me smile when I load pages like these. Bonus points when it's blended the aesthetic with modern information design to make it still easy to follow and parse.
For the record, I don't support this move. Breaking backward compatibility as a systems programmer is just burning down other people's work. Without an immensely good reason it's just arson.
How'd I call it? I was looking at the condition of the MDN docs around these coupled with what I know of software pop culture as a sign that nobody building browsers thinks XML is worth supporting anymore.
I'm not one for the conspiracy presented here though. I think it's just out of fashion which has become the arbiter of all that matters in software development. "Is the brand of the things I build, and the brands of the things I build with in fashion or not?" It's rich kids keeping up with the Joneses.
It always makes me roll my eyes when the people responsible for this sprawling mess of what is technically the web "standards" go on parades around small corners of the swamp to exclaim, we're cleaning up www subdomains! Never mind they've stuffed an entire Bluetooth stack, DRM, multiple database technologies, over two dozen media codecs, shader programming and more into the web ecosystem. Those three characters gotta go.
Same here. Doesn't matter that browsers still have to parse and support XML by way of XHTML. It's XSLT processing that broke the camel's back. Better force every piece of software that's used that spec into costly rewrites because I don't like it.
RSS will still work just fine in most readers. I think even most browser based readers are doing backend processing of the feed text to turn it into HTML instead of using the browser's XSLT parser to render them. I could be wrong though. Sorry I don't have any good reader suggestions here. I just built and maintain my own for personal use.
If you've been using XSLT on your feed to make it look great in a browser, or worse still, built entire mission critical applications leveraging XSLT, I feel for you. I won't rehash my thoughts on either side of that choice, however, if you think you want to, I think you should be able to count on the web platform remaining a platform instead of just being whatever some Googler thinks being a platform means that week.
In any case, all the more reason I'm bullish on a project like Ladybird. With fewer than seven competitors it's easy to get consensus on what you'll impose on the rest of society. Not only that but here you've got two of the three on the take of the third. Monopolization is really good at completely divorcing you from the problems you cause for everyday people.
Just a fun anecdote filled piece all about how to build good user interfaces. Excellent read. Well worth your time, even if you're versed in the subject.
To recap the highlights:
A user interface is well-designed when the program behaves exactly how the user thought it would.
Every time you provide an option, you're asking the user to make a decision.
Users don't read the manual.
Users can't control the mouse very well.
These are mostly reformulations of well known UI design guidelines:
Jakob's Law: Users spend most of their time on other sites.
This one's unique. Partly not interrupting a user. Partly not abdicating the design part of design. Partly not adding controls only a few people want.
Paradox of the Active User (Carroll & Rosson, '87).
Fitts's Law: The time to acquire a target is a function of the distance to—and size of—the target.
Sure this uses many more words for less than is covered by the Laws of UX website. The stories and examples are just fun to read though. Having vivid stories to remember can significantly improve how many of these abstract concepts you remember when you're working on UI.
This is the conference talk behind The Documentation System. This is my all time favourite framework for organizing documentation on a project. It builds a little 2x2 matrix based on practical versus theoretical and studying versus working to categorize documentation. Really helps provide clarity on what you're writing and where it should go.
There's often times to break with this strict breakdown. For example I love having a dedicated page to talk about the project explaining what it is and why you should care at the top of the documentation and outside this structure. FAQs also tend to sit outside just to be really easy to find. It's fine to break with this structure when it makes sense, but having this as the backbone of the documentation has really improved splitting documentation up. To try and stop having stream of conciousness dumping documents.
I would strongly suggest not throwing everything out and starting again. Just start by adding this structure to your project and link (don't move) the existing documents that already fit this structure. That's already a lot of work and doesn't destroy what you have before you've fully built the replacement. Next, you need to build buy-in. If people are going to keep writing documents the old way (usually randomly in wherever they think makes sense) then you'll never converge. Getting buy-in from the team about this system means all new documentation will be built starting from these viewpoints. Even if the folder structure is later abandoned, just having these use cases in mind when writing documentation prevents making information soup.
Once all that's done you can then begin refactoring documents as you update them, splitting them into new documents inside each of the relevant sections. Over time, if you have analytics, you should start to see more and more people reading documents from the new sections and less from the old. Whenever you see a document outside this system being used often, refactor it into the system. If you don't have analytics on your docs, you probably should. It's invaluable to help find what documentation is having a real impact and what documentation isn't.
So much great advice in this video. This pretty much covers a lot of what I've learned by observing a number of projects, teams, and groups I follow. This is absolutely how it's done well and absolutely a great way to think about community. Obviously this can't be the only way to think of it, but it definitely lines up with what I'm seeing work.
Not just commercial communities either. This is how successful communities are built for hobbies, socialization, coalitions, companies, unions, religions, paramilitaries, and more. Learning how to foster, maintain, moderate, discourage, and alienate people trying to get together and contribute towards a common project, that's what power is all about. It's also why so many of these sorts of institutions have begun failing in society. They don't know how to build and maintain community anymore. Or rather, they've lost the one or maybe two people among them who actually knew how to build community.
It's not something broadly understood, taught, or practiced so those few people who know how to do this hold outsized impact on the organizations they, well, organize. I've repeatedly seen whole communities collapse when the one person doing this work left for any number of reasons from infighting, loss of passion for the project, and on a few occasions, just straight up dying. It's work that's heavily undervalued and doesn't really get a lot of credit. It's easy for people to not really understand who is doing the work to make the community they enmesh in actually work as a community and just take it for granted. Like any random collection of people would spontaneously form like this. That it has nothing to do with careful deliberate cultivation going on both within and without.
I'm reading way more into this videos than is there. This is Matt just talking about how he's made the MCDM community work. It's got a lot of what I've been seeing from the practices in other successful communities. It also helped identify what's missing in the unsuccessful ones I've followed and watched wither. This lecture just really brought together a whole lot of other things and crystallized a lot of thoughts I'd had laying around and couldn't completely bridge.
I love this simple versus easy distinction. He's right, we do throw those two terms around interchangeably in software development and being clear between the two is critical to improve our communication. I'm not as much a simple software advocate. Simple is great and has a lot of maintainability and reliability improvements it imparts but it certainly balances against secure, performant, and time to deliver for me. See Rust and Other Interesting Things or Data-Oriented Design and C++ for more details. But having this language, the ability to talk clearly about choosing the easy path sometimes or instead refining it to be simple by detangling two things that have been complected. That's very useful to discuss trade-offs with colleagues.
The saddest part of this talk is that the table he builds, of programming language constructs that are complex verses simple. That table is never really explained well in the talk. This is like a two week cram course cut down to fit in an hour. If you don't already know what he means by managed refs or polymorphism a la carte, you're stuck. Or at least it took me many years to appreciate this table fully and I assume others are in the same boat. I don't think a TIL post is the right format to go into details either, but I'll backlog an item to create a blog post about that table in detail sometime soon (famous last words).
Having listened to a few conference talks about satellite ops/sec and having talked/read/listened to/from hams who do AmSat stuff, this isn't really unknown. Lots of them talk about, for example, secret frequencies and protocols that let them read and write arbitrary memory on the satellite to enable emergency recovery. Essentially intentional remote code execution to help save the millions of dollars spent putting the thing beyond reach of repair.
This is however the first work I know of that's really spent the time to detail all the really fun stuff going on. For me, this paper is far less about the conclusions and far more about documenting all the obfuscation techniques, protocols, and worth knowing specifications to get you up to speed on what's going on up there in case you want to have a listen and try decoding some of this stuff yourself.
It's not as bad as Firesheep, which is what it took for the web industry to start taking cryptography seriously for inter-device communication. Maybe they don't need something that bad to get their act together? Though the automotive industry is facing the Flipper Zero and they're still dragging their feet and largely sticking their heads in the sand.
I'm not going to say this is a simple solved problem. Space makes deterministic computing much less reliable and redundancy much more expensive. I'm not aware of any cryptographers working on RadHard crypto algorithms and protocols though. Granted, I didn't look too deeply through the literature. Could be an open research problem. Essentially you'd have to design a cryptography system that can remain secure in the presence of some limited probability of arbitrary bit flips of the source code and runtime. Bonus points for doing it in low compute environments like those found on cube sats.
Cars have no excuse like cosmic rays though. Come on, it's well past 1994.
The original source material for this piece is NIST SP800-63 which contains all the actual specifications. The Malwarebytes labs post is just more fun which helps get the relevant bits across. Bureaucracies move glacially slow but the standard has finally been updated. Complexity rules, enforced scheduled password changes, and rotation history tracking do not lead to better security. We have fairly overwhelming evidence of this at this point. In passwords, length always wins.
Of course passwords are still completely lost on most people so you get idiotic headlines like Complicated Passwords Make You Less Safe, Experts Now Say. No, using a bigger character set still improves security. Nobody is saying you should stop using complicated passwords. We're saying adding arbitrary rules for users to follow just makes people frustrated while at best not meaningfully improving security and in many cases, actively making it worse.
People just do the most obvious things to satisfy your pointless rules. I need an uppercase, lowercase, number and symbol, better use Welcome2025!. If you've ever set this password for anyone, please stop. Stop it right now. You are single handedly undermining the security of your company. Very few people who you give that to ever change it. It's probably the most obvious password in the history of passwords along with qwertyuiop, monkey123, and Lisa1969.
Final note, use a password manager. I'll even let you use one that syncs to the cloud if that's what it takes to get you using one. Let it generate huge 60 character passwords full of symbols for you and stop trying to remember them all.
You can usually embrace this even in an organization that demands estimates. To me, a line manager's key job is insulating the workers from the business so they can get things done. The key tool at your disposal is scope. I remember watching this talk a long time ago and in the time since it's combined with a few other ideas I've read about death marches. That's when everybody working on the project knows the deadline is literally never going to work, and yet you all keep marching. A simple way to unpack that involves thinking of projects as being a combination of cost, time, scope, and quality. You can only control three. Trying to control all four leads to a death march.
If you just work by starting with a deadline, a lot of it slots into place. A point at which we need to ship/demo/whatever then you can work backwards. Using projection, not estimation, you can spot things are slipping early, often earlier than estimators realize, and you need to either move the deadline or cut scope. Reducing scope is usually easier than you think. Your customer doesn't know all the cool things you wanted to build. They only know what you put in their hands. If you agreed to more, you can talk it out. Focus on what's most important. This happens all the time and it's not the big deal many people make it out to be. Also, for big projects, iterate. Don't just promise the whole thing in a year. Promise a part in a month or two. That's a great way to get feedback early and fix things before they're fully load bearing.
Not only that, just counting tickets really does give you a projection that's fairly accurate. I've used it before when estimates had months and my calculations showed years. Years later, I was right. When estimates can be as much as 200% wrong and projection is usually within 20%, it's insane not to switch.
This works because a ticket represents one unit of work from start to finish. There's a bunch of overhead in starting, testing, shipping, and so on. So each unit tends to scope about the same amount of work. That is, roughly one chunk of work someone wants to finish before doing another thing or the amount of complexity they can manage in one go. It also means it doesn't matter who's scoping as long as they're scoped together. They'll bucket into roughly the same size. What size doesn't matter too much. Just that they're about one unit of work.
This really does work. It's how I manage my team. The entire process can be summed up as make an ordered list of things to do and then do it. Repeat. It really doesn't need to be more complicated. Simultaneously, any process missing one of those components is doomed. The most often missed part is ordered list. If you have a vague sense of priority you'll end up with all sorts of informal channels of power attempting to pick their own winner among the work to be done.
I could drone on but I'm certainly not right about what will work best for your team. There's a lot of things to try, but here I'd suggest mostly, try less. Try cutting things. It's too easy to add and too hard to remove. Do the hard thing and see what happens. You can always add it back if you all worked better before. You'll probably find that more substantive things will start getting done but you feel like less is happening. That's because everyone will be busy doing instead of talking about doing.
Pretty neatly sums it up. The software industry has always had faces, people for whom the entire point of technology is to make the cover of some magazine, arms crossed, looking smug for the camera. To find themselves an interview so they can stroke their ego in public.
Focus on these losers long enough and that'll be all that's left. The stories we tell sculpt the future we see. These days the story is that if you work hard enough, some techbro can buy your work to claim it as their own so they can climb atop their pile of stolen valor like a dragon's hoard. If you refuse, they'll just light a pile of Saudi investment money on fire to undercut you and drive you out of business. Guess who this story really appeals to and attracts to the industry. Guess who it drives away.
Early Woz got me hyped, Aaron drove it home, Ken and Rob gave me a tradition to inherit, and at least a dozen more have done their part too. I consider myself a proud hacker. Not a great one mind you, just proud. Take it apart and put it back together purely for the discovery and fun it brings. Make it do things you shouldn't be able to because the limitations drive creativity.
If you listen to the story though, that's antithetical to the point of technology. I should only care about it in so far as it generates capital. Exponential growth. Unicorn. Sell that baby and become rich beyond your wildest dreams.
I make money to have time to play with the technology, not the other way 'round.
This is a pretty great introduction to group theory from the prospective of a distributed systems programmer. Really useful stuff. It starts by mentioning abelian groups offhandedly in order to poke fun at the impenetrability of the jargon of group theory compared to how easy it is to understand the concepts involved. If you understand idempotency, you already have an intuitive understanding of things like commutativity (which is what items in an abelian group share). If you don't, this talk makes it really easy to understand what properties resilient distributed systems tend to try and design upon and why.
Yeah, I think that elegantly sums it up. We're in so deep on economy as speculation at this point that basically nothing about a company matters beyond attracting investment. It's companies looking to get in on yield farming. It means the economy is mostly a measure of how compelling the collection of FOMO stories seem. This is why you've got runaway. If your FOMO story aligns with a lot of other companies stories, this only further boosts the FOMO.
Cryptocurrencies showed that the economy as an exchange of goods and services was only incidental, not explicit to generating the needed speculation. Making and selling (or more likely renting out) things is now only there as props in telling these stories to earn the real money. That is, people giving you heaps of cash in exchange for stock. Basically anything you can invent by typing numbers into a spreadsheet that buyers can trade amongst themselves will work. Stock these days fits the bill because you don't have to pay dividends. Why not? The story goes that if you did that, you wouldn't be growing as fast. Conveniently this reinforces the FOMO narrative.
Whenever someone whinges that the stock market is up or down and somebody inevitably retorts back that the stock market isn't the economy, I'm actually starting to think they're wrong. The stock market really has become the economy. Anyone with power has so much money tied up in the stock market, that to them, their ideas, what they think is important, the stock market weighs heavily in every decision. Everyday people aren't like this, they need bread and circuses which are becoming ever increasingly more expensive (because doing that makes the stock go up). But to those setting policy direction in government and companies, the stock market really does drive their entire outlook.
Look, if 99.9999% or more of your wealth was in this one vehicle, most people really would do everything they could to prevent their wealth decreasing even if it meant destroying people and the planet to do it. You're only going to live 30-50 more years tops. Problems for later generations or suckers less fortunate are superficial compared to your retirement portfolio.
If you've never edited Wikipedia, give it a go. It's way simpler than you probably think it is, especially for the often undervalued work of citing sources or fixing grammar and/or punctuation. You're likely going to read a bunch of Wikipedia anyway. Take the extra few minutes to help fix problems when you see them.
A great run through many of the noodly little details of Unix processes, signals, alarms, select, poll, and more. Includes a go through the self-pipe trick which I hadn't thought about until now, but is a neat way to simplify. I'm really happy when someone explains something by working a solution to a problem with all the trade-offs left in. Doubly so when the explanation also includes all the hairy bits of the implementations instead of leaving them as a stumbling exercise to the reader.
About a decade ago when Waymo was making all sorts of headlines, I was talking to someone who thought we had the same timeline in mind. That it wouldn't be long until every truck driver would be out of work, so let's armchair politician what that'll mean and what should be done. I laughed and said, yeah, probably around 2050. At the time he thought I was nuts and I didn't bother to explain why. Today we're still at least a decade or more away but at least we've surpassed a hundred bodies on the road to self driving.
I bring this up because I think it's too easy for people to convince themselves that isolating oneself in a cave can lead to super intelligence and that intelligence is all you need to control and shape the world around you. It's the same flawed assumptions that have some thinking you'll put your brain in a jar at some point or that you could upload your conciousness to a computer. I'm sure you were endlessly bullied as a kid for liking computers and being an antisocial recluse, but I'm sorry to inform you, it doesn't work like that. None of this works like that.
In reality, technologies, even ones that go on to reshape civilisations, act over decades. Humans have a tendency to highly overestimate short term impacts of technology and end up completely blindsided by the long term changes these technologies bring. When I got on the internet everyone was talking about how it would cut out the pointless middlemen of markets and bring people closer together in a global village. In reality, it has been a key part of doing almost the opposite. Over the last couple decades the internet has played no small part in ushering in a golden age of monopolies and grifters all while disillusioning people of centrism, leading us back to the age of unified visions, and with that, a renewed interest in political violence.
It's not to say that technologies do the opposite of what people worry they will. That's far too reductive. It's that even revolutionary technologies like electricity, fire, steel, or the wheel act over decades, not years. Why? Well for that it takes an article like the above. Reality is extremely complicated and detailed. To understand all the ways reality slows down the adoption of these technologies, it requires more work than I'm doing in a TIL post.
The guts of email are from a different era. Always love when people dig into it to share with everyone. Always learn your history. It's invaluable for helping you not say really dumb things in front of those who not only know the history, but those who were there. You may not get it all perfect, but much like learning to speak someone's native language, when you're at least trying it opens a whole lot of good will.
I will warn you, it ends with a, "That end's the part that's going up on Youtube." *cut to black*
Now I really want to know what was talked about after. It's a great talk, as all of Dylan's tend to be.
Might as well hunker down and learn how the mono-browser works. It's not as sad as it sounds. In many ways, the talk is all about the problem domain of browsers with footnotes into the Chromium codebase and not the other way around. Also of note, it's a little old, but only so much changes so fast and a lot of the foundation isn't going anywhere fast.
This goes far beyond designers. If you can't sell your work, you're in a dead end career. Full stop. Not just to customers, though that helps, no. The number of developers I know who are stuck in their career because they've never learned to sell their work within the organization is staggering. It's easily one of the two biggest things between senior developers and staff developers (the other being focus). The myth that great work sells itself needs to be seen for just that, a myth. Mike's here to help you with that.
Also, this talk is wonderful. It leans heavily on the old school preaching rhetoric. It's entirely captivating when done right. Once you've sat through this lecture to learn the material, sit through it again and take notes on the style. See what you can incorporate in your own speeches to take them to the next level.
We need so much more of this in software development. The practice of just telling people to use some library or other has hurt the field so much. You reinvent the wheel to learn how the wheel works, to improve the wheel, to design a wheel that works bettor for the problem you're actually working on, to apply lessons learned on different problems and cross pollinate innovations. Don't reinvent the wheel is probably the single least self-aware statement in history. The wheel is probably the single most reinvented piece of technology humans have ever used.
In any case, this is an excellent introduction to writing your own sound system. The downside is that every operating system has their own audio system, and the largest ones have nearly half a dozen different audio systems each. The one thing the libraries can do for you is try to cover over all the different audio systems. The problem is that not knowing how they work under the hood leaves your knowledge hollow. So study up. Write to them directly. Learn their idiosyncrasies. There's great insights on trade-offs in there.
By vehicle he means car, but the idea that there's limits to how much you can simulate in realtime for a game is absolutely true. Love that he shares a great base model for a vehicle though. A fantastic resource for anyone starting on a car in games. You'll have to play around with the feel until you get something better for your game, but a good starting point to understand the basics none the less.
