Hacker News new | past | comments | ask | show | jobs | submit login
Build a Team that Ships (2012) (nav.al)
173 points by saadalem on April 20, 2020 | hide | past | favorite | 102 comments

I’ve been shipping for more than thirty years. Twenty-five of them, as a manager.

Not everything has been a success, and I was not the “big boss,” during most of that time, so I often had to work in far-from-perfect systems.

The one thing that has been a constant drumbeat, throughout my entire career, was a relentless focus on “Done.”

“What does ‘Done’ look like?” Is a question I’m constantly asking myself. It can change, as the project progresses, but it’s always there.

I tend to start vague, with “Done” being almost abstract, and get sharper and more focused, as the project coalesces around an end-user deliverable.

As I said, I have had many less-than-stellar outcomes, but I’ve always delivered an end product.

The best ones have been the ones with the least planning up front. Not always the most ambitious ones, but the best ones.

I’ve learned to adopt an “organic” project process, based on the assumption that it’s impossible to know the end result when I start.

I write about that in these articles:




> What does ‘Done’ look like?

At least in the software world, I'd say an abandoned project is done. Good enough to ship is something else entirely.

> I’ve learned to adopt an “organic” project process, based on the assumption that it’s impossible to know the end result when I start.

For some things you do want to spend a bit more time planning up ahead, as some decisions can be hard to undo later.

But I think one should definitely try to make code pieces as modular as possible, and as easy to change as possible. As you say, the final product will likely not be as one imagines at the start. Especially since customers seldom know exactly what they want.

So many times I can whip up new features in short order, because I spent some time up ahead making small reusable modules out of functionality, so it's easy to use from elsewhere.

> I think one should definitely try to make code pieces as modular as possible

Absolutely. That's the key. Modules and layers; each with its own project identity and lifecycle. loose-coupling, minimal APIs, and reevaluation phases at the completion of every module.

If you do this right, projects can be almost "Lego" simple, with the ability to rapidly reconfigure to adapt to changing requirements.

Here's an example. Yesterday, I was working on a "UUID scrubber" for the Bluetooth project I was working on (https://github.com/RiftValleySoftware/BlueVanClef). I started by having a private class function to do the scrubbing, but realized that this would be something that could be useful for any similar project, so I broke it off, and added it to my toolbox project (https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...). That meant that I also had to write a unit test for it, and then update my Carthage include.

Took, like fifteen minutes, and I now have a permanent tool for scrubbing UUIDs.

Another habit that I developed, was making every project I do, including "one-off" experimental projects, "ship quality."

I simply cannot put too much stress on the need for maximum quality. As a lone developer, I just cannot afford bugs. It's imperative to do it right the first time.

The general argument against a high-quality process is that it is inefficient and slow.

Unless you make it a habit.

"We are what we repeatedly do. Excellence, then, is not an act, but a habit."

-Aristotle (Probably, but these attributions should always be taken with a grain of salt)

In addition to defining “Done” I think it’s also important to define “Enough info to start” and “Enough info to finish”. In a lot of projects the stakeholders aren’t willing to commit to anything which then leaves the dev teams without direction. I have been multiple times in situations where the deadline was ticking but somewhere between project management, project management and development management (too much management?) they couldn’t make their up their minds and critical questions didn’t get answered.

"I was not the “big boss,” during most of that time, so I often had to work in far-from-perfect systems."

I am the big boss of our 12 person company but I still cannot ever get to a perfect system. Yes in theory, I can make all the decisions and impose BUT it is far from it. The challenges of building a perfect system is not only related to how much power you have (yes it helps) but many other factors.

Yup. A perfect ship team is the Philosopher's Stone of software engineering. If anyone gets it perfect, they get to knock Bezos out of top place.

I worked for a Japanese company for most of my career.

It was...challenging.

HUGE team of very, very capable engineers (I regularly worked with some of the finest scientists and engineers in the world), but hidebound like you wouldn't believe.

I quickly learned never to use the word "agile" when talking to my bosses. Frowny faces appeared everywhere. They considered it a "low quality" process.

The main issue, is that I was talking to top-shelf engineers and managers, who had been delivering top-quality products for 100 years. This was not trying to convince impressionable American VCs or play "buzzword bingo." These folks knew how to do something, and they had been having success for generations.

It's just that what worked so well for hardware, went pear-shaped with software, and I was never able to successfully convince them of that.

That made me very sad, as I think that they really lost a lot of benefit, because they couldn't pivot into modern software engineering. I loved that company, and I have tremendous respect for my peers in Tokyo.

Since leaving that company, I have been working on my own, and implementing the ideas that I cultivated while working there.

It's been fairly effective.

Those cranky bastards had one thing right, though. The software industry has a shockingly high tolerance for crap. It's a real challenge to try to advocate for doing quality work.

I was almost ready to start an argument. But the bottom line (verbatim) nails it!

99.999…% of all software is utter crap. If people would build houses like they build software we would generally all live in paper boxes glued together by duct tape. And those paper boxes would explode on a regular basis for unknown reasons…

Still you will hear most people in this business saying: "That's fine". Look, "it works".

I don't think this will ever change. One of the reasons this won't change (besides development costs of course) is imho the overall mindset that "bugs are unavoidable, any software has bugs". As long as it's a "natural" thing to deliver buggy crap, and people declare you outright crazy if you even mention that there's something quite wrong there, no chance that this will change (at least not until software will be produced mostly by machines).

I generally don't bother setting up bug trackers, as I get so few bugs.

One reason is that I keep my scope fairly humble, so it can be argued that software that doesn't do that much doesn't have room for bugs.

But I like to avoid dependencies, if at all possible, and have a number of habitual practices in my coding that I think result in exceptional quality.

Problem is, it's not valued at all. I'm in a semi-retired status, and have found that no one wants decent quality.

It's been rather depressing, TBH.

One of the open-source systems I designed is becoming a worldwide infrastructure, and they have more bugs than ever (I don't code it anymore), and that means they have maybe 20 issues, in all; across about 50 subprojects. When I was doing it, it was a single-digit count, but only about five projects.

It's still of remarkably high quality. The folks who took over are good, and follow good practices. Also, the substrate is very strong.

Edit: skip this. I've read your links and it's clear you wouldn't fall into this trap. Sorry.

I had a boss who relentlessly focused on getting things done, neglecting anything but the immediate cost. If the cost could be pushed into the future (well, that wasn't the calculation - it was more like 'can I ignore this right now') then it was. He built up a whole lot of technical debt that was expensive to deal with, and some never was dealt with, so continued costing permanently. Any thoughts?

It’s cool.

Tech debt is a HUGE deal. Since I work alone (for the most part) these days, it’s an absolute killer.

I can’t afford it at all.

The single biggest guarantor of a massive debt (IMNSHO) is a rigid up-front specification.

>The single biggest guarantor of a massive debt (IMNSHO) is a rigid up-front specification.

Or the lack of any meaningful upfront planing.

This goes in both ways. But I agree of course with the above. Detailed specs, especially done in some ivory tower, will cause massive problems, no question.

This is what I do: https://littlegreenviper.com/miscellany/forensic-design-docu...

I call the upfront spec my "Napkin Sketch." It's often a single diagram.

A problem I've seen a lot of too. In this case, the definition of 'done' is totally leaving out all that technical debt. Hence 'something' has been shipped, but the work has most definitely not been 'done'. Just giving an appearance of done, sweeping other stuff under the carpet. It gets expensive doing that. And gives a very lumpy carpet!

Take a gander at my work. It is quite possible to ship without debt, but you need to be flexible (the word “agile” is almost worthless, these days, so I prefer “flexible”).

Think we've a lot in common. Maybe to do with being older and more experienced; been there, done that, got the t-shirt. I started with Assembler on Intel hardware and problems with coding that in scale aren't so different to today's environments. As for 'Agile', yep that died as a marketing phrase, even though the intentions (and the manifesto) are entirely valid. Flexible is a better choice now. Fragile is what we often get!

> "the word 'agile' is almost worthless, these days, so I prefer 'flexible'

It's kind of sad, though. What you said above ("I’ve learned to adopt an 'organic' project process, based on the assumption that it’s impossible to know the end result when I start.") is literally what Agile was trying to convey when it started out.

Yup. I loved the Manifesto. They had the right idea.

My experience is that things go pear-shaped when those pesky "people" get involved. It's all great on paper, and in the theoretical perfect world, but as soon as people start getting involved, and developing their own mental models, it can cause problems.

A big factor, as well (IMNSHO), is that a lot of folks decided that they wanted to be "gatekeepers" of the methodology, so they started to formalize it, and develop a vocabulary that they "own."

That happens with pretty much everything.

I'm old, grumpy, and very experienced. A great deal of the programming that I do is "instinctual." I don't stop and say "This would be a great place for OBSERVER!". I just go ahead and set up a subscription management utility, and don't give a damn what it's called.

In my experience, every time we come to a "new paradigm," a great deal of it is really just a formalization or rebranding of concepts that have been around for years.

> agile...worthless

True IME. Any time I see the word Agile, I now consider it to mean Clusterfuck In Progress.

Sounds eerily familiar, especially "People choose what to work on.".

You can't have that for the whole team in the real world. There are tasks which are universally unpleasant. Usually this devolves into one guy (the one who "ships" the most so is favoured by management) picking the best, most "shippable" tasks and the rest getting what's left.

That's because what this philosophy does is it turns what was supposed to be teamwork into some kind of weird competition over who shipped the most.

And contrary to popular belief when people compete instead of working together the outcome is usually worse.

I know one company that implements very similar rules and while they do make good money, they ship unmaintainable crap. Fortunately for them there's a niche for that as well.

I've heard that Facebook's culture has these same incentives. Ship more, even if it's crap-quality code, and you'll be favored.

I understand what this is like, and it sucks. Everyone else is left picking up the broken pieces of what the "superhero" built.

To be devils advocate, I've seen many "anit-superheros" of maintainability do months of work and not end up with an objectively "better" body of code. Often it's just different, and sometimes slower hard harder to extend due to premature abstraction.

There isn't an easy answer here, but incentivizing speed of iteration (aka shipping) has several benefits, both to getting value to customers as well as to architecture and maintainability of the code.

I think that most of those people are not familiar enough with the system that they are complaining about to understand why its so complex.

I have been involved in paying off many kinds of tech debt, and I see a lot of people scream maintainability and then realize the problem that the horrible thing solves is itself a horrible problem.

If you can fix it, fix it, if you think its going to take months to years of work to fix it to be maintainable the truth is likely you never will.

Any product that is static long enough for you to do this is probably not making enough money to justify the cost of doing that kind of refactor except as a hobby project (or was really well designed in the first place, or is a literal hellscape you should let die.)

I totally agree with that, but I'm not sure I agree it's playing devils advocate. By which I mean, I don't think we're disagreeing here. They're both real things that happen:

1. People rushing out crap code and not taking responsibility for cleaning their mess.

2. People trying to clean up code, but doing a poor job for various reasons. (Incompetence, lacking sufficient domain-knowledge at the start, bogged down by organizational problems, etc.)

The problem in each case is people either lacking the capability or desire to do excellent work. "Ship fast or write decent quality code" is a false dichotomy.

"who shipped the most"

And how do you measure that - LoC, tickets, elapsed time, amount of time talking about it, executive weighting....

Perception by management

You’re both right

The granularity of choosing what to work on also has to be the granularity of ownership.

If individuals choose what to work on, then individuals have to be responsible for owning the things they've built. Doing support, doing maintenance, being accountable for problems. If you let people cherry-pick the fun bits and then leave the crap to someone else, then you're doomed, as you say.

I work on a team like this. It's pretty weird, having come from classical XP teams where the team as a whole makes decisions and owns the code collectively. I don't think it's better. But it does work.

Yeah, there are some perverse incentives in both of these approaches.

We had a classic "glasses salesman" story going on here.

The story goes like this: there was a store that sold prescription glasses which had a few salespeople.

One was consistently better than all the others, so management took note and wanted him to teach the others.

Turns out that what he did was to observe people coming to the store and only approach those who looked rich, going as far as distracting the other salespeople so that they wouldn't get a chance.

These rules aren't for regular people, they are for rich coders. "Lean In" wasn't for everyday housewives, it was for rich executives.

That's the pattern.

"making good money" is the goal of a company.

Humans locally minimize entropy, sometimes in exchange for fulfilling an objective function or following some optimization gradient (profit).

It's nice when it works out and we leave things behind in better conditions than we found them, but that's not what the universe is playing at. Nor is it necessarily a/the goal.

It's weird how this all works, and how short a time we have to affect it. It would be nice if everything we made was good and worthwhile, but it's hard to know where things are even going to wind up, and if our investments in making certain things better will pay off. You have to consider opportunity cost when making improvements.

(This pandemic is really screwing up my sleep schedule.)

At the top level, yes. The incentives at various points in the organization are significantly more complicated though.

The relationship between what engineers want and making money is less strong than most would care to admit, for example.

Of course it is, but you can go about this the smart way or the less smart one.

I for one voted with my feet, because I judged this particular approach to be shortsighted.

Where are the companies that try to make their employees better? As someone who is an employed software developer, but has never been confused for a rockstar coding ninja, things like this hit me emotionally when I read them.

This might not be the smartest thing to put onto the internet, but I'm not someone who comes in guns a-blazing and ships dozens of features my first week. Or do I ever get to a high velocity. Would I like to? Sure. But that's not where I am at now.

So, a lot of companies talk like this. I suspect this is like baseball before Moneyball -- what if you can get people who are undervalued and make them better? What companies are doing that? Or even, how does one do that on their own?

A lot of the big tech companies actually have processes around mentorship. It's one of the reasons I think working at a big tech company can be more valuable than at a small startup, especially early on in one's career.

I don't mean to suggest all startups forgo mentorship, but often, smaller startups simply don't have processes in place for most things, including mentorship. And of course, what you get mentored on depends on the company too: at a big company, the focus may be on growing your career, whereas the mentorship at a smaller company may be about navigating an uncertain product roadmap.

Unfortunately, getting into a big tech company (especially when not doing so right out of a well-known college) requires a lot of luck, so getting access to this mentorship isn't exactly easy...

> This might not be the smartest thing to put onto the internet, but I'm not someone who comes in guns a-blazing and ships dozens of features my first week.

Nobody does. We have a running joke at our company of avoiding anyone who thinks they’re going to accomplish anything meaningful in the first month. Unless your company is totally mismanaged (ours is not), there won’t be the low-hanging fruit around that they think will be.

My company does this, but our pay is somewhat under market rate - our developers make not much compared to what is bandied about here. But then again, I run a company in a desirable field, the rules are pretty lax, and we invest a ton of money in employees.

You might find the inverse relationship, unfortunately. High salaries often come with high expectations and low time to develop employees because of your high salary. That's been my experience, and I've worked for a fair number of large and small tech firms.

Tbh it has been the opposite experience for me.

Small companies had little onboarding process, little to no training budget, and everything had be deployed yesterday. Plus a lower salary.

Large companies had formal onboarding, training budgets which they encouraged you to use, and didn't mind spending more time get the thing right before releasing and a higher salary.

The only large company I worked at where this was true was Microsoft. I have literally nothing bad to say about my experiences there, even the fact that I was caught up in the massive layoffs after the Great Financial Crisis. They handled it all with class and encouraged us to abuse their educational resources.

This hasn't been true most other places I've done contracting work for, or heard from friends who are full-timers.

It probably just runs the gamut depending on personal experiences. I guess my point is that it's hard to find a really high salary and expect to be trained up, and that seems logical enough to me.

High salaries often come with high expectations and low time to develop employees because of your high salary.

The strangest thing I've noticed about my experience in the tech industry is the utter and complete disconnect between salary and expectations. I've worked for a wide gamut of firms, from startups with single-digit numbers of engineers to FAANG companies with thousands of engineers. I have never noticed a clear correlation between salary and expectations.

The job where I was under the most pressure and where I had the most asked of me was actually my lowest paid position. I graduated in 2009, on the tail end of the financial crisis, and I counted myself fortunate to find a job at a local firm that was hiring. This was in the Midwest, so I counted myself fortunate to have a job offer at all, regardless of the salary. I very quickly found out why that firm was perpetually hiring. The work environment was so high pressure (and the wages so far below market rate, even during the recession) that people would leave as soon as they could find an opportunity (any opportunity) elsewhere. I held out for about 8 months before finding another role that paid significantly more and had significantly less expectations around how fast I would ship.

> You might find the inverse relationship, unfortunately. High salaries often come with high expectations and low time to develop employees because of your high salary. That's been my experience, and I've worked for a fair number of large and small tech firms.

This is surely correct. I just ask myself whether this is just a very different formulation of what zck wrote:

> I suspect this is like baseball before Moneyball -- what if you can get people who are undervalued and make them better?

If we identify "undervalued" with "salary below market rate", one obtains the statement above: By moneyballing, look for great developers who are paid below market rate (and will thus accept a salary far below the one of "rockstar developers") and hire them.

>> If we identify "undervalued" with "salary below market rate", one obtains the statement above: By moneyballing, look for great developers who are paid below market rate (and will thus accept a salary far below the one of "rockstar developers") and hire them.

Yeah, I don't disagree with this at all. My software architect was writing JCL COBOL full-time before he took this job and has a degree in Computer Science from a no-name private school. He knew nothing of our tech stack, but he was a hard worker and a good culture fit, so I hired him and gave him two months (EDIT: on salary) to teach himself - bought him all the courses, books, and such he could stand. Within 3 weeks he was pushing to our repo.

> If we identify "undervalued" with "salary below market rate", one obtains the statement above: By moneyballing, look for great developers who are paid below market rate (and will thus accept a salary far below the one of "rockstar developers") and hire them.

This is very close to what I was thinking, but there's a slight difference. I was thinking less about people who are _underpaid_ relative to how well they are performing, and more about people who are _underperforming_ relative to how well they could be.

I imagine this to be the most powerful kind of sports scouting -- you look for the people who could do well in the majors, no matter how well they're doing now. It's trivial to say "LeBron James would be a good #1 pick"; it's harder to recognize people like Kurt Warner (https://en.wikipedia.org/wiki/Kurt_Warner), an NFL quarterback who went undrafted, but was inducted into the NFL Hall of Fame. I'm talking about people who have more potential than they're showing.

Well it's good that it's up on the internet. Gives you and me data on which companies to avoid.

Ha, it does. Though, I meant "I don't know if it's smart to admit publicly that I'm not a Linus Torvalds-level programmer".

Very few companies want employees who think they're as good as Linus. No companies should want that, but they gotta learn the hard way...

> If they can’t ship, release them. Our environment is wrong for them. They should go find someplace where they can thrive. There’s someplace for everyone.

You don't need to fit in everywhere, different places work in different ways.

Express interest in improving yourself to a more senior colleague. Too many people just sign off on PRs, etc because we "don't have time" to help our junior engineers grow. Encourage real feedback on your work. Companies do a dis-service not to invest in improving their employees.

In other fields, both unions I've worked under have training programs. Companies don't offer education directly but they do pay a tiny percentage into the training fund, which goes towards classes.

I've worked on several teams, but mostly solo in my programming career. I can tell you without hesitation that the times I felt the "best" were when I was shipping things every single day.

There were a few jobs I had where I'd work on a project for what seemed like an endless amount of time and almost never saw any sort of real-world feedback--it was sad and demotivating.

I definitely agree that if you want results, keep your team small, have everyone ship things, and be personally responsible. It's highly motivating and from what I've experienced, draws out the best in people.

You can compare this philosophy to "Publish or Perish" in academia. Universities tell scholars if you don't "ship" (publish frequently, get citations), we fire you.

In that system, quantity is more important than quality. It's about pointless journals, conferences and citation rings, rather than actual research. "Publish or Perish" is about institutions trying to inflate their ranking, rather than fulfilling their original purpose: advance the frontiers of human knowledge.

Another example: When IBM projects paid engineers based on "kilos", or thousands of lines of code added, what was the result? millions of lines of pointless, redundant code. Bloated software that doesn't work and is impossible to maintain.

Another example: Stacked ranking/Vitality curve. The idea is simple: you evaluate each employee, producing a score. Then you rank all employees within a team. The lowest scoring 10% gets fired. Repeat every year... result? teams hire the worst employees they can, because that improves their chance of surviving the next stacked ranking iteration. Repeat for many years and you obtain an incompetent organization incapable of doing anything, full of toxic people.

If you use sprint velocity as your most important metric, the result will be a lot of redundant actions followed by corrective actions to undo those actions. It looks like a lot is getting done, but that's the same as saying that a truck driver driving in circles is productive based purely on fuel utilization, when in reality the guy is not going anywhere.

A perverse incentive, that's what it is. Want to have 0% crime rate? Have a population of zero, problem solved. Want to end elephant poaching? Kill all elephants, problem solved.

What is important is not only when you ship, but what you ship, and how you ship it. Don't upset your customers in the process of releasing changes. And keep the vital aspects of your product working...


Most of these problems can be curbed by pproper oversight and exception handling, however i also find that techniques based on empathy and trust tend to help longterm.

So there are aspects of development that rank higher than shipping, right?

That invalidates the "shipping is #1" credo. Sustained and sustainable growth is #1.

Accountability is important, but being forced to ship a broken release is irrational.

"All doers, no talkers"

Some of the absolute worst teams I have been on were like that. Full of self-proclaimed "doers". Always doing things without thinking even the basics through, no coordination whatsoever. Creating complete shitshows and clown-fiestas that others then have to fix somehow and always, always (did I say always already?) with the dumb excuse "well, at least I did something".

These are the "net negatives" on your projects.

P.S. And no, "be smart gets things done" people do not refer to themselves as "doers".

All of us have dealt with those kinds.

1. Overzealous ActionJockeys, who would just do shit - bothered only about local maxima ("I did mine! His thing is not yet done!" or "My code is superb; others' is total poop") Few variants are BrilliantJerk, who is supersmart but nobody wants to work with him. Also on same lines are some appreciation junkies and hero-role-playing characters , who always want to "save the day" - the LastMinuteHero types; but they'll never ever train others to hold their own as that could pose a peril to their heroism.

2. Dr AnalysisParalysis and his gang of bikeshedders. Could spend a week to choose the color of a button and while doing so earn a PhD in color theory.

3. Clueless Jimmy who just does what the leads ask him to do. He's a sure shot follower (in the lead-follow-or-get-outta-way kind) who just does NOT want to know the big picture.

4. Albatross managers. They come, they scream, they poop and fly away. Caw-caw caw Ca-caw!

5. IndifferentManagement - Anything goes as long as money comes in timely.

"All doers, no talkers" is just absolute peak Silicon Valley - may be the does should talk often and properly, to do things well. And do it well.

Collaboration over competition - it's 2020 FFS!

One approach is building a team that actively prohibits bad characters (like those listed above) and empower them by treating them like adults, and things would just work? But very few would do it - cause "the SV prophets said otherwise! "

That reminds of a colleague who used to refer to a project manager he worked with as "Mr On Time and On Budget" - because that was all he cared about.

Keen observers will have noticed that something is missing....

I assume 'talkers' means people that only talk. OP isn't making a case for or against planning, just saying that if you're taking a small team approach, once the planning is sufficient, the people who do the planning also have to jump in and produce. Your 'small team' can't be one programmer with a team of BAs, POs and designers looking over their shoulder for 40 hours a week.

This obviously doesn't apply across the board (but what does), but in my experience, on engineering teams I've been on, so-called & self-proclaimed "doers" are only doers of highly visible work, whereas the "talkers" are the real behind-the-scenes doers.

They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt. is (and that they'll be stuck doing it) and they want to talk/plan out/advise people on the least burdensome options.

They invisibly help/mentor the self-proclaimed "doers" on the projects they've eagerly taken on without any clue as to how challenging it will end up being (the same project the "talkers" cautioned others about because their knowledge gave them some degree of foresight).

The truth is, you probably need both breeds. The "doers" for ambition and the ability to actually start something (without getting lost in months of talking/planning) and the "talkers" to insist on the limited amount of talking/planning needed and actually have the knowledge to follow through.

There's always more people willing to tell you what to code than the people who can code. You are not mentoring anything if you can't step in and do the job yourself.

I would point out he described people who do the most uncomfortable work on the project and therefore also talk to other people.

The "does" he described cherry pick easy, fun, highly visible work, refuse to coordinate with others, dont help with integrating other peoples parts and then take offense when people doing integration complain.

Hiring armchair architects will not do you any good, you want doers with enough experience doing things that they can plan when needed.

He did not des armchair architect:

> They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt

This is literally the people who deal with consequences of bad code. If you fire on bad code and then you leave maintennance on others, you are the "armchair" one. Because you are not dealing with consequences.

Everyone who does maintenance work thinks they could do better than the original creators, most of the time they are wrong.

They go and decide to do a rewrite by committee to ensure everything is clean now, sit in endless meetings discussing the best way to do things, end up with a product doing half the things of the old one since they make even slower progress than the pace they would go at even with massive amounts of technical debt, and because their clean solutions actually are less flexible than the old "ugly" ones. Now we have two versions of the products to maintain since we couldn't migrate everything meaning we now have more technical debt than before. The result is roughly the same as if someone just sat and churned through everything on his own, just that you now don't have a clear culprit to blame.

I like how you build strawman maintenance programmer and completely twist original debate around.

Good rhetorical trick, but not much more.

In practice, purely maintennace programmer is rare up to not existing. Most people do both maintennace and new projects. I have seen many people who wanted to cherry pick the best tasks, never coordinated and left after "finishing". They never even learned about issues of their decisions - because they run away as their creation was becomming hard to keep.

My comment above is anecdotal, based on people I've worked with & managed over ~15 years. Others will have different experience than I and will have worked with different individuals, but in my own career I've never worked with the type of engineer you're describing.

OP indeed does seem to be making a fairly anti-planning case. Banning anyone telling anyone else what they should be making is very anti-planning.

It didn't really say you shouldn't tell people what to build, but that they should build what they want. This means instead of ordering them to build something you should convince them to build it, this ensures they are fully on board with the shared vision and possibly they might even have good arguments and convince you that their version is better.

I agree that in general it’s better to persuade than it is to order. But once you cross a certain organizational size, it becomes indistinguishable from just not planning at all. Once your company and product crosses a certain size, planning on persuading every single team in the critical path to care about every single product feature is a fool’s errand; a certain amount of “we need X by Y” must come in to play.

More broadly, there are finders, minders, and grinders. Different companies need different compositions of those characteristics, but startups tend to lean towards finders (people that can sell) and grinders (the aforementioned "doers").

I don't think it's good for any individual to be an extreme with any trait. Thats how you end up with a sales team that sells the world with no regard for how it'll get done, or a developer who can crank out features with no ability to support those features, or product folk that spend hours every day with meetings full of people toiling over all the accessories that may one day need to fit inside your bike shed.

My coding career started in 1987. For the last 3 years, and for the first time in my career, I've been working on a product that has a team of professional designers, ie proper graphic designers, artists, "empathetic" people, etc.

And for the first time in my career, I've looked at the product and thought "Wtf! that's a thing of beauty ". As a result I'm confident that users will actually, you know, like our product, not just tolerate it.

So, IME, having confidence in what you're producing has a material benefit on the motivation of the developers to get their end of things right too.

> You have to ship something into live production every week – worst case, two weeks. If you just joined, ship something.

I've tried this. To be frank, it's the wrong incentive. All processes will start revolving around this. It gives a great rush to the head but a false sense of security.

Despite patting ourselves on the back on our great release cycle and velocity, we never had the time to listen and adapt to our users.

We changed. We now measure how quickly we respond to any kind of feedback.

This is one the most important jobs of product managers, if you have them: building out a backlog of shovel-ready high ROI work aggregated from customer requests, user analytics, and strategic engineering efforts.

If PM is doing their job well, engineers can build and ship multiple times within a sprint without significant delays waiting to gather feedback.

I work on a team that functions this way. We're pretty productive for a team of 4 doing 100 story points a week. We usually deploy a day or two after our 1 week sprint ends.

The down side is that I'm exhausted all the time. We don't interact much outside of reviewing PRs, questions and help regarding our domains on the project. This can be a lonely experience during the COVID WFH days. Its a difficult pace to sustain week after a week with no real days to work on personal projects. At the end of the day I'm disgusted by screens, terminals and editors. That is not a good sign.

The upside, I'm outputting the most code in my career (I came from enterprise/IGO work). I'm learning how to perform at a high-pace. There is a lot of focus on preparation: eating right, sleeping/resting correctly and spending time off-computer time breaking down problems I need to solve during my next 'shift' into sizeable, ordered chunks. All done so I can make my 8 hours productive the next day.

Committing, merging and deploying at a rapid rate feels good but I become more and more like a factory worker each week.

I also feel that being disgusted by editors and terminals at the end of the day is a really strong sign of something off. I can say that in some jobs I would study / do personal stuff at night, in some others I just wanted to drink after leaving the office.

That would kill me in a short amount of time. Is this a permanent state of affairs?

Half baked and complex are hardly descriptions that endorse their process:

> It’s not perfect. We ship too many features, many half-baked. The product is complex, with many blind alleys. It’s hard to integrate non-engineers – they aren’t valued.

> It’s hard to integrate non-engineers – they aren’t valued.

> But, we ship.

That in particular meant I viewed the article as a cry for help.

But it seems like all the commentary here thinks it is sincere and not an ironic piece?

"Being complex" is not the same thing as "being complicated".

"Peer-management. Promise what you’ll do in the coming week on internal Yammer. Deliver – or publicly break your promise – next week."

This idea of commitments as value keeps coming up. It's difficult to explain to many technologists who see their value as measured in work, middle managers who see their value measured in negative time. If you just take the problem you are solving, express it functionally in terms of what goes into it, and what it will produce when it is solved, committing to that creates value for others. If you've seen Ray Dalio's "economic machine" video, commitments are are not unlike creating credit that facilitates spending, which creates growth. I get there are dodgy anti-patterns for creating fake commitments and fake credit that project managers tend to use, but a team that is creating growth doesn't need people like that.

What constitute “shipping” exactly? “Just ship more” is as ambiguous as “be a better driver”. It doesn’t tell you much about the quality of code, amount of tech debt they’re creating while shipping frantically and generally not taking the time for careful design. Software should be designed like they do mechanical engineering - you get a few prototyping shots at it but it’s expensive to iterate too many times - prototypes cost a few thousand dollars depending on the complicity of whatever you’re designing. So spend the energy and focus into designing robust code that isn’t gonna fall apart in 6 months. Stop chasing after “shipping” madness. Instead of shipping, perhaps ask for a solid chunk of the equity. Don’t do cheap labor for small startups unless you’re handsomely paid for the appropriate risk involved in your career.

This is 100% true for later stage companies with established products/stakeholders and 100% false for early stage startups.

I have found product market fit 3 times in my life. Each time was with an extraordinarily shitty, unmaintainable, low quality codebase. But those shitty codebases iterate the end product faster and the speed of iteration is all that matters when you are trying to make your worthless startup become a useful company. Once you find what your users want, 100% it will be rewritten from scratch in a scalable, robust, thoughtfully designed way anyway.

With you on the equity bit.

I was on the ship ship ship, bandwagon for a long time. Until, I realized there is a technical debt that you eventually need to pay down the road. Its like playing tetris. There are only soo many blocks you can place at will. Eventually, it catches up with you and game over!!!

I'm going to take a stab at responding to this, to see whether it's the insufferable tone of the writing that bothers me, or something else.

If we assume the author is part of a team that makes software and has users, to "ship" for him or her is another way of saying "deliver a product that our customers will find valuable enough to use" and hopefully pay for. Do the people who use this software depend on it for any important purpose, or would its failure be inconsequential?

Maybe I'm wrong with the assumption that the author wants to make a product people would pay for, since they lead with "we want a team of self-managing people who ship code." It doesn't say we want to make a business. It begs the question of Why? We ship to what end? Would it be less impressive to say, We just like to write software and want everyone to leave us alone?

Why write an article and observe that your process creates too many half-baked features but do nothing to reflect on that and reduce waste?

Why make the ridiculous claim that you don't value people who aren't programmers? What goal, if any, would such a statement help you reach? Why are we shipping so often (...customer feedback...?) if we don't care about anyone?

And of course the pithy final line.

So no, it's not just the tone that bothers me. It's the dismissive and plainly antagonistic approach to software development that says the creator is the only one with any worth.

I'd be interested to know how the author might reflect on this piece today.

This might apply to B2C products where being first to market plays a vital role. Buggy Android being first to market as an alternative to IPhone, gave it a huge boost against the polished windows phone.

After reaching this target, the company would need developers with completely different skillsets, whose importance is seldom written about.

The author is the founder of AngelList which isn’t a business. Business as in delivers goods and services in exchange for money.

AngelList is to angel investors what HN is to YC.


The least surprising sentence after all of that was:

> It’s hard to integrate non-engineers – they aren’t valued.

This describes a bunch of hackers, not a company.

I wonder how many CEOs have said something like this just before a "bunch of hackers" has eaten their lunch and decimated their stock price?

i'm 51% confident this article is pure sarcasm

"When a measure becomes a target, it ceases to be a good measure." (Goodhart's law)

A team that ships often is arguably doing great (because complex things that work are made out of simple things that work, and early feedback is important), but you can definitely just ship random shit and be satisfied with it if you've set your mind to ship often without regard to the proper way it should be done. Shipping often is easy, shipping often good things is hard.

> Absolutely no middle managers. All BD via APIs.

What does BD refer to here and how do APIs eliminate middle managers?

Assumed business development.

Behaviour driven?

What works/worked for AngelList isn't going to work for your team necessarily.

Choose your culture and incentives wisely and use an approach that helps you to solve problems.

If the consequence of shipping software that has an unknown and undesired behavior could cost your customers millions of dollars an hour you should probably invest in a team that is familiar with formal methods (or some other approach to ensuring you ship the right thing). Shipping the first thing that works on your dev machine that passes a few unit tests isn't generally sufficient when property or people are on the line.

How does one go about improving this in a big corporate company? Our development team is focussed on shipping, but most of our delays come from the business changing their mind and changing requirements constantly.

The people who act as the bridge between development and business just side with the business. Anything that goes wrong is blamed on our development team.

It’s probably just a hopeless situation and time to move on.

I was trying to work out who the author(s) were, and whether this was the kind of content-marketing blogspam that doesn't belong on HN. But it's pretty anonymous. Their twitter account retweets Scott Adams and seems to be on the "unlockdown young people to keep the economy moving" viewpoint. Some data points for your bayesian filter.

He's a successful startup founder (100's of millions networth). Not some clown.

> People choose what to work on. Better they ship what they want than not ship what you want.

Among many drawbacks to this idea, it puts a hard cap on your organization size. Building large companies with hard to build products requires getting hundreds of engineers moving in the same direction, i.e. someone telling someone else what to make.

I think there's (at least theoretically), the idea that folks could flock like birds or fish in a shoal and all make independent motions based on observation of others with no heirarchical orders and self-organize into a coherent mass which is efficiently moving in the same direction, but I haven't seen it arise in practice so far.

Over-simplification, mentally convenient; however, won't go far in the real world. Some good point though to narrow-minded. Read more man.

Wait what here is the advantage again?

I think OP is describing the winning formula for a productive team, but he's attributing it primarily to the wrong factor.

Shipping often increases quality if you're getting good feedback from users and acting on it. But it's not a slam dunk obvious "best practice" or whatever. The end goal is to deliver the best quality software (or alternatively the most sell-able software), shipping early isn't some arbitrary metric you use to assess your engineers, it's a strategy to get your product from point A to B as quick as possible, where B is something really useful that the market wants, and A is presumably something crap that you can't sell. Because if you already have a piece of great software then your focus should be on selling it, not throwing more darts at the wall and hoping you don't knock the dart board off.

Looking at the dot points, I have no doubt that all of OP's teams are successful. They're all great advice, except for the one the title and conclusion of the article are based on.

Their first point is "keep the team small, all doers, no talkers". IME that already puts you way ahead of the pack. By far the easiest way to cork a startup is to hire one of everything and wait for Parkinson's law to bone you. A small team of programmers isn't the ideal setup for everything, but I bet it does well above average compared to the field (which is good, because the average startup goes down like the Hindenburg if YC's data is accurate).

Outsourcing stuff that isn't core is also good advice. Half the reason big teams don't work is exponential growth of communication. If you can modularise your business so that one app/feature/whatever is tied strictly to one communication channel, then you avoid all that. Obviously it can backfire. I'm sure everyone has seen a few projects eat dust by outsourcing to the wrong people, it's not exactly an original story. I think it's good advice in general though.

Aligning people's development goals with the business's goals is obvious. The further suggestion to prioritise employee's wants over the business's is interesting though. I think it's on the right track but the actual good advice is buried a layer deeper here. You should prioritise work your team wants to do, but there's a prerequisite that you probably also need a team that wants to do work that is good for the business. I think the real advice is hire people who are (or can become) mentally invested in what your business is trying to accomplish. And the easiest shortcut to that is probably to make them financially invested in it by offering equity. Align everyone's goals then trust your team completely. I think if you're already in a position where your employees don't care and have tangential goals (like a bit of resume driven development), then you probably don't have a great move to make, and blindly following OP's advice isn't likely to improve the situation much.

One person per project is fantastic advice for some definition of 'project'. Big businesses and big teams hate this approach, it's all about bus factors and treating everyone like cogs that can be moved around to wherever they're needed. Most of the teams I've been on would rather everyone have a shitty basic knowledge of an entire huge codebase than have anyone be responsible for any subset of it. And IME it always devolves into one hero that tries to control everything and everyone else feels like they have no control. I've been on both sides of it countless times, and I don't think it's the best way to build software. Not by a long shot.

I think the reason it happens is because good developers have an innate want for more control, to take on more power and the responsibility that comes with it. Supressing that might work for average teams that can do their job with average developers (including good ones that are brought down to the mean), but if you want to stand out from the crowd you need to build an environment where everyone can have responsibility and be a core part of the team.

'Peer management' works great. But OP's approach isn't the way to go about it. I know a handful of great developers, people who I would entrust with my business or back with my own money. One of the things they all have in common is that timed status reports designed to hold them accountable wouldn't work on them. They might put on a smile and suck it up but I can guarantee you they wouldn't actually give a fuck what anybody thought about their delivery speed unless they actually respected them as a peer. So this is another dot point with a huge pre-requisite. It's great advice as long as you already have a team that all respect each other's abilities and are all close friends who don't want to disappoint each other. And if that's the case then you don't actually have to take action as a founder or CEO. You don't need to set up weekly reminders for your staff to make promises, the accountability will have grown naturally and already be there. Good engineers are self managing. OP says that themself in the opening paragraph. So this specific advice seems a bit out of place.

That leaves 'no tasks longer than one week'. I think in the context of OP's teams, this advice is crap. If you're already nailing everything above, then you have a team that will deliver results and build great software. In every project I've worked on, there has been stuff in the pipeline that would take longer than a week and be a net positive for the business. Especially if you're running a small team and have a modular workload with shared responsibility as above. There's always going to be something that, if you broke it down, would represent a big hairy mess of interrelated tasks that have a high level of complexity, affect the same parts of the code base, and require the same high level of domain knowledge. Breaking those kinds of tasks down is usually a mistake, and it's totally fine to have a team member you trust go off on a little odyssey for a fortnight or a month to deliver them. That doesn't mean they work in a silo, or you don't get kept in the loop, just that they're given space to work.

In large teams these tasks are usually brute forced by breaking them down, creating jira monstrosities with every dependency thoroughly tracked, then splitting them up amongst a team of 10 people. They always, without fail, slip a couple of sprints and end up taking a month anyway, with the added bonus of tying the whole team up for that time. Nobody notices of course because we all know the correct language to use to make it sound like everything that was done was efficient and necessary and nobody really wants to suggest that whatever project management best practices are in these days might not have a 100% strike rate over the extremely varied work that goes into a complex software product.

So, tldr; OP has a bunch of great advice that you should definitely follow, but I think they're off base on a couple of things.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact