Position-Aware Geckos, GSAP Rock Climbing, and Hand Drawn Buttons

Julia Evans has an extremely relatable and extremely charming talk in Making Hard Things Easy. Julia has a way of putting her finger on technology concepts that are notoriously difficult and making them easier to understand. She does this both by sharing her own tactics, like learning a reduced set of options or commands, as well as by producing very approachable guides.

I like her formula: infrequent use + lots of gotchas = disaster.

(As a CSS guy who regularly hears people complain about CSS, this tracks.)

Another trick to avoiding that disaster is… using computers! Tools like linters can help you fix (or avoid) the very mistakes that can make a technology frustrating or error prone. She uses the tool ShellCheck, which I’d never heard of, as an example to avoiding problems in Bash scripts. Then, sharing when you find tools like this that actually help you. I found that last bit especially interesting. It’s good to be “intellectually honest” about sharing tools that really have helped you, not tools that seem like they could help you, because they look nice or whatever.

Speaking of hard things… you know what can be hard? Refactoring. I’ve probably over-repeated this, but David Khorshid one said “It should be called legendary code not legacy code”, referring to the idea that code that is in production doing work, even if you think it might be sloppy, inefficient, inelegant, is literally doing the job it needs to do. Whereas some theoretically rewritten wonderful code has yet to prove itself.

Miroslav Nikolov writes:

Code refactoring may cost a fortune if not done right. A dysfunctional revamped system or new features coupled with incorrect rewrite is, with no doubt, damaging. One can argue to what extent.

Refactoring code can be very dangerous, so it’s worth being very considerate about what you’re doing. A few of Miroslav’s points:

✅ Isolate improvements from features. Do not apply them simultaneously.

❌ Do not mix expensive cleanups with other changes. But do that for small improvements.

This makes me think about TypeScript.

TypeScript is (uh, obviously) newer than JavaScript, so there is a good amount of code out there that has been refactored into TypeScript. Whether than was worth it or not is up for debate. People that love it might say that a refactor like this actually makes the code safer, and they probably aren’t wrong to some degree, although it wouldn’t be hard to argue that any refactored code has risks.

There is also cost to the TypeScript itself. Build tooling and whatnot of course, but also the syntax itself. Remy Sharp has made the call that his own personal code isn’t in TypeScript, partially for this reason:

A “well crafted” definition, type or interface (still no idea when I should use each), is often a huge cognitive load on me.

Being presented with lots of double colons, <T> when I’m not sure what T refers to, a wall of interfaces and more is an upfront cost on me, the reader.

Often the types will be tucked away in other files (probably good) but working out the argument required to a function call often leaves me distracted in the task of understanding what’s required rather than making my function call.

I feel that. I’m slowly getting better at TypeScript myself, because at CodePen we’ve decided to take advantage of it when we can. I can see the value in it fairly regularly, but I’m also fairly regularly frustrated by it and question the hours lost. I’ve felt this way for years, and I’m still not quite sure what to make of that.

One of the reasons you might be refactoring something is because you’ve decided on some new abstractions. A classic, in my experience, is that you’re adding, dropping, or changing a framework. The old one just isn’t doing it anymore, times have changed, and you either want to go vanilla or move to something more modern. There is probably some kind of axiom where any sufficiently large codebase is always undergoing at least one refactoring per hundred thousand lines of code or the like.

Have you read the Hammer Factories thing? It’s a pretty satisfying read, save for a few dated stabs at comedy that read pretty misogynisticly. Sometimes you just need a hammer, is the thing, it’s clearly the right tool for the job, but the industry wants you to you some all-in-one hammer, wait, no, a hammer factory, wait, no, a factory for building hammer factories, wait, no…

It feels true to me that front-end specific work has always been treated as lower-value than back-end work. Don’t hate me, but part of me feels like that’s fair. I’m a front-end guy myself and actually think it’s extremely valuable, but ultimately most products real value lies in some kind of unique back-end magic. The problems on the back-end, on the whole, are harder and riskier and scarier, and that translates to higher paying roles. Of course there is tons of nuance here. A product with a very decent back end and total garbage front end is likely to have problems catching and may outright fail because of a poor experience for the people actually using the thing, and making an experience people love is weighted toward the front end. Or as Josh Collinsworth recently wrote:

In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?

There used to be a time where if you knew both front end and back end you were a unicorn and it was considered very rare and you were a powerful force in this industry. Now unicorns are dead. We call that “full stack” now and it’s all but expected that you are one. Especially if you’re skilled in the front end, you can’t just say that, you have to say “full stack” or your job prospects ain’t looking great. Then the actual expectations of full stack mean that you’re good at the JavaScript stuff, you’re fine with the work that connects that JavaScript client work with JavaScript on the server, and you know enough front end to use a design system, library, or hack some workable things together.

It’s just a thought, anyway. It solidified in my mind reading Andrew Walpole:

The full-stack developer was borneth!

It looks great on paper, especially to the payroll department: One person to fill traditionally two roles. But in reality, we know it doesn’t work that way. It may be a role for a technology generalist to thrive in, but one person’s effort is finite, and consistent, quality development across the entire product development spectrum requires focus and expertise. Nevertheless, start-ups soaked up the efficiency, and in a tumultuous churn of web tech it was a decent defense.

There is a new Node.js website and it’s always fun to read a little behind-the-scenes. That would be a hard job but it looks like they did a great job.