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.

(How's that for a hook? Are you interested now?)

So I was a freelance developer for a very long time, mostly in distance learning. In 2003 and 2004, I did a gig for a major publisher, pretty much single-handedly building the front end for a tool that could generate customized websites for each of their titles -- it was a very early precursor to today's learning management systems.

Having taken a long round trip out of that industry and back again, I now work full-time for that same publisher, and just for fun thought I'd try to ask around and see if anyone remembered that old tool I built back in the day.

Friends: they're still using it. Prominently. Almost unaltered. The design is unbelievably dated, significant parts of the UI are broken, and there's still a "this feature is temporarily disabled" apology popup that I remember adding to one of the widgets a couple decades ago -- but it's still in use across a majority of their titles; subsidiary to their new products, but still in there as a top level link.

It predates git (we were using Concurrent Versioning System for code management; the "commit messages" are a string of comments at the top of each file). It predates browser support for PNGs. It predates jQuery. It predates HTML5. It *definitely* predates all current frameworks. Worst of all, it had the misfortune to be built during the years of The Great XML Delusion, when the entire industry suddenly became convinced that XML was the Way Things Should Be Done, so the entire front end was built as a gigantic wad of XSLT templates, a complicated and obsolete language that nobody in the present day wants to relearn (myself included!) Which probably goes some way towards explaining why the broken bits are still broken. Here's the best part: some years after I built it and moved on, I went to a UX conference with Kate Krolicki where one of the presentations was devoted to tearing that exact product apart from a usability point of view (I had introduced what I thought was a clever navigation mechanism, which turns out to not have been clear to a lot of users). So that was fun too.

I have found the person responsible for maintaining it and apologized. I should probably track down a generation of educators and students and apologize to them too.

All this is to say, to my tech-oriented friends: if you ever feel like your work is too ephemeral, that it'll all be replaced when the next framework fad sweeps in, if it ever seems like you're just building sandcastles that'll get washed away by the next tide.... remember that that's a good thing.

What's the worst, most horrifying codebase you've ever worked on? What made it so challenging or nightmarish?

This one’s only horrifying in retrospect; at the time I thought it was some of my best work. (Yes, it’s 100% my fault.)

The product in question was at heart a content management system for generating variations on a specialized type of website in bulk. I was responsible for building the front-end system that would take in the website data and pass it through a series of designed templates to output the finished site.

This was during that brief period of the late 1990s when the entire industry had collectively decided XML was The Way Things Should Be Done, so naturally I decided to build the template system in XSLT.

XSLT, if you’re not familiar with it, was a fascinatingly pure language; its purpose was to transform XML structures into other XML structures and was itself written in XML because XML was The Way Things Should Be Done.

Among other interesting challenges, it was strictly idempotent, which from a philosophical standpoint is awesome but from a practical standpoint meant that – for example – any looping operation had to be done via recursion instead, because incrementing a variable for an iteration loop counted as a side effect, so was Not Allowed. Control flow was best done through data decomposition instead of branching logic. And so on. To people used to scripting languages and markup, it was a real brain-breaker.

I loved it. No longer did I need to wheedle the specific bits of data I needed from the backend guys, it would all just come at me as one gigantic wad of XML, and I could shuttle it through my increasingly gigantic wad of XSL templates to generate anything I wanted. I had so much power! I could do anything!

Now, to be clear, the entire time I was enjoying myself doing this, I knew full well I was working in a doomed language. This was long before modern front end frameworks existed; at the time “front end” skills generally meant you knew Photoshop, HTML, CSS, and maybe a handful of javascript recipes you’d lifted from other sites using “View Source”. And here, by contrast, was this ultra-verbose, weird-looking “front end” language that required some relatively advanced CS concepts compared to what web developers were used to at the time. No way was this going to last.

But I was loving it, I was learning those advanced concepts and feeling like something of a badass for being able to do it. Over the course of a year or so I built up a pretty substantial set of these templates which gradually got less terrible as I learned what I was doing; towards the end, I was writing highly decomposed, idiomatic code that I considered clever, and sometimes even “elegant”. Got them to the launch date, collected my contract fee and moved on to the next job feeling good about myself.

I have it on good authority that they kept those XSL templates in place, untouched, for the next five years until the product was scrapped and replaced altogether because literally no one at the company could understand how they worked. The clever, elegant code was the worst part of course. My earlier, clumsy approaches were the most readable.

That was an important lesson. Dumb, readable code is infinitely better than clever.

Describe a horrifying architectural decision you encountered in a project. How did you deal with it?

This was during my freelancing days. One of my regular clients – a midsize corporation that outsourced a lot of development work – called me in a little bit of a panic: they’d contracted out a small project to a new vendor, the work was complete and they were nearing the launch date. Once they started replacing the test data with the real thing, though, they’d started running into major performance issues: the whole site bogged down when it had more than a tiny amount of data to work with. The vendor was blaming the hardware and recommended upgrading to a much more powerful and expensive server. The client called me in for a reality check before spending that money.

Long story short, the problem turned out to be a utility function these guys had written to make it more convenient to talk to the database: you’d feed it a SQL query, it’d open the db connection, run the query, return the results, then tidy up and shut down the connection.

Very nice, and it did make their code very readable. But the problem, which I’m sure many readers have spotted already, is that opening and closing a database connection is a slow, expensive operation: ideally, you want to open it once, run all your queries, and then close it only when you’re completely finished. The way these guys had written their code, it was opening and closing the connection for every individual operation, meaning sometimes hundreds or thousands of times: once to load a list of data, once again for each and every item in the list. No wonder the server was bogging down!

This turned out to be an easy fix – just remove the ‘open’ and ‘close’ operations from the utility, and move them to the beginning and the end of the program instead of repeating them inside loops. But it was a good demonstration of the danger of shortcuts, and the difference between being able to get something to work, and understanding why it works and what it’s doing under the hood. They never would have had this issue if they had had to write code to open and close the database every time they were doing it, but the fact that it was tucked away in a utility out of view made it easy not to notice.

I think about this pretty much every time I install a new npm module or otherwise import someone else’s code… what otherwise sensible thing is it doing that might ruin my day?

Refactoring Disasters – A story of how you failed?

We had two separate but related web products, built in separate repositories by different teams using different code styles. We wanted to merge those into one product.

Both codebases were large enough that refactoring them into a sensible, unified repository would be a long-term project; we needed a shorter term solution in the meantime.

What we should have done is left the code where it was, unified the UI, and had the site navigation link back and forth between each product as needed.

What we did instead was copy all the code from product A into subfolders in product B’s repository, with the intention of later on gradually refactoring the code from both to match each other, and find and eliminate duplicate functionality as we went.

This might have worked out okay! Except for the fact that the engineer assigned to copy the code over decided it would be a good idea to start doing some of that refactoring as he went; he made a number of substantial changes to the code on both sides according mostly to his own personal taste, to varying degrees of completeness.

He mostly managed to avoid breaking things in obvious ways during this process but also managed to set many subtle traps for his fellow engineers who weren’t aware of the (of course undocumented) changes he’d made. He then, of course, promptly resigned to join a rival company.

(If you’re thinking this whole situation points to major flaws in both the management and the code review processes of that organization, you are not incorrect!)

So we ended up doing that long term refactor in double time, in public view. We got there, but it was quite a ride, involving one of the most rueful retrospectives I ever hope to be part of.

Last I heard, that company was in the process of “breaking up the monolith” and starting in on decomposing that unified front end into, uh, separate but related products.

Have you ever had to deal with a third-party library or framework that caused unexpected issues or complications?

On October 4, 2021, Facebook screwed up their DNS records and locked themselves, and their associated APIs, offline most of the day. This took our application down with it because it was too tightly bound to those Facebook APIs, implicitly assuming they would never be offline. I mean. It’s Facebook, right? Why would Facebook go offline?

Our frantic code rewrite to correct that took most of the day, plus five minutes – in other words, their API came back online almost immediately before we finished deploying the changes that allowed us to work without that API.

Oh well. At least we were ready for the next time.

Have you ever had a terrifying "oops" moment or made a coding mistake that sent shivers down your spine?

I’m pretty strict about making sure I never have access to the production server because I don’t ever want to be the guy who accidentally breaks something on prod.

I have been this guy, though: “Oh what’s this extra code still lying around unmerged? I’ll just tidy up a little bit.” I still have a screenshot from Slack that day:

That was just code, though. You can always untangle code problems. The most truly terrifying moment of my career takes us way back before Slack, before hipchat, all the way back to the email era.

This was at a small but established startup. One of our customer support people sent a late-night message to a bunch of the team, looking for advice on how to handle some issues with a particularly demanding customer. I don’t remember at all what the specific issue was, but it turned into one of those after-hours griping sessions, all of us blowing off a little steam emailing each other our complaints about how difficult these people were and how unreasonable some of their requests… The cc list kept growing, everyone from sales to engineering to the CEO got their digs in, and eventually, the CSR got the answer she needed and went to send that to the customer.

And then came this message back to the list:

“Uh… guys? Guys I think I accidentally just forwarded this whole email thread to the customer”

Cue roughly ten minutes of silence, during which everyone presumably had small heart attacks while scrolling back through the reply-all chain to see which awful statements they were going to have to personally apologize for. It turned out to be a false alarm, she hadn’t in fact sent the whole thread to the customer – but, yeah, that was a cold sweat moment I hope never to have to go through again. Broken code is fixable. People, now, that’s another story.

I was talking about software development with some software developers, as one does. And one of those software developers said a thing that I found really interesting:

“Realistically having no hierarchical structure at all is actually the most suitable design pattern.”

This is a great example of the sort of thing I believed about management, before I actually became a manager. I now know it to be absolutely incorrect.

(I also am aware of how self-serving it sounds for a manager to say that, and that it's a long shot to be able to convince anyone who hasn't actually experienced it otherwise; but I'mma give it a try.)

There were a tremendous number of surprises in store for me when I first officially crossed over to the management track -- not least, that it was in fact a full-time job. When I was first asked to take on a job with the word “manager” in the title, I did so under the illusion that I would be able to continue productively coding alongside my managerial duties. That lasted... maybe six months. Two things happened: first off, there just simply wasn't time enough in the day to do both the building and the managing -- there's effectively an infinite supply of tasks available in both piles. And we had other people around who could do the “building” part. Second, I just wasn't being a terribly effective developer, even when I could carve out the time for it: once you're no longer regularly working within a particular codebase, it starts to move on without you. The tasks that I could reasonably take on with my split attention and availability got progressively smaller as time went on, until it became obvious it would make a lot more sense for me to let go of the IDE.

But so let’s go back to that “having no hierarchical structure at all is ideal” thing. Sure, as a manager I’m able to fill my days and then some, but maybe I'm kidding myself: maybe it's all just bureacracy and sitting in on meetings, and I'm at best ineffective or at worst an active hindrance to getting things done. It sure feels that way from the developer’s seat, sometimes. So now that I've played for both teams I'm going to try to list out, first off, why management happens; and then what it’s actually good for.

Management Is Inevitable

Companies are made of people. People have opinions. Opinions differ. Absence of hierarchy can work in an extremely small group; in a teeny tiny startup you may be able to achieve consensus on every significant issue, but at any real scale at all there are inevitably going to be conflicts that must be resolved somehow. For a company to be successful everyone needs to be pulling in at least mostly the same direction. It doesn't even necessarily have to be the best possible direction, but if you're all canceling each other out you're not going to get anywhere.

Even in the total absence of hierarchy, when those conflicts arise, one of two things will happen: it’ll fall apart, or a hierarchy will naturally emerge. And ad hoc hierarchies tend not to be sustainable for long. The leaders that naturally emerge in that sort of situation are often the least suited to leadership, they're too often the ones who talk the loudest or with the most certainty, not the ones with the best understanding of what's really needed or how to get there. For another, stepping up to that leadership position means taking on a buttload of extra work and responsibility; if there isn't some sort of compensation for that, the only ones who'll be willing to take it on are the ones who are in it for the power and status. So, again, the least suitable people.

If you want good leaders you need to treat it as what it is, a job that's distinct from day-to-day engineering, with sufficient rewards (financial or otherwise) to make it worth taking on.

So, fine, we've got a relatively flat hierarchy, now we grow the company a bit more, enough that we need two or three or four teams, more than a single manager or lead can reasonably handle... guess what, someone needs to make sure those teams aren't working in conflict, so guess what, you either end up accidentally letting the least qualified people drive the bus or you officially add a layer to the hierarchy.

Now zoom out a bit more, you've got engineering, you've got a product team, you've got a design team; someone's got to make sure they're working together and communicating with each other and etc. And so on. End result: large scale bureaucracy.

(And yeah, the bigger a company gets, the heavier its bureaucracy gets, and the more they slow down. That's part of the natural lifecycle of companies, and it's why startups can still succeed -- they can move faster at smaller scale while they hope to grow up (or get absorbed in). And all that extra bureaucracy and slowness has a hidden benefit: it acts as an insulator against bad ideas. The costs of a catastrophically bad decision as a startup are relatively small: you just go out of business and try again. In a giant company, a catastrophically bad decision can end up costing millions and millions of dollars or putting thousands of people out of work or, like, reshaping all public discourse if you're named Zuck or Musk... so maybe it's not a bad thing to slow that new idea down long enough to be sure.)

And aaaaaall of this so far is just the "telling people what to do" part, which is arguably the smallest part of what a manager does all day.

A Sampling Of What Managers Do Besides Tell People What To Do, In No Particular Order

Recruiting and internal career development.

You can't just hire people and put them to work, it's not that simple. Senior engineers come in with their own opinions about how to do things, you need to make sure they become aligned with the rest of your codebase and strategy. Most of the time you want to promote from within, and put the people who already know how your code and product works in control of more of it -- this means identifying the good future leaders, encouraging them to grow those skills, finding tasks for them that will let them learn and make mistakes and grow their abilities and knowledge. It also often also means gently dissuading the ambitious but not-suited-for-advancement developers from trying to put themselves in a role that will be harmful to the company, or finding ways to satisfy that ambition more productively. And it means finding training and continued education for everyone at all levels, so they don't stagnate or fall out of date.

Establish processes and structure.

There is so. much. more that goes into creating a software product than just writing the software. How should we organize the work itself? Scrum? Kanban? Something else? What should our code review process look like? How do we ensure code quality? What should our tests look like? How much time should we devote to maintenance vs new feature work? How do we decide what to prioritize and when? What should we document, and to what level of detail? What does our QA process look like? How much of all of this should be left loose now, at this stage of our company's growth, to evolve organically rather than being imposed from above?

Risk management.

What are we going to do if things go wrong? If the proverbial engineer gets hit by a bus, or that server crashes, or that high-value customer starts asking for a lot of custom feature work, or asks us to comply with some new security or legal standard [shakes fist at SOC2], or someone oopsies on the command line in production, how do we recover? How do we prevent those things happening in the first place? Who should have access to this data or that server or the other customer's email address?

Vendor and third-party partnerships.

There are a billion SaaS products out there to help with everything from observability tooling to recruitment and interview processes to static code analysis to data storage to etc etc etc. Which ones are most appropriate for your company at this stage of its lifecycle and budget, or should you be rolling your own? (Sure, you could treat this as a set of specialist roles, and decide which specialists you can find and want to hire -- but be careful; a database specialist whose only context for the rest of the department's work is being the database specialist, are they going to be able to make good decisions about what the people who'll actually be using the database every day will need?)

Cross-departmental advocacy and strategy.

Sales wants a constant stream of new features to sell. Engineering wants to spend the next few months refactoring the garbage code they had to churn out for the last few months' constant stream of new features. Design wants to update the UI across the product line. None of those people are wrong, there are always competing interests, and management within all of those groups and more need to either figure out how to come to consensus or how to define a new hierarchy so someone can make the decision and get us all pulling in the same direction again.

Morale, culture, and personalities.

Employee A needs a lot of handholding but is afraid to ask for help. Employee B has some kind of beef with Employee C that neither of them wants to talk about. Employee D is talented, but not nearly as talented as they think they are. Employee E is low-key racist. Employee F is usually great but is going through a divorce so isn't really focused on getting their sprint done. Employee G just wants to punch the clock until retirement. Employee H is a rockstar in the IDE but has limited English-language skills. Employee I has a grating personality. Employee J doesn't see the value of unit tests, so refuses to write them, and their code keeps breaking in production. Employee K keeps showing up to meetings late or not at all, and even when they do you're petty sure you know the reason their camera is always off. Employee L is bored with what they've been working on and wants to switch to a feature area they don't have any experience in. Employee M keeps trying to shed their workload onto Employee N. Employee O is basically useless and everyone knows it, but their uncle is on the board. Employee P is a complainer. Employee Q has a lot of great ideas but no followthrough. Employee R is quiet, poker-faced, and impossible to get a read on. Employee S puts in the hours and then some, but their code is unreadable. OK, those are your reports, now figure out how to get all those people working together as productively as possible, or decide which ones are unsalvageable and need to be fired (but figure out how to do that in a way that won't freak out the rest of the department). Good luck have fun!

So, yeah, that's some of it. I was sort of aware, when I worked as a developer, that this sort of thing was going on; but the amount of day-to-day energy that has to go into it, and the degree to which that effort shapes the company, really caught me by surprise. All those meetings and memos and directives and decks aren't just for show or to get in the way of the real work. (Even more surprising was seeing from the other side the amount of influence individual non-managers also have on shaping the future -- but that's a whole other story, we'll save that one for later).

Code gets dusty awfully quickly! What keeps happening is, I get distracted and forget to update this website for a while, and then the code rot sets in and I'm unable to update the site for some extended period of time until I get around to either fixing it up again or replacing it completely.

I did not, this time, have to rewrite the technology underlying this site from scratch in order to get it running (though I was tempted, and actually got a pretty good way into building a web components-based static site generator before I came to my senses.)

Instead, I had to

• Fix an encoding error in the database, where at some point the UTF-8 content got re-encoded as ISO 8859-1 causing a lot of "n£" mojibake. (I spent a while barking up the wrong tree on this one: the encoding in the static-rendered files was correct, and the mojibake only showed up on hydration; therefore I spent way longer than I should have fiddling with content-type headers, thinking the data was getting corrupted in transit. Turns out the static files just predate the database problem.)
• Get a working Vue install running on a new machine. Since I'm the only one using this software, I set up this site so that the authoring tools appear when running in development mode, but are not currently included in the production build. This is very convenient, and means everything is in place to turn this into a multi-user site if somehow I ever found a reason to do that; but means that to write a new blog post I have to actually run the site build tools locally in dev mode. The code was all sitting comfortably in a git repository, that part's fine, but
• most of its dependencies are out of date or outright deprecated.
• The command-line tool for installing the framework and its dependencies was deprecated.
• I had to install new old versions of node, npm, node-sass, and eventually python, which some build tool deep in some sub-dependency's stack wanted for some reason
• (And then update each of those a step at a time to get them as current as possible without introducing too many breaking changes)
• Having done all that, and finally getting the site to run locally, I discovered I needed to track down a 'credentials' file which I had carefully .gitignore'd (because you don't want tokens in the cloud!), and therefore lost, (because the cloud is where I keep all my stuff!)
• I also needed to temporarily disable the part of my code that checks the user's password, because I had forgotten it and it was only stored in encrypted form in the database. (For whatever reason, I built really robust security into a blogging tool that will only ever be used by one person. There's a nonce on every api call to mitigate bearer token theft. I don't know why I thought I needed that.)
• Lastly I needed to modify the SQL table structure again, because somewhere in the process of debugging the encoding issues way back in step one, I dropped and recreated a table, and lost the auto-increment setting on one key.

