Bryan Cantrill:

I actually view the primarily role of a technical education, in computer engineering or in computer science / software engineering, is giving you humility that anything works at all […] that once you understand how extraordinary it is for a machine to work at all, you’re humbled.

More 👏 humility 👏 please.

Cantrill makes a good point that “complexity is contagious”. It doesn’t merely accrue, it can go viral and spread to everything around it when not properly managed.

When simplicity in the abstraction is a non-goal, you don't know what to say “No” to.

When constructed systems are done well, there is someone at the helm, or a group at the helm, or unifying principles, that allow them to know what to say “No” to and give them permission to say “No”.

New software is so hard because people aren’t ready for it. No matter when you ship it:

The most calcified software of all: the software in our minds.

Which is why:

The biggest problem for a revolutionary system is to stay funded.

When you’re drowning in complexity, just know that it can get better — it will get better! How do you know that? Because revolutionary ideas can change the abstractions we build on.

when you are mired in accreted systems, that is when revolution systems form. That is a solace we can take when we are in extremely complicated, accreted systems.

It’s very complicated to make things simple — and it’s very simple to make things complicated.

John Oliver:

The thing about not waiting until you’ve solved all the problems with your product is you’re then launching a product with a shit ton of problems.

(Context: Olver had just played a video of an AI company CEO who said he was happy to not be making a “Doctor” AI chatbot because that would involve too much risk because it has to be right. A “Friend” chatbot, he argues, doesn’t have to be anything but “entertainment” so you can launch it into the world before all the problems have been ironed out.)

Coffee tastes like music. When you listen to music:

you could pick out the cello from the violin, but they blend so well together. But if the balance is off, if one instrument is too loud or the tone’s not right or something’s a bit off, very quickly it is distracting and unpleasant. It’s more than just the music, the harmony, the melodies, balance is so important too. With great coffee, you should really notice the instruments unless you want to. You should just be enjoying the music.

Replace “great coffee” with “great software” and this holds.

Sadness. It’s that moment at the end of a cup of coffee where you go for one more sip and it's finished and your brain’s like, “Hey, I was drinking that! I’m not ready to be done yet.” It’s such a lovely moment of sadness. It’s beautiful because it ends. Great coffee should leave you wanting more, not worrying about what you should eat or drink to get rid of that sensation in your mouth.

There’s an art of knowing when to end something.

via R. Alex Anderson

Warren Buffett:

[My dad] didn’t care about money at all. He believed very much in having an inner scorecard and to never worry about what other people are thinking about you. If you know why you’re doing what you’re doing, that’s enough.

Jake Nations:

There is no silver bullet. Not better prompts, not better models, not even writing specs. Just the unavoidable work of understanding your system deeply enough to change it safely.

Can we understand our own systems when we delegate the responsibility of building them to something (or someone) else?

Every time we skip thinking to keep up with generation speed, we’re not just adding code we don’t understand, we’re losing our ability to recognize problems [and complexity]

I kinda like the idea that what makes you a great developer is your ability to spot errors and prevent mistakes. That’s it.

In other words: the experience of having done something the wrong way, and the resulting wisdom to know better in the future.

That’s really just life.

Alex Petros at Big Sky Developer Conference (2025):

A lot of people chafe at the idea that we’re going back to something we we used to do before. But if you wrote a web server in PHP that returns HTML in 2005, and you did that 2015, and you did that in 2025, it would work great today about just as well as it did back then. So hypermedia is sort of the base layer of stuff you might do on the web. That is always going to be true, there's never going to be a different base layer. So you can be pretty confident that you're building on a foundation that lasts.

Tristan Harris summing up where we are with AI:

We are building the most powerful, inscrutable, uncontrollable technology that we have ever invented, that's already demonstrating the rogue behaviors that we thought only existed in bad sci-fi movies. We're releasing it faster than we've deployed any other technology in history, and under the maximum incentive to cut corners on safety.

ThIs Is FiNE.

This is a great definition for an “app”: a limited web browser.

[social apps] are often just bespoke web browsers that only take you to a very specific website and keep your traffic inside a walled garden while also collecting lots of data about what you see and what you do

I’ve never really enjoyed Bill Maher as entertainment, but his segment on tech deserves some introspection by us tech workers.

You [tech folks] keep improving things because A) let’s be honest, it justifies your job, and B) it’s fun — for you. I get it. It’s what you’re good at: tinkering with shit…you like over-engineering stuff, but don’t tell yourself you’re making anyone’s life better.

What constitutes progress?

Is it progress that we’re moving ever closer to where we never engage with other human beings? Is it progress that CEOs used to brag about how many people they employed but now they brag about how many people they’re throwing out of work?

Silicon Valley’s motto:

If it ain’t broke, fuck with it.

there's nothing to sell if the art doesn't happen in the right way. It has to be protected. And it can't happen on the same kind of a timetable that business can. It's just a different thing. Art doesn't come in a quarterly way.

It doesn’t matter how artistic breakthroughs work — they’re not meant to really be known — just so long as they happen and you can recognize when they do.

knowing how [art] works doesn't make it work. The magic isn't how it works, the magic is the magic. The magic happens in a way that's intuitive and accidental at times, or incidental where you try lots of things and suddenly something works and you don't know why.

If you're not interested in working on it any more, it's done.

Jerry says he prefers a yellow legal pad over typing on a keyboard. He calls a keyboard "too corporate" and says he likes how contrary the legal pad is in this way.

To be creative, you gotta feel like you're getting away with something.

I like that. I'm gonna ask myself that on personal projects: “What aspect of this makes me feel like I'm getting way with something?”

That's fun.

That’s the thing that’s interesting about open source. Instability and chaos make it stronger. On the other hand, that instability is really dangerous for companies that are trying to extract value because it becomes very slippery and brittle.

Big company: why are you rocking the boat?

Community: we don't mind rocking the boat because we’re not a giant ocean liner.

A big company is like a giant ship that has to start making its turn a mile before the actual turn itself. Whereas the community is comprised of thousands of small, distributed boats that can make (in contrast) hairpin turns.

A talk by James Long at dotJS 2019 around “local first” software. A few things that stood out to me:

• “Local apps” are fast because the computing takes place on your local device instead of a back and forth between client/server.
• “Local first” takes away all your performance concerns (that stem from having to use the network) because it simply takes away the network — and that's a whole swath of performance concerns.
• Because there’s no network, your app is only bound in performance by its computational (and memory) limitations.
• A whole swath of security concerns disappear if your app is local. As James notes, “You can’t SQL lite inject yourself.”

This line is more powerful when you hear it in the talk, as it’s a bit confusing when written down, but I still love it:

[Breaking changes] are unplanned work, which means you have to do work that you didn't expect to do in order to keep building the thing you already built that worked.

A great talk from Simon Willison full of practical advice on large language models.

I liked his personal AI ethics:

• I won't publish anything that will take someone longer to read than it took me to write

• I never commit code if I couldn't both understand and explain every line

I also liked his point about how LLMs have helped him redefine “expertise”. Expertise isn't knowing every API of a tool by heart — that’s trivia. Expertise is knowing what the tool can do and what kinds of questions to ask in order to use the tool effectively.

Also this line just so accurately describes tech:

It's not easy to do well, but it's trivial to get up and running.

I also thought it was interesting that he suggests running the models your own laptop because you see a lot more of the hallucinations and holes in the models (vs. the ones from corporations which try to build in safeguards) which give you a better understanding of how they work.

Neil deGrasse Tyson noting that the “if all you have is a hammer, everything looks like nail” phenomenon exists even in physics:

Seems like whatever’s your speciality, you think the solution lies within your expertise.

A great talk from Maciej Ceglowski in 2014.

Our job is to get [the people] connected, maybe put a decent font on the knowledge, and then watch the fireworks happen.

What happens next is wonderful and unexpected. It’s a humble vision of technology. We know how to make the tools but we don't believe that we're smarter than seven billion people in how we choose to use them. We say, “Surprise us.” And then we iterate back when we see something cool they're doing. Then maybe we try to design different tools to make that happen more easily.

A lot of the interesting things that happen in technology are not things we planned or anticipated, yet we still like to think this next time around we’ll design things from the ground up.

When Twitter came out, they didn’t even anticipate things like the hashtag...again and again we have this history of not really knowing how our technologies are going to be used but it doesn't stop us from thinking we can design the next ones from the ground up.

The economic basis of the internet is surveillance.

It’s an interesting phenomenon that people don’t feel quite the same about commercial surveillance as they do government surveillance.

• Gov is spying on us? [Pitchforks] Ah, hell no!
• Private company is spying on us? Meh.

If the gov made you carry a device with incredibly sensitive personal details like geolocation metadata, there could be protests in the street. But if it’s from a commercial entity we’ll do it voluntarily.

Google [is] the world’s defacto internet server. It occupies a dominant position in almost every area of online life. It’s unremarkable for a user today to connect to the internet on a Google phone using Google hardware talking to Google servers on a Google Browser while blocking ads served by Google AdSense on sites where trackers use Google Analytics and DoubleClick and whatever else

One of the best talks on creativity I’ve heard. Definitely worth the ~30 minutes.

We like to do easy things.

It’s easier to do trivial things that are urgent than it is to do important things that are not urgent (like thinking). And it’s also easier to do little things we know we can do, than to start on big things we’re not so certain about.

