stuff tagged with "engineering"

Big O

🔗 a linked post to samwho.dev » — originally shared here on 2025-08-23

Big O notation is a way of describing the performance of a function without using time. Rather than timing a function from start to finish, big O describes how the time grows as the input size increases. It is used to help understand how programs will perform across a range of inputs.

In this post I'm going to cover 4 frequently-used categories of big O notation: constant, logarithmic, linear, and quadratic. Don't worry if these words mean nothing to you right now. I'm going to talk about them in detail, as well as visualise them, throughout this post.

I have a minor in computer science, and I remember sitting through many explanations of the importance of Big O notation, yet it hasn’t really mattered much in my career until recently.

If you have heard of Big O but aren’t clear on how it works, give this post a shot. It contains a lot of great visualizations to help drive the point home.

The Curse of Knowing How, or; Fixing Everything

🔗 a linked post to notashelf.dev » — originally shared here on 2025-05-06

Too many bangers to pull out of this one. Well worth a full read. But here are a couple juicy pull quotes to whet your pallette:

Programming lures us into believing we can control the outside events. That is where the suffering begins. There is something deeper happening here. This is not just about software.

I believe sometimes building things is how we self-soothe. We write a new tool or a script because we are in a desperate need for a small victory. We write a new tool because we are overwhelmed. Refactor it, not because the code is messy, but your life is. We chase the perfect system because it gives us something to hold onto when everything else is spinning.

I’m trying to let things stay a little broken. Because I’ve realized I don’t want to fix everything. I just want to feel OK in a world that often isn’t. I can fix something, but not everything.

You learn how to program. You learn how to fix things. But the hardest thing you’ll ever learn is when to leave them broken.

And maybe that’s the most human skill of all.

Experience Doesn't Stack: The Myth of Collective Knowledge

🔗 a linked post to joanwestenberg.com » — originally shared here on 2025-05-05

We should stop worshipping numerical comfort. Twenty partial views don’t make a whole picture. They make noise. They make an echo. They create professionalized, sanitized, panel-approved blindness.

If you're lucky enough to know someone with twenty years of scar tissue in a domain, listen. Don't just ask what they know. Ask what they've unlearned. Ask what they stopped saying because nobody understood. That's where the signal lives.

“Worshipping numerical comfort” is a fantastic phrase that I’ll be pondering here for the next few days.

AI assisted search-based research actually works now

🔗 a linked post to simonwillison.net » — originally shared here on 2025-04-21

I’m writing about this today because it’s been one of my “can LLMs do this reliably yet?” questions for over two years now. I think they’ve just crossed the line into being useful as research assistants, without feeling the need to check everything they say with a fine-tooth comb.

I still don’t trust them not to make mistakes, but I think I might trust them enough that I’ll skip my own fact-checking for lower-stakes tasks.

This also means that a bunch of the potential dark futures we’ve been predicting for the last couple of years are a whole lot more likely to become true. Why visit websites if you can get your answers directly from the chatbot instead?

The lawsuits over this started flying back when the LLMs were still mostly rubbish. The stakes are a lot higher now that they’re actually good at it!

I can feel my usage of Google search taking a nosedive already. I expect a bumpy ride as a new economic model for the Web lurches into view.

I keep thinking of the quote that “information wants to be free”.

As the capabilities of open-source LLMs continue to increase, I keep finding myself wanting a locally-running model at arms length any time I’m near a computer.

How many more cool things can I accomplish with computers if I can always have a “good enough” answer at my disposal for virtually any question for free?

The Best Programmers

🔗 a linked post to justin.searls.co » — originally shared here on 2025-04-15

The single best trait to predict whether I'm looking at a good programmer or a great one is undoubtedly perseverance. Someone that takes to each new challenge like a dog to a bone, and who struggles to sleep until the next obstacle is cleared.

Today (literally today), I delivered the final story for the third project I’ve had at my day job since starting back in October.

This project involved a lot of unknowns and uncertainties, and resulted in a ton of code that was written and thrown away in order to arrive at the final stab at version 1.

It was painful. Ask my wife and she’ll tell you I spent many days in doubt, riddled with anxiety and impostor syndrome, feeling like a fraud.

But then, just like that, I’m able to click the “squash and merge” button, and it’s done. The clouds lift. It’s incredible.

Sort of reminds me of Courtney Dauwalter’s pain cave metaphor. Every time I start an engineering project, I go into the pain cave and start chiseling away at the walls.

Once I’ve chiseled enough, I am rewarded by stepping back out of the cave and celebrating what I’ve built. It’s an incredible feeling.

It’s a short lived euphoria, though. I only get a few moments before I dust myself off, grab a quick bite to eat, and begin my descent back into the cave to start chiseling away on the next project.

AI ambivalence

🔗 a linked post to nolanlawson.com » — originally shared here on 2025-04-03

Maybe, like a lot of other middle-aged professionals suddenly finding their careers upended at the peak of their creative power, I will have to adapt or face replacement. Or maybe my best bet is to continue to zig while others are zagging, and to try to keep my coding skills sharp while everyone else is “vibe coding” a monstrosity that I will have to debug when it crashes in production someday.

I enjoyed this piece because I think it represents the feelings I hear from artists. You might not consider computer programming an art form, but if art is humans expressing themselves, then writing code absolutely qualifies.

And like a lot of other artists, many of us "computer people” make money by doing our art for other people. It turns out that for the last fourty years, we could do our art for other people and we'd get paid quite well to do so.

But now that anyone can basically vibe code solutions to basic problems¹, a increasing set of non-nerds is able to use computers themselves. That naturally will drive down our value.