And now I have a functioning website again. Easy as that!

Narrator: It was not as easy as that

Turns out that while developer mode is working fine, so I can talk to the database and add and edit these posts, building a deployable update to the app is still not possible. Something deep in the internals of PrerenderSpaPlugin is, I'm pretty sure, getting from something deep in the internals of webpack a Promise when it's expecting a callback, or maybe the other way round, anyway static renders are failing silently and I haven't yet figured out why.

Modern software development is mostly a matter of gluing things to other things, connecting this framework to that database using this dependency and etc. That sure doesn't mean it's gotten easier.

(In particular I feel like we're due for a reckoning for putting so much trust in npm. It's so convenient depending on other peoples' code, but those dependencies go out of date or accrete incompabilities so quickly, even if you're actively maintaining a project it can be hard to keep up with new vulnerabilities and breaking changes from dependency updates; set a project aside for a while and you're pretty much guaranteed to have to rebuild its whole infrastructure from scratch next time you want to pick it up again.)

The bad old days

From the invention of javascript in 1995 to the release of Firebug in 2006, the only way to debug your client-side code or design was trial-and-error: if something wasn’t working, or didn’t look right, you’d change something, see what happened, and keep trying until you either figured out the problem or, well, didn’t.

We’re not talking about littering your code with `console.log` instead of using a debugger – there was no console. There was no DOM inspector. There was just the rendered page and your source code and an F5 key worn smooth from constantly reloading the page after every change.

We could get away with this, mostly, because at the time what was happening inside the browser was much less complicated than the activity on the server: the browser was just for layout and maybe some light interactivity. Anything significant that might go wrong with the application logic would show up in the server logs where you could track it down later.

Observability in modern software development

These days, when your entire application is just as likely to be running inside the browser with the server doing little but handing out data through an API, that’s not good enough. While you’ll still run into the occasional novice whose idea of debugging consists of using the `alert()` box, few people would argue that that’s the best or even a viable approach.

In-browser developer tools started out as little more than a console for logging ajax requests, but over the years have grown into a robust set of tools for examining our work while we’re working on it: you can easily inspect any DOM element to see which CSS rules are affecting it and why; you can pause your code while it’s running to see or even modify its internal state; measure performance directly to identify problems, even use higher level tools built for specific frameworks to examine for example React component state.

And these tools will continue to grow in power and available functionality both within the browser and with more targeted tools.

But once that application goes into production, you’re working blind again.

If you have ever found yourself asking an end user if they know what a developer console is, and if they know how to open it, then you know how challenging it can be to identify and debug a problem that is only happening on someone else’s machine. “Hit F12 and try to describe what you see” is a frustrating experience for the user and the developer both – but what are worse are the problems you never even find out about, either because it’s only partly broken and the user assumes it’s supposed to be like that, or because it was so irretrievably broken they abandoned your product altogether.

If you’re finding yourself in that position, you probably want to consider investing in some observability tooling for your app. Sometimes called “real time user monitoring” (RUM) or “digital experience monitoring,” at heart this is, basically, the modern front-end equivalent of those old-school server logs: tracking client-side errors by logging them as they occur and providing detailed information about the error, such as the browser and version, the location of the error in the code, and the user's actions leading up to the error. This information can be used to identify and fix issues quickly, improving the user experience.

In principle the most basic form of this monitoring is an afternoon’s coding exercise: catch all errors, post error messages to server, job well done! But in practice there’s some nuance to making sure you’re not missing anything: monitoring software is maybe not quite as useful if the errors you’re monitoring for can prevent the monitor from running.

For any nontrivial application, unless you are extremely budget-constrained I’d suggest investing in one of the existing observability tools purpose-built for this sort of thing – they’ll have more robust data capture than you can easily build yourself, can scoop up lots of additional useful information along the way (which user had the problem? What browser, on what operating system, from what region, etc?) and will also generally include search and visualization tools for searching through all that captured data, flagging newly discovered issues for your developers’ attention, and generating all the charts and graphs your management team could ever desire.

Sifting through observability data: uncovering relevant insights

The observability tool I’m most personally familiar with – I’m going to choose not to name and shame, because from what I can tell this is a common problem – while it captures a tremendous amount of useful information, it does not always offer the most intuitive ways of surfacing that information. The UX has, let’s say, a steep learning curve. At my last org we had to make conscious effort to remind engineers to actually dig through those reports regularly, and to train them up on how to locate the relevant data for a specific user complaint – you can set alerts for major outages, but tracking down the right information to explain a problem only one or a handful of users were having wasn’t always the easiest.

The fact that we were responding to user-reported errors and then trying to find the explanation in the captured data is already a sign of this not working as well as it could: ideally we would have been identifying and resolving these issues without the user needing to report them to us. Better than not having the data at all, of course, but the tooling is not the whole story; it takes care and diligence both to configure these tools usefully, and to use them effectively. As above, monitoring software is maybe not quite as useful if nobody’s looking at the monitor or if the monitor is capturing so much unneeded data that it becomes difficult to identify what’s significant.

Observability, not surveillance

It’s important with any data capture tool to use that data responsibly, and with sensitivity to both legal and human concerns. Once you’ve built in the tooling to capture errors, it’s pretty straightforward to also capture information about the user’s session that aren’t errors – up to and including, well, literally every action the user takes. Used properly this can be tremendously useful: you can see which features users prefer and how they use them, which parts of your application load too slowly, where users give up on your sales funnel, what info they type into every form field… and at this point hopefully the PII issues here are obvious: particularly if your application handles financial, medical, or other sensitive data it’s extremely important to filter out info you don’t want to be capturing, and to control who in your org is able to access what you do capture. In all cases you need to make sure your Terms & Conditions have the proper disclosures about what you’re capturing and how you’re using it. I’m not a lawyer, don’t ask me; talk to someone in Legal at least once before you start playing with these tools, is what I’m saying.

And even with the data that’s not inherently sensitive, it’s important to make responsible use of it. That customer on the support call who’s complaining that they’ve been struggling to get past an issue in your product for HOURS and HOURS – it might be personally satisfying to tell them that you can see in the logs they tried twice and then gave up, but the customer is probably not going to be happy about that interaction even after you solve their issue. Basically, don’t let your use of these tools cross over from observability into surveillance.

TL;DR

The work we do these days is too complex and too important for it to be feasible to simply throw your code into production and hope it works. Depending on user bug reports guarantees you’re not seeing the problems in your code early enough; for any user who took the time to contact your support team, there are probably dozens or hundreds who encountered the same problem. Observability tools are not magic and they have some drawbacks – existing tools can be complex to configure, difficult to use effectively, and are frequently expensive – but they’re an essential part of the modern developer’s arsenal.

Can you please tell us about yourself? Your technical experience, cool projects you’re working on, and all the fun stuff:)

I’ve been working on web-based applications for as long as the web has been around to work on: the browser in use at my first job was NCSA Mosaic. (We were all very excited when Netscape came along and introduced innovations such as a background color that wasn’t gray.) It was pretty easy to get into the industry back then, you just had to learn all five HTML tags and you were all set; from there it was just a matter of keeping up with changes as new ideas get introduced and old ones fall out of favor. I’ve worked as a designer, a UX specialist, in product development, and in engineering teams; I’ve done stints as an IC and in management. I even tried the solopreneur thing for a while, during which I learned I really need someone setting external deadlines for me if I’m going to get anything done.

Please describe your organization's R&D department structure. Specifically, your team? (Size, roles, etc.)

I’ve done my share of “real” jobs, but much of my work has been as a consultant, which means I’ve been able to see inside a lot of different organizations at everything from startup to global scale. In practice, while the details differ across orgs, this generally boils down to one of three general situations:

• Startup scale. Small team, low process overhead, everyone has full visibility into what everyone else is doing, the codebase is greenfield and the product definition is still pretty vague.
• The transitional phase, where that startup starts to find success and suddenly needs to start working at scale. There are lots of potential pitfalls here – practices that worked just fine when you were all in the same room start to fail, and it’s really easy for companies to lose focus or jump to the wrong solutions.
• The well-established organization: there’s a process for everything, roles are well defined, and the scope of authority for any given team or individual is smaller and more focused. It’s hard to ruin a company at this stage – all the bureaucracy that’s built up over time acts as an insulator against bad ideas – but it’s also hard to keep up the pace or do anything truly innovative. (Unless you spin off a skunkworks and start the cycle anew!)

Each of those phases has different challenges and needs a different structure.

In an early startup you probably shouldn’t even try setting up too much process or code architecture; any predictions you make about what you’ll need before you find your product market fit are likely to be wrong.

In a very large organization the main challenge is visibility and trust: now you’ve got multiple departments – design, product, engineering, program management, etc – each with multiple layers of management all trying to work on the same product. All of that structure is necessary to organize the large numbers of people involved, but it can lead to a disconnect between decision-makers and actual reality.

That middle zone is the really challenging one – you really do have to throw out a lot of what used to work, which can be very painful for the people used to working that way. (It’s also, in my opinion, the most interesting: it’s where you really get the opportunity to make big changes and to build for the future. At a startup you have to just keep trying things until one works; at an established organization most of the interesting decisions have already been made.)

On a scale from 1 to 10, how complex do you think your code base is and why? (i.e., Kubernetes, local clusters, Monolith or microservices, DBs, Git methodology (trunk or feature branches), Monorepo or multi repo, etc.)

I’m afraid I’m going to dispute the premise of the question a little bit here. There are different kinds of complexity; some of them are unavoidable (algorithmic complexity), some of them are self-inflicted (tech debt or conflicting code styles), some are organizational (business rules evolve faster than code does), some of them are tradeoffs you make to reduce other kinds of complexity.

