Hey friends,

We've entered Ghost Turkey season (the period between Halloween and Thanksgiving) with a bang this year. Between travel recovery and sickness in the fam, we've stumbled at the opening gate, but we're on our way to being back on our feet! 💪🤒

Thinking Too Hard 🤔

Whenever we all get together at an offsite, as we did last week, we run workshops focused on improving our code, processes, team dynamics—whatever we believe will enhance our craft.

Last week, one of our topics was "polish": identifying specific ways to elevate the products and solutions we build. There was a lot of good discussion, but one thread I want to pick out was the concept of learning one (or more) things per project.

I've written before about writing goals at the start of a project, but it's very easy (I'm guilty as well!) to not be intentional about defining a personal goal for a project. If we do not define our own goals, the only measure of success will be defined by someone else. When we define our own goals, we're plotting an intentional path to something that will improve our understanding and craft, even if the project fails by other standards.

So how do we write a good goal? I stole a structure earlier this year from Mouse Guard that I'm still a fan of. The structure goes:

• Imperative: A command.
• Action: An activity or task.
• Target: A focus.
• Condition (optional): A limiter, timeframe, or qualifier.

For a project, the condition will usually (but not always) be the completion of the project. I like to have at least one tech goal and one process related goal. Here are a few examples:

• I will (imperative) explore and integrate (action) Rive animation data-bindings (target).
• I must not forget (imperative) to run a full performance audit (action) of the site (target) before the initial client review (condition).

I have found this helps direct intentional improvement on what might be 'just-another-project'. If you haven't been setting goals for your projects, maybe it's time to start!

Interesting Web Bits 🍿

Web Stuff

• Maurycy found that feeding LLM scraper bots garbage was easier than blocking them... Who knew robots like fast food too!
• Ahmad creates some extremely durable components with modern CSS... but I wonder if this winds up being an anti-pattern. I've found it's often better to have multiple types of a component with specific purposes than one super-component that works everywhere. Editing that super-component 6 months later is a real joy... 😅
• The ever-helpful Josh Comeau gives a rundown on the CSS linear() function.
• Using anchor positioning and some trickery to make tooltips.

Other Stuff

• Did you know most shapes can pass through themselves?. Except for things like the Noperthedron. Obviously. (Totally knew that...)
• Pablo asks you to stop insulting us with your AI-generated blog posts and face the world with your own thoughts and feelings.
• We all knew it was coming but my favorite non-Adobe editing suite, Affinity, is now available for free through a Canva account. I just hope more things don't disappear behind a Canva paywall...
• A lovely interactive demonstration of how dithering works.
• Ro thinks we should tinker to develop our taste, and taste helps drive skill (if you can overcome the gap).
• Justin Gary reminds us that constraints can be magical (and that the magic was in us alllllll alloooooooong). 🪄

Watch and Play

• 🎮 Egg, egg, egg!
• 🎮 If you find normal crossword easy, try cryptic, fan-made crosswords.
• 🎮 Polytrack, a very smooth low-poly racer with a level-editor (and people have make some impressive levels! If nothing else, go look at those community levels!)