I use "value" here in a cold, hard, capitalistic sense. Maybe it's our turn, as artists who care about making efficient, beautiful, artistic computer programs, to worry about how we'll derive value in a world where anyone can vibe code their ideas to life.

Refactoring to understand and "vibe coding"

🔗 a linked post to seangoedecke.com » — originally shared here on 2025-03-15

If you want to onboard someone onto a new codebase, let them rewrite part of it. They’ll learn a lot from the process, but crucially they’ll become an instant subject-matter expert on the part they rewrote. With a few refactors, you can go from a situation where you’re the only go-to engineer to a situation where multiple engineers on the team can take ownership. That’s the only sustainable way to run a large codebase.

This is exactly what I’ve been doing at work for the last six months, and now I’m the subject matter expert on a small number of essential components of the system.

These sneaky buggers… ?

How I know I'm working with a strong engineer

🔗 a linked post to seangoedecke.com » — originally shared here on 2025-02-24

I realised the other day that I actually have a straightforward heuristic for this. I count the number of times I have this thought:

“Oh nice catch, I didn’t think of that!”

Man, Sean’s been on an absolute tear lately with these observations. Definitely worth an RSS feed add if you’re into software engineering.

Seven things I know after 25 years of development

🔗 a linked post to zverok.space » — originally shared here on 2025-01-30

This post deeply resonates with me.

Never give up seeking truth, however uncomfortable it is. Search for knowledge. Adjust your worldview. Ask. Rewrite outdated code. Drop faulty hypotheses and unreliable foundations.

Software author is, first of all, a writer. They are a person who stands upright and says: “that’s what I know for now, and that’s my best attempt to explain it.” Having this stance, preferring it to everything else, and hiding behind terms, concepts, and authority are invaluable qualities for long-term project success.

Or, basically, for any long-term human activity success.

Working fast and slow

🔗 a linked post to seangoedecke.com » — originally shared here on 2025-01-26

When I’m in the zone, problems seem more straightforward. Even complex tasks feel pretty doable. Once I notice that, I try to pack my time with high-priority work only. I’ll put off responding to all but really important messages (Slack’s “remind me later” is a great feature). I also try as hard as I can to avoid multi-tasking, so I can keep my entire attention on getting a single task right at a time. If I feel like continuing to work through the evening, I let myself do that, knowing I’ll give myself the time back the next day or the one after that.

When I’m not in the zone, every task seems complex and rife with booby-traps. I feel like I have to proceed defensively and avoid taking risks. On days like these, I try and knock out easy wins and don’t worry so much about prioritization. I do a lot of general talking and bouncing between multiple projects. I don’t feel so bad about stopping work earlier than usual, knowing that at some point I’ll make it up with a period of hard focus

I’ve been reading Sean Goedecke’s blog for a few weeks now, and it is exceptionally helpful to hear these words at this point in my career.

This post spoke to me because I’m working on a project at work where it’s been hard to achieve flow for consistent periods of time.

I’m sharing this to remind myself that it’s okay to have rough days, and the important thing is to be honest with yourself and show up every day, even (especially?) if you don’t want to.

My latest self-improvement experiment is determining what environmental factors will induce flow. I can’t seem to find the right album, the right physical space, the right combination of stimulants and exercise, the right amount of “small wins”, whatever it might be to help trigger the excitement that comes when I get into flow.

The most consistently successful approach has been to completely accept my current situation and problem solve as best I can in that exact moment. In other words, I ask myself: how can I win this moment?

Withered Technology

🔗 a linked post to lmnt.me » — originally shared here on 2025-01-22

Though Nintendo employs more-modern technologies now, they are still criticized for not having the most-modern technologies that their rivals are all-too-happy to include, often at the cost of compatibility, affordability, and energy efficiency.

This is not a condemnation of using cutting-edge technology. But if given the choice, I prefer “lateral thinking with withered technology.” I think that’s a great philosophy to consider when making anything.

“Lateral thinking with withered technology” is how I approach building websites. Use battle-tested, slow moving frameworks that don’t depend on a cornucopia of vulnerable third party plugins. :cough cough wordpress react cough sneeze:

HTML and CSS are going nowhere, and vanilla JS can do virtually anything you need these days. Render your stuff server side and keep the client side lightweight.

Can you complete the Oregon Trail if you wait at a river for 14272 years: A study

🔗 a linked post to moral.net.au » — originally shared here on 2025-01-13

Two years ago, Twitch streamer albrot discovered a bug in the code for crossing rivers. One of the options is to "wait to see if conditions improve"; waiting a day will consume food but not recalculate any health conditions, granting your party immortality.

From this conceit the Oregon Trail Time Machine was born; a multiday livestream of the game as the party waits for conditions to improve at the final Snake River crossing until the year 10000, to see if the withered travellers can make it to the ruins of ancient Oregon. The first attempt ended in tragedy; no matter what albrot tried, the party would succumb to disease and die almost immediately.

Filed under “reasons I love the Internet.”

Mistakes engineers make in large established codebases

🔗 a linked post to seangoedecke.com » — originally shared here on 2025-01-06

As a general rule, large established codebases produce 90% of the value. In any big tech company, the majority of the revenue-producing activity (i.e. the work that actually pays your engineering salary) comes from a large established codebase. I’ve seen multiple cases where a small elegant service powers some core feature of a high-revenue product, but all the actual productizing code (settings, user management, billing, enterprise reporting, etc) still lives in the large established codebase.

So you should know how to work in the “legacy mess” because that’s what your company actually does. Good engineering or not, it’s your job.

This was a great read as I’ve been immersed inside a large (but not too large) codebase at my new gig for the past few months now.

It’s funny: I never wanted a job as an engineer. But it turns out I kinda actually like this work? ?

Write code with your Alphabet Radio on

🔗 a linked post to vickiboykis.com » — originally shared here on 2024-12-29

Nothing is black and white. Code is not precious, nor the be-all end-all. The end goal is a functioning product. All code is eventually thrown away. LLMs help with some tasks, if you already know what you want to do and give you shortcuts. But they can’t help with this part. They can’t turn on the radio. We have to build our own context window and make our own playlist.

When LLMs can stream advice as clearly and well as my Alphabet Radio, then, I’ll worry. Until then, I build with my radio on.

A significant contributor to my depression last year was a conviction that LLMs could do what I could do but better.

I’m glad I’ve experimented with them heavily over the past couple years, because exposure to these tools is the only real way to understand their capabilities.

I use LLMs heavily in my job, but they are not (yet) able to replace my human teammates.

OAuth from First Principles

🔗 a linked post to stack-auth.com » — originally shared here on 2024-12-17

I’ve implemented OAuth in both directions, and I still learned something new from reading this article about how OAuth works.

Reckoning

🔗 a linked post to infrequently.org » — originally shared here on 2024-12-17

Canadian engineers graduating college are all given an iron ring. It's a symbol of professional responsibility to society. It also recognises that every discipline must earn its social license to operate. Lastly, it serves as a reminder of the consequences of shoddy work and corner-cutting.

I want to be a part of a frontend culture that accepts and promotes our responsibilities to others, rather than wallowing in self-centred "DX" puffery. In the hierarchy of priorities, users must come first.

What we do in the world matters, particularly our vocations, not because of how it affects us, but because our actions improve or degrade life for others. It's hard to imagine that culture while the JavaScript-industrial-complex has seized the commanding heights, but we should try.

And then we should act, one project at a time, to make that culture a reality.

Algorithms we develop software by

🔗 a linked post to grantslatton.com » — originally shared here on 2024-11-12

I started a new job as a software engineer last month.

It’s the first job I’ve ever had where all I need to do is write code. I don’t need to worry about finding customers, protecting the company from lawsuits, ensuring the product is the correct product to build, or making payroll.

All I need to do is write code.

This is the first time in my career where I can actually focus on the art of writing good code.

I came across this article from Simon Willison’s blog, and boy, there are a lot of great pieces of advice for folks in my position here.

As a junior engineer, there's simply no substitute for getting the first 100K lines of code under your belt. The "start over each day" method will help get you to those 100K lines faster.

You might think covering the same ground multiple times isn't as valuable as getting 100K diverse lines of code. I disagree. Solving the same problem repeatedly is actually really beneficial for retaining knowledge of patterns you figure out.

You only need 5K perfect lines to see all the major patterns once. The other 95K lines are repetition to rewire your neurons.

making things better

🔗 a linked post to explaining.software » — originally shared here on 2024-10-24

Tradeoffs exist; improving one aspect of a system can make other aspects worse. As projects grow, our control over them shrinks. Ugly truths abound, and beauty is a luxury we can rarely afford.

Knowing this, however, does not mean accepting it. Confronted with this dissonance, this ugliness, we inevitably gesture towards a better future. We talk about better design, better practices, better processes. We await better abstractions. We imagine a world in which we cannot help but make something beautiful.

This belief in the future, in an unending ascent towards perfection, is a belief in progress. The flaws in this belief — its internal tensions, the fact that it is closer to a theology than a theory — have been pointed out for centuries. It is, nevertheless, an inescapable part of the software industry. Everything we do, whether design or implementation, is oriented towards an imagined future.

This is a beautiful sentiment about software systems which could easily apply to most any system (like, our political and social systems, for example).

This Post Is Not About Python

🔗 a linked post to jerf.org » — originally shared here on 2024-10-10

Engineers are not fans of technologies.

They are also, of course, not dispassionate Vulcans who get every assessment perfectly rationally correct at all times, trivially proved by how much even relatively rational engineers can disagree with each other.

But engineers should never be fans.

There was a moment not too long ago where I closely followed every single Apple rumor, watched every single keynote, and could tell you the names of every single executive.

It’s mid-October and I’m still not exactly sure when Apple intelligence is coming to my iPhone 15.

Maybe part of growing up is being less fanatical about tools and more fanatical about solving problems.

Why We Can't Have Nice Software

🔗 a linked post to andrewkelley.me » — originally shared here on 2024-09-18

The problem with software is that it's too powerful. It creates so much wealth so fast that it's virtually impossible to not distribute it.

Think about it: sure, it takes a while to make useful software. But then you make it, and then it's done. It keeps working with no maintenance whatsoever, and just a trickle of electricity to run it.

Immediately, this poses a problem: how can a small number of people keep all that wealth for themselves, and not let it escape in the dirty, dirty fingers of the general populace?

Such a great article explaining why we can’t have nice things when it comes to software.

There is a good comparison in here between blockchain and LLMs, specifically saying both technologies are the sort of software that never gets completed or perfected.

I think it’s hard to ascribe a quality like “completed” to virtually anything humans build. Homes are always a work in progress. So are highbrow social constructs like self-improvement and interpersonal relationships.

I think it’s less interesting to me to try and determine what makes a technology good or bad. The key question is: does it solve someone’s problem?

You could argue that the blockchain solves problems for guaranteeing the authenticity of an item for a large multinational or something, sure. But I’m yet to be convinced of its ability to instill a better layer of trust in our economy.

LLMs, on the other hand, are showing tremendous value and solving many problems for me, personally.

What we should be focusing on is how to sustainably utilize our technology such that it benefits the most people possible.

And we all have a role to play with that notion in the work we do.

Writing Javascript without a build system

🔗 a linked post to jvns.ca » — originally shared here on 2024-09-09

I make a lot of small simple websites, I have approximately 0 maintenance energy for any of them, and I change them very infrequently.

My goal is that if I have a site that I made 3 or 5 years ago, I’d like to be able to, in 20 minutes:

• get the source from github on a new computer
• make some changes
• put it on the internet

But my experience with build systems (not just Javascript build systems!), is that if you have a 5-year-old site, often it’s a huge pain to get the site built again.

I have websites that I made in middle school that I’m able to get up and running in roughly as much time as it takes to find the old folders.

I also have websites that I am unable to run on my new laptop because the dependencies are too out of date and now supported on my new architecture.

What Is React.js?

🔗 a linked post to briefs.video » — originally shared here on 2024-09-03

In summary:

• Facebook is a [redacted] company with a terrible web interface.
• React is a technology created at Facebook to administer its interface.
• React enables you to build web applications and their interfaces the way Facebook does.
• I am not calling Facebook "Meta"
• JavaScript-first interfaces built on ecosystems like React’s are cumbersome and under-performing.
• React prevails because its evangelical proponents and apologists have convinced developers that Facebook’s success can be attributed to technological quality and not aggressive capitalism.

Over the past fifteen years, I feel like I’ve had a pretty good track record of knowing which technologies to pay attention to and which technologies to confidently let pass by me.

When React first dropped, I thought the setup process seemed so onerous and filled with so many dependencies that I slowly backed away and haven't really needed to look back.

It would be irresponsible of me to have zero experience in React, so of course I've inherited projects that others have started on top of it. But every time I jump into a React project, I feel like I’m Homer jumping into his unchlorinated pool.¹

The death of the [modified] developer

🔗 a linked post to newsletter.goodtechthings.com » — originally shared here on 2024-09-01

Perhaps we can define “junior developer” this way: it’s somebody who needs human supervision to accomplish the things a full-fledged member of the technical staff should be able to do using only AI assistance.

If we can’t make room in our taxonomy of technical work for someone who still needs human training, we are just doing the same old thing IT has been doing for decades: borrowing from our future to cash in on the current hype. AI, “chat-oriented programming”, whatever tomorrow’s buzzword is—they’re fascinating, they may be productivity enhancers, but they won’t remove the need for experienced human generalists in the loop.

And every experienced generalist starts out inexperienced. They start as a junior developer. That’s not where software engineering dies: it’s where it’s born.

Five Behaviours to Become an Effective Staff-Plus Engineer

🔗 a linked post to infoq.com » — originally shared here on 2024-08-19

This talk helped me articulate a few key arguments that I can use to counter myself when in the throes of impostor syndrome-related attacks from my inner monologue.

Basically, a “staff-plus engineer” is anyone in a technical role that is higher than a senior engineer. These are sometimes referred to as principal engineers, staff engineers, etc.

The big difference between staff-plus and individual contributor path is that an IC role is one you go down when you truly want to contribute as an individual, often acquiring such an expertise in a specific domain that you just do your thing alone.

A staff-plus role requires collaboration, often leading teams, but always being the lynchpin which helps be the voice of technical leadership across multiple teams.

The responsibilities of a staff-plus role include (probably) writing and (definitely) reviewing code, providing technical direction, mentoring and sponsoring other engineers, providing engineering context to non-technical people, and being involved in strategic projects which aren’t shiny but are critical to the success of an organization.

I think I came across this talk at a timely point in my career. I have been tasked with doing staff-plus engineering work ever since starting my first company, and it’s honestly the stuff I love the most.

I’m not a developer who loves to write code. I love writing code because it results in a tool that makes someone’s life easier. What brings me joy is in doing the discovery work needed to clearly articulate the problem and charting a course that’ll lead us to a solution.

The deskilling of web dev is harming the product but, more importantly, it's damaging our health

🔗 a linked post to baldurbjarnason.com » — originally shared here on 2024-08-16

Of course you’re having problems keeping up with everything that’s happening in web dev. Of course!

You’re expected to follow half-a-dozen different specialities, each relatively fast-paced and complex in its own right, and you’re supposed to do it without cutting into the hours where you do actual paid web development.

Worse yet, you’re not actually expected to use any of it directly. Instead you’re also supposed to follow the developments of framework abstractions that are layered on top of the foundation specialities, at least doubling the number of complex fields a web dev has to follow and understand, right out of the gate.

This is immense – an expectation so mind-boggling that we need to acknowledge just how remarkable it is that each of us has managed as well as we have.

This entire article is an excellent summary of the state of the software development industry from the perspective of a web developer. I think Baldur hit the nail on the head several times here.

I first learned Javascript from a book I got from the library somewhere around 1999. This predated XMLHttpRequest, debuting with IE5 in 2001, which literally enables every single subsequent Javascript framework out there.

In just the last ten years alone, I’ve worked with React, Typescript, Coffeescript, Vue, Angular, Backbone.js, Ember.js, Next.js, ES6, and maybe another dozen Javascript variants that I can’t recall right now… but I wouldn’t consider myself an expert in any of them.

Like Baldur says in this article, “framework knowledge is perishable.” I don’t want to spend all my time learning a framework which, if history is any indicator, will be obsolete in a few years.

The underlying Javascript knowledge, though, is not ephemeral. I can dig up webpages I built in fifth grade and render them in moments with ease on my modern day Macbook, whereas dashboards built on React from only five years ago can only be brought up if I spend an entire day setting up an environment with a billion dependencies.

I can do that because the vanilla Javascript that worked in IE5 still works great in any modern browser.

I do have to be a realist, though… the jobs out there today do require you to use these frameworks because the software pipeline is way more complex than it was in 2000. Frameworks provide a standarized way of building software within this modern landscape. For the record, I have no problem picking one up in the course of my work and figuring it out.

I wish more organizations would simpilfy rather than move towards increasingly complex ways of writing and delivering software. I feel like so much more value could be realized by paring back the staggering amounts of dependencies that these frameworks use. Codebases would be much thinner, deploy times would be faster, your footprint for potential security threats would be smaller, etc. etc.

Anyway, I also think the way he wraps up this article is grimly astute:

The tech industry will never be a genuinely free market as long as big tech companies are allowed to be as big as they are today.

What we have today is a centrally-planned economy by MBA sociopaths, operated as a looting ground for the rich.

It will never function on normal competitive, supply-and-demand market principles.

Because, even though a healthier market is the only thing that has a hope of a return to the fast-growing tech industry of prior decades, it would also require big tech companies to accept a smaller slice of the overall pie and allow new competitors to grow.

Why do that when you can strangle the market and keep the entire corpse for yourself?

Literally laughed out loud at “centrally-planned economy by MBA sociopaths.”

Everybody's Free (To Write Websites)

🔗 a linked post to sarajoy.dev » — originally shared here on 2024-07-17

Enbies and gentlefolk of the class of ‘24:

Write websites.

If I could offer you only one tip for the future, coding would be it. The long term benefits of coding websites remains unproved by scientists, however the rest of my advice has a basis in the joy of the indie web community’s experiences.

I love the reference to Wear Sunscreen, one of the great commencement speeches.

There is amazing advice and inspiration for building websites in here. It also reminded me of POSSE, meaning “Publish (on your) Own Site, Syndicate Elsewhere.”

All I Need to Know About Engineering Leadership I Learned From Leave No Trace

🔗 a linked post to jacobian.org » — originally shared here on 2024-07-13

I saw Simon Willison share this article and thought it was too good not to share it myself.

We respect wildlife in the wilderness because we’re in their house. We don’t fully understand the complexity of most ecosystems, so we seek to minimize our impact on those ecosystems since we can’t always predict what outcomes our interactions with nature might have.

In software, many disastrous mistakes stem from not understanding why a system was built the way it was, but changing it anyway. It’s super common for a new leader to come in, see something they see as “useless”, and get rid of it – without understanding the implications. Good leaders make sure they understand before they mess around.

Or, as the footnote succinctly puts it: “find out, then fuck around.”

This article also taught me about Chesterton’s fence, a principle that says “don’t destroy what you don’t understand”.

Comfortable with the struggle

🔗 a linked post to rachsmith.com » — originally shared here on 2024-07-12

I’ve known developers who’ve put up with the struggle with the expectation that one day it will go away: one day they’ll be an expert and never have to struggle again. This day never arrives, and so they bail out of the field.

Unfortunately, I don’t think the struggle ever goes away. I’ve been doing this professionally for 14 years now and I still have to deal with the struggle almost every work day.

If you can be comfortable with the struggle and build up your tolerance for it. If you’re able to sit in that moment and be okay without drama or a total crisis of confidence, I’m fairly sure you’re going to do just great.

The Struggle comes in multiple shapes and sizes too. Here is a short list of my experiences with The Struggle from this week alone:

• Impostor syndrome
• Anxiety about breaking a physical connector
• Frustration with unclear objectives
• Being overwhelmed by unfamiliar technologies
• Debugging something and being unable to find an answer

After 12 years of professionally dealing with The Struggle, I’m still able to handle many aspects of it, but my tolerance is quickly diminishing.

Dealing with The Struggle is much easier when you feel like there’s a reward for you at the end of it. Right now, I’m trying to restore my old iPod fifth gen with an SD card, and no matter what I do, I cannot get it to work right.

I’ve been all over forums, digging into the sixth and seventh pages of search results, desperately looking for clues as to why I’m not getting it to restore.

But I can picture myself playing that brick breaking game soon, and that first game is gonna be so much fun after all of this work.

A Stretch of Route 66 Will Play 'America the Beautiful' as You Drive to the Side

🔗 a linked post to popularmechanics.com » — originally shared here on 2024-07-03

Two years ago, the New Mexico Department of Transportation decided to spice up a particularly desolate stretch of Route 66 between Albuquerque and Tijeras by adding grooves in the road that will play music when you drive over them. If you drive the speed limit of 45 mph for the quarter-mile stretch, you can hear "America the Beautiful" play through the vibrations in your car's wheels.

Some delightful engineering here. I wonder what happens if you hit it at faster or slower speeds?

Choose Boring Technology

🔗 a linked post to mcfunley.com » — originally shared here on 2024-06-28

I saw this article referenced while reading Bill Mill’s recap of relaunching a website, which in and of itself is a delightful read for those of us who nerd out on large-scale system architectures.

I am almost certain I’ve read Dan’s piece on boring code before, but I wanted to share it here because it serves as a great reference for those of us who are sick of making bad tech stack decisions for bad reasons.

In particular, the ending here sums up my experience consulting with many different tech teams:

Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.

Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.

The teams which move the fastest are the ones who are aligned on a vision for what is being built.