So the trick isn’t “let’s make our codebase less complex,” it’s identifying which complexity is harmful, and which is necessary for the current stage of your company.

The architectural complexity of microservices or Kubernetes is a great example of tradeoff complexity: microservices, Kubernetes, Terraform et all are inherently much much more complex than their traditional equivalents; that complexity is the price you pay for scalability. I see way too many small or mid-size companies jump into these complicated solutions too early, or just because they think they need to, and end up accepting that architectural complexity before they’re feeling the pain points that would justify it. If you’re not routinely needing to spin up and configure new containers, you don’t actually need Kubernetes. That pool of Terraform-configured step functions could probably have been built a lot more quickly and easily as a plain old API. Basically, if you’re not working at FAANG scale, you probably don’t need FAANG-scale tooling to get your job done.

Git methodologies are another good one. I’m old enough that my first encounter with source control was CVS, in which developers would literally “check out” the file they were working on, blocking anyone else from touching that file until they checked it back in. (That’s one way to prevent merge conflicts!) Subversion improved on this, it had what could charitably be described as “branches”, but it wasn’t until git that a real branch-and-merge strategy was really viable; to work effectively before git you had to do a lot of communication and keep your changes small and focused.

What engineers who grew up on git tend to forget is that it was designed for a specific purpose – managing a large number of contributions from a variety of external sources into the linux kernel – which doesn’t necessarily match the way a lot of engineering teams work. (In a way git itself is another architectural complexity tradeoff: you accept the fact that merges are hard, in exchange for allowing independent teams to work simultaneously on the same code.) GitFlow was a fairly elaborate process that evolved, mainly, to minimize the pain of those merges. The thing is, though, most engineering orgs aren’t the linux kernel, they’re not made up of teams of external contributors who have no choice but to work independently and deal with the conflicts at the end. So it’s interesting to me that that trend is now starting to swing the other way, as more and more organizations realize that smaller, more focused commits merged constantly are just a better way to work (for lots of reasons, not just avoiding merge headaches, but that’s a key one).

I’m 100% a convert to trunk-based development after seeing how much it improved our process at my last organization; switching from long-lived branches to quickly-merged code and a simple feature flag system was one of those rare cases of an absolutely unambiguous improvement; the whole problem of code merges just evaporated overnight. Don’t get me wrong, I love git, you couldn’t pay me enough to go back to the bad old days of file locks, but long-lived branches are unnecessary and cause more problems than they solve. I wouldn’t be surprised if some future version of “source control” ends up looking a lot more like real-time collaborative editing than like what we’re used to doing today.

Can you describe your development process? (Describe a common process from writing the code locally until it reaches production) Do you follow a certain methodology?

Every single organization I’ve worked with in the last couple decades has described themselves as using an Agile methodology. None of them mean the same thing by it – the only thing everyone agrees on about Agile is that everybody else is doing it wrong. “Agile” as a concept is a little overripe at this point; the consultants have got hold of it and formalized a bunch of rules and roles that I’m not convinced fit every organization that tries to use them.

But the core principles of it are still essential:

• Work in short, iterative cycles, both for planning future feature development and for the design and implementation.
• Check what you’re building against real users as frequently as possible, to make sure you’re building the right thing.
• Maintain a culture of open feedback between product, engineering, and design – they are not separate processes.
• Same thing between labor and management. Developers need to feel safe telling their bosses they've made a wrong decision.
• Same thing within engineering teams; developers should be reviewing each others code, suggesting improvements, and accepting feedback from one another.
• Move small changes into production frequently, rather than doing a few big releases with big changes.
• Iterate, don’t redesign.
• Automate everything you can, earlier than you think you need to.

Where do you think the blind spot in your delivery process is?

I think the most important and challenging part of coding is not the delivery process, or the build process, or the testing or the framework or the documentation – it’s in deciding what to deliver in the first place. If you can nail that part, if you can predict accurately enough what your users need, the rest pretty much just follows on its own.

Keeping your releases small and frequent makes this much easier, because you don’t have to predict with perfect accuracy: you can try out a small thing, iterate on it if the users like it, or abandon it without too much sunk cost if they don’t.

This is tremendously challenging for a lot of organizations; especially in those not used to continuous delivery there can be a lot of pressure to stuff too many ideas into every new feature. Which leads to a vicious cycle: overstuffed releases take longer to develop, which increases the pressure to stuff even more things into version n+1, because everyone knows it’s going to be a long time before you’ll get a chance to add anything in version n+2.

At which phase do you perform testing? (i.e., local, CI, production)

Personally I’m a big fan of test driven development when I’m building something complicated, less because of the resulting code coverage and more because it’s just easier to think through whatever the problem is one edge case at a time instead of trying to reason about it all at once. Write a test for each case, write code until all the tests pass, and you’re done.

This doesn’t necessarily result in tests that will be particularly useful after the code has been written, though. It's pretty rare that an old unit test will suddenly pick up on a bug in unmodified code. So you also need to be doing some integration testing to make sure all your bits and pieces are working together -- it's much more common for a change in module A to trigger unexpected consequences in module B. I'm not sure there's a one-size-fits-all approach to this, it really depends on the product and the scale you're working at. Maintaining a quality test suite can be a lot of work especially when your product is going through a lot of changes: it's really a whole separate codebase that has to be kept up to date with any changes in feature or business logic, and there's always pressure to be writing more features instead of writing more tests. At small scales, or in periods of rapid change, manual testing may be more efficient than trying to maintain a fully automated test suite; as the features start to stabilize, or grow past the point where testing everything by hand is feasible, it's important to make time to set up a real staging environment with production-like data, and set up automated workflows against it to make sure the outcome is what you expect.

And of course you'll miss things. It's inevitable. So you have to have production monitoring, some telemetry that'll notify your engineers when something breaks in real users' hands. (And you have to have a process in place that ensures the engineers actually see those notifications and can claim the time to do something about them.)

Do you see the connection between complexity, feedback, and productivity? Do you measure developers’ productivity, and if you do, how?

I actually spend a lot of my time trying to talk management out of leaning too heavily on productivity metrics. They’re tempting traps, because there are so many numbers you can measure and charts you can make and it all looks so much like science that you could be forgiven for forgetting that they don’t actually measure productivity.

We’ve all figured out that counting lines of code or hours-on-keyboard are useless metrics, so far so good; now we just need to learn the same lesson about code coverage, PR size, TTO, TTM, story points per sprint, rework percentage… All of those things can be meaningful signals, but they’re not measurements of productivity. A long cycle time might indicate any number of different things: maybe the requirements were unclear or are changing, maybe the team is having to refactor a lot of legacy code before they can progress, maybe the team got walloped by some other unplanned work, maybe there’s a lot of friction somewhere in your development process, maybe the thing the team is working on is just genuinely difficult, maybe there’s disagreement within the team about how to build the thing, maybe somebody’s slacking off and bottlenecking the rest of the team. The point is you just don’t know from the metric itself whether it even is a problem, let alone what to do about it. (I’d much rather have a team with the slow cycle time because they went back to the product team to clarify the requirements, than the team that just plowed ahead and built the wrong thing very quickly.)