And creativity is hard. There’s discomfort and anxiety:

If we have a problem, and we need to solve it, until we do we feel inside us a kind of internal agitation, a tension, an uncertainty that makes us just plain uncomfortable, and we want to get rid of that discomfort. In order to do so, we take a decision. Not because we’re sure it's the best decision but because taking it will make us feel better.

Well, the most creative people have learned to tolerate that discomfort for much longer and so just because they put in more pondering time their solutions are more creative.

The trick is to live in that discomfort:

[Donald MacKinnon] discovered that the most creative professionals always played with the problem for much longer before they tried to resolve it. They were prepared to tolerate that slight discomfort and anxiety that we all experience when we haven’t solved a problem.

John goes on to clarify:

Please note, I'm not arguing against real decisiveness. I’m 100% in favor of taking a decision when it has to be taken, and then sticking to it while it’s being implemented. What I’m suggesting to you is that before you take a decision you should always ask yourself the question, “When does this decision have to be taken?” And, having answered that, you defer the decision until then in order to give yourself maximum pondering time which will lead you to the most creative solution.

And if while you’re pondering somebody accuses you of indecision, say, “Look baby cakes, I don’t have to decide until Tuesday and I am not chickening out of my creative discomfort by taking a snap decision before then. That’s too easy.”

Love it.

The way that we've found that's most effective to get interesting behavior out of AIs is to just pour data into them. This creates a dynamic that is really socially harmful. We're on the point of introducing these Orwellian microphones into everybody's house and all that data is going to be used to train neural networks which will then become better and better at listening to what we want to do.

If you think the road to AI goes through this pathway, then you really want to maximize the amount of data that is collected…It reinforces this idea that we have to collect as much data and do as much surveillance as possible.

I always love Maciej’s take on tech.

AI risk is like string theory for programmers. It’s fun to think about, you build these towers of thought and then you climb up into them and pull the ladder up behind you so you’re disconnected from anything. There's no way to put them to the test short of creating the thing which we have no idea how to do.

Data pipelines take on an institutional life of their own. It doesn't really help that people speak about “the data driven business” like they’re talking about “the Christ centered life” in these almost religious tones of fervor.

Great counterpoints to the religion of data.

The promise you’re told is that enough data is going to lead you to insight.

I worry the reason we haven't learned from the fiasco of the 60's, the systems analysis, the fetishizing of data, is because after all it's only anecdoteal. There's only the one data point.

Talking about Erroom’s law, which is Moore's law but backwards for the drug industry (the amount of money 2 cents worth of research could've bought you in the 50’s costs you 1 dollar today, and its exponentially increasing in cost).

The basic fact is that a chain-smoking chemist just randomly shooting compounds into mice is a more cost-effective way to discover drugs than an entire genomics data set. That is a bizarre result.

Speaking about this relationship where you measure the world and then make judgements. Then humans enter the world, see what you're modeling and measuring, and adapt to get around your measurements. So you take into account their cheats and then update your rules.

Notice what you've started to do. Instead of just measuring the world, you're now in this adversarial relationship with another human being and you've introduced issues of power and agency and control that weren't there before. You thought you were getting a better idea of what is happening in the reality, but you've actually just introduced an additional layer between yourself and reality. This kind of thing happens over and over again.

Honestly, I have’t watched this whole thing. It’s long. But this excerpt aptly describes a problem from which so much software and technology suffers.

Cryptocurrency does nothing to address 99% of the problems with the banking industry because those problems are patterns of human behavior. They’re incentives, they’re social structures, they’re modalities. The problem is what people are doing to others, not that the building they’re doing it in has the word “Bank” on the outside.

A short talk worth watching. Shows how we are the ones driving innovation because we need to make pragmatic choices in the things we build today.

The Abstraction Fallacy

Making a messy model a bit cleaner increases utility radically.

An infinitely pure model must therefore be infinitely useful.

Actually

Optimal representations are pragmatic.

They're only useful for a specific set of situations.

Never in the history of human kind have so many done so much nothing and tried to make a living at it. And I’m not even talking about Wall Street.

What a great start! An interesting commentary I found linked in a critique of web3.0.

Most of you watching this have real jobs, not make believe “influencer” jobs.

The economy of nothing wouldn't exist if not for hyper consumption…People seem to be desperate to be entertained constantly.

As a UI designer, I found his finger pointing at YouTube’s UI interesting as well.

YouTube is a harsh task master. Sure the analytics page might congratulate you on a successful video. But if you don’t keep it up, it will depress you with comments like [shows screenshot from the YouTube UI]: “Your numbers are down because you didn’t publish enough this week.”

Do you creators take a few days off or, heaven help you, go on vacation? Hell no! You could drop subscribers! Are you nuts? So I would blame YouTube as the reason for YouTubers producing so much “nothing” content. YouTube insists a break is good for you, but their analytics page tells you they are liars.

Maciej talks about his youth and how, whenever he did something bad, he was threatened with: “this will end up on your permanent record.” Then he learned there was no such thing as a “permanent record”. But, switching gears to the internet we’re building, he now says:

How depressing to grow up and be part of the generation that implements the god damn permanent record for all of us?

In programmer folklore, we obsess over data loss. We got PTSD from losing data once that now we’re dead set on capturing and retaining everything forever. We haven’t arrived at a point in time where we fear but data gathering and retention over data loss. Rather than having a little foresight, it seems we're going to capture and retain everything and then learn from experience why that’s a bad idea.

It's almost as if we [we got burned] by the fact that computers only understood binary and couldn’t really understand floating point, that [instead of fixing it] we just decided “we’re going to use integers from now on as a society because the computers don’t let us do otherwise.”

Why harboring with “feudal” internet companies (like Lord Google) for aspects of your digital life can be bad:

This is a dilemma of the feudal internet. We go to these protectors because they can offer us more security, but their business model is to make us more vulnerable by getting us to surrender more of the details of our lives to their servers and to put more faith in the algorithms that they train, and then which train us in return to behave in certain ways.

As always, Maciej is funny:

I'm not convinced that a civilization that is struggling to cure male pattern baldness is capable of [solving the problem of death]. If we're going to worry about existential risks, I propose we address the two existential risks that already exist and we know for a fact are real, which are global nuclear war and climate change.

But these real and difficult problems are messy. Tech culture prefers to pick more difficult, abstract problems that haven't been sullied by any sort of contact with reality. They worry about how to give Mars an Earth-like climate rather than how to give Earth and Earth-like climate. They debate how to make a morally-benevolent, God-like artificial intelligence rather than figuring out how to make ethical guardrails around the real artificial intelligence that they're already deploying across the world.

An interesting talk given in 2013 but the presenter, Brett Victor, pretends as if it was 1973. It shows how things we would not have wanted to happen in computers have happened.

The thesis of the talk, however, revolves around this idea: if you’re constrained by believing you know what you’re doing and you know what programming is, then you’ll be unable to see any adjacent ideas that might actually be better than the ones we have now.

The most dangerous thought you can have as a creative person is to think that you know what you’re doing. Because once you think you know what you’re doing, you stop looking around for other ways of doing things and you stop being able to see other ways of doing things. You become blind…

You have to say to yourself, “I don't know what I’m doing.”…Once you truly believe that, then you’re free and you can think anything.

Honestly, a lot of this talk was over my head. But the presenter, Bryan Cantrill, was engaging and funny and I couldn’t stop listening.

Being ahead of your time is not commercially fruitful.

I also learned second system syndrome is a thing.

I do like this idea of complexity sneaking into our lives and having to actively fight it, almost like it's roaches or something.

Great talk. Funny and candid. A thoughtful rebuke of many commonplace ideas in tech today:

I mentioned perseverance because there's this pernicious idea that comes from startup world that you should "fail quickly". I've always been a proponent of failing really really slowly because if you aren't in it for the money you don't know when you've succeeded or if you might succeed. Success doesn't come labeled in any way to distinguish it from failure—unless you're in it for money in which case it's really easy to count your success.

Later he talks about how Thoreau wasn’t much of a success in his lifetime. Only later were the insights of his writings recognized as ahead of their time. Maciej then weaves that narrative into his own points about perseverance and being open with money when he sarcastically points out the absurdity of financials as a measure for his definition of “success”:

I earned $181,000 from pinboard last year, which is 23,000 times as successful as Henry David Thoreau. Not bad at all.

And then this:

[You should write things down because] experience is hard-won knowledge and you don't want to just let it get away.

And lastly this:

We can't depend on big companies to take a stand for us.

The evaluator, which determines the meaning of expressions in a programming language, is just another program.

I honestly did not understand much of this talk. But what stood out to me the most—and what I wanted to note down—was the insight stated above. Or, to restate it from another point in the talk:

A program can have another program as data.

This in-depth analysis of loading scripts in the browser is filled with nerdy technical details.

For example, Tim tells this story about a team that was loading a giant bundle of JavaScript using the <script async> tag. To try and improve performance, they ruthlessly cut down the amount of JavaScript being shipped to the browser. They got the file size way down and...performance got worse! Do you know why? Watch this video to find out—or I’ll just tell you why: even though it was async, the giant mass of JavaScript was blocking the parser when it arrived, and because it was so much smaller than before, it was arriving earlier and thus blocking the parsing of the HTML document earlier and giving the appearance of slower performance. Hence Tim’s statement at one point in his talk:

Don't take anything as gospel. There will always be tradeoffs.

Observations from someone who has been building for the web for 20 years.

We keep engineering more complexity and then using complex solutions to abstract it away for a while until we build new complexity on top of the new abstractions. If we zoom out enough, the overall pictures looks less like overall simplification.

It’s interesting to view “progress” through this lens (screenshot from talk): a pile of abstractions, each hiding the previous layer’s complexity. Either way, Kyle’s sentiment resonates with me quite often:

I'm not tired of building products for the web. I'm tired of being a modern JavaScript developer...Most days, I don't seem to be very good at my job.

Based on some recommendations on Twitter, I started watching some Strangeloop talks. To be honest, I don’t fully grasp a lot of what’s being discussed in these talks, but there are little bits and pieces I find and note down.

In this particular talk, Jamie points out an interesting historical fact around regexes. My familiarity with regexes is: those big cryptic pattern matching strings I hopefully never have to deal with much. I found it interesting that what makes them scary (a regex that’s more than like seven characters long) is basically due to the over-extension of a constraint that shaped their original design.

This is an interesting point of origin: [regex's] usefulness on the command line and while editing led directly to how concise regular expressions are—which is great if you need to be concise. If you don't need to be concise it means that the syntax is rather cryptic.

I ended up down a Malcom Gladwell rabbit hole the other day, which resulted in some interviews with him playing in the background while I worked and I liked this:

A special kind of insight comes from distance...I think we’re really reluctant to re-examine our conclusions about the past. There’s so much to be learned by simply going back and saying “we made up our mind about this [thing] that happened”, boom, the day after it happened. And then we just let it sit there and never went back to say, “well, was I right?” There are all kinds of things you can learn, years later, that can fundamentally change your understanding of history and how you reach your own conclusions.

Then later:

It brings to mind that famous epigram “history is written by the victors.” And that’s true. The account that you get in the first go-round is written by the guy who won. So one of the reasons it’s so important to go back and look at history again is you have to give other people a chance to speak. People are willing to be honest with the passage of time.

I originally discovered this via a link on Dave Rupert’s blog—along with his relatable commentary:

Whenever I read the original Agile Manifesto and it’s accompanying Twelve Principles, my soul leaps! But in practice inside enterprise Agile frameworks, my soul is often left crushed...In my experience, there seems to be a strongly held belief that if you obey certain rituals: have certain meetings, say certain words, pray certain prayers, commit to improbable deadlines; your product will enter the Promise Land. It’s hard for me to rectify what I know about software development with this religion. I have resigned myself to being an apostate.

However, I didn’t get around to listening to the source video until recently. It’s fantastic. The speaker is Martin Fowler, one of the original signers of the Agile Manifesto. The fact that he basically calls apostasy on what most of us likely participate in as the de-facto, day-to-day, shared implementation of agile, is striking.

with so many differences, how can we say there is one way that will work for everybody? We can’t. And yet what I’m hearing so much...is imposing methods upon people. That to me is a travesty.

Even the agile advocates wouldn’t say that agile is necessarily the best thing to use everywhere. The point is: the team doing the work gets to decide how to do it. That is a fundamental agile principle, which means that if a team doesn’t want to work in an agile-way, then agile probably isn’t appropriate in that context. And that is the most agile-way of doing things.

I can’t help be nod my head in agreement with Dave’s summary: “Fowler’s perspective and patience with the Agile Industrial Complex gives me a foothold to keep from falling into hopelessness.”

While specifically targeted at designers and the design industry, I thought this was a rather (comedic) talk on the culture of the technology at large. It’s kind of written in the spirit of the old tale “The Emperor’s New Cloths”, a way of saying “look at these moments in your professional life and realize that nobody is wearing any clothes”.

A couple quotes I liked:

that’s the spirit of the creative: always carrying that soul-crushing insecurity

the more buzzwords you use, the less you have to explain your actual design thinking.

“empathy map”, “user journey maps”, we’re kinda crazy about maps, I don’t know what it is, probably because we’re lost [as an industry].

A great, visually-instructive talk about the event loop and how your JavaScript actually gets executed by the browser. He has some great examples of gotchas that are worth wrapping your head around. Like this one: if the user clicks the button, in what order are things logged?

button.addEventListener('click', () => {
        Promise.resolve().then(() => console.log('p1'));
        console.log ('1');
      });
      button.addEventListener('click', () => {
        Promise.resolve().then(() => console.log('p2'));
        console.log('2');
      }):
      

His descriptions of tasks, animation callbacks, and micro tasks, from the perspective of the browser, were all eye opening. Great talk for anyone doing JavaScript.

Not a talk about software, but has some good insights into what makes a great leader:

The conductor of an orchestra doesn’t make a sound. He depends for his power on the ability to make other people powerful...I realized my job is to awaken possibility in other people...

He says the way you can tell if you’re awakening possibility in other people is by looking into their eyes. And if someone’s eyes aren’t reflecting that awakened possibility, then you have to ask:

Who am I being that my player’s eyes are not shining?

And that can extend to anyone in your sphere of influence: “who am I being that my [children’s / employees’ / friends’] eyes are not shining?”

I thought this was a really great presentation around how to be effective building software.

If you have a rockstar and everyone on the team is deferring to the rockstar, you have fewer people on your team taking initiative. If you have a team of 10 people and 9 of them, when you ask a question, just turn to look at the senior dev to see what their solution is, you’ve just lost 9 brains worth of thinking power.

You have to ask yourself:

What are the underlying problems that created the need for a rockstar to come in and fix everything?

He makes a point about how code reviews get a bad rap because a lot of teams only conduct code reviews when something is wrong:

Code reviews are a chance for the lead developer to flog someone in the public square because they did something that, I don’t know, was a memory hog. That is not what a code review should be. I think that code reviews should mostly be when someone does something that you like. Pull it up in front of the entire team and walk through what they did right. Then talk about all the other ways it could’ve been written that wouldn’t have been optimal. Show what the anti-pattern could’ve been, and praise what was done.

[As a senior developer] You should be constantly failing in front of your team then showing them how you learn from your mistakes, because that’s how you got where you are — that’s how you became a senior developer.

A really good point on thinking about longevity in the things you build:

Use stable open source tools if that option exists because if you build something in house you are now saying “this tool, in addition to our product, is something that we need to maintain and staff.”

Write code that’s small and easy to delete...when you optimize for deletion, you don’t have to write code that’s valid five years in the future...[google scale] you should be building features for 500 rather than optimizing for 5 million...weight the tradeoffs and choose the thing that will make your team more productive, not the thing that will make your app best in ten years.

About the first twenty minutes of this talk (before he gets into the Brittian-specific stuff) is absolutely fantastic.

Education should prepare young people for jobs that do no yet exist, using technologies that have not yet been invented, to solve problem of which we are not yet aware.

His main point is that we (in computers) often put too much focus on technology and not enough on ideas. He showed this really cool video about how you could illustrate sorting algorithms to kids without using any technology. His point is that we need more that encourages inquisitiveness and imagination.

He also makes good arguments about why we should teach “computer science” (again, ideas not technology) to kids. Technologies come and go, but the underlying ideas persist:

Why do we teach biology to kids? Do we expect every kid to become a biologist? No. It’s about coming to understand the world you live in and how you can navigate it, how to take control of events in your life and not just be at their mercy.

Education shouldn’t be about teaching a skill and splitting someone out at the end who is armed with that skill. Rather we teach skills or reason and dedication and problem solving so that when they get spit out, they can navigate the successive waves of technology that will come at them over their careers. Knowing one won’t be enough.

The path to success is through not trying to succeed. To achieve our highest goals, we must be willing to abandon them.

In a lot of ways, that’s the premise of this talk. And I, for one, thought his points resonated a lot with my own experiences of creativity. There’s quite a few paradoxical findings here.

Jobs responding to a question/insult about a particular technology. I think his response is a good reminder that before any technology, you need vision and principles for what you’re doing. Those will guide you more than any technology. In fact, focusing too much on just what’s going on with the tech can often blind you to the potential of what you’re trying to do.

As we have tried to come up with a strategy and a vision for Apple, it started with “what incredible benefits can we give the customer, where can we take the customer?” not starting with “let’s sit down with the engineers and figure out what awesome technology we have and how we are going to market that?” And I think that’s the right path to take.

The principles of this talk are illustrated by code examples of BASH, but I think they are general enough to apply to any programming language. The speaker walks you through his own personal thought process and techniques for understanding and refactoring a piece of code which he did not write himself.

I️ found many useful ideas from his own personal techniques that I’d like to try. His overall goal is to make the code easy to understand and comprehend at a glance. He does this by breaking things up into really small function chunks, so you end up with something like:

// Top of file
      DoThing();
      DoAnotherThing();
      DoLastThing();
      
      // Underneath main execution are the declarations
      function DoThing() {...}
      function DoAnotherThing() {...}
      function DoLastThing() {...}
      

I also enjoyed this quote around the ~11:30 mark:

Programming is not a moral debate. We’re not talking about evil and good. We’re talking about a process of programming. “Writing terrible code” is probably a misnomer. That so called “terrible code” is code that is experimental and trying to prove something. That’s fine. Prove it. Understand it. Get it to work. Learn from it. Then make it clearer. Make it better. As needed.

Just happened to be listening to some Cake the other day and the song “No Phone” came on. To be honest, I kind of sat marveling that this song was written in 2003, way before smartphones came along. Seems incredibly prescient. Here’s some lyrical excerpts:

No phone No phone I just want to be alone today
...
Ringing stinging
Jerking like a nervous bird
Rattling up against his cage
Calls to me throughout the day
...
No phone No phone I just want to be alone today
...
Rhyming chiming got me working all the time
Gives me such a worried mind
...
No phone No phone I just want to be alone today
...
Shaking quaking
Waking me when I'm asleep
Never lets me go too deep
Summons me with just one beep
The price we pay is steep
...
My smooth contemplations will always be broken
My deepest concerns will stay buried and unspoken
...
No phone No phone I just want to be alone today

Generally enjoy these talks by Rich Hickey, even though a lot of the time he’s talking about programming concepts beyond my understanding. What I do enjoy is his ability to describe problems in mainstream programming and ask “Wait, why are we doing this? We’re making things so hard for ourselves!”

Here’s just one quote I enjoyed from his talk:

When you look at programming languages, you really should look at: what are they for? There’s no inherent goodness to programming languages. Only suitability constraints.

An interesting overview on the state of React and where it’s headed, especially in regards to React Fiber and its “cooperative multitasking” feature.

The speaker does a really good job explaining the current problem React has due to the single-threaded nature of Javascript, which essentially boils down to this: it doesn’t matter how efficient your code is if you end up scheduling a lot of it in an uninterrupted sequence. React Fiber attempts to solve this through a more asynchronous approach to component rendering.

It’s an interesting look at where we are with React and where we might go in the future.

Some thoughts about the direction of JavaScript, specifically how to remove redundant constructs of today’s javascript from the language and leave ourselves with fewer methods of expression. You might think having fewer methods of expression would be a bad thing, but he argues that fewer is actually better because it lowers the cognitive dissonance you encounter when running into two things that are mostly similar but not identical, which you then have to expend mental energy differentiating (he illustrated this with an analogy to purging your life of things, which I thought was interesting). It’s a parallel for Garrett’s law, which goes something like this: if two things are similar, either 1) accentuate the differences and make them more different, or 2) eliminate the differences and make them identical.