Often, these teams hold a “strong opinions, loosely held” mentality where they decide what tools they’ll use, and they’ll use them until they no longer solve the problem at hand.

Put another way: in a business context, experimenting with your tooling is a huge organizational expense that rarely yields a worthwhile return on investment.

Your focus should be on what you are building rather than how you’re building it.

If you can use open source, you can build hardware

🔗 a linked post to redeem-tomorrow.com » — originally shared here on 2024-03-18

I’ve been dreaming of building my own electronics since I was a kid. I spent so many afternoons at Radio Shack, and even tried my hand at the occasional kit, with limited success. Every few years in adulthood, I’ve given it another try, observing a steady downward trend in difficulty.

I’m telling you: we’re at a special moment here. The labor savings of open source, the composability, the fun: all of it has come to hardware. You can build things that solve real problems for yourself. I first imagined my heat pump devices over a year ago, and I have been frustrated they didn’t exist every day since.

Now my dreams are real, and the largest energy consumer in the house can be automated and remotely controlled.

That’s amazing.

As soon as I gain employment again, the very first thing I’m buying is a 3D printer, and I’m gonna start building stuff.

I don’t quite know what yet.

But I’ll find something.

npm install everything, and the complete and utter chaos that follows

🔗 a linked post to boehs.org » — originally shared here on 2024-03-17

We tried to hang a pretty picture on a wall, but accidentally opened a small hole. This hole caused the entire building to collapse. While we did not intend to create a hole, and feel terrible for all the people impacted by the collapse, we believe it’s also worth investigating what failures of compliance testing & building design could allow such a small hole to cause such big damage.

Multiple parties involved, myself included, are still students and/or do not code professionally. How could we have been allowed to do this by accident?

It’s certainly no laughing matter, neither to the people who rely on npm nor the kids who did this.

But man, it is comical to see the Law of Unintended Consequences when it decides to rear its ugly head.

I applaud the students who had the original idea and decided to see what would happen if you installed every single npm package at once. It’s a good question, to which the answer is: uncover a fairly significant issue with how npm maintains integrity across all of its packages.

But I guess the main reason I’m sharing this article is as a case study on how hard it is to moderate a system.

I’m still a recovering perfectionist, and the older I get, the more I come across examples (both online like this and also in my real life) where you can do everything right and still end up losing big.

The best thing you can do when you see something like this is to pat your fellow human on the back and say, “man, that really sucks, I’m sorry.”

The worst thing you can do, as evidenced in this story, is to cuss out some teenagers.

Seabound: Charting a Course to Decarbonize Shipping

🔗 a linked post to collabfund.com » — originally shared here on 2024-03-15

Seabound’s carbon capture technology diverts a ship’s exhaust gas into a container full of small pebbles of calcium oxide, which chemically react with CO2 in the exhaust gas to form calcium carbonate. In other words, we make limestone onboard ships, effectively locking the CO2 into small pebbles. When the ship returns to port, we offload the limestone and either: 1) sell it for use as a building material, or 2) recycle the pebbles to separate the CO2 from the calcium oxide so that we can reuse the calcium oxide to capture more CO2 on another ship, and then sell the pure CO2 for clean fuel production or geological sequestration.

Our process is unique because we only capture the CO2 onboard and leave it locked in limestone, rather than trying to separate and liquefy the pure CO2 from the limestone onboard as well. These steps of separation and liquefaction are typically the most complicated, expensive, and energy-intensive for carbon capture technologies, which is why we’ve shifted them to shore where we can leverage economies of scale and land-based energy infrastructure.

This is the sort of solution I want to be a part of. How cool of a concept is this?!

Why The First Computers Were Made Out Of Light Bulbs

🔗 a linked post to youtu.be » — originally shared here on 2024-02-08

If somebody would’ve shown me this video when I was 12 or 13, I think computer programming would’ve been way easier for me to understand, and I think I would’ve been more motivated to stick with engineering school.

That being said, I’m glad I’m at a point in my life where it all now kinda makes sense why binary is a thing.

This whole video was a pleasant way to appreciate the ingenuity of people. It also fixed a core analogy of mine: it’s not that we tricked rocks into thinking, rather it’s that we tricked atoms into moving whichever direction we want.

Half-assing it with everything you've got

🔗 a linked post to lesswrong.com » — originally shared here on 2023-09-03

If you're trying to pass the class, then pass it with minimum effort. Anything else is wasted motion.

If you're trying to ace the class, then ace it with minimum effort. Anything else is wasted motion.

If you're trying to learn the material to the fullest, then mine the assignment for all its knowledge, and don't fret about your grade. Anything else is wasted motion.

If you're trying to do achieve some combination of good grades (for signalling purposes), respect (for social reasons), and knowledge (for various effects), then pinpoint the minimum quality target that gets a good grade, impresses the teacher, and allows you to learn the material, and hit that as efficiently as you can. Anything more is wasted motion.

Ah, an engineer’s approach to optimizing life.

There is a good section in here as well about how to deal with the associated guilt when you take this approach.

The Disappearing Art Of Maintenance

🔗 a linked post to noemamag.com » — originally shared here on 2023-08-01

Whatever comes next must take responsibility for that legacy, while also articulating something new and perhaps even bolder than what came before. There is a useful lesson drably concealed in the MTA’s maintenance facility in Queens: What we inherit comes with responsibility. Vintage machines are owed our best efforts, and our ingenuity in keeping them running should at least be equal to our ingenuity in forging them. 