What efforts do you implement or recommend to enhance your or your teams’ productivity?

The thing to remember, the really important thing, is that engineers like solving complicated problems. They like writing code and building things, that’s why they’re in this line of work! Give an engineer a meaty problem, the scope and authority to solve that problem, and a development environment that isn’t going to get in their way, and they’re going to be productive every time.

My main goal as an engineering manager is to get out of my teams’ way, and to do my best to keep the rest of the organization out of their way too.

The biggest productivity killers:

“I don’t know why we’re building this feature” is a huge one. If a team is building something just because they were told to, and not because they understand its value, they’re going to be undermotivated (and will likely build the wrong thing, to boot.) The best solution to this is to have as few people as possible between the engineers and the actual users, and to empower your engineering teams to push back on ideas that don’t make sense to them.

“I spent all day in meetings” or “interrupted by questions” or “responding to pagerduty tickets” or similar. This one’s pretty well-known; software engineers need uninterrupted focus time. Make sure they get it. Encourage them to block out segments of the day in their calendars, reduce the number of routine scrum ceremonies and planning sessions you subject them to, and if someone keeps peppering your engineers with questions or one-off requests, empower your engineers to say “no” (and find some less-interruptive way to get that person what they need).

“I spent all day tracking down [a bug / the right config / a particular error message / a stray semicolon]”. Everyone gets hit by the occasional head-scratcher of a bug that takes way longer to sort out than it theoretically should have, and to a point that’s fine. But if it’s happening routinely, that’s another signal that needs looking at: maybe your code isn’t sending out accurate error messages, making bugfixes take longer than they should; maybe your engineers are working in an environment or context they’re not familiar enough with or that is too bleeding-edge; maybe they’re working in an inefficient way. (This last one is, ironically, especially common in orgs that put a lot of emphasis on fast delivery: engineers under pressure to churn out code don’t feel empowered to take the time to figure out, say, why their sourcemaps stopped working three months ago, so instead spend time trying to debug compiled production code. You need to give your team time to streamline their own processes.)

Friends, don't let friends start any more business intelligence SaaS products, there are more than enough already

(Not me in this case. I've long wished for a way to put, like, a five-year delay on my posts so I can safely talk about work stuff. Check back in 2027 for the scoop on that one, I guess. As preemptive penance for vaguebooking, here's a story from my own career that fits):

I got fired from my first real job in this industry. It was legit, and the right choice for the company: major mismatch between me and the CEO, both he and I were frankly too young and inexperienced to resolve it appropriately, and honestly I had kind of lost faith in the mission and was not putting in the energy needed by a startup at that phase of its lifecycle. (Hindsight, amirite?) It was the early days of Internet 1.0, so like all internet companies ours was run by a bunch of children and one graybeard, as was the fashion at the time. Our particular grownup was Dick Sabot who, among his many more significant accomplishments, was able to inform me that I should under no circumstances walk into that building ever again, in such a way that had me nodding happily along in agreement. It wasn't until literally hours later that the penny dropped and I realized I was newly unemployed. Skills.

(Here I am now, almost three decades later, in a managerial position myself. I'm semi-fluent in corporate comms -- I can hear and understand it, but never came within a mile of Dick's level of fluency in delivering it; instead I've opted for a much more blunt "I have no poker face whatsoever, you will know at all times exactly what I think of your ideas." Which suits! Because I do, in fact, have no poker face whatsoever. FWIW my reports seem to appreciate that directness; those managing me tend to either value it highly or be supremely irritated by it, not much in between.

"the attacker is clearly not overly familiar with the product so they spend time looking up Q&A on Stack Overflow on how to use and configure it. This act of looking up things (visiting questions) across the Stack Exchange Network becomes a frequent occurrence and allows us to anticipate and understand the attacker’s methodology over the coming days."

(I'm copying this over from a Stack Exchange answer I wrote a few years back, basically because I want to be able to link to it as part of my portfolio in a way that will make sense to people who don't live and breathe Stack Exchange. This was written for UX designers; if I were to put together a corresponding essay from the developer's point of view it would... well, it would be the same but different; I may need to think about doing that one of these days....)

Question

As we know, in UX design it is important to care about pixel level details in addition to the big picture. Meaning that all UI elements are perfectly aligned, correct colour, etc. However, from time to time I get comments like "is this really important, maybe users will not notice this?" from other dev team members. What would be the best way to get people understand the importance of pixel precision and small details?

Answer

I've been on both sides of this one, at different points in my career. Defusing this type of conflict gracefully is extremely important for an organization: once the relationship between dev and design becomes an adversarial one, your product will suck, it's just a matter of time. The "Stand your ground! My way or the highway!" type of response are going to be awfully tempting, especially in the moment, but will be counterproductive in the long run.

There are certainly cases where this is simply the result of laziness or a lack of skill on the part of the developer. We've all seen that happen, 'nuff said. There are, equally, cases where it's arrogance or a lack of knowledge on the part of the designer -- I've been on the receiving end of layouts for the web that were put together by someone with a good eye but no understanding of how HTML works, which would have been genuinely, and (more importantly) unnecessarily difficult to implement without a bit of adjustment.

But even in the best circumstances, assuming good faith and talent on both sides, this sort of conflict will still arise. Negotiating this is a long-term process -- below I'm going to be describing the best case scenario to aim for; not all of this will be fully achievable in all organizations or situations, but at least it may give you a sense of what to aim for (or of whether your org is already so dysfunctional as to be beyond salvage...)

Find your allies

Some developers care more about usability and product appearance than others; some will simply be better at it than others. If your dev team is large enough to have split into front-end and back-end specializations, this sorting-out process will likely already have started for you; otherwise start paying attention to which of the developers seem literally unable to see whether elements are aligned or the wrong color, and (through product management, or individual conversation, or machiavellian intrigue, or whatever works in your organization) try to get the least-interested-in-UI developers assigned to tasks where they can do the least damage.

Get developers involved early in the design process.

The worst case scenario, to be avoided at all costs, is the one where you throw a completed design over the wall to the dev team and move on to your next task, while they're left in isolation to implement it. The more you can integrate those processes, the better for everyone.

This doesn't mean "ask the developer to do some of the design work" -- but the dev team needs an opportunity to chime in on a design early, to point out aspects of your design that may prove difficult to implement, or even to contribute technical details that could make the user workflow easier. This can also give them time to shape their early development work in ways that will make implementing your final design easier or faster or just plain better.

The social aspects of this are worth mentioning as well: exposing developers to your design process, rather than just its end results, can give them a better understanding of what goes into the design and why; and conversely it can help the design team to:

Understand the technical consequences of what you're asking for

Some design changes are easy. Some would require substantial rewrites of large chunks of code. It's not always going to be obvious which is which; often it depends on implementation choices that were made years ago. Maybe the technical consequences of that beautiful design are just too high; maybe there's a different or modified design which would serve the same purpose at a much lower cost. Part of this is a matter of keeping lines of communication open between the teams, but part of it is the responsibility of the designer to have at least a baseline understanding of how those designs ultimately get built. The (thankfully increasingly uncommon) photoshop-only designer is simply not qualified to do web design, in my opinion -- they're going to constantly be making design mistakes that they don't even know are mistakes. This benefits no-one.

Be able to articulate specifically why what you're asking for matters

I constantly use this as a reality check on my own designs, even when I'm working solo: I find that if I can't describe, in words on paper, why a particular aspect of my design needs to be the way it is, then it probably doesn't.

It's not enough to say "it looks better this way," you have to be able to explain why it looks better that way.

This is a vitally important career skill. It's crucial for communication with management and with developers, of course. But it'll also make you a better designer, because it forces you to examine your own work critically, and to understand in a rigorous, methodical way, which aspects of your design actually work well and which ones are just pretty. Pretty is important, but it's not sufficient.

(The "users won't notice that" thing, incidentally, is a red herring. Users often won't notice that -- that's the goal; if they're noticing something, it probably means they're noticing a problem. Users also don't notice whether the dev team has normalized the database properly, or whether they picked framework X over framework Y, but that doesn't mean those choices are unimportant. Similarly, most users may not consciously be aware that an element is off alignment or a slightly wrong shade of blue, but enough of those will contribute to an overall impression of sloppiness or lack of polish.)

Prefer style guides over mockups

A mockup, by definition, only covers a single program state; it's not possible to build mockups for every possible situation, so at some point or another the developer is going to be left to come up with a way to cover some case you didn't think of. If there's a solid, comprehensive style guide in place for the project, they're much more likely to come up with something that works. If there isn't, they'll either have to come back to the design team to ask for more mockups, or they'll just wodge something together the best they can. You know how well that usually works out.

Another advantage to style guides over mockups is that it makes the developer more involved in thinking about the design as a design. Few people enjoy just doing the grunt work of fulfilling someone else's plan to the letter -- it's much more engaging and motivating to be empowered to contribute to that plan, if only in small ways. Given a good set of ground rules, most (admittedly not all) developers will be more than capable of doing so.

And a third advantage: it keeps you honest as a designer. It's easy to inadvertently gloss over the hard parts of a design when building a mockup: your lorem ipsum fits tidily in the space available, the amount of content is always just right, that messy edge case dialog box isn't necessary, etc. Designing rulesets and guidelines, rather than individual screens, forces you to think about the product as a system rather than as a collection of pretty pictures, which always benefits the end result.

Choose your battles

"Pixel perfect design" is not actually the goal, and it's very important not to slip into that mode of thinking. A completed, usable, attractive product is the goal. This, as with all other aspects of design, is a matter of acceptable compromise between competing interests; this necessarily includes the developers' interests.

The fact is, some pixels are more important than others. Before wading into a fight on any particular issue, make sure it's going to be one for which the payoff is worth the battle. Be prepared to accept pushback and critique from the developers just as you would from management, sales, and end users, and do your best to work with them rather than against them.

This means that I at last feel sufficiently well-informed to make the following statement:

JSX is an abomination upon the earth; a soulless attack on the very concept of markup languages; an unreadable frankensteinian mishmash of not-quite-javascript with not-exactly-HTML whose purported advantages are more easily accomplished in other frameworks by just being sane about how you structure your templates.

I do not like eeeet

ok end of nerd rant thx

It really makes me feel a lot better about the quality of my own work. And a lot worse about the quality of the industry I work in.

Srsly I'm sitting here looking at a glossy ppt deck full of insights like "No users in the test understood what this button was for. Recommendation: draw more attention to it by making it bigger and bolder" I mean COME ON

Trufax guys, I was seriously tempted to just play along and see how far into the job I could get before anyone realized I was not who they thought they were hiring. I srsly think I could maybe have pulled it off, it would have been a little bit of a stretch, but I could totally learn python if someone was paying me to

AND ALSO why are so many people named Daniel Beck software developers? I mean really, it's just implausible. Besides this guy and me I know of at least one in Brazil and another in Germany (because over the years I've received mail meant for each of them, because I have the firstname.lastname@gmail address and they don't.) Is it that common a name? Does something about it draw people towards algorithms? Are our simulitarian overlords just being lazy? EXPLAIN

• Firefox 46 supports some -webkit prefixed CSS properties
• WebKit is moving away from prefixes

(Emily didn't get it either. Trust me, it's funny)

Shit. And many other expletives.

EDIT

Thanks folks for your kind words after my little temper tantrum this afternoon. After some more research I'm no longer at all concerned -- the products (I'll stop being coy, it's brave.com) are far less similar that I at first thought, and our end goals are, let's say, entirely orthogonal. Which is nice, because I didn't fancy my chances going head to head against Brendan Eich.

Also it, uh, surprise, sorta turns out their product head is an old friend. Small world! (Hi, Elissa! I can't say I'm a fan of your company's business model, but, seriously, congratulations, that's a major step up)

So I'm taking this as the kick in the pants I needed to start moving more quickly, and (soon) more publicly, on this thing. Maybe even pick a name for it. (The domain name for my working title "unfuck the web" is taken. Probably for the best.) But I'll cook dinner first. The web'll probably wait *that* long at least

I hope

Somebody stop me before it is too late

That's everybody covered, right? I'm pretty sure that's everybody

For some reason this recruiter’s email reminded me of that