Comment by onion2k

I am very similar in this respect, however once I get to a place where I am implementing something very similar to something in my past, it becomes easier to draft a doc first because I have been down that path before

That’s why I either started with the ports and adapters pattern or quickly refactored into it on spikes.

You don’t have to choose what flavor of DDD/Clean/… you want to drink, just use some method that keeps domains and use cases separate from implementation.

Just with shapes and domain level tests, the first pass on a spec is easier (at least for me) and I also found feedback was better.

I am sure there are other patterns that do the same, but the trick is to let the problem domain drive, not to choose any particular set of rules.

Keeping the core domain as a fixed point does that for me.

The problem is that you can only meaningfully pair program with programmers. The people involved in architexture/design meetings might not be programmers. The questions that arise when 2 programmers work might not be resolvable without involving the others.

I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious that asynchronous review cycles are way too slow nowadays, and we're DDoSing our project leaders who have to take responsibility for engineering outcomes.

I’ve started pair programming with Claude and it’s been pretty fun. We make a plan together, I type the code and Claude reviews it. Then we switch.

Maybe it's time to do pair agentic engineering? Have two engineers at the screen, writing the prompts together, and deciding how to verify the results.

You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion.

> I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times.

My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for the third time, to get to a much worse product slightly faster. Now we can do that part 10x faster, cool.

The thing is, at every other level of the company, people are actually planning in terms of quarters/years, so the underlying product being given only enough thought for the next 2 weeks at a time is a mismatch.

> Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks.

That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.

> > Most of what's planned falls down within the first few hours of implementation.

> Not my experience at all. We know what computers are capable of.

You must not work in a field where uncertainty is baked in, like Data Science. We call them “hypotheses”. As an example, my team recently had a week-long workshop where we committed to bodies of work on timelines and 3 out of our 4 workstreams blew up just a few days after the workshop because our initial hypotheses were false (i.e. “best case scenario X is true and we can simply implement Y; whoops, X is false, onto the next idea”)

Comparing the same work done between agile and waterfall I can accept your experience of what sounds like an org with unusually effective long term planning.

However the value of agile is in the learning you do along the way that helps you see that the value is only in 10% of the work. So you’re not comparing 100% across two methodologies, you’re comparing 100% effort vs 10% effort (or maybe 20% because nobody is perfect).

Most of the time when I see unhappiness at the agile result it’s because the assessment is done on how well the plan was delivered, as opposed to how much value was created.

> I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring.

That’s not the point. The point is to end up with something actually useful in the end. If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it.

The reason waterfall methodology falls flat so often is not long delivery times, but ending up with completely the wrong thing.

I think it also depends on how people think. I might be able to sit can't sit in a meeting room/white board/documentation editor and come up with what the big problems is (where pain points in implementation will occur, where a sudden quadratic algorithm pops up, where a cache invalidation becomes impossible, ...) even if I stare at this white board or discuss with my peers for days.

But when I hammer out the first 30 minutes of code, I have that info. And if we just spent four 2-hour meetings discussing this design, it's very common that I after 30 minutes of coding either have found 5 things that makes this design completly infeasible, or maybe 2 things that would have been so good to know before the meeting, that the 8 hours of meetings just should not have happened.

They should have been a single 2 hour meeting, followed by 30 minutes of coding, then a second 2 hour meeting to discuss the discoveries. Others might be much better than me of discovering these things at the design stage, but to me coding is the design stage. It's when I step back and say "wait a minute, this won't work!".

Agile is for when you don't know what you're making and you're basically improvising. People forget that.

Would love to be a fly on the wall for a couple of months to see what corporate CxO's actually do.

Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin. Probably wouldn't be a massively successful one, but good enough to survive 2 years and have millions in the bank for that, or get fired and get a golden parachute.

(half) joking - most likely I'm massively trivializing the role.

Software engineers are pushed to their limits (and beyond). Unrealistic expectations are established by Twitter "I shipped an Uber clone in 2 hours with Claude" forcing every developer to crank out PRs, managers are on the look out for any kind of perceived inefficiency in tools like GetDX and Span.

If devs are expected to ship 10x faster (or else!), then they will find a way to ship 10x faster.

>> Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to.

I have been doing this to, and I've forgotten half of them. For me the point is that this usage scenario is really good, but it also has no added value to it, really. The moment Claude Code raises it prices 2x this won't be viable anymore, and at the same time to scale this to enterprise software production levels you need to spend on an agent probably as much as hiring two SWEs, given that you need at least one to coordinate the agents.

> little structs and helpers all over the place that we already have in common modules

I've often wondered about building some kind of automated "this codebase already has this logic" linter

Not sure how it would actually work, otherwise I'd build it. But it would definitely be useful

Maybe an AI tool could do something like that nowadays. "Search this codebase for instances of duplicated functions and list them out" sort of thing

> Does it? Reverting a bad deploy is not only about running the previous version.

It does. We’ve tried. No it’s not as easy as running the previous version.

I have written about this: https://swizec.com/blog/why-software-only-moves-forward/

Having data model changes be a part of regular deployments would give me persistent heartburn.

[dead]

> Expect to pay me for the availability outside work hours.

We pay people enough to care about the software they ship.

Don’t want to be called outside of work hours? Make sure your code works. Simple.

That's the polite version of "we know where you live". Telling someone you have their phone number is a way of saying "we'll call you and expect immediacy if you break something."

Wanna be treated like an adult? Cool. You'll also be held accountable like an adult.

Never received a phone call at 5am on a Sunday because a bug is causing a valued customer to lose $10k/minute, and by the way, the SVP is also on the line? Lucky bastard

Presumably they will be contacted if there's a problem. So the hire has an interest in not creating problems.

My sense is that there is a narrow slice of software developers who genuinely do flourish in a pair programming environment. These are people who actually work through their thoughts better with another person in the loop. They get super excited about it and make the common mistake of "if it works for me, it will work for everybody" and shout it from the hilltops.

Then there are the people who program best in a fugue state and the idea of having to constantly break that to transform their thoughts into words and human interaction is anathema.

I say this as someone who just woke up in the wee hours of the morning when nobody else is around so I can get some work done (:

I worked for five years at a shop where a few years in we started pair programming aggressively. One of our most experienced engineers was really into XP and agile work (in the “purer” meaning of the term). He often suggested pairing when thorny problems came up, and eventually it spread. It often took half or more of the available time for programming each day. That was by far the best working environment I’ve been in. The team was excellent and it seems like we all improved in our skills when we started doing it more. We cut down on how long it took to get in while managing to produce better code. It made planning features and adjusting to unforeseen snags in plans so much quicker. I can’t emphasize enough how much of an impact it made on me as a developer or how much I miss it.

The biggest downside to me was that it forces a level of engagement exceeding the most heads down solo work I’ve done. I’d come home and feel mentally exhausted in a way I didn’t usually.

I like pair programming for certain problems: things that are genuinely hard / pushing the boundaries of both participants knowledge and abilities. In those scenarios sometimes two minds can fill in each other's gaps much more efficiently than either can work alone.

I like pair programming. Not everytime or even everyday, but to shadow a junior a few hours a week, or to work with another senior on a complex/new subject? It's fine.

There's no such thing as a hiring process that avoids that problem 100% of the time.

After all, most people will be on their best behavior during an interview, and even a lengthy interview process is a very short period of time compared to working with someone for weeks or months.

They’re all bad hiring processes. Some worse than others. Hiring known quantities can slip onto nepotism shockingly fast.

Someone giving work like that should be either junior enough that there is potential for training them, so your time investment is worth it, or managed out.

Or it didn't really matter that the function was complex if the structure of what's surrounding it was robust and testable; just let it be a refactor or bug ticket later.

I know the aggravation of getting a hairball of code to review, but I often hold my nose. At least find a better reason to send it back, like a specific bug.

If you're sure cyclomatic complexity should be minimized, I think you should put such rules in a pre-commit hook or something that runs before a reviewer ever sees the code. You should only have to help with that if someone can't figure out how to make it pass.

If you're not willing or politically able to implement that, you might be wasting time on your personal taste that the team doesn't agree with. Personally I'm pretty skeptical of cyclomatic complexity's usefulness as a metric.

>Do people really argue about variable names?

Of course they do. A program's code is mostly a graph of names; they can be cornerstones of its clarity, or sources of confusion and bugs.

The first thing I do when debugging is ensuring proper names, sometimes that's enough to make the bug obvious.

I have seen this mostly on teams which refuse to formalize preferences into a style guide.

I have fixed this by forcing the issue and we get together as a team, set a standard and document it. If we can use tools to enforce it automatically we do that. If not you get a comment with a link to the style guide and told to fix it.

Style is subjective but consistency is not. Having a formal style guide which is automatically enforced helps with onboarding and code review as well.

Yes. 80% of comments to my PRs are "change _ to -" or something like that.

The most senior guy has the worst reviews because it takes multiple rounds, each round finds new problems. Manager thinks this contributes to code quality. I was denied promotion because I failed to convince half of the company to drop everything and do my manager's pet project that had literally zero business value.

The point of PRs is not to avoid mistakes (though sometimes this can happen). Automated tests are the tool to weed out those kinds of mistakes. The point of PRs is to spread knowledge. I try to read every PR, even if it's already approved, so I'm aware of what changes there are in code I'm going to own. They are the RSS feed of the codebase.