The work of maintenance is ultimately a way of parsing and knowing a thing and deciding, over and over, what it’s worth. “Maintenance should be seen as a noble craft,” said Rossmann, the boot-strapping repair man who learned the secrets of the iPhone’s circuits. “It should be seen as something that teaches people not just how to repair, but how to think.”

This article reinforced one of my core tenets of software engineering: the simpler, the better.

It also supplies an important distinction between repair and maintenance. Repair is when you fix something that’s broken. Maintenance is about making something last.

The article calls for finding a way to better incentivize acts of maintenance in our economic system, and the more I reflect on that, the more I find it reasonable.

Building new stuff is cool and often necessary, but finding a way to make our old stuff last longer is equally cool.

Not just with our bridges and train cars and iPhones, but with our elderly too.

How Wine works 101

🔗 a linked post to werat.dev » — originally shared here on 2023-07-31

This is preposterously nerdy stuff, but if you are into understanding how you could run Windows software on a Linux machine, this article is for you!

Text Is the Universal Interface

🔗 a linked post to scale.com » — originally shared here on 2023-07-14

The most complicated reasoning programs in the world can be defined as a textual I/O stream to a leviathan living on some technology company’s servers. Engineers can work on improving the quality and cost of these programs. They can be modular, recombined, and, unlike typical UNIX shell programs, are able to recover from user errors. Like shell programs living on through the ages and becoming more powerful as underlying hardware gets better, prompted models become smarter and more on task as the underlying language model becomes smarter. It’s possible that in the near future all computer interfaces that require bespoke negotiations will pay a small tax to the gatekeeper of a large language model for the sheer leverage it gives an operator: a new bicycle for the mind.

I have a fairly lengthy backlog of Instapaper articles that I’m combing through, and I prefer to consume them in reverse chronological order.

This article is roughly 10 months old, and it’s funny how out of date it already feels (remember when GPT-3 was state of the art?).

But more importantly, the conceit of the article is still spot on. The internet (hell, pretty much all computers) are built on thousands of tiny programs, each programmed to do one specific task extremely well, interoperating together to do something big.

It’s like an orchestra. A superstar violinist really shines when they are accompanied by the multi-faceted tones of equally competent bassoonists, cellists, and timpanists.

There's still no silver bullet

🔗 a linked post to changelog.com » — originally shared here on 2023-06-28

Saying “use the right tool for the job” is easy, but actually selecting the right tool for the job is anything but. Good tools are hard to find, hard to evaluate, hard to learn. We have constraints, we have biases, we have shortcomings.

But that’s all part of the work.

And if you “just use Go” or “just use React” or “just use Postgres” for every problem that crosses your keyboard, you’re just not putting in the work.

I’ve only worked in agencies my entire professional career, and that work has honed two important traits of a good engineer: curiousity and agility.

Being curious gives you the ability to explore new tools and understand how they work.

Being agile (not in the project management sense, but the “moving freely and quickly” sense) gives you the ability to deploy those tools to solve increasingly complex problems.

It’s not that I don’t have a standard set of tools I reach for when solving a wide swatch of problems (Rails, Postgres, etc.), but as I get older, I’m finding that I am more willing to engage with newer tech.

I come from a background of writing Javascript by hand, but I'm starting to play more with Vue and React, and I can see why people like these tools.

Same thing with CI/CD pipelines. I always thought they were more fiddle-y and brittle than they were worth, but that's because I've generally been a lone wolf. In a team context, they are extremely useful.

If you keep hearing noise about a new technology, it's probably worth taking a look over the fence to see how that tool could be used.

The Contingency of Listening

🔗 a linked post to instapaper.com » — originally shared here on 2023-06-24

Let the mastering engineers do their thing, using whatever technology they find best. Get the reproduced music however you can. And focus on the analog component you are going to have to add to the chain in the end, no matter what: your ears.

A while back, NPR had a test that allowed you to tell whether you could tell the difference between various levels of audio compression.

Even though I did decent on that test, I’ve still never really been able to discern the difference listening to an album on vinyl versus a 320kbps MP3 rip.

That could be because I’m not listening to it on amazing headphones or speakers, but I think the main reason I enjoy listening to vinyl records is that it forces me to focus.

Having a majority of the music ever recorded at our fingertips is incredible, but taking time to really listen to an artist’s work from front to back feels like a luxury. The ceremony of selecting a record, setting it on the table, and dropping the needle feels more special than shouting into the air for Siri to start it.

(Shouting into the air to summon music is also supremely dope, though… don’t get me wrong.)

The blind programmers who created screen readers

🔗 a linked post to theverge.com » — originally shared here on 2023-06-22

For most companies, accessibility isn’t a priority, or worse, something that they pay lip service to while doing the bare minimum to meet regulatory compliance. Ojala’s pet peeve is people thinking that accessibility is a feature, a nice-to-have addition to your product. When they tack on accessibility later, without thinking about it from the very beginning, Ojala can tell — it feels haphazard. (Imagine first creating a product with a colorless UI, then to add colors later as an afterthought, only to use the wrong color combination.)

I heard long ago that the reason developers should start testing software with accessibility in mind is that everyone, at some point in their life, will benefit from accessible technology.

At a minimum, as your eyesight gets older with age, an increase in font size will make it more comfortable to read things.

Any story that revolves around a few people banding together to solve an actual problem, and how that solution literally changed people’s lives, is so inspiring to me.

It’s what I yearn for at this point in my life. I don’t mind making money and building apps which drive business value. The stability of my job has done wonders for my mental health, and I am supremely grateful that I have it.

But boy, wouldn’t it be fun to get to work on something that has an outsized positive impact on people’s ability to live productive lives?

Everything I learned about concurrency and reliability I learned at the Waffle House

🔗 a linked post to youtu.be » — originally shared here on 2023-02-20

A friend recommended this video to me while I was out with Covid a few months back and I just got to watch it.

Now I get to recommend it to you!

If you are a nerd for process, you will love this. Just one small fact to entice you to watch this: did you know Waffle House employs their own meteorological staff?

Semiconductors: Everything You Wanted to Know

🔗 a linked post to youtu.be » — originally shared here on 2022-11-17

You may be thinking: “there is nothing I ever wanted to know about semiconductors.”

I assure you: there is.

This video, created by the excellent Farnam Street, dropped my jaw several times around a topic that is crucial to our way of life, yet is virtually invisible to the vast majority of us.

Take an hour and watch it. It may put many things (including the geopolitical tensions around Taiwan) into better perspective for you.

What I’ve Learned in 45 Years in the Software Industry

🔗 a linked post to bti360.com » — originally shared here on 2021-06-18

No. 2: Focus on the Fundamentals

Technology constantly changes, but some fundamental approaches to software development transcend these trends. Here are six fundamentals that will continue to be relevant for a long time.

• Teamwork — Great teams build great software. Don’t take teamwork for granted.
• Trust — Teams move at the speed of trust. Be the kind of dependable person you would want to work with.
• Communication — Communicate honestly and proactively. Avoid the curse of knowledge.
• Seek Consensus — Take the time to bring your whole team along. Let discussion and disagreement bring you to the best solution.
• Automated Testing — Well-tested code allows your team to move fast with confidence.
• Clean, understandable, and navigable code and design — Think of the next engineer that will take over your code as your customer. Build code that your successor won’t have any trouble reading, maintaining, and updating.

Super astute observations, many of which seemed to be hard-earned.

Programming Sucks

🔗 a linked post to stilldrinking.org » — originally shared here on 2021-03-19

Here are the secret rules of the internet: five minutes after you open a web browser for the first time, a kid in Russia has your social security number. Did you sign up for something? A computer at the NSA now automatically tracks your physical location for the rest of your life. Sent an email? Your email address just went up on a billboard in Nigeria.

These things aren’t true because we don’t care and don’t try to stop them, they’re true because everything is broken because there’s no good code and everybody’s just trying to keep it running. That’s your job if you work with the internet: hoping the last thing you wrote is good enough to survive for a few hours so you can eat dinner and catch a nap.

As poignant, true, and depressing as it was back when it was 2014.

The illusion of certainty

🔗 a linked post to app.spectator.co.uk » — originally shared here on 2020-07-27

If you engage engineers, you don’t know what you are going to get. You may be unlucky and get nothing. Or their solution may be so outlandish that it is hard to compare with other competing solutions. On average, though, what you get will be more valuable than the gains produced by some tedious restructuring enshrined in a fat PowerPoint deck.

Craig Mod: Fast Software, the Best Software

🔗 a linked post to craigmod.com » — originally shared here on 2019-12-24

Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance.

I’ve tried articulating this notion to my clients, but now I’m just gonna send them this article.

If you manage a software project, or are interested in software development, Craig’s thoughts are a must read.

The (not so) hidden cost of sharing code between iOS and Android

🔗 a linked post to blogs.dropbox.com » — originally shared here on 2019-08-16

Until very recently, Dropbox had a technical strategy on mobile of sharing code between iOS and Android via C++. The idea behind this strategy was simple—write the code once in C++ instead of twice in Java and Objective C. We adopted this C++ strategy back in 2013, when our mobile engineering team was relatively small and needed to support a fast growing mobile roadmap. We needed to find a way to leverage this small team to quickly ship lots of code on both Android and iOS.

We have now completely backed off from this strategy in favor of using each platforms’ native languages (primarily Swift and Kotlin, which didn’t exist when we started out). This decision was due to the (not so) hidden cost associated with code sharing. Here are some of the things we learned as a company on what it costs to effectively share code. And they all stem from the same basic issue:

By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults. This overhead ended up being more expensive than just writing the code twice.

Say it with me: "write once, run everywhere" is a terrible long-term approach for building mobile apps.

One of the biggest reasons we lose leads is because people are swayed by the promise of having a single codebase that runs on iOS, Android, and the web. Solutions like Xamarin, Flutter, and React Native are touted as these golden solutions that will save you time and money.

These solutions, however, introduce a layer of overhead that end up making it more expensive than it would have been if you did it the right way from the start.

If you are looking to build custom mobile software for your business, learn from Dropbox's example and build your apps using native frameworks from day one.

A Conspiracy to Kill IE6

🔗 a linked post to blog.chriszacharias.com » — originally shared here on 2019-05-12

The bittersweet consequence of YouTube’s incredible growth is that so many stories will be lost underneath all of the layers of new paint. This is why I wanted to tell the story of how, ten years ago, a small team of web developers conspired to kill IE6 from inside YouTube and got away with it.

As someone who got started developing websites on IE2, IE6 continues to haunt my nightmares to this day. This story made me feel some semblance of vengeance. Kudos to these unsung heroes of the internet.

Speculative Developers

🔗 a linked post to macsparky.com » — originally shared here on 2012-02-06

If you want to develop apps, take your time and make something awesome. Make it fast. Make it beautiful. Make something you’re proud of. Don’t make 60 crappy apps: Make one really good one.

As someone who's about to start an iOS development business, this is exactly the model I intend on adopting. If you make something you want to use (and especially something you're proud of), other people will want to use it too.