From my perspective - speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome.
Over my career, I've been surprised multiple times when I presented early draft to a stakeholder and they said, "oh, that's great, I've got what I need now"...and this was maybe 1/3 of the effort I was planning for.
The way I see it, if the problem is important - any early solution should provide some relief. If some initial relief isn't wanted, the problem is probably not important.
Along these lines, in my work with stuck startup founders, I often ask, "if we were going to demo a prototype to a customer (in 2 days | at the end of the week), what would it be?"
I cannot possibly emphasize this more strongly. It's so important to deliver complete and working products quickly and regularly, that it's worth the cost of the occasional lost customer who leaves because all of their needs aren't met immediately. A) they're rarer than people seem to think and, B) the people you gain due to this incremental approach more than cover the losses.
That said, some devs interpret "quick" to mean "sloppy", which is not correct. When you can cut releases hourly the cost of some kinds of bugs does go down, but fewer bugs is better, and as always some categories of bugs are, "never, ever" (e.g. data corruption/leak, security bugs, outage inducing bugs).
> That said, some devs interpret "quick" to mean "sloppy", which is not correct.
Totally agree, but I've seen some devs completely melt when we need to go fast/iterate. For them, they really do produce sloppy work when they go too quickly. Many "big thinker" types are like this. Not defending it, just an observation.
With a good sales team, you can land customers who don’t see all the features they need, because you’re routinely delivering a solid if simple product that gets major new functionality a few times a year and if you just hold on we will get your feature to the top of the list.
Those paying customers are where your MRR comes from. Another case of perfect being the enemy of good.
As a customer of startups, I really abhor this attitude. Especially when it lingers for years after the initial product launch. Which is shockingly common.
For example, partially complete features are often completely abandoned for years and years, because they're "good enough." Unfortunately, good enough, often means unhappy customers actively looking for new competitors.
One company in particular, I absolutely despise, because of this. They are pretty much only focused on releasing new features. The old features, while functional, are in desperate need of improvement. (In many very obvious ways.)
This particular company had a good IPO. Their stock then dropped 90%. I wonder why.
> They are pretty much only focused on releasing new features.
My guess is that behavior is NOT motivated by the theory "deliver early drafts with more smaller iterations", but is instead motivated by the theory "the people who decide to buy our products do it based on feature checklists, rather than quality of anything."
These are actually not even aligned theories. The "smaller iterations with early drafts" appraoch is best done with fewer features included, not more features that are incomplete.
Many markets incentivize companies to deliver crappy software, and it is frustrating, but not, I think the fault of an agile/iterative/deliver-early-and-often approach. If you can make the most money by delivering a giant feature list of crappily implemented poorly-thought out features that don't fit well together, you'll tend to do that, regardless of theory of project management.
Having been on the other side of this - often times our users are unhappy with the unfinished features, but our customers are delighted.
That is to say, the CxO or director we've sold to has everything on their checklist and is getting "good enough" results out of their organization. Our job is to understand which of the unfinished features will cause grumbling and which will motivate users to convince an executive to switch to a competitor. It's very unusual for the former to ever be worth prioritizing.
> Unfortunately, good enough, often means unhappy customers actively looking for new competitors.
Here's the thing though - it's your intuition that customers are unhappy, but the startup in question has actual data. It's entirely possible that a small group of people similar to you are unhappy but for a majority of the userbase the feature has gone as far as it needs to. Resources are scarce and priorities need to be changed, which sometimes means making hard decisions.
It's interesting that people almost never disagree with this when they're the customers. We love seeing progress, even if it's a small portion of what we need. When frequent updates show that progress is slow, we're glad we're aware, and we don't blame the updates themselves for slowing the project down. In the rare cases where we feel like the process demands too much of our attention, we don't stress about it; we just say, "Looks great. Let's talk again in two weeks or when you have completed feature X."
Those hypothetical drawbacks only loom large in our minds when we're the ones doing the work.
What about those invisible people who gave it a try and decided there were just too many gaps and bugs? They are not customers anymore and probably never will be.
I once worked on a team, in house at a company, where we were tasked with developing a prototype, in a scripting language with a well-known web framework.
Meanwhile another team at a consulting company, was tasked with developing the final product in java, all very enterprise.
The outside company ended up with a failed project, missing deadlines and going over budget multiple times. The prototype became the product.
Let me guess. Someone used JSF and hibernate in the same project. That is an easy way to blow up development time by a factor of 5x to 10x for literally no benefit.
If they find the appeal to authority useful, I'd grab them a copy of _Software Engineering at Google_ and leave them a bookmark in "Help Me Hide My Code".
> The way I see it, if the problem is important - any early solution should provide some relief. If some initial relief isn't wanted, the problem is probably not important.
I experienced this today, just now. The whole org’s release for fall was hinging on what I was proposed… the relief of everyone once the presentation was over and it all clicked, when they saw the light at the end of the tunnel, that the path that I had uncovered towards that is reasonable, and tenable is priceless.
I understand now that I live for this shit. 10/10 would do it again and again and again.
It's also dramatically easier to have a discussion around what does or doesn't work with a concrete example. "This but with X" or "This but without Y".
I've found this also helps just internally - start with a prototype and you have engineering discussions that are more practical than theoretical.
> ..and this was maybe 1/3 of the effort I was planning for.
Quick anecdote. When just starting out I was building a tool to automatically find the composition of essential oils used given a GC/MS output, and was told it needed to be "fast". I spent a long time optimising it, working on parallelising it and more. I spoke to them after getting it down to maybe 15 seconds or a couple of minutes something like that and was getting ready to explain why I couldn't make it fast.
"So you said you need this to be fast to be worthwhile, but"
"[intejects] yeah being fast is important, if it takes more than a day or two it'll be a lot harder to use"
> speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome.
Well put. Too many managers and execs use the word "speed" but never define it for others to make actionable.
Scenarios in real life:
Coder: "what's important while we're working?"
Exec: "Speed." _feeling_cool_
Coder: "I authored features a,b,c,e,..x,y,z ~ already working fast, gimme a raise!"
Exec: _realizes none of those features were desired objectives_ ...
Or
Senior software engineer: It'll take 9 months, 5 devs, and $200k to run...
Everyone else: ... not even sure business will be kicking in 9 months ...
I think even talking about the draft gives you an idea about the severity of the problem. My experience has been the same. If the problem is severe enough a crappy draft will do. Conversely if someone is asking for multiple refinements even to arrive at basic decisions, I begin to write off the problem as not critical.
I really like the framing of "providing relief". I think it also makes sense to allow the definition of who experiences the relief to be flexible (e.g in some cases the audience that experiences relief might be developers, security engineering, sre, etc. not just customers...)
I'd rather name it an MMP - a minimal marketable product. It was good enough that it worked, and the buyer (in this case the stakeholder) was happy enough to "buy" it.
There's IMHO a slight difference between MMP and MVP in the perspective one takes.
When it comes to business (corporate), you hear "do it right". But in reality that means "do it fast even if wrong". If mistakes are made, what happens depends upon management.
In most cases, I have seen people who do a project 100% correct, sometimes slightly slower get ignored.
Other people who get it done fast, even with many blaring mistakes, get rewarded. Usually the people who worked on it end up working 24/7 to get it fixed. That is looked upon by most managers as very good work.
If your projects go live without issues, it is usually forgotten, people who fix their own issues by putting in fixes after go-live by working 24 hours, get noticed and rewarded.
graphic designers sometimes ship their draft deliverables with 1 or 2 obvious bugs, and allow the customer to recommend these 'changes' on their own for final delivery. and if they don't, they're just fixed for final delivery anyway.
i read about it before i had this done to me for the first time, and i played along with it. it's a neat trick because it's plausibly deniable for everyone involved and the outcome is good while minimizing the bullshit work in favor of a sacrificial final word.
I've done this in hardware design, presented a design for review with a problem that had already been discovered and had a fix in progress. It was a red herring that gave the customer something to latch onto and feel like they were contributing to the success of the project. Somewhat dishonest, yes, but very effective in getting customers to work with you rather than be adversarial.
There is a concept of a sacrificial feature to prevent customers from becoming fixated on other aspects of the design that would actually create problems if changed. I prefer to avoid that sort of dark pattern though because it erodes trust.
This was known as adding a 'duck'. It is unfortunately very helpful when your client stakeholder doesn't value your expertise as much as they should. It works for web design too, but you must be careful that your duck doesn't become a feature!
This is a weird thing to tie to graphic designers. Just because you noticed a graphic designer doing that doesn't mean it's a thing that's more commonly practiced among graphic designers than any other trade.
The fact of the matter is unless your company is very mature, getting 3 big features to prod in a month even if that means bringing down some system for awhile is generally much more valuable than getting a single feature out with zero downtime.
As the company and number of devs grow, the probability of a dev doing something stupid increases substantially, so those early mistakes can actually be quite valuable in showing where your infrastructure has gaps.
Let the imperfect code happen early, it often leads to free chaos-testing and more stable infrastructure.
How can you distinguish between "project is not important/forgotten and due to that, no issues are discovered" and "there are no issues, so it is forgotten"?
I encountered this in a previous job. I told them during design phase the implementation was failing basic computer science knowledge and would cost the company a lot of excess computing costs (due to redundant work).
a quarter after launch it was a crisis because $5k a month customers were costing $50k a month in compute. The original designer put in some patches that got it down to $25k, and then $3k and was a "hero". By my estimates the limit of the actual work being done should have been < $500. But we didn't have time to implement that due to a quarterly insistence and folks all nodding their heads at eachother to get promoted.
In the end he got promoted and i got a negative review for not being a "team player" (ie being disagreeable about a design I knew had undesirable properties)
Unpopular opinion: I find with long projects that development speed later on depends a lot on whether we made good decisions early on. Stopping to figure out an architectural thing can make things easily changeable later. Keeps your speed up, even a couple of years into a project.
"Do it fast" feels really, really good. It's motivating, and you feel like you're pushing forward. But it can really slow you down in the long run. Eventually, everything's so coupled that it takes weeks or months to add new features or fix bugs because you can't touch anything without breaking five other things.
As a mentor-of-sorts once told me, you end up feeling like the street sweeper after the parade
Of course, this is only rational if you know what you're building ahead of time, and that you'll need the things you're preparing to build
Speed is underrated. I've worked on a lot of side projects and for a long time I couldn't get them done. I spent too long "perfecting" baseline things like folder structure (really) and overall system design. This made things slow-going and I tended to abandon them.
Over time, I started just hacking things together and shipping them, worrying less about perfecting those initial things. (I used YAGNI a lot in my decision-making.) What I learned is that there were so many more things I had to do and had to learn to do to ship. I could only get to those tasks and learn those skills by "skipping" through the earlier tasks. Working quickly helped.
I started thinking of projects as this vertical stack of work that you move up from bottom to top. If you could look holistically at absolutely everything you needed to do to ship a project, you could mark some as having a larger impact on the success of the project than others. Those are things that require more time and energy.
When you move slowly, you have a very small scope of the overall project, just stuff at the bottom, and predictions about the future. You may not really know what's ahead. If you go slowly and try to do everything perfectly down there, you spend a lot of energy on a small subset of tasks which may actually have smaller impact than something in the middle or towards the end.
Speed allows you to move through those early tasks move towards a more holistic view of the entire system so that you can determine which are high impact and which are not. You might need to double-back on an earlier task if you misjudged something as low-impact and ended up spending less time than you should on it, but at least you're not pouring energy into low-impact tasks on average.
It's not quite the same thing, but building a prototype is a good example of learning the end to end of a system without worrying too much about quality. It gives you an initial idea of what's possible and you use that to get a better picture of what's high and low impact in a project.
This is a valid approach, but not because of its "speed".
When you start a project, you have a great many things you don't know and need to learn. This is the case in 99% of projects out there. By definition, you cannot at the start of it optimize for things you don't know anything about, because... how, exactly?
If you work in a particular stack a lot, prepare a starter project template. Put some time into it, set it up so that it is optimized for letting you learn the things you don't know and helping you discover and make architectural decisions as they become necessary to make. And then just go wild.
This is the bottom-up programming approach advocated by pg in his book, IIRC. Have a setup where you can iterate quickly in the small, and make it easy to abstract and refactor as you go. You don't need a Lisp for that, just some tools with proper configs. It's also what R&D guys tend to do naturally with their Jupyter Notebooks - the difference, other than the kinds of problems faced, is that devs don't have the luxury of leaving the code in a form of REPL session transcript.
Not OP. But applies to long term support, remember the loooong overdesigned redesign? Yeah, don't do that and rather make small quick improvements. "OH you found a typo in our config format? Update it and it'll ship in the next patch". Instead of "naw it's fine, leave it we're rewriting the configuration subsystem in that fancy new yaml/json format".
Just a note : I've noticed that when working with management, they often have issues "grokking" the issues they are asking for you to solve.
By offering an imprefect, quick solution, it lets them understand the issue and readjust their needs in consequence - and often, the quick imprefect solution is good enough/enough work to show it's a bad idea and to move on.
When starting project I have 2 steps : vomitting and touching up. You puke out a solution(minimum viable product), without thought about optimisation. When that exists, you change hats and optimise. Works wonders.
> You puke out a solution(minimum viable product), without thought about optimisation.
And that's where it ends, because unless your employer vastly overhired, there's already a dozen (or more...) of tasks in the backlog just waiting for you to vomit them out as well.
After a year or two of working like this, you have a mountain of technical debt and no time work on it all. The entire system slowly disintegrates under its own weight.
There needs to be a balance between fast and correct, and it is only up to the developer to resist the pressure from management to work fast (at the expense of correctness). I would go as far as to say that it is one of your main non-technical duties as a developer to resist and manage this pressure as best as you can.
Maybe you're a genius who can analyze problems and implement solutions both fast AND correctly, but that is very rare.
The truth is that complex problem solutions can have complex, messy implementations. They can also have simple, beautiful implementations. Or anything in between. But what they almost invariably require is complex investigations... which take time to conduct properly.
Most (not all!) "fast" programmers I've worked with over the last 15 years produced output of questionable quality, often stemming from the "what you don't know you don't know" part of the knowledge pie chart, instead of some deeply thought out cost/benefit calculation.
IMO if the code sticks around long enough to disintegrate under its own weight, than that code was a rousing success!
"Resisting management" is almost always a horrible idea. Code is only useful when it provides a solution at the right time for the right price. If not, it is no longer useful and the world moves on.
Overall quality is nothing more than a reflection of business maturity. Like a mighty old tree with a great big trunk. It has had time to grow strong and majestic.
Most businesses don't live longer than 5 years. Most products and solutions are temporary fixes or ideas that don't last longer than a few months. Investing huge amounts of time and resources into those things is a recipe for disaster.
> After a year or two of working like this, you have a mountain of technical debt
What's the reason to stay longer than 2 years? From what I see it's x10 times harder to get raise inside an organisation vs when changing it.
Probably, the reason is that companies adapted to employees getting rise and leaving soon. So a raise inside org is more a calibration for those highly underrated on entry ones than some real compensation for any experience.
I'm not a programmer. Could you estimate how much more comple/ how much longer it takes to implement quicksort?
Otherwise, my point is that this is often good because, when begining projects, management can lack perspective of how the project will actually get done. Having a "draft" version that is planned to be scrapped lets you decide where optimisation is necessary, see future bottlenecks more clearly, and thus you can set a better foundation for the actual project.
And if it's possible to make that version say 20x or 100x faster than a V1 of the final project, I think the insight gained is worth it.
Edit0: Sometimes you even learn that it's a bad idea at all - better to learn that quickly and start over.
Edit1: After a cursory read, it seems quicksort it as simple as it gets in execution, being very few lines of code. But I'm also reading that in production code, quicksort is just part of the custom sorting algorithm that should be written for the specific database it's being applied to. If that's the case - using quicksort is the vomitting. i get what you mean "without thought about optimization"...some optimization expected, but heavily weighted towards rapid execution and low complexity.
I wonder how the author thinks about this now, 8 years later.
Way back in 2016/2017 I saw this video on prototyping where the programmer whipped up a snake clone in around 4 minutes. I deliberately practised programming in this way: how fast can I go from idea to working prototype? Code style, organization, testing, best practices be damned: you have about how long it takes to run a load of laundry, how much can you get done?
I did this for a few months. I focused on games. I roughly tracked how much time it took to get from empty file to the first interaction with the game. I tried to focus my practice on getting to that first interaction. And the overall time I spent and how far I got with the idea.
The thing with going that fast is... the code sucks. You're not writing it for an audience, for your future self, to make it possible to extend and compose; when you want to go fast and prototype in this way you're deliberately not going to use this code for anything later on. You just want to get the idea out there to see, "is this even fun? Would it even work at all?"
... before you go ahead and spend the next 6 - 12 months spending your limited time on something. Because finding out your game isn't actually fun after all of that effort is demotivating.
In this sense speed is useful. It's useful in certain contexts when doing programming on the job. Especially at startups where the runway is limited and you don't know if you even have customers yet.
However!
Be prepared to throw it out. Once you find some traction for a feature or process; throw out the prototype/MVP code. Make sure it's cheap to do that: you can write software that is loosely coupled, you can write a better API that uses the MVP code underneath, write good tests against the new interface, remove the old code paths piece by piece, etc. If it's a core part of the product and there are customers for it get rid of that prototype/MVP code some how (it's easier to plan for this and not get too attached to the first iteration if you do it intentionally).
Hmm I had a similar experience but with different results. I took fairly hard but common problems that I had to do and started timing myself.
First time it would be like 2 hours, then I'd get it down to 1.25 hours. Then 45 mins. Then finally I got it down to 18 minutes and couldn't get it any faster. I learned so many tricks and it really burned into my brain all the different faster ways of doing things.
I noticed at work I got way, way faster. I ended up outperforming my entire team, by myself. I think mostly because A) I now had a habit of working fast B) I viewed it as a competition, so no water cooler talking C) I didn't have to think about how to do it, I just knew, and I knew how to do it quickly.
It literally took me from making 75k to 400k in 2 years. I just applied that to everything I could, so when doing interviews I was able to just flood the interviewer with the depth of my knowledge and how fast I worked.
Now I really put in a tremendous effort into this, not just a few hours, it was an obsession for me. But once I did it I got those skills for life. Even now that I'm rusty I still go really fast.
Also, my code quality itself is quite good, because I'll write it as fast as I can (frequently only takes 15 mins), then refactor like crazy (5 to 10 mins) and still be an hour faster than everyone else.
Agreed - There's a certain thing about greenfield development in particular(which is quite fully the realm of startup coding) where you have to approach the first, second, maybe third iteration as one that will be thrown away, so when it does get thrown away, you make it easy to do so. And that leads towards some pretty dumb code, often "copy-paste-modify, sort it out later" code.
A lot of "best practice" ideas that get made into blogposts impose a structure that hinders disposability in favor of a certain aesthetic goal: to do the thing with less repetition and slightly cleaner abstractions. The goal is often not unreasonable, but it conflicts with the action of rapid iteration.
So I tend to write now with an eye towards trying to keep the code disposable until I face a certain class of error to eliminate, that needs the more abstract method. Often part of the disposability is in not actually solving the entire problem, but cheating and returning a wrong answer, e.g:
Instead of fancyAlgorithm() being written in a way that creates any dependencies I write a skeleton "function fancyAlgorithm() {return true;}" and then later upgrade it to a lookup table, and then to the algorithm. Because most of the code that matters to the app won't be in the algorithm, but in how all the other data is being passed around. The sooner I can get that piece to return a wrong answer with known error, the sooner I can arrive at a complete but wrong app, which can be corrected into a higher quality one. When not all the pieces of the app are there, it's not clear what error you need to be solving for, which leads to squeezing effort onto code that isn't important.
This is kind of conflates the idea of a person doing a job quickly, and the idea of tools having low latency/quick response, which confuses the issue if what you care about is working quickly — the bottleneck for work is usually the speed of our thinking, or the limits of our motivation to work. But, it's usually not the speed of our tooling. You wouldn't become a better programmer with a faster computer, and usually not a more effective one either. I'll ignore the second definition.
In my opinion, you want to spend about as much time as ever, but spend more of your time working on something that is close to a solution. So, you want to work on the first draft as quickly as possible, so you can either refine it, or toss it out and do another iteration. The advantage is overall quality and confidence in your solution.
For reasons mentioned in the article, I do not prefer to be thought of as working quickly and well, since that often means someone sees your first draft and says "great, looks like you're done, now let me give you something else to work on". Better to have a reputation for taking about as long as most people, but producing better results.
I'm very slow at doing things, because I consider things too much, I very much believe this is the main skill I need to work on, because the quicker you do something, the quicker it goes wrong, so you can course correct.
The book Creativity INC by Ed Catmul talks about this and they actually studied it at Pixar and they discovered the teams that moved faster were the best, the teams that considered everything for much longer, were wrong just as much as the teams that moved quickly, the only difference is because the other team moved quickly they could course correct sooner and also they were less tied into there original idea, so happy to drop it and go the other direction, were as the team that was slower and more considered took longer to drop the non-working idea, as they dug deeper and tried to make it work, since they were more invested in it.
I worked at a company where the team was asking for an internal dashboard to see real time metrics from these events we handle. My boss was like "Yeah, we are gonna need 6 months and a team of 5, and we need to plan this out right for once".
I went and wrote a version of it in a weekend and it ended up being what they needed. They had a few minor requests which took an hour or two but not much overall.
My boss was pretty mad at me that I made him look bad though lol. I could have handled that part better I guess, but I hate when people want to spend forever planning especially when you can get something out real quick.
When folks speak hypothetically about speed, they almost always assume identical outputs. Which is pretty contrary to at least my experience, if not reality.
Apple is the worlds most valuable company, and they're first and fastest in essentially nothing. So it really depends on the market you're going after.
Anecdotally, (and backed by language learning research iirc), when learning is involved iterations are important. Learn a little, practice a little, get feedback a little, repeat frequently.
But afaik it all comes down to the cost of failure. Public iteration on your encryption algorithm that's guarding billions of dollars is probably a bad idea.
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.
This is why I intentionally wait before answering emails that aren't related to my core responsibilities. I want fewer of these, so I best not establish a reputation as somebody who quickly provides an answer to everything. Got other things to do :-)
As the article states, this only works for stuff that can be broken up into low effort chunks. Not everything is like that such as maintaining legacy systems or working with large teams. :)
As somebody who works with legacy systems, it might take me a while to understand everything, but I think being able to experiment with different solutions rapidly is incredibly useful and has helped me zero in on the best possible solution considering the constraints. It also helps in understanding how the system works on a deeper level that often isn't possible just by reading code. Sometimes you just have to break things while implementing a possible solution.
In fact, almost nothing that's actually _useful_ is. Anything that can be broken up into predictable low effort chunks is something that can be automated away.
I don't think he says predictable or low effort. Obviously you can't build and release a bridge in a week, nor a big software system. But you can still push yourself to move fast (a relative term), and these projects do in fact get broken down into steps, even if you can't predict all the steps from here to there, and even if you can't release something along the way.
Speed matters when the thing being built is isolated.
If you're building a new feature/product whatever, and the business views that both as a standalone feature, but also as a stepping stone to support another product or feature then the code you get when writing quickly is going to slow you down in that next step.
Scale that up a few levels and you end up with 'enterprise code' that no one wants to touch for fear of breaking all the parts that depend on the pieces below it.
So write code quickly when its isolated and not planned for use in additional products, features, capabilities.
It is very difficult to convince management to prioritize tech debt and the only successful way is in the frame of enabling additional product capabilities.
If you're building a stepping stone, you still have to figure out how to make it isolated in a way then do it quickly. Like if it's a software service, spend the extra time figuring out a good API then speed through the initial implementation.
Aside from this post ultimately seeming like a bit of a joke given its conclusion, I found myself reflecting on a few things:
- Prompting people to send me MORE email is a horrifying thought and set me right off thinking this would be a parody piece.
- He's write that writing quickly can lead to more ideas. But if I'm writing for someone else, "quickly" can have multiple meanings: I can write one thing quickly, then have to rewrite it several times quickly to remedy all the assumptions and missing concepts even a competently, cleanly, and professionally written piece of text will have, OR I can slow down, answer all those questions as I go, and effectively write once well. Slowing down has been the best writing skill I've ever found for professional writing.
- Having a straight brain-to-Google interface appropriate for 2015 described as permitting almost impulsive thought is ... scary. Discipline benefits even creativity.
- I couldn't help thinking that this piece could have been simply "Work at a comfortable pace, and work on a single item, and don't get distracted by the world" and been more beneficial than "work quickly" (though, again, defining "quickly" is tricky).
From a DevOps perspective, speed is often the indicator that you're doing things right. If you integrate code quickly and often, if you deploy quickly and often, if you patch and upgrade software quickly and often, if you detect, diagnose and fix issues quickly and often, those are all indicators of a high-performing team. Quality isn't always correlated, but high-performing teams tend to care about quality, so it's not uncommon to add quality improvements to the list if you're doing everything else.
I think that part of the problem is companies/executives/manager who think that teams need to 'do' that in order to become high-performing rather than, as you stated, it's an indicator.
There needs to be a suitable environment, skills/training, support framework and everything else around to enable the team to become high-performance over time, that when starts showing that indicator.
Correlation not Causation.
All too often these are mixed by those who read the books that offer 'Acceleration' and think that enforcing these processes will somehow make the team fit.
We tend to get better at the things we do often. Companies which have annual release cycles are almost always terrible at actually shipping software in my experience. One of my first goals in any new organization is improving iteration / feedback cycle speed.
A good post overall, but the final paragraph is particularly great:
> Now, as a disclaimer, I should remind you of the rule that anyone writing a blog post advising against X is himself the worst Xer there is. At work, I have a history of painful languished projects, and I usually have the most overdue assignments of anyone on the team. As for writing, well, I have been working on this little blog post, on and off, no joke, for six years.
When I got my first big corp job at a FAANG company, in the first week a senior dev gave me the worst work advice I've ever received: "Always write code as if you expect it to be around for at least 10 years."
I think that's how that dept was doing things, and it was paralyzing. This was business logic that needed flexibility, not something like an OS kernel. Not only did new features not get shipped, but the pedantic approach actually caused tech debt because better solutions were seen as too hard. Code really did sit around for 10 years, and not because it was good code (it wasn't).
The CRUD IDE/Stacks of the late 90's were closer to the domain and that was a large reason for the productivity I used to see: more done with less key/mouse-strokes and less code. Web stacks make one waste time fiddling with janky stack parts & layers instead of domain logic, where it SHOULD be spent.
It's hard to match their productivity with current web stacks, often requiring specialists and/or big learning curves. (Sure, the 90's IDE's had their warts, but were getting better with time, until web murdered them. And I'll limit this to small-and-medium apps rather than enterprise/web-scale.)
It's usually assumed the features that made them productive are mutually exclusive with web-ness. I'm not convinced; the industry just stopped experimenting. What would help is a state-ful GUI markup standard so that GUI's don't have to be re-re-reinvented via HTML/DOM/JS, which is inherently ill-suited for rich CRUD GUIs.
Having your language/tools/standards being a close fit to the domain matters. It's why COBOL lives on despite being even older than me. I'm not saying we should mirror COBOL as-is, only that it still carries important lessons, including FDD: Fit the Damned Domain.
To a point. burnout matters too. If creating emails quickly leads to quick replies and more emails, before you know it you've emailed to your exhaustion point.
this is a tactic and strategy matters too. speed matters on things that matter.
I don't know, this is good advice perhaps for things which are not important.
But, if you are writing an email to a person whose time is valuable, better not to do it quickly. Save a draft, come back to it tomorrow, read again, then send.
If you are writing a legal document, don't do it quickly. Write it, come back to it again to review. Is it still a good idea?
If you are doing something completely new, do it slowly and step by step -- if it is new you don't know if it is right without checking each step.
If you have an idea, read the literature, patents, see what is out there first.
Great post, the summary for me being: speed is not just speed. There seem to be many other benefits aside from just maximizing productivity. It's a change in mindset that reduces decision paralysis/fear of starting, as well as encouraging experimentation.
As an aside, I was originally not going to post this comment as it doesn't really say anything not present in the article itself. But then I decided that going for it instead of overthinking or reworking it counts as an exercise in working quickly :).
I think about this another way. If you're fast enough, you can afford to do the gardening you need to keep your codebase in a good way without having to schedule it all in. If you're fast enough, when doing data analysis, you earn the space to ask the next question, and the next, and to do a deeper analysis.
But... as a lead, I've struggled to train speed before. Some people I've worked with have had it, junior or senior, and some have not.
Has anyone had good experience helping others become faster at their work?
No. I think humans are all unique. Just like a pro basketball coach, you are looking for the right talent for your particular team and your particular context.
I have had extremely smart, talented, thorough engineers who are slower than whale shit in an ice flow. For a startup, those engineers are a death sentence. It doesn't matter how good they are, if they aren't fast, they hold everyone back.
Are you building the roman empire, or are you building a small group of bandits that move swiftly through the night? Each case has it's corresponding strategy.
I think this effect is due to a cost of brain plasticity. You brain likes to close stuff regularly. Any new theory should be met with a kind of categorization, conclusion or a new idea to try later.
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.
> It is a truism, too, in workplaces, that faster employees get assigned more work.
Maybe there's irony I'm failing to perceive, but how exactly are these supposed to be good things from the fast worker's viewpoint? The truism is that working quickly is only rewarded by being assigned more work that's expected to be done even faster, which is a vicious circle if ever there was one!
Eh. Anyone who observes small children will see that they learn very slowly, but constantly. And they are extremely good at it - better than nearly all adults - at a minimum they pick up language, gross motor skills like walking, running, climbing, any number of fine motor skills, within 2-3 years.
They don't work quickly, they display no haste or concern for efficiency. In fact, they're quite inefficient.
> Now, as a disclaimer, I should remind you of the rule that anyone writing a blog post advising against X is himself the worst Xer there is. At work, I have a history of painful languished projects, and I usually have the most overdue assignments of anyone on the team. As for writing, well, I have been working on this little blog post, on and off, no joke, for six years.
And, amusingly, it currently loads really slowly too.
I'm not against or in favour of speed. History showed us many times that most people don't care about truth and correct solutions, people care about efficiency and moving things fast. Just look at gaming industry and preordering. Agile project management. This is what is called taking risks and making a jump into abbyss before we look what is underneeth. Taking risk is always praised. Question is which jump will be last one and will kill us all?
In addition to the many great points made in the article, I would add that speed does a couple of other things for you:
- The faster you finish work, the more time you have to make your work better
- The faster you are even at things like browsing HN or Reddit, the more value you get per hour (e.g. seeing more new ideas, reading more blog posts, etc)
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.
That's funny: when I learnt this, I have encouraged myself to reply with a delay so that give people a chance to resolve problems on their own and generate less emails for future me to handle.
This reminds me of Steve Yegge's classic blog post "Programming's dirtiest little secret"[0]. Yegge's post is of course about touch-typing, but it essentially makes the same argument. Doing things slowly is a liability, not primarily because it consumes more time, but because it makes you opt out of doing certain things because of their perceived cost.
"You'd be absolutely astonishedly flabbergasted at how many programmers don't know how to READ. I'm dead serious. You can learn to speed read even faster than you can learn to type, and yet there are tons of programmers out there who are unable to even skim this blog. They try, but unlike speed readers, these folks don't actually pick up the content."
Nice article. This is basically in the article when they talk about email responses back and forth, but not explicitly called out: if you are fast, people that interact with you get faster, too. Toyota figured this out with kanban (https://en.wikipedia.org/wiki/Kanban) and revolutionized process thinking. So, if you are thinking about how to get your team to work faster, focus on what is making slow team members go slowly.
I always see arguments for working faster.
Never arguments for taking your time to get solutions correct even if it doesn't produce something immediately visible.
> Whereas the fast teammate—well, their time feels cheap, in the sense that you can give them something and know they’ll be available again soon. You aren’t “using them up” by giving them work.
Well that is not always true. Producing results is one thing, making sure you learn enough in that process is another. Managers eager to cram down one micro manage task after another will use up a persons knowledge without restocking it. Yes faster can be better as lot‘s of people agree here with but there are limits.
"If you work quickly, the cost of doing something new will seem lower in your mind. So you’ll be inclined to do more." well if it is work that I know I can do quickly I'm just gonna procrastinate the hell out of it, if it is something I enjoy doing I am already inclined to do it
Being fast and iterating reminds me so much of the EM algorithm.
Probably a bit of a stretch but still:
You start with an initial estimate of the hidden variables (solution), check what the consequences are by implementing it, and apply the knowledge about the right consequences to improve the solution.
Consistently I see this advice from everyone who I consider has achieved outside success in their field.
Greg Brockman (OpenAI Cofounder) : Developer Speed is the most important thing I care about: (https://www.youtube.com/watch?v=CqiL5QQnN64). I believe he said more about this topic but I can't find it now.
Frank Slootman (Snowflake CEO): In his book Amp It Up, he stresses why pushing people to move fast is extremely important
Elon Musk (Let's not get into a debate about Elon and just agree that he has helped setup 2 100bn+ companies) : "I believe in maniacal sense of urgency, if you can implement something right after the meeting, do that", upon his work philosophy when taking over twitter.
In my personal experience one of the most impressive coders I met, worked extremely fast while also being very accurate, almost indicating that no tradeoff even exists.
https://web.archive.org/web/20230602051336/http://jsomers.ne...
https://archive.ph/jl4oc
From my perspective - speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome.
Over my career, I've been surprised multiple times when I presented early draft to a stakeholder and they said, "oh, that's great, I've got what I need now"...and this was maybe 1/3 of the effort I was planning for.
The way I see it, if the problem is important - any early solution should provide some relief. If some initial relief isn't wanted, the problem is probably not important.
Along these lines, in my work with stuck startup founders, I often ask, "if we were going to demo a prototype to a customer (in 2 days | at the end of the week), what would it be?"
I cannot possibly emphasize this more strongly. It's so important to deliver complete and working products quickly and regularly, that it's worth the cost of the occasional lost customer who leaves because all of their needs aren't met immediately. A) they're rarer than people seem to think and, B) the people you gain due to this incremental approach more than cover the losses.
That said, some devs interpret "quick" to mean "sloppy", which is not correct. When you can cut releases hourly the cost of some kinds of bugs does go down, but fewer bugs is better, and as always some categories of bugs are, "never, ever" (e.g. data corruption/leak, security bugs, outage inducing bugs).
I agree completely. That sounds much better than my current strategy of delivering incomplete and broken products at unpredictable intervals.
14 replies →
To go fast, stay humble and use boring technology.
1 reply →
> That said, some devs interpret "quick" to mean "sloppy", which is not correct.
Totally agree, but I've seen some devs completely melt when we need to go fast/iterate. For them, they really do produce sloppy work when they go too quickly. Many "big thinker" types are like this. Not defending it, just an observation.
With a good sales team, you can land customers who don’t see all the features they need, because you’re routinely delivering a solid if simple product that gets major new functionality a few times a year and if you just hold on we will get your feature to the top of the list.
Those paying customers are where your MRR comes from. Another case of perfect being the enemy of good.
There is high overlap between customers who leave because their needs aren't met immediately and customers whos needs will never be met.
I agree, and would add "(nearly)-no software regression" (no "a feature that has worked before stops working"), and never twice the same one.
As a customer of startups, I really abhor this attitude. Especially when it lingers for years after the initial product launch. Which is shockingly common.
For example, partially complete features are often completely abandoned for years and years, because they're "good enough." Unfortunately, good enough, often means unhappy customers actively looking for new competitors.
One company in particular, I absolutely despise, because of this. They are pretty much only focused on releasing new features. The old features, while functional, are in desperate need of improvement. (In many very obvious ways.)
This particular company had a good IPO. Their stock then dropped 90%. I wonder why.
> They are pretty much only focused on releasing new features.
My guess is that behavior is NOT motivated by the theory "deliver early drafts with more smaller iterations", but is instead motivated by the theory "the people who decide to buy our products do it based on feature checklists, rather than quality of anything."
These are actually not even aligned theories. The "smaller iterations with early drafts" appraoch is best done with fewer features included, not more features that are incomplete.
Many markets incentivize companies to deliver crappy software, and it is frustrating, but not, I think the fault of an agile/iterative/deliver-early-and-often approach. If you can make the most money by delivering a giant feature list of crappily implemented poorly-thought out features that don't fit well together, you'll tend to do that, regardless of theory of project management.
Having been on the other side of this - often times our users are unhappy with the unfinished features, but our customers are delighted.
That is to say, the CxO or director we've sold to has everything on their checklist and is getting "good enough" results out of their organization. Our job is to understand which of the unfinished features will cause grumbling and which will motivate users to convince an executive to switch to a competitor. It's very unusual for the former to ever be worth prioritizing.
3 replies →
> Unfortunately, good enough, often means unhappy customers actively looking for new competitors.
Here's the thing though - it's your intuition that customers are unhappy, but the startup in question has actual data. It's entirely possible that a small group of people similar to you are unhappy but for a majority of the userbase the feature has gone as far as it needs to. Resources are scarce and priorities need to be changed, which sometimes means making hard decisions.
17 replies →
It's interesting that people almost never disagree with this when they're the customers. We love seeing progress, even if it's a small portion of what we need. When frequent updates show that progress is slow, we're glad we're aware, and we don't blame the updates themselves for slowing the project down. In the rare cases where we feel like the process demands too much of our attention, we don't stress about it; we just say, "Looks great. Let's talk again in two weeks or when you have completed feature X."
Those hypothetical drawbacks only loom large in our minds when we're the ones doing the work.
What about those invisible people who gave it a try and decided there were just too many gaps and bugs? They are not customers anymore and probably never will be.
1 reply →
I once worked on a team, in house at a company, where we were tasked with developing a prototype, in a scripting language with a well-known web framework. Meanwhile another team at a consulting company, was tasked with developing the final product in java, all very enterprise.
The outside company ended up with a failed project, missing deadlines and going over budget multiple times. The prototype became the product.
>The outside company ended up with a failed project, missing deadlines and going over budget multiple times. The prototype became the product.
Getting paid to fail is a decent second place prize
Let me guess. Someone used JSF and hibernate in the same project. That is an easy way to blow up development time by a factor of 5x to 10x for literally no benefit.
I wish the PO of my team read it.
He is so insecure to talk to customers and iterate with them that it gets on my nerves.
He always have an ideal of "finished work" that, very often, we end delivering something not finished and/or wrong because we didn't iterate enough.
Customers not always know what they want even though they say that they know what they want.
If they find the appeal to authority useful, I'd grab them a copy of _Software Engineering at Google_ and leave them a bookmark in "Help Me Hide My Code".
You can find the text here:
https://abseil.io/resources/swe-book/html/ch02.html#help_me_...
(disclaimer: work there, but wasn't involved in the book at all)
1 reply →
> The way I see it, if the problem is important - any early solution should provide some relief. If some initial relief isn't wanted, the problem is probably not important.
I experienced this today, just now. The whole org’s release for fall was hinging on what I was proposed… the relief of everyone once the presentation was over and it all clicked, when they saw the light at the end of the tunnel, that the path that I had uncovered towards that is reasonable, and tenable is priceless.
I understand now that I live for this shit. 10/10 would do it again and again and again.
It's also dramatically easier to have a discussion around what does or doesn't work with a concrete example. "This but with X" or "This but without Y".
I've found this also helps just internally - start with a prototype and you have engineering discussions that are more practical than theoretical.
> ..and this was maybe 1/3 of the effort I was planning for.
Quick anecdote. When just starting out I was building a tool to automatically find the composition of essential oils used given a GC/MS output, and was told it needed to be "fast". I spent a long time optimising it, working on parallelising it and more. I spoke to them after getting it down to maybe 15 seconds or a couple of minutes something like that and was getting ready to explain why I couldn't make it fast.
"So you said you need this to be fast to be worthwhile, but"
"[intejects] yeah being fast is important, if it takes more than a day or two it'll be a lot harder to use"
...
Well it was a useful lesson at least.
> speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome.
Well put. Too many managers and execs use the word "speed" but never define it for others to make actionable.
Scenarios in real life:
I think even talking about the draft gives you an idea about the severity of the problem. My experience has been the same. If the problem is severe enough a crappy draft will do. Conversely if someone is asking for multiple refinements even to arrive at basic decisions, I begin to write off the problem as not critical.
I really like the framing of "providing relief". I think it also makes sense to allow the definition of who experiences the relief to be flexible (e.g in some cases the audience that experiences relief might be developers, security engineering, sre, etc. not just customers...)
Ahhhhhh! the MVP
I'd rather name it an MMP - a minimal marketable product. It was good enough that it worked, and the buyer (in this case the stakeholder) was happy enough to "buy" it.
There's IMHO a slight difference between MMP and MVP in the perspective one takes.
1 reply →
When it comes to business (corporate), you hear "do it right". But in reality that means "do it fast even if wrong". If mistakes are made, what happens depends upon management.
In most cases, I have seen people who do a project 100% correct, sometimes slightly slower get ignored.
Other people who get it done fast, even with many blaring mistakes, get rewarded. Usually the people who worked on it end up working 24/7 to get it fixed. That is looked upon by most managers as very good work.
If your projects go live without issues, it is usually forgotten, people who fix their own issues by putting in fixes after go-live by working 24 hours, get noticed and rewarded.
graphic designers sometimes ship their draft deliverables with 1 or 2 obvious bugs, and allow the customer to recommend these 'changes' on their own for final delivery. and if they don't, they're just fixed for final delivery anyway.
i read about it before i had this done to me for the first time, and i played along with it. it's a neat trick because it's plausibly deniable for everyone involved and the outcome is good while minimizing the bullshit work in favor of a sacrificial final word.
I've done this in hardware design, presented a design for review with a problem that had already been discovered and had a fix in progress. It was a red herring that gave the customer something to latch onto and feel like they were contributing to the success of the project. Somewhat dishonest, yes, but very effective in getting customers to work with you rather than be adversarial.
There is a concept of a sacrificial feature to prevent customers from becoming fixated on other aspects of the design that would actually create problems if changed. I prefer to avoid that sort of dark pattern though because it erodes trust.
1 reply →
I’ve also done this, with both visual design and software.
It’s a deliberate canary - if the client didn’t comment on the obvious mistake/bug, I know they didn’t actually look at it.
1 reply →
This was known as adding a 'duck'. It is unfortunately very helpful when your client stakeholder doesn't value your expertise as much as they should. It works for web design too, but you must be careful that your duck doesn't become a feature!
This is a weird thing to tie to graphic designers. Just because you noticed a graphic designer doing that doesn't mean it's a thing that's more commonly practiced among graphic designers than any other trade.
2 replies →
We've all read the duck story, but it was probably bullshit, and nobody does that
2 replies →
The fact of the matter is unless your company is very mature, getting 3 big features to prod in a month even if that means bringing down some system for awhile is generally much more valuable than getting a single feature out with zero downtime.
As the company and number of devs grow, the probability of a dev doing something stupid increases substantially, so those early mistakes can actually be quite valuable in showing where your infrastructure has gaps.
Let the imperfect code happen early, it often leads to free chaos-testing and more stable infrastructure.
How can you distinguish between "project is not important/forgotten and due to that, no issues are discovered" and "there are no issues, so it is forgotten"?
I encountered this in a previous job. I told them during design phase the implementation was failing basic computer science knowledge and would cost the company a lot of excess computing costs (due to redundant work).
a quarter after launch it was a crisis because $5k a month customers were costing $50k a month in compute. The original designer put in some patches that got it down to $25k, and then $3k and was a "hero". By my estimates the limit of the actual work being done should have been < $500. But we didn't have time to implement that due to a quarterly insistence and folks all nodding their heads at eachother to get promoted.
In the end he got promoted and i got a negative review for not being a "team player" (ie being disagreeable about a design I knew had undesirable properties)
4 replies →
Unpopular opinion: I find with long projects that development speed later on depends a lot on whether we made good decisions early on. Stopping to figure out an architectural thing can make things easily changeable later. Keeps your speed up, even a couple of years into a project.
"Do it fast" feels really, really good. It's motivating, and you feel like you're pushing forward. But it can really slow you down in the long run. Eventually, everything's so coupled that it takes weeks or months to add new features or fix bugs because you can't touch anything without breaking five other things.
As a mentor-of-sorts once told me, you end up feeling like the street sweeper after the parade
Of course, this is only rational if you know what you're building ahead of time, and that you'll need the things you're preparing to build
Agreed. In the same vein I have seen this approach work well too: "make the issue a big deal, then be the hero that fixes it"
If you just fix it business as usual.. or prevent the issue then noone will care about you.
Speed is underrated. I've worked on a lot of side projects and for a long time I couldn't get them done. I spent too long "perfecting" baseline things like folder structure (really) and overall system design. This made things slow-going and I tended to abandon them.
Over time, I started just hacking things together and shipping them, worrying less about perfecting those initial things. (I used YAGNI a lot in my decision-making.) What I learned is that there were so many more things I had to do and had to learn to do to ship. I could only get to those tasks and learn those skills by "skipping" through the earlier tasks. Working quickly helped.
I started thinking of projects as this vertical stack of work that you move up from bottom to top. If you could look holistically at absolutely everything you needed to do to ship a project, you could mark some as having a larger impact on the success of the project than others. Those are things that require more time and energy.
When you move slowly, you have a very small scope of the overall project, just stuff at the bottom, and predictions about the future. You may not really know what's ahead. If you go slowly and try to do everything perfectly down there, you spend a lot of energy on a small subset of tasks which may actually have smaller impact than something in the middle or towards the end.
Speed allows you to move through those early tasks move towards a more holistic view of the entire system so that you can determine which are high impact and which are not. You might need to double-back on an earlier task if you misjudged something as low-impact and ended up spending less time than you should on it, but at least you're not pouring energy into low-impact tasks on average.
It's not quite the same thing, but building a prototype is a good example of learning the end to end of a system without worrying too much about quality. It gives you an initial idea of what's possible and you use that to get a better picture of what's high and low impact in a project.
This is a valid approach, but not because of its "speed".
When you start a project, you have a great many things you don't know and need to learn. This is the case in 99% of projects out there. By definition, you cannot at the start of it optimize for things you don't know anything about, because... how, exactly?
If you work in a particular stack a lot, prepare a starter project template. Put some time into it, set it up so that it is optimized for letting you learn the things you don't know and helping you discover and make architectural decisions as they become necessary to make. And then just go wild.
This is the bottom-up programming approach advocated by pg in his book, IIRC. Have a setup where you can iterate quickly in the small, and make it easy to abstract and refactor as you go. You don't need a Lisp for that, just some tools with proper configs. It's also what R&D guys tend to do naturally with their Jupyter Notebooks - the difference, other than the kinds of problems faced, is that devs don't have the luxury of leaving the code in a form of REPL session transcript.
This is all true. The SWEs I work with in a corporate environment don't get it, but the managers do.
Am I right that you are talking only about quick creation of something new and not about long term support of created system?
Not OP. But applies to long term support, remember the loooong overdesigned redesign? Yeah, don't do that and rather make small quick improvements. "OH you found a typo in our config format? Update it and it'll ship in the next patch". Instead of "naw it's fine, leave it we're rewriting the configuration subsystem in that fancy new yaml/json format".
It's both. The long-term improvements have to be done in small increments too.
Just a note : I've noticed that when working with management, they often have issues "grokking" the issues they are asking for you to solve.
By offering an imprefect, quick solution, it lets them understand the issue and readjust their needs in consequence - and often, the quick imprefect solution is good enough/enough work to show it's a bad idea and to move on.
When starting project I have 2 steps : vomitting and touching up. You puke out a solution(minimum viable product), without thought about optimisation. When that exists, you change hats and optimise. Works wonders.
Except the reality often looks like:
> You puke out a solution(minimum viable product), without thought about optimisation.
And that's where it ends, because unless your employer vastly overhired, there's already a dozen (or more...) of tasks in the backlog just waiting for you to vomit them out as well.
After a year or two of working like this, you have a mountain of technical debt and no time work on it all. The entire system slowly disintegrates under its own weight.
There needs to be a balance between fast and correct, and it is only up to the developer to resist the pressure from management to work fast (at the expense of correctness). I would go as far as to say that it is one of your main non-technical duties as a developer to resist and manage this pressure as best as you can.
Maybe you're a genius who can analyze problems and implement solutions both fast AND correctly, but that is very rare.
The truth is that complex problem solutions can have complex, messy implementations. They can also have simple, beautiful implementations. Or anything in between. But what they almost invariably require is complex investigations... which take time to conduct properly.
Most (not all!) "fast" programmers I've worked with over the last 15 years produced output of questionable quality, often stemming from the "what you don't know you don't know" part of the knowledge pie chart, instead of some deeply thought out cost/benefit calculation.
IMO if the code sticks around long enough to disintegrate under its own weight, than that code was a rousing success!
"Resisting management" is almost always a horrible idea. Code is only useful when it provides a solution at the right time for the right price. If not, it is no longer useful and the world moves on.
Overall quality is nothing more than a reflection of business maturity. Like a mighty old tree with a great big trunk. It has had time to grow strong and majestic.
Most businesses don't live longer than 5 years. Most products and solutions are temporary fixes or ideas that don't last longer than a few months. Investing huge amounts of time and resources into those things is a recipe for disaster.
2 replies →
> After a year or two of working like this, you have a mountain of technical debt
What's the reason to stay longer than 2 years? From what I see it's x10 times harder to get raise inside an organisation vs when changing it.
Probably, the reason is that companies adapted to employees getting rise and leaving soon. So a raise inside org is more a calibration for those highly underrated on entry ones than some real compensation for any experience.
IME fast programmers are great at externalizing their QA
2 replies →
The customer is always right about what they want.
1 reply →
> You puke out a solution(minimum viable product), without thought about optimisation. When that exists, you change hats and optimise.
So, you first implement bubble sort, and when that exists you scrap everything and implement quick sort.
Not sure if that'd be my preferred way of doing it.
I'm not a programmer. Could you estimate how much more comple/ how much longer it takes to implement quicksort?
Otherwise, my point is that this is often good because, when begining projects, management can lack perspective of how the project will actually get done. Having a "draft" version that is planned to be scrapped lets you decide where optimisation is necessary, see future bottlenecks more clearly, and thus you can set a better foundation for the actual project.
And if it's possible to make that version say 20x or 100x faster than a V1 of the final project, I think the insight gained is worth it.
Edit0: Sometimes you even learn that it's a bad idea at all - better to learn that quickly and start over.
Edit1: After a cursory read, it seems quicksort it as simple as it gets in execution, being very few lines of code. But I'm also reading that in production code, quicksort is just part of the custom sorting algorithm that should be written for the specific database it's being applied to. If that's the case - using quicksort is the vomitting. i get what you mean "without thought about optimization"...some optimization expected, but heavily weighted towards rapid execution and low complexity.
1 reply →
I wonder how the author thinks about this now, 8 years later.
Way back in 2016/2017 I saw this video on prototyping where the programmer whipped up a snake clone in around 4 minutes. I deliberately practised programming in this way: how fast can I go from idea to working prototype? Code style, organization, testing, best practices be damned: you have about how long it takes to run a load of laundry, how much can you get done?
I did this for a few months. I focused on games. I roughly tracked how much time it took to get from empty file to the first interaction with the game. I tried to focus my practice on getting to that first interaction. And the overall time I spent and how far I got with the idea.
The thing with going that fast is... the code sucks. You're not writing it for an audience, for your future self, to make it possible to extend and compose; when you want to go fast and prototype in this way you're deliberately not going to use this code for anything later on. You just want to get the idea out there to see, "is this even fun? Would it even work at all?"
... before you go ahead and spend the next 6 - 12 months spending your limited time on something. Because finding out your game isn't actually fun after all of that effort is demotivating.
In this sense speed is useful. It's useful in certain contexts when doing programming on the job. Especially at startups where the runway is limited and you don't know if you even have customers yet.
However!
Be prepared to throw it out. Once you find some traction for a feature or process; throw out the prototype/MVP code. Make sure it's cheap to do that: you can write software that is loosely coupled, you can write a better API that uses the MVP code underneath, write good tests against the new interface, remove the old code paths piece by piece, etc. If it's a core part of the product and there are customers for it get rid of that prototype/MVP code some how (it's easier to plan for this and not get too attached to the first iteration if you do it intentionally).
Hmm I had a similar experience but with different results. I took fairly hard but common problems that I had to do and started timing myself.
First time it would be like 2 hours, then I'd get it down to 1.25 hours. Then 45 mins. Then finally I got it down to 18 minutes and couldn't get it any faster. I learned so many tricks and it really burned into my brain all the different faster ways of doing things.
I noticed at work I got way, way faster. I ended up outperforming my entire team, by myself. I think mostly because A) I now had a habit of working fast B) I viewed it as a competition, so no water cooler talking C) I didn't have to think about how to do it, I just knew, and I knew how to do it quickly.
It literally took me from making 75k to 400k in 2 years. I just applied that to everything I could, so when doing interviews I was able to just flood the interviewer with the depth of my knowledge and how fast I worked.
Now I really put in a tremendous effort into this, not just a few hours, it was an obsession for me. But once I did it I got those skills for life. Even now that I'm rusty I still go really fast.
Also, my code quality itself is quite good, because I'll write it as fast as I can (frequently only takes 15 mins), then refactor like crazy (5 to 10 mins) and still be an hour faster than everyone else.
Could you elaborate? What kinds of problems are solvable within say 2 hours?
2 replies →
Agreed - There's a certain thing about greenfield development in particular(which is quite fully the realm of startup coding) where you have to approach the first, second, maybe third iteration as one that will be thrown away, so when it does get thrown away, you make it easy to do so. And that leads towards some pretty dumb code, often "copy-paste-modify, sort it out later" code.
A lot of "best practice" ideas that get made into blogposts impose a structure that hinders disposability in favor of a certain aesthetic goal: to do the thing with less repetition and slightly cleaner abstractions. The goal is often not unreasonable, but it conflicts with the action of rapid iteration.
So I tend to write now with an eye towards trying to keep the code disposable until I face a certain class of error to eliminate, that needs the more abstract method. Often part of the disposability is in not actually solving the entire problem, but cheating and returning a wrong answer, e.g:
Instead of fancyAlgorithm() being written in a way that creates any dependencies I write a skeleton "function fancyAlgorithm() {return true;}" and then later upgrade it to a lookup table, and then to the algorithm. Because most of the code that matters to the app won't be in the algorithm, but in how all the other data is being passed around. The sooner I can get that piece to return a wrong answer with known error, the sooner I can arrive at a complete but wrong app, which can be corrected into a higher quality one. When not all the pieces of the app are there, it's not clear what error you need to be solving for, which leads to squeezing effort onto code that isn't important.
Related:
Speed matters: Why working quickly is more important than it seems - https://news.ycombinator.com/item?id=20611539 - Aug 2019 (172 comments)
This is kind of conflates the idea of a person doing a job quickly, and the idea of tools having low latency/quick response, which confuses the issue if what you care about is working quickly — the bottleneck for work is usually the speed of our thinking, or the limits of our motivation to work. But, it's usually not the speed of our tooling. You wouldn't become a better programmer with a faster computer, and usually not a more effective one either. I'll ignore the second definition.
In my opinion, you want to spend about as much time as ever, but spend more of your time working on something that is close to a solution. So, you want to work on the first draft as quickly as possible, so you can either refine it, or toss it out and do another iteration. The advantage is overall quality and confidence in your solution.
For reasons mentioned in the article, I do not prefer to be thought of as working quickly and well, since that often means someone sees your first draft and says "great, looks like you're done, now let me give you something else to work on". Better to have a reputation for taking about as long as most people, but producing better results.
> You wouldn't become a better programmer with a faster computer, and usually not a more effective one either.
Disagree, any time I have to wait for tools is a tragedy.
I've definitely became much more productive at each computer upgrade.
I'm very slow at doing things, because I consider things too much, I very much believe this is the main skill I need to work on, because the quicker you do something, the quicker it goes wrong, so you can course correct.
The book Creativity INC by Ed Catmul talks about this and they actually studied it at Pixar and they discovered the teams that moved faster were the best, the teams that considered everything for much longer, were wrong just as much as the teams that moved quickly, the only difference is because the other team moved quickly they could course correct sooner and also they were less tied into there original idea, so happy to drop it and go the other direction, were as the team that was slower and more considered took longer to drop the non-working idea, as they dug deeper and tried to make it work, since they were more invested in it.
I worked at a company where the team was asking for an internal dashboard to see real time metrics from these events we handle. My boss was like "Yeah, we are gonna need 6 months and a team of 5, and we need to plan this out right for once".
I went and wrote a version of it in a weekend and it ended up being what they needed. They had a few minor requests which took an hour or two but not much overall.
My boss was pretty mad at me that I made him look bad though lol. I could have handled that part better I guess, but I hate when people want to spend forever planning especially when you can get something out real quick.
When folks speak hypothetically about speed, they almost always assume identical outputs. Which is pretty contrary to at least my experience, if not reality.
Apple is the worlds most valuable company, and they're first and fastest in essentially nothing. So it really depends on the market you're going after.
Anecdotally, (and backed by language learning research iirc), when learning is involved iterations are important. Learn a little, practice a little, get feedback a little, repeat frequently.
But afaik it all comes down to the cost of failure. Public iteration on your encryption algorithm that's guarding billions of dollars is probably a bad idea.
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.
This is why I intentionally wait before answering emails that aren't related to my core responsibilities. I want fewer of these, so I best not establish a reputation as somebody who quickly provides an answer to everything. Got other things to do :-)
As the article states, this only works for stuff that can be broken up into low effort chunks. Not everything is like that such as maintaining legacy systems or working with large teams. :)
As somebody who works with legacy systems, it might take me a while to understand everything, but I think being able to experiment with different solutions rapidly is incredibly useful and has helped me zero in on the best possible solution considering the constraints. It also helps in understanding how the system works on a deeper level that often isn't possible just by reading code. Sometimes you just have to break things while implementing a possible solution.
> Not everything is like that
In fact, almost nothing that's actually _useful_ is. Anything that can be broken up into predictable low effort chunks is something that can be automated away.
If you can automate away programming, there's some people who would like to give you a lot of money.
7 replies →
I don't think he says predictable or low effort. Obviously you can't build and release a bridge in a week, nor a big software system. But you can still push yourself to move fast (a relative term), and these projects do in fact get broken down into steps, even if you can't predict all the steps from here to there, and even if you can't release something along the way.
Or don't automate it and enjoy the extra slack time
Speed matters when the thing being built is isolated.
If you're building a new feature/product whatever, and the business views that both as a standalone feature, but also as a stepping stone to support another product or feature then the code you get when writing quickly is going to slow you down in that next step.
Scale that up a few levels and you end up with 'enterprise code' that no one wants to touch for fear of breaking all the parts that depend on the pieces below it.
So write code quickly when its isolated and not planned for use in additional products, features, capabilities.
It is very difficult to convince management to prioritize tech debt and the only successful way is in the frame of enabling additional product capabilities.
If you're building a stepping stone, you still have to figure out how to make it isolated in a way then do it quickly. Like if it's a software service, spend the extra time figuring out a good API then speed through the initial implementation.
Aside from this post ultimately seeming like a bit of a joke given its conclusion, I found myself reflecting on a few things:
- Prompting people to send me MORE email is a horrifying thought and set me right off thinking this would be a parody piece. - He's write that writing quickly can lead to more ideas. But if I'm writing for someone else, "quickly" can have multiple meanings: I can write one thing quickly, then have to rewrite it several times quickly to remedy all the assumptions and missing concepts even a competently, cleanly, and professionally written piece of text will have, OR I can slow down, answer all those questions as I go, and effectively write once well. Slowing down has been the best writing skill I've ever found for professional writing.
- Having a straight brain-to-Google interface appropriate for 2015 described as permitting almost impulsive thought is ... scary. Discipline benefits even creativity.
- I couldn't help thinking that this piece could have been simply "Work at a comfortable pace, and work on a single item, and don't get distracted by the world" and been more beneficial than "work quickly" (though, again, defining "quickly" is tricky).
I agree with the email point. Who wants people to send them more emails?
From a DevOps perspective, speed is often the indicator that you're doing things right. If you integrate code quickly and often, if you deploy quickly and often, if you patch and upgrade software quickly and often, if you detect, diagnose and fix issues quickly and often, those are all indicators of a high-performing team. Quality isn't always correlated, but high-performing teams tend to care about quality, so it's not uncommon to add quality improvements to the list if you're doing everything else.
I think that part of the problem is companies/executives/manager who think that teams need to 'do' that in order to become high-performing rather than, as you stated, it's an indicator.
There needs to be a suitable environment, skills/training, support framework and everything else around to enable the team to become high-performance over time, that when starts showing that indicator.
Correlation not Causation.
All too often these are mixed by those who read the books that offer 'Acceleration' and think that enforcing these processes will somehow make the team fit.
We tend to get better at the things we do often. Companies which have annual release cycles are almost always terrible at actually shipping software in my experience. One of my first goals in any new organization is improving iteration / feedback cycle speed.
A good post overall, but the final paragraph is particularly great:
> Now, as a disclaimer, I should remind you of the rule that anyone writing a blog post advising against X is himself the worst Xer there is. At work, I have a history of painful languished projects, and I usually have the most overdue assignments of anyone on the team. As for writing, well, I have been working on this little blog post, on and off, no joke, for six years.
When I got my first big corp job at a FAANG company, in the first week a senior dev gave me the worst work advice I've ever received: "Always write code as if you expect it to be around for at least 10 years."
I think that's how that dept was doing things, and it was paralyzing. This was business logic that needed flexibility, not something like an OS kernel. Not only did new features not get shipped, but the pedantic approach actually caused tech debt because better solutions were seen as too hard. Code really did sit around for 10 years, and not because it was good code (it wasn't).
Compensation plays a big role in how fast I'm willing to get something done
Doesn't compensation follow good/fast work, not precede it?
That has not been my experience in modern corporate America.
Sometimes, but not always.
The CRUD IDE/Stacks of the late 90's were closer to the domain and that was a large reason for the productivity I used to see: more done with less key/mouse-strokes and less code. Web stacks make one waste time fiddling with janky stack parts & layers instead of domain logic, where it SHOULD be spent.
It's hard to match their productivity with current web stacks, often requiring specialists and/or big learning curves. (Sure, the 90's IDE's had their warts, but were getting better with time, until web murdered them. And I'll limit this to small-and-medium apps rather than enterprise/web-scale.)
It's usually assumed the features that made them productive are mutually exclusive with web-ness. I'm not convinced; the industry just stopped experimenting. What would help is a state-ful GUI markup standard so that GUI's don't have to be re-re-reinvented via HTML/DOM/JS, which is inherently ill-suited for rich CRUD GUIs.
Having your language/tools/standards being a close fit to the domain matters. It's why COBOL lives on despite being even older than me. I'm not saying we should mirror COBOL as-is, only that it still carries important lessons, including FDD: Fit the Damned Domain.
To a point. burnout matters too. If creating emails quickly leads to quick replies and more emails, before you know it you've emailed to your exhaustion point.
this is a tactic and strategy matters too. speed matters on things that matter.
I don't know, this is good advice perhaps for things which are not important.
But, if you are writing an email to a person whose time is valuable, better not to do it quickly. Save a draft, come back to it tomorrow, read again, then send.
If you are writing a legal document, don't do it quickly. Write it, come back to it again to review. Is it still a good idea?
If you are doing something completely new, do it slowly and step by step -- if it is new you don't know if it is right without checking each step.
If you have an idea, read the literature, patents, see what is out there first.
Great post, the summary for me being: speed is not just speed. There seem to be many other benefits aside from just maximizing productivity. It's a change in mindset that reduces decision paralysis/fear of starting, as well as encouraging experimentation.
As an aside, I was originally not going to post this comment as it doesn't really say anything not present in the article itself. But then I decided that going for it instead of overthinking or reworking it counts as an exercise in working quickly :).
I think about this another way. If you're fast enough, you can afford to do the gardening you need to keep your codebase in a good way without having to schedule it all in. If you're fast enough, when doing data analysis, you earn the space to ask the next question, and the next, and to do a deeper analysis.
But... as a lead, I've struggled to train speed before. Some people I've worked with have had it, junior or senior, and some have not.
Has anyone had good experience helping others become faster at their work?
No. I think humans are all unique. Just like a pro basketball coach, you are looking for the right talent for your particular team and your particular context.
I have had extremely smart, talented, thorough engineers who are slower than whale shit in an ice flow. For a startup, those engineers are a death sentence. It doesn't matter how good they are, if they aren't fast, they hold everyone back.
Are you building the roman empire, or are you building a small group of bandits that move swiftly through the night? Each case has it's corresponding strategy.
I think this effect is due to a cost of brain plasticity. You brain likes to close stuff regularly. Any new theory should be met with a kind of categorization, conclusion or a new idea to try later.
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.
> It is a truism, too, in workplaces, that faster employees get assigned more work.
Maybe there's irony I'm failing to perceive, but how exactly are these supposed to be good things from the fast worker's viewpoint? The truism is that working quickly is only rewarded by being assigned more work that's expected to be done even faster, which is a vicious circle if ever there was one!
Eh. Anyone who observes small children will see that they learn very slowly, but constantly. And they are extremely good at it - better than nearly all adults - at a minimum they pick up language, gross motor skills like walking, running, climbing, any number of fine motor skills, within 2-3 years.
They don't work quickly, they display no haste or concern for efficiency. In fact, they're quite inefficient.
> Now, as a disclaimer, I should remind you of the rule that anyone writing a blog post advising against X is himself the worst Xer there is. At work, I have a history of painful languished projects, and I usually have the most overdue assignments of anyone on the team. As for writing, well, I have been working on this little blog post, on and off, no joke, for six years.
And, amusingly, it currently loads really slowly too.
When I read about speed of doing things this always reminds me a tale of two programmers https://news.ycombinator.com/item?id=677655, archive link https://web.archive.org/web/20121226223216/http://mail.linux...
I'm not against or in favour of speed. History showed us many times that most people don't care about truth and correct solutions, people care about efficiency and moving things fast. Just look at gaming industry and preordering. Agile project management. This is what is called taking risks and making a jump into abbyss before we look what is underneeth. Taking risk is always praised. Question is which jump will be last one and will kill us all?
In addition to the many great points made in the article, I would add that speed does a couple of other things for you:
- The faster you finish work, the more time you have to make your work better
- The faster you are even at things like browsing HN or Reddit, the more value you get per hour (e.g. seeing more new ideas, reading more blog posts, etc)
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.
That's funny: when I learnt this, I have encouraged myself to reply with a delay so that give people a chance to resolve problems on their own and generate less emails for future me to handle.
(2015)
https://archive.is/2019.08.06-012000/http://jsomers.net/blog...
This reminds me of Steve Yegge's classic blog post "Programming's dirtiest little secret"[0]. Yegge's post is of course about touch-typing, but it essentially makes the same argument. Doing things slowly is a liability, not primarily because it consumes more time, but because it makes you opt out of doing certain things because of their perceived cost.
[0] http://steve-yegge.blogspot.com/2008/09/programmings-dirties...
"You'd be absolutely astonishedly flabbergasted at how many programmers don't know how to READ. I'm dead serious. You can learn to speed read even faster than you can learn to type, and yet there are tons of programmers out there who are unable to even skim this blog. They try, but unlike speed readers, these folks don't actually pick up the content."
Heh!
Nice article. This is basically in the article when they talk about email responses back and forth, but not explicitly called out: if you are fast, people that interact with you get faster, too. Toyota figured this out with kanban (https://en.wikipedia.org/wiki/Kanban) and revolutionized process thinking. So, if you are thinking about how to get your team to work faster, focus on what is making slow team members go slowly.
I always see arguments for working faster. Never arguments for taking your time to get solutions correct even if it doesn't produce something immediately visible.
...I'm sure there is no economic correlation
Being more productive is more valuable and profitable.
"Correct" doesn't sprout fully grown from your head like Athena from Zeus
Valuable and profitable for investors, or society ?
Because absolutely not both.
> Whereas the fast teammate—well, their time feels cheap, in the sense that you can give them something and know they’ll be available again soon. You aren’t “using them up” by giving them work.
Well that is not always true. Producing results is one thing, making sure you learn enough in that process is another. Managers eager to cram down one micro manage task after another will use up a persons knowledge without restocking it. Yes faster can be better as lot‘s of people agree here with but there are limits.
related: Some reasons to work on productivity and velocity
https://news.ycombinator.com/item?id=28882043
I agree with his points. The question is: what are some ways of working fast without being sloppy? Would be interested in how people here do it.
1. Slow is smooth and smooth is fast. Don't rush and crush.
2. Practicing to get faster at the nitty gritty boring details, relying less on your reference materials, is as important as the big ideas.
In my experience, after you've finished 90% of the work, there's the other 90% ... in the other aspects.
Like, you finished your software? Great. Now you have to make a sales funnel, do PR, push news about it, etc. Slack off on anything and it is a flop.
In short, if you're dreading work, chances are you need partners!
"If you work quickly, the cost of doing something new will seem lower in your mind. So you’ll be inclined to do more." well if it is work that I know I can do quickly I'm just gonna procrastinate the hell out of it, if it is something I enjoy doing I am already inclined to do it
Tinkering and iterating is key to progress.
The more “volume” of work you can do per unit time, the more you can be ruthless in culling work that don’t meet your standards.
From the outside observation, it will look like the person consistently outputs quality work, when in reality it is just a harsh selection process.
Being fast and iterating reminds me so much of the EM algorithm.
Probably a bit of a stretch but still:
You start with an initial estimate of the hidden variables (solution), check what the consequences are by implementing it, and apply the knowledge about the right consequences to improve the solution.
Site not loading for me :(
Have you tried loading it faster?
Which is a little ironic considering this quote from the article:
> It’s now well known on the web that slow server response times drive users away. A slow website feels broken.
I was just about to give up when it finally loaded
I guess the author did the website too quickly.
The best solution I found to this logjam was this quote:
> "Make haste slowly." - Baltasar Gracian
We can go older: "festina lente" in Latin. (https://en.wikipedia.org/wiki/Festina_lente)
'Haste makes waste'. I see this with coworkers all the time.
Consistently I see this advice from everyone who I consider has achieved outside success in their field.
Greg Brockman (OpenAI Cofounder) : Developer Speed is the most important thing I care about: (https://www.youtube.com/watch?v=CqiL5QQnN64). I believe he said more about this topic but I can't find it now.
Frank Slootman (Snowflake CEO): In his book Amp It Up, he stresses why pushing people to move fast is extremely important
Elon Musk (Let's not get into a debate about Elon and just agree that he has helped setup 2 100bn+ companies) : "I believe in maniacal sense of urgency, if you can implement something right after the meeting, do that", upon his work philosophy when taking over twitter.
In my personal experience one of the most impressive coders I met, worked extremely fast while also being very accurate, almost indicating that no tradeoff even exists.
make it work, then make it right (if time permits)
your job isn't writing code, it's fixing someone's problems
[dead]
[flagged]