Here are some examples of changes the speaker recommended:

• Tabs vs. Spaces
  • Get rid of tabs. Not because spaces is “better” but because we have two things doing the same thing. Let’s simplify. And since we can’t get rid of spaces, tabs has to go.
• Double Quote " vs. Single Quote '
  • Get rid of single quotes (as it’s already overload in use as an apostrophe) to do things like encapsulate strings and use double quotes exclusively.
• null vs undefined
  • Get rid of null as an empty pointer and use undefined solely (he recommends leveraging null in the future as an empty object).

He goes into depth on other idiosyncrasies of JavaScript and how he would fix them. Things like what 0 / 0 should equal and why (0.1 + 0.2 === 0.3) returns false. It was an interesting talk and I found the metaphor for removing clutter from your life an interesting parallel to the argument for removing redundancies from the langauage of JavaScript. Obviously you can’t just remove them now, but from a perspective of personal code writing, it’s an interesting argument I may try out in practice.

Two important questions when building software:

1. How well does it work?
2. How well does it fail?

Great example with CSS shapes. In browsers that don’t support it, if you use it, you just get a regular fallback.

Service workers are another good example. When somebody loads your webpage for the first time, they download images, html, css, etc, and a service worker. Then on any subsequent request, the service worker does it’s work. Note that every browser, the first time your page is loaded, doesn’t support service workers because they haven’t been downloaded yet. So you start out building under the assumption that your site doesn’t have a service worker, then you enhance from there.

