Part of the impetus for this was a general retreat from engaging in the increasingly unpleasant social media sphere — but like the existence of this site in the first place, it’s honestly more an exercise in personal vanity than anything else.

Though it was mildly entertaining to dust off the old web scraping skills to semi-automate the retrieval of my words from various social media sites and older web forums back to this one. Facebook and Instagram made it easy, they have a reasonably good (though well-hidden) export feature.

What I did not do, and probably should have, is record the original source of each post. Not so I could include a link back to the original — they can probably survive without my trackback traffic — but so I could keep track of the different customs and mores from different sites in different eras.

(A “meme”, for example, on 2000s-era LiveJournal used to basically be one of a collection of writing prompts passed around between bloggers so they’d have something to blog about. Later on it became an image-based joke with text in Impact font. These days, of course, it counts as a nuanced political opinion. How things change.)

Some of this stuff was originally written for a private audience, so if you see me complaining about a freelance client know that I wasn’t publicly ranting in real time. I was privately ranting in real time. Very different. The passage of time has sufficiently anonymized the guilty parties — except in cases where that was myself — so I feel ok about hosting those in public here now.

Not that this really feels all that “public”: I know for a fact this site is read more frequently by bots than by humans. Hello, bots. These are some of the words that helped train you. Enjoy.

Anyway, that’s the update. I mention it mostly so that if something seems weirdly out of context, that’s because it is.

I’m a UX/IA designer turned frontend developer turned engineering manager, which is a very efficient way to spend a career moving steadily closer to the meetings. I’ve been working on the web since the era when ugly was a technical limitation instead of a brand choice. I like messy situations: products that need rethinking, teams that need structure, organizations pretending uncertainty is a temporary bug. I’m good at making systems — product systems, design systems, team systems — less chaotic and slightly less insulting to the people using them. I also maintain a personal website in the year 2026, so obviously I have accepted that I am a type. I take photos of giant roadside objects, paint despite evidence, and keep writing on a blog like social media was an unfortunate side quest. It’s not nostalgia so much as a refusal to die in an app.

• I have spent an unreasonable amount of my life translating between designers, developers, and managers who are all technically using English.
• I keep ending up in transitional moments: reorgs, greenfield efforts, legacy overhauls, startups trying to put on adult clothes.
• I crossed from design into engineering and then into management, which means I now understand exactly how every function disappoints the others.
• I have probably sent some version of ‘please include an agenda’ in more organizations than is medically ideal.
• Creature: graybeard web raccoon with one paw in IA, one in frontend, and the rest of him rifling through thirty years of broken process looking for something salvageable
• Vibe: Like if your most competent engineering manager was raised by the 1990s web, survived freelance client madness, and now turns up at dinner muttering about developer workflows, bad meeting invites, and the strange dignity of still owning a personal website. Strong ‘I have seen three generations reinvent the same mess with worse typography’ energy.
• Emoji: 🦝

So here I am to make some more predictions; we can check back in a few years to see how wrong I am.

AI is useful for production code

I’m starting with an easy one that’s already (relatively) uncontroversial. But six months ago I’d have made the opposite prediction here. So see, I’m already ahead of the game!

Early models produced garbage, to be sure; and even some current agentic models (GPT-4 and below for example) tend to incidentally break more functionality than they introduce. But I’ve successfully used both Claude Sonnet and whatever model backs Rovo to:

• perform a major refactor and redesign of a large, complex application feature, by basically prompting “Here’s the old version, here are the characteristics of the new version, good luck” and then iterating a bit on the UI. All this in a framework I’m basically a novice in (Angular).

• search for and extract data from a scattered collection of human-structured (i.e. inconsistently-formatted) Confluence documents

• analyze a very noisy date-and-value sequence — ok, yes, my scores in an idle game — by basically prompting it “Here’s some data, what can you tell me about it?” It was able to detect exponential growth, decided to calculate a moving average to smooth out the noise, made accurate predictions about future trends, and even correctly identified the inflection point at which the rate of growth changed. (Which was the date of an in-app purchase). All without hand-holding on my part; I don’t have the statistical knowledge to do so even if I’d wanted to.

I’m not going to make any guesses about to what degree what we’re calling AI actually lives up to that acronym. But in practice this is functionally well beyond “predict the next token.”

