Software Engineering Ideas That Influence Me

I watch a lot of conference talks on YouTube and I read a lot of software engineering articles. Some of that media has really helped me become a better engineer. As a relative newcomer to engineering, I know my style will develop further and my current judgment of "best practice" will change (and I can see how it's changed historically by looking at my old code), but I plan to read/watch these resources every year. I look forward to future me gaining new perspective on them.

I've tried to categorize these links, but naturally there's some overlap :)

In some cases, I'll remove links if I feel like I can expand the concept into a separate blog post and link from that.

Workflow

General Concepts / Ideas

  • The Grug Brained Developer - This is an excellent list of somewhat disconnected advice about how to manage complexity in code, tests, and what works and what doesn't work, even though it looks nice on paper.
  • The Mathematical Hacker: Evan Miller argues here that math is a tool for understanding the world, and that programmers should use it to do a lot of the heavy lifting. It's a bit of a reality check to some of my "well I can add this thingie here, and won't that be elegant" daydreams. Code is to solve a problem, and most of the harder problems are best solved mathmatically and simply transcribed as code.
  • Hammock Driven Development: Rich Hickey: Lectures like this are hard to come by. Rich Hickey gives wonderful tips on how to solve hard problems. The main one is that it can take a lot of time and conscious/unconscious thought to get an elegant solution.
  • Semantic Compression: This post (and the rest of the series) have really helped me to grasp the "semantic compression" concept Casey uses here. I can actually trace its influence on my thought process through my historical code.

Architecture

Data oriented design

I don't actually write a lot of explicitly data oriented designed programs (most of my code is probably best categorized as "automation" or "web software", which don't require this level of performance) but man there are some great talks about it!! Data-oriented design originated in game programming, but some compiler teams have taken hold of it.

Using Types for Correctness

There's a lot of repetitiveness here, but I think seeing concepts explained in different ways with different examples can be very helpful.

How to Debug

This is a mix of debugging advice as well as "war stories" for examples

Observability

This is mostly focused on OpenTelemetry, since I really like the "protocol over specific vendors" approach they provide:

Testing / Formal methods

Platforms

Specific Concepts / Ideas

  • Against unnecessary databases - This seems obvious in hindsight. However, I often get too eager to transform my data as I'm ingesting it and pay the price (difficult to understand, change, and test) later.
  • John Carmack: Best programming setup and IDE | Lex Fridman Podcast Clips - YouTube - In this interivew with Lex Friedman, John Carmack really makes a good case for getting really familiar with IDEs and debuggers instead of using text editors like Vim without language-aware tools. It has inspired me to be much more aggressive about learning the ins and outs of what VS Code (especially the debugger) can offer me. These days I have a hard time memorizing NeoVim's shortcuts and endlessly updating plugin ecosystem anyway. Also see Why an IDE?.
  • What the heck is the event loop anyway? | Philip Roberts | JSConf EU - YouTube is THE BEST explanation I've found on how async/await works. I need to refer back to it when I do anything somewhat complicated with async/await.
  • John Carmack on Inlined Code: This John Carmack article talks about the benefits of inlining code that's only going to be called once. It also links to another functional programming article and you can follow that rabbit hole for far longer than you originally intended (don't ask me how I know that).
  • How To Survive Your Project's First 100,000 Lines - a very nice checklist of specific tips on scaling a project.
  • The Worst API Ever Made: This is a rather hilarious post that really emphasizes how, when architecting a program, you should write the usage code first, so your users don't hate their experience with your API.
  • HTML First - this site explains how to build frontends with HTML first, instead of large JavaScript dependencies. I want to do this primarily because I think it's more maintainable.
  • Write code that is easy to delete, not easy to extend - really good article about how locking into an architecture too early can hurt you, and when it's worth it.

Example Code

These are libraries that have really impressed me with their usability; whatever they're doing, I want to emulate it!

Example Stories