It’s a really good way to build your UI’s, by building them around failure cases.

In my search for stuff to listen to, I Google’d “the best programming talks” and this was one I stumbled on in a comment thread somewhere out there on the internet.

As I’m not a real computer programmer (but as Pinocchio said, maybe someday) I like to find talks that take a broader perspective and explore principles applicative to any discipline, be it programming, design, or maybe just woodworking. This talk had some of that, thought it was also quite technical at times. Anyhow, I wanted to just make some notes on the tidbits I liked (the slides from the talk can be found here).

Implementation Should Not Impact API

Don’t let implementation details “leak” into API

I think this stood out to me most because it’s something I’ve seen happening a lot at my current job: the technical details of a particular service or API has leaked into a user-facing product and become a mental model for both internal employees and external customers. The problem with this, as the speaker points out, is that it inhibits the freedom to change the implementation in the future because people depend on it.

Names Matter

Around minute 31 he talks about how your API is a little language unto itself. You should be consistent and regular where terminology is largely self-explanatory. If you succeed in naming things consistently and simply your code can end up reading like prose, which is generally an indicator of a well-designed API, i.e.

if (car.speed() > 2 * SPEED_LIGHT) {
        speaker.generateAlert('Watch out for cops!');
      }
      

Using Conventions

Around minute 39 he started talking on how you should borrow conventions from existing languages and platforms. Some of his points included:

• Obey standard naming conventions
• Mimic patterns in core APIs and language
• Don’t transliterate APIs

His point, which I think can be generalized to any profession, is that if you build with concepts people are already familiar with, it can lend simplicity to your product. If somebody knows how to use a native convention in a programming language or ecosystem, they’ll know how to use yours. But don't transliterate he says. If you’re building for C, don’t learn everything about C’s way of doing X and mirror that to your tool. Plus what was correct in C may not be correct for your particular implementation. It’s good to step back and ask “what is this trying to do?”.

specialization generally leads to optimization, not innovation

Though this talk was targeted at rails developers, I couldn’t help but see the parallels to front-end javascript developers.

npm install hairball

Is that simple or easy? It's easy — easy to get that complexity. Perhaps it was simple to get a hairball, but now you have to deal with that hairball and inevitably down the line that's complex.

If you want everything to be familiar you’ll never learn anything new.

Just a cool video about craftsmanship. I love how the philosophy behind the craftsmanship is what drives the work forward, not the data behind the product.

Jackson Browne, an American singer-songwriter who’s been inducted into the Rock-n-Roll hall of fame, did an interview around his newest album Standing in the Breach and revealed a few nuggets about the creative process of making his album which I found relevant to any kind of creative process in general.

One of the first questions the host asked was if he had a personal favorite track on his record. He responded:

No I like them all. Each one of them, at one time or another, has been my favorite song. That’s what it takes to finish them, they have to be something I’m really interested in...[my] songs aren’t always finished when I start recording them. I may just rewrite a verse, or I may actually take something out. It’s a process of exploring. I want to know what the song is capable of doing musically before I finish the subject in terms of lyrics. Nothing’s worse that writing too many verses and having to throw some out. You know, if you find out you don’t really want to hear two verses before the chorus but you’ve already setup the narrative. That’s happened a couple times, where I songs just on the acoustic guitar but when I started to play it with a band I realized “I don’t want to hear another verse, I want to [go right into the chorus]”. I’m always rewriting but I don’t like to throw things away.

That last sentence of his is great: always rewriting, refining, simplifying, making better, making more concise yet impactful and deep. Great stuff.

Later in the interview he talks about his relationship with his album producer how well they work together and compliment one another:

We’re a perfect match because he’s a good engineer but he’s got infinite patience. I’m a neophite, in a recording I’m not technical at all, so I need someone to sit there with me while I think about what I want to think about and who doesn’t engage me with what he wants to do, but just does what he wants to do. Some engineers are ambitious and want to talk about what they want to do, “I’m going to do this, I’m going to do that, can we do this?”. I need somebody that’s much more...patient. Someone who’s almost passive and who will allow me to move things around and turn the balances upside down. And things may remain out of balance for long periods of time and then [i’ll bring them back]...In a funny way, we’re bystanders to each others’ work.

I love this idea he expresses about allowing yourself (and having your producer, co-worker, boss, etc. allow you) to put things out of order to discover possibilities so when you arrive at the final product, you know there’s no other way the thing could be because you’ve explored all possible permutations.

In this same vein of continually exploring possibilities, the host asks if it’s hard for him to release songs because, at that point, the song would officially be considered “finished”:

It’s a bit of an acquired skill to know when a song is done because it’s very easy to keep going and keep adding things because it’s interesting, it’s fun. In a way you’re never done. The song is going to continue to grow after the album too, you just have to know how far you can go with this particular recording.

At the end of the interview, the host opens the discussion to questions from the audience. A guest in the crowd asked him how he remembers and tracks his half-baked ideas. He answers by talking about how he keeps track of snippets on his iPhone which helps him a lot because sometimes he remembers the idea of a song better than it actually was, like “oh yeah I was working on this thing that was really great” and then he’ll look up the snippet on his phone and realize “oh wow, that actually wasn’t very good” but that bad idea can spur other good ideas:

Most of my ideas come from mistakes that interest me...I could disappear into my music room with some of my recordings and make a bunch of songs out of the boxes and boxes of my recordings because each of them represents a moment when I thought I was doing something of value or interesting.

Love that first sentence: “most of my ideas come from mistakes that interest me”. That’s why you shouldn’t be afraid of anything you’ve done in the past. It’s all experiential fodder for good things in the future.