The job of “software developer” will soon more closely resemble that of a tech-oriented manager

Working with an AI agent feels a lot like working with a very eager junior developer. They make similar types of mistakes: the main complaint from skeptics these days is that they can produce unmaintainable spaghetti code if not closely supervised. Well, guess who else does that?

They work best when they have clear instructions and the full context. Just like a real developer. Constructing a good prompt feels an awful lot like writing a good JIRA ticket. (I wouldn’t be at all surprised if someone’s already working on building a direct JIRA-to-code pipeline, except that most JIRA tickets aren’t that well-written or clear.)

They have their own personalities. Claude is a flatterer, constantly congratulating you on how good your suggestions are. Gemini is chatty as hell (which they’ve obviously tried and failed to rein in; the chain-of-thought pre-response is littered with the phrase “I need to be concise, so...”). GPT models are terse and sometimes pretend their mistakes didn’t happen, which they have in common with a subset of human engineers. (I’m really not impressed with GPT, if that wasn’t clear.)

They perform better if you’re nice to them. Seriously, I really believe they do; I don’t think I’m just anthropomorphizing here. When I’ve gotten frustrated with the AI making mistakes and started SHOUTING or being sarcastic, I’ve seen the chain-of-thought include “Based on the user’s tone, I need to...” and start outputting noticeably inferior results. I’ve even see people theorize that they have moods, or perform differently at different times of day; though this one I suspect is anthropomorphism, or else the AI vendors quietly swapping in cheaper models at peak hours.

All of them do, sometimes, create redundant functions or construct difficult-to-understand complex objects; the code they produce isn’t always clear and maintainable. They sometimes go down rabbit holes and get stuck on the wrong approach or code themselves in circles.

Again, just like a junior engineer.

(I’ve found it’s best to let them write a rough first draft of whatever feature I’m asking them to implement, then switch to a different chat context and ask for a code review and refactor. So, yes, you do need to watch their output closely, have enough tech experience to be able to distinguish good code from bad, and to ask for improvements when necessary — true unskilled “vibe coding” isn’t really enough. Yet.)

So the upshot of coding with AI is that you no longer need to have a grasp on the syntax or low-level details, the agents can take care of that; but you do need to do careful code reviews, understand what you’re looking at, and ask for improvements where necessary.

This feels very similar to the technical aspects of managing software engineers.

We’ll be stuck with current frameworks forever

AI agents work best when working in a familiar context, because they have a large corpus of existing code to draw from. I’ve found that they’re substantially more productive when working in a React, Angular, or Vue context than in vanilla or custom-rolled code. (I’m mostly a front-end guy, so I’m not as able to evaluate whether this applies to back-end code as well, but I expect it does).

Because we no longer have to pay as much attention to the fine syntax and structural details, there’s little incentive to write a substantially new framework in the age of AI — or at least for a newly-created one to grow large and successful enough for there to be enough human-generated code in it for an AI to train on and become expert in.

So what we have now — React, Vue, Angular, webpack, babel, etc — is going to be with us for a very very long time. They’ll get incremental updates, sure, but I wouldn’t expect a paradigm shift in code structure anytime soon.

The disposable front end (and maybe backend too)

Rewrites and refactors are ridiculously easy now. There’s no clearer prompt for an agent than an existing codebase, and agents are far better at remembering long lists of edge cases and workarounds than humans are.

I think the age-old wisdom of “never do a full rewrite” is approaching its end. Because the hard part of a rewrite is reading and understanding the existing code — which you no longer need to do. I’m already looking at some of my older projects and realizing that it’d probably be easier to start from scratch than to update and refactor what already exists. And I’m less concerned about losing the bugfixes and improvements that will have collected over time, because the AI is good at retaining those in the rewrite.

I think this works because I’ve done it already. My team was falling behind on a major-version refactor of wildly-outdated legacy code, so I rolled up my sleeves and claimed one of the features for myself. Put the old version in one folder, started fresh in a new folder, added a feature flag to toggle between them, and over the course of a couple weeks Claude and I reproduced all the functionality with modern code patterns and the new workflow. Would’ve taken me three months if I’d done it by hand, conservatively, because I’d have had to learn the framework first.

It passes all the tests, was accepted as maintainable by human code reviewers, and the only bug reports it’s garnered since it went live are actually feature requests. (Well, ok, there was one bug, but it was my fault; I didn’t catch a duplicated line of text. That’s it, seriously.)

The main concern with AI-generated code is that it’ll be difficult for humans to understand and maintain... but maybe that doesn’t matter anymore. This is the prediction where I may be furthest out on a limb, but I think it’s at least possible that “throw it all out and start over” will be a valid pattern for major-version updates.

Turmoil and chaos while we figure this stuff out

Job losses will be incalculable. It’ll be much more difficult to break into the industry, there’ll be a shortage of actual junior engineers before too long. It’ll resemble the offshoring movement but this time without the cultural or timezone barriers — and much less expensive; going flat out with the most expensive models I’m only able to spend about eight dollars a day on tokens. No human can compete with that.

As the current crop age out to retirement there’ll suddenly be a shortage of skilled seniors capable of supervising the AI output. (It’ll be a race to see whether the AIs can get to the point where they need as much skilled supervision before that happens. If it doesn’t, we may see a rehash of the COBOL experts coming out of retirement for Y2K, except this time it’ll be for everything. If it does, software engineering will become a niche or academic activity Someone still needs to build and train the models, and invent new algorithms and approaches, but those people are already a tiny segment of the current industry. and the product teams will take over directly for most software.)

Competition will be faster and fiercer. It’ll be much easier to quickly replicate a competitor’s feature set; if someone comes up with a great new idea everyone else will have it production within weeks. Market success will come more from marketing, branding, ease of use, and patent law, than from the feature list. Startups will therefore have a much harder go of things; large established companies will have the branding, and can afford the marketing and patent lawyers. There’ll be less incentive for acquisitions. Good UX may be the only way true startups have left to compete.

It’s going to kind of suck for almost everyone, honestly. As exciting and productivity-enhancing this stuff is on an individual level, I’m kind of relieved I’m closer to the end of my career path than the beginning. I don’t envy people graduating from bootcamps or their CS degrees this year.

Your job is not to manage people, but to manage processes and lead people.

You manage processes on how you expect work to be done, where each person's responsibilities start and end, how their careers are made, and how all this can be discussed, and/or changed.

You lead people by example and through empathy. They have goals, fears, motivations, and lives outside of work. Act as you would want them to act if the roles were reversed.

Working with your engineers

Align on “why”.

As engineers, we tend to focus on the “how” – the implementation details, the technical solutions – but it’s equally important that your team members understand why they’re building what they’re building. Ensure they have a clear picture of how their development work fits into the rest of the platform and the organizational strategy; understanding the “why” leads directly to better decision-making and more thoughtful solutions. Assume (and encourage) positive intent.

Trust, collaboration, and psychological safety are essential for innovation and problem-solving. When team members believe their colleagues are acting with good intentions, it reduces misunderstandings, minimizes conflict, and encourages open communication. Ensure you and your team focus on solutions rather than assigning blame, and create an environment where constructive feedback is embraced.

Give (and receive) timely, candid feedback.

Honest feedback allows individuals to identify blind spots, refine their skills, and align their efforts with team goals. It fosters accountability and ensures that issues are addressed promptly, preventing small problems from escalating into larger ones. Leaders who encourage a culture of candid feedback create an environment of mutual trust, where team members feel empowered to share insights and challenge ideas, driving innovation and excellence. Meet regularly with your engineers, both as a group and in individual 1:1s, to create consistent opportunities for open dialogue. Set clear expectations, and expect the same from your team.

Create a safe environment.

Treat failures as learning opportunities rather than occasions for blame. Team members are more likely to share concerns or report issues early when they know they won’t face punishment for doing so. Encourage team members to suggest new ideas or alternative approaches without fear of judgment. Run blameless postmortems and retrospectives to analyze challenges objectively, focusing on systemic improvements rather than individual fault.

Create a productive environment.

Equip the team with the best tools and resources to succeed, while shielding them from organizational distractions and unnecessary politics. Put performance over presence, and quality over quantity, to ensure that efforts are impactful rather than merely visible. Minimize interruptions, and be mindful of timezones and external obligations when scheduling meetings. Encourage team members to actively participate in conversations. Work with engineers to define a viable career path and create opportunities for learning and advancement, and periodically look at your team to make sure we have the right people in the right roles.

Encourage continual improvement.

Technical debt is inevitable: requirements and business needs change, legacy code ages, and bugs are patched quickly and not always cleanly. Encourage developers to improve the application while working on their projects. Turn copypasta into reusable objects, and break up large objects that are difficult to maintain and reason about. Improve the database schema even if it hurts in the short term. Delete old and unused code. Recognize when a codebase has exceeded its useful lifespan and move to replace it with something better.

Fixing tech debt isn’t a standalone project – if you treat it as such you’ll eventually find a reason to abandon it entirely because it’s impacting deadlines. It should be something engineers do all the time during their normal development activities.

Working with the organization

Share your team’s solutions and practices.

Make sure other teams know what your team is working on to avoid duplicated effort. Sharing solutions doesn’t just save time; it can spark new ideas. Sprint demos are a great starting point for showcasing your work, but look for other ways to connect, like cross-team meetings, shared documentation, or informal discussions, to ensure everyone is aligned.

Understand solutions built by other teams.

Stay informed about what other teams are building and how their work might complement your own. Whether it’s tools, processes, or features, leveraging their solutions can save time and resources while strengthening collaboration across the organization. The more you understand what’s happening across teams, the better positioned you’ll be to avoid duplication and maximize efficiency.

Share your perspective with your team’s leadership group.

Your technical expertise offers valuable insights. Share your perspective with your team’s product, project, and program managers to highlight low-hanging technical opportunities they might not be aware of. Similarly, they may have product or roadmap knowledge that can help inform your own decision-making.

Working with your upstream management

Ensure management understands the value of the software the team creates. This includes demonstrating team's work and showing incremental improvements. Ensure your team’s efforts support organizational goals (and work with your leadership to understand those goals). Regularly communicate the team’s achievements in terms of business value, such as increased efficiency, enhanced user experience, or revenue growth, to bridge the gap between technical efforts and strategic goals.

Challenge the status quo.

Always be on the lookout for ways to make things better – whether it’s improving workflows, upgrading tools, or cutting down on inefficiencies. Keep an eye on infrastructure costs and find smarter ways to spend without sacrificing performance. Pay attention to what’s slowing engineers down, and look for ways fix those pain points.

Working with your customers (internal and external)

Bring customer feedback to the team.

Every bug ticket or feature request is a chance to refine your product and better meet user needs. Share this feedback with your team to help them understand the real-world impact of their work and prioritize fixes or enhancements that matter most.

Ensure top-level support and uptime.

Keeping our products reliable and running smoothly is non-negotiable. Take charge of observability to monitor performance, detect issues early, and respond quickly when problems arise. Own the process of software upgrades to ensure your applications are always operating on stable, supported versions.

Build tools for internal customers.

Empower your internal teams by creating tools that make their jobs easier and more effective. Whether it’s analytics platforms, dashboards, or customer support tooling, these resources help teams make informed decisions, streamline workflows, and provide better service, which ultimately drives the success of the entire organization.

Understanding success as an engineering lead

An engineering lead's success can be measured by their agreement with the following statements:

• I and my team understand what we’re building, and why it matters to the customer and to the organization.
• We understand how our projects mesh with other teams' work, and how they fit into the organization’s overall goals and strategy.
• My team members volunteer new ideas and suggest alternative approaches to their tasks. I help my team make decisions; I don’t make decisions for them.
• My team is reliably able to predict the duration and complexity of a given task. We understand the requirements clearly before we start building. We routinely meet our sprint commitments and neither over- nor under-commit.
• Our code is readable, stable, and maintainable. Everyone on the team has the ability to recognize what mediocre, bad, or excellent work looks like. We take ownership of, and pride in, our work.
• When something goes wrong, I learn about it quickly – whether via observability tooling or by a team member raising the issue before it gets that far.
• We are able to remedy problems without panic or excessive disruption. We work to ensure that the same problem will not occur again.
• I understand each of my team members' strengths; their weaknesses; and their career goals. I’m also aware of my own strengths and weaknesses, and help my team in ways that play to my strengths.

Other than doomscrolling, I mean.

Yep here it is, 2:21 and I’m just waiting around until 2:30.

NINE MINUTES TO CHECK THE MAILBOX HERE GOES FUN

Note to self: move mailbox three minutes farther from house

LLMs have no concept of truth or facts, but will just tell you what it “thinks” you want to hear. In this they are perhaps a perfect match for this modern age