{ "archive_path": "archive/1780155189.642808", "base_url": "dubroy.com/blog/fast-is-better-than-slow", "basename": "", "bookmarked_date": "2026-05-30 15:33", "canonical": { "archive_org_path": "https://web.archive.org/web/dubroy.com/blog/fast-is-better-than-slow", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=dubroy.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "dubroy.com", "downloaded_at": "2026-05-30T15:33:16.029812+00:00", "downloaded_datestr": "2026-05-30 15:33", "extension": "", "hash": "HWMNTTVR8MVV2ND36DZ5", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://dubroy.com/blog/fast-is-better-than-slow/" ], "cmd_version": "8.10.1", "end_ts": "2026-05-30T15:34:14.766762+00:00", "index_texts": null, "output": "ArchiveError: Failed to find \"content-location\" URL header in Archive.org response.", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:43.485060+00:00", "status": "failed" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://dubroy.com/blog/fast-is-better-than-slow/" ], "cmd_version": "131.0.6778", "end_ts": "2026-05-30T15:33:29.113280+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:19.416990+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=dubroy.com" ], "cmd_version": "8.10.1", "end_ts": "2026-05-30T15:33:19.224516+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:16.080058+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://dubroy.com/blog/fast-is-better-than-slow/" ], "cmd_version": "8.10.1", "end_ts": "2026-05-30T15:33:19.330143+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:19.286254+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2026-05-30T15:33:36.522601+00:00", "index_texts": [ "Fast is better than slow (https://dubroy.com/blog/res/normalize.css) (https://dubroy.com/blog/res/style.css) (RSS Feed) (http://dubroy.com/blog/rss.xml) (https://dubroy.com/blog/fast-is-better-than-slow/) (/) Patrick Dubroy (/about/) About (/now/) Now (/consulting/) Consulting (https://dubroy.com/blog/archives/) Archives (https://dubroy.com/blog/fast-is-better-than-slow/) Fast is better than slow May 23, 2026 Don\u2019t question why. Fast is better than slow. That\u2019s just how it is. Your job is to take everything you can already do and do it faster. If you can embrace the idea that fast is intrinsically better than slow, you\u2019re halfway home. If you can get an entire team of players to embrace that idea, you\u2019re going to win a lot of games. All other things being equal, if I can get the ball from Point A to Point B with one touch, it is better than getting it there in two touches. Why? Because one touch is faster than two touches, and fast is better than slow. \u2014 Dan Blank, (https://soccerpoet.com/product/store/Paperbacks/) Soccer IQ About 10 years ago, I realized all the best programmers I had worked with had something in common: they were fast . By that I mean that they moved quickly: we\u2019d discuss a problem and an hour or two later they\u2019d already have a patch ready or a prototype to show off. It took me a while, but eventually I realized: they weren\u2019t fast because they were great programmers, they were great programmers because they were fast. Think about it \u2014 if you\u2019re fast, you get data more quickly. That helps you make better decisions, sooner. It also means you learn faster, and over longer periods it means you learn more . Being fast also means you can try out multiple approaches to a problem and pick the best one. A lot of people push back on this because it sounds like hustle culture. But there are lots of ways to move faster that don\u2019t involve working long hours. Jamie Brandon has written a pair of excellent posts on this: (https://www.scattered-thoughts.net/writing/speed-matters/) Speed matters and (https://www.scattered-thoughts.net/writing/moving-faster/) Moving faster . You should go and read those if you haven\u2019t already. I have a few suggestions of my own \u2014\u00a0things that are a bit more about the messy reality of working as a software engineer than they are about coding per se. And I\u2019m slightly embarrassed to admit that, unlike Jamie, they took me more than a decade to learn. Don\u2019t delay. This is a big one. I\u2019ve worked with many people who seem to move slowly out of habit. They learn about a problem at 4pm, and decide to tackle it tomorrow. Or next week, or next quarter. I think this is often about avoiding discomfort. Getting started is hard: you often don\u2019t know exactly what needs to be done, or where to begin. It\u2019s comforting to believe that waiting will make it easier, but in my experience it rarely does. Reclaim the small chunks. Some programmers have convinced themselves that they need long, uninterrupted work periods to get anything done. As I wrote in (https://dubroy.com/blog/getting-things-done-in-small-increments/) Getting things done (in small increments) , I think this is more of a preference than a hard constraint. Most people could get better at this if they tried. The wins can be surprisingly big. At many companies, you might be lucky to have a single uninterrupted block of 3\u20134 hours each day. Say you have another hour or two of meetings \u2014 that\u2019s still 25\u201335% of your time lost to fragmentation. You can get a lot more done if you spend that time being productive rather than reading email or browsing Hacker News. Don\u2019t worry about looking dumb. You probably already know that you should share your work early and often. But it\u2019s uncomfortable, so it\u2019s easy to put it off while telling yourself a story like \u201cI have a high bar for quality.\u201d You\u2019ll get results much faster if you learn to push through that discomfort. Oliver Burkeman talks about (https://ckarchive.com/b/wvu2hghk5m82zf9r552rqtn34kzxxc8) the 70% rule : If you\u2019re roughly 70% happy with a piece of writing you\u2019ve produced, you\u2019ll should publish it. If you\u2019re 70% satisfied with a product you\u2019ve created, launch it. [\u2026] Moving forward at 70% takes more guts, more strength of character, than holding out for 100%, because it entails moving forward amid uncertainty, anxiety, and the disagreeable feeling that comes with putting less-than-perfect work into the world. The same goes for PRs. Don\u2019t waste time polishing your code in hopes that your reviewer will find nothing wrong \u2014\u00a0push it now and accept the feedback. There are no points for getting your PR approved without comments. Another way to move more quickly (and potentially look dumb in the process) is to ask your colleagues for advice. I\u2019ve seen many developers who seem to think they\u2019re required to come up with everything themselves. But software development is a team sport \u2014 don\u2019t force yourself to go it alone. Pick your battles. When it comes to collaboration, don\u2019t waste time bikeshedding. If your PR reviewer wants you to change something, it\u2019s almost always faster to do what they\u2019re asking than to argue about it. 95% of the time, the differences are so minor that it\u2019s barely worth discussing. Save your time and energy for the 5% that matter. The same thing applies when you\u2019re reviewing \u2014 don\u2019t waste your time on inconsequential things. I\u2019m definitely not saying you should rubber stamp everything; I often leave comments suggesting better names, or other ways to do things, but leave the final decision up to the author. I think at least 50% of my reviews are \u201cLGTM with comments\u201d \u2014 in my opinion, this gives you most of the benefits of code review without letting it suck up too much time (for you or your teammates). Do only what\u2019s required. In one of my first internships, the team lead gave me some advice: \u201cWhen someone asks you to do something, do the absolute minimum that\u2019s required. If you can do that consistently, everyone will think you\u2019re a genius.\u201d At the time, I thought it was cynical; but over the years, I\u2019ve come to realize how wise it is. If you try to go \u201cabove and beyond\u201d, you\u2019re almost always guessing \u2014 about what someone else wants, or what the system will require in the future. And the more inexperienced you are, the greater the chance that your guess is wrong. To move faster, don\u2019t waste time doing things that nobody asked for. Don\u2019t question why. Fast is better than slow. That\u2019s just how it is. Your job is to take everything you can already do and do it faster. Hey there! I'm Patrick, a programmer and independent researcher based in Munich, Germany. I'm a co-creator of (https://ohmjs.org) Ohm , and (with Mariano Guerra) an author of (https://wasmgroundup.com) WebAssembly from the Ground Up . I do technical advising and freelance development for companies big and small, and have availability for new projects in 2026. Interested in working together? (https://dubroy.com/about) Get in touch . \u00a9 2006\u20132026 Patrick Dubroy \u00b7 Powered by (http://www.butterbreze.de/zutaten.html) Butterbrezn and (http://www.augustiner-braeu.de/) Augustiner . Subscribe: (https://dubroy.com/blog/rss.xml) RSS \u00b7 (https://buttondown.email/pdubroy) email " ], "output": "htmltotext.txt", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:36.505760+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://dubroy.com/blog/fast-is-better-than-slow/" ], "cmd_version": "2024.10.7", "end_ts": "2026-05-30T15:33:43.447981+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:36.632823+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://dubroy.com/blog/fast-is-better-than-slow/" ], "cmd_version": "2.2.3", "end_ts": "2026-05-30T15:33:36.472672+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:33.059230+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmpzytk5pds", "https://dubroy.com/blog/fast-is-better-than-slow/" ], "cmd_version": "0.0.11", "end_ts": "2026-05-30T15:33:32.705130+00:00", "index_texts": [ "May 23, 2026\n \nDon\u2019t question why. Fast is better than slow. That\u2019s just how it is. Your job is to take everything you can already do and do it faster.\nIf you can embrace the idea that fast is intrinsically better than slow, you\u2019re halfway home. If you can get an entire team of players to embrace that idea, you\u2019re going to win a lot of games.\nAll other things being equal, if I can get the ball from Point A to Point B with one touch, it is better than getting it there in two touches. Why? Because one touch is faster than two touches, and fast is better than slow.\n\n\u2014 Dan Blank, Soccer IQ\nAbout 10 years ago, I realized all the best programmers I had worked with had something in common: they were fast. By that I mean that they moved quickly: we\u2019d discuss a problem and an hour or two later they\u2019d already have a patch ready or a prototype to show off.\nIt took me a while, but eventually I realized: they weren\u2019t fast because they were great programmers, they were great programmers because they were fast.\nThink about it \u2014 if you\u2019re fast, you get data more quickly. That helps you make better decisions, sooner. It also means you learn faster, and over longer periods it means you learn more. Being fast also means you can try out multiple approaches to a problem and pick the best one.\nA lot of people push back on this because it sounds like hustle culture. But there are lots of ways to move faster that don\u2019t involve working long hours. Jamie Brandon has written a pair of excellent posts on this: Speed matters and Moving faster. You should go and read those if you haven\u2019t already.\nI have a few suggestions of my own \u2014\u00a0things that are a bit more about the messy reality of working as a software engineer than they are about coding per se. And I\u2019m slightly embarrassed to admit that, unlike Jamie, they took me more than a decade to learn.\nDon\u2019t delay. This is a big one. I\u2019ve worked with many people who seem to move slowly out of habit. They learn about a problem at 4pm, and decide to tackle it tomorrow. Or next week, or next quarter.\nI think this is often about avoiding discomfort. Getting started is hard: you often don\u2019t know exactly what needs to be done, or where to begin. It\u2019s comforting to believe that waiting will make it easier, but in my experience it rarely does.\nReclaim the small chunks. Some programmers have convinced themselves that they need long, uninterrupted work periods to get anything done. As I wrote in Getting things done (in small increments), I think this is more of a preference than a hard constraint. Most people could get better at this if they tried.\nThe wins can be surprisingly big. At many companies, you might be lucky to have a single uninterrupted block of 3\u20134 hours each day. Say you have another hour or two of meetings \u2014 that\u2019s still 25\u201335% of your time lost to fragmentation. You can get a lot more done if you spend that time being productive rather than reading email or browsing Hacker News.\nDon\u2019t worry about looking dumb. You probably already know that you should share your work early and often. But it\u2019s uncomfortable, so it\u2019s easy to put it off while telling yourself a story like \u201cI have a high bar for quality.\u201d\nYou\u2019ll get results much faster if you learn to push through that discomfort. Oliver Burkeman talks about the 70% rule:\n\nIf you\u2019re roughly 70% happy with a piece of writing you\u2019ve produced, you\u2019ll should publish it. If you\u2019re 70% satisfied with a product you\u2019ve created, launch it.\n[\u2026]\nMoving forward at 70% takes more guts, more strength of character, than holding out for 100%, because it entails moving forward amid uncertainty, anxiety, and the disagreeable feeling that comes with putting less-than-perfect work into the world.\n\nThe same goes for PRs. Don\u2019t waste time polishing your code in hopes that your reviewer will find nothing wrong \u2014\u00a0push it now and accept the feedback. There are no points for getting your PR approved without comments.\nAnother way to move more quickly (and potentially look dumb in the process) is to ask your colleagues for advice. I\u2019ve seen many developers who seem to think they\u2019re required to come up with everything themselves. But software development is a team sport \u2014 don\u2019t force yourself to go it alone.\nPick your battles. When it comes to collaboration, don\u2019t waste time bikeshedding. If your PR reviewer wants you to change something, it\u2019s almost always faster to do what they\u2019re asking than to argue about it. 95% of the time, the differences are so minor that it\u2019s barely worth discussing. Save your time and energy for the 5% that matter.\nThe same thing applies when you\u2019re reviewing \u2014 don\u2019t waste your time on inconsequential things. I\u2019m definitely not saying you should rubber stamp everything; I often leave comments suggesting better names, or other ways to do things, but leave the final decision up to the author. I think at least 50% of my reviews are \u201cLGTM with comments\u201d \u2014 in my opinion, this gives you most of the benefits of code review without letting it suck up too much time (for you or your teammates).\nDo only what\u2019s required. In one of my first internships, the team lead gave me some advice: \u201cWhen someone asks you to do something, do the absolute minimum that\u2019s required. If you can do that consistently, everyone will think you\u2019re a genius.\u201d At the time, I thought it was cynical; but over the years, I\u2019ve come to realize how wise it is.\nIf you try to go \u201cabove and beyond\u201d, you\u2019re almost always guessing \u2014 about what someone else wants, or what the system will require in the future. And the more inexperienced you are, the greater the chance that your guess is wrong.\nTo move faster, don\u2019t waste time doing things that nobody asked for.\n\n\nDon\u2019t question why. Fast is better than slow. That\u2019s just how it is. Your job is to take everything you can already do and do it faster." ], "output": "readability/", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:29.164981+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://dubroy.com/blog/fast-is-better-than-slow/" ], "cmd_version": "8.10.1", "end_ts": "2026-05-30T15:33:29.137583+00:00", "index_texts": null, "output": "Fast is better than slow", "pwd": "/data/archive/1780155189.642808", "schema": "ArchiveResult", "start_ts": "2026-05-30T15:33:29.133911+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "ArchiveError: Failed to find \"content-location\" URL header in Archive.org response.", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Fast is better than slow", "warc": null, "wget": null }, "link_dir": "/data/archive/1780155189.642808", "newest_archive_date": "2026-05-30T15:33:43.485060+00:00", "num_failures": 1, "num_outputs": 8, "oldest_archive_date": "2026-05-30T15:33:16.080058+00:00", "path": "/blog/fast-is-better-than-slow/", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01KSWR978V224AD66A01CNNVGY", "snapshot_id": "4a96574c-9ba5-4a83-859a-9426595aee1e", "sources": [ "/data/sources/1780155188-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1780155189.642808", "title": "Fast is better than slow", "url": "https://dubroy.com/blog/fast-is-better-than-slow/" }