I used to be like: "I'm a Rails dev, so my blog *has* to be a Rails app!" Nowadays, I'd pick whatever is the absolute easiest tool for me to write, edit, and deploy.

This week I shipped something new on the website: a user manual for working with me. Have you ever made one of these? Was it useful? Share in the replies! www.jakeworth.com/user-manual/

Tonight is the Maine JS Meetup! Join us at Novare Res in Portland for an evening of ECMAScript-compliant conversation and socializing. 🍻 www.meetup.com/mainejs/even...

It's the Hashrocket Starter Pack! "Follow all" for insights from some of the smartest, most interesting folks to ever walk the streets of Jax Beach. 🏝️ go.bsky.app/ArMALD4

🎉 Tuesday night, join us in the Old Port, Portland, Maine for an evening of socializing and JavaScript! Always a great group, and great conversation. www.meetup.com/mainejs/even...

This week, we ran an experiment: entire team voting on tickets to be included in an upcoming release! It was interesting. Has anyone done this? What would you call it; participatory software planning?

🌲 I made a Bluesky Starter Pack of devs in Maine! We're a small community, and growing. Click that follow button, and let's get a conversation going! go.bsky.app/6WrdHtm

Testing a feature or bugfix, make sure you aren’t trying to "catch it passing." Okay: "Can I get it to work?" Better: "Does it ever fail, even if I stray from the happy path?"

"Being fast" matters at the org level, too. Fast organizations fix little things. They experiment instead of talking. They deploy fearlessly because they know they can recover quickly from mistakes.

💻 New England programmers: just a few weeks until our monthly Maine JS Meetup! We'll be socializing and talking JavaScript at Novare Res in the Old Port. RSVP now! www.meetup.com/mainejs/even...

My gratitude continues to deepen for getting to pair program with some very smart people early in my career. It was challenging. I got a lot better, quickly. I still marvel at some of the techniques I saw.

Tired: making a list. Wired: making a list, then ranking it. Here's why you should prioritize most lists that you make, at work and beyond. "Always Be Ranking" www.jakeworth.com/posts/always...

Anytime you're making a list at work, of anything, rank it. Tech debt? Security concerns? Feature requests? Rank them. Rank them so that you do the important ones first. Those are the only ones you probably will do.

Write acceptance criteria that actually work! AC that helps you: - Build the “right Thing” - Build the “thing right” - Document I also cover how to learn this skill as a team and individual contributor. #ProductManagement www.jakeworth.com/posts/accept...

Fight to work on big things. When presented with the option of working on something big, like a new app or major new feature, or doing anything else, prefer the big thing. You'll learn more, gain ownership, build patterns, have visibility, and context switch less.

There is always an argument against shipping. Be the person always arguing to ship.

I'm trying to build a "Maine software engineer" Bluesky starter pack! If you you're a software engineer in Maine, send me a message.

Has anyone written a great guide to writing software bug and feature tickets? It's one area of our field that I see a lot of variance. #agile

Yesterday, I vibe-code a Python CLI to delete typos, one-offs, sensitive items, etc. from your Zsh history. One of my favorite LLM use-cases!

Auto-formatters? No thanks; I type it all perfectly by hand, in a way nobody disagrees with.

What are your favorite conversational LLM prompts? I'll start: I'll share a blog post and ask: "What are the weakest parts of this argument?"

In the next four weeks, you should go to a tech meetup.

Working in Docker this week for the first time in years. This watch (+ sync and build) setting has been a game changer.

You’ve been given programming some work, and you’re stuck. Hours have become days. To make matters worse, you haven’t told anybody. This is the solution.

I gave talk this week at Maine JS about the JavaScript MutationObserver API. It's really cool! Here is the app I made that demonstrates the feature.

Big win this week-- learning about Docker Compose Watch! Reduced iterations from over a minute to seconds.

🐛 Debugging tip: Stay focused! If something irrelevant comes up— your text editor's busted, you need to update a library— make a note and fix it later. My new debugging guide for rising engineers is out: 'Don’t Stay Stuck' 🚀 jwworth.gumroad.com/l/dont-stay-... #dontstaystucktips

💛 Tonight is our Meetup! Join me in Portland, Maine, for JavaScript Lightning Talks! meetu.ps/e/P4mxz/1Jbw...

Talking about MutationObserver on Tuesday, because it’s cool! Has anyone used it in a project? developer.mozilla.org/en-US/docs/W...

Today’s analog project: going to try to make a candle that smells like a brand-new Gibson guitar.

What's a favorite essay about programming for you? I've kept my own long list here.

"In the face of ambiguity, refuse the temptation to guess." --The Zen of Python, Tim Peters

"Don't ask for advice; ask for a code review."

One "technical talk preparation" suggestion: practice with a timer. It's easy to go short, long, or spent too much time on a section. That can throw you off.

What's a book about business or technology you read recently, that changed how you think? Two from me: "Shape Up" by Ryan Singer, "The Ride of a Lifetime" by Robert Iger

I've been lucky to have worked with some great engineers, and one thing that they tend to do exceptionally well is reporting about their work at meetings.

You can understand computers. It bears repeating.

Live-coding interviews filter out good people. I try to avoid them myself and I don't run them as an interviewer.

🔥 New blog post! I wrote about learning something more deeply, JS promises, using the Feynman technique. Plus a little Chat-GPT feedback because it's 2025. www.jakeworth.com/posts/learni...

Steve Martin once said the secret to success is to "Be so good they can't ignore you." How do you get that good as a programmer? The most direct path I know is to build things.

When I find a bug with a software product, I learned from Steve Klabnik to always open a ticket, even when abandoning the product. We've all been on the other side, building something and wondering if anybody cares. Or stuck, and so grateful to find a ticket that validates our situation.

Common (Ruby): user_a = create(:user, last_log_in: today) user_b = create(:user, last_log_in: last_year) Better: frequent_user = create(:user, last_log_in: today) unengaged_user = create(:user, last_log_in: last_year)

How does one exit Vim "Ex" mode? But first... how did you even get into "Ex" mode?

ZSH tip: leverage the aliases you already have! github.com/djui/alias-t... Input: $ git status Output: Alias tip: gst

Celebrating a win: I made my first dollar online this week. A few copies of "Don't Stay Stuck." Dinner's on me!

🐛 Debugging tip: every time you fix a bug, ask: "When I was stuck, what did I miss?" My new digital debugging guide is live today! 'Don’t Stay Stuck: A Debugging Guide for Rising Engineers.' #dontstaystucktips jwworth.gumroad.com/l/dont-stay-...

🔥I’m launching something tomorrow that I’m proud of! Watch this space.

I activated an egghead.io subscription for a while. Does anyone have course recommendations to share? Frontend / general technologist space.

🏆 Had my first question on Reddit (r/webdev) blow up today (that wasn't people dunking on my .vimrc)!

Debugging tip: when stuck, try a binary search (git-bisect, or commenting out half of a function). A binary search can identify *when* something stopped working. Sometimes you need to work backwards from an answer. #dontstaystucktips