{ "archive_path": "archive/1770357387.077353", "base_url": "www.seangoedecke.com/getting-the-main-thing-right", "basename": "", "bookmarked_date": "2026-02-06 05:56", "canonical": { "archive_org_path": "https://web.archive.org/web/www.seangoedecke.com/getting-the-main-thing-right", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=www.seangoedecke.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": "www.seangoedecke.com", "downloaded_at": "2026-02-06T05:56:34.103893+00:00", "downloaded_datestr": "2026-02-06 05:56", "extension": "", "hash": "16V37S6GAD3R5Z0SBVGX", "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://www.seangoedecke.com/getting-the-main-thing-right/" ], "cmd_version": "8.10.1", "end_ts": "2026-02-06T05:58:22.616965+00:00", "index_texts": null, "output": "TimeoutExpired: Command '['/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://www.seangoedecke.com/getting-the-main-thing-right/']' timed out after 60 seconds", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:57:22.557082+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://www.seangoedecke.com/getting-the-main-thing-right/" ], "cmd_version": "131.0.6778", "end_ts": "2026-02-06T05:56:51.131503+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:56:43.915312+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=www.seangoedecke.com" ], "cmd_version": "8.10.1", "end_ts": "2026-02-06T05:56:37.612030+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:56:34.436665+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://www.seangoedecke.com/getting-the-main-thing-right/" ], "cmd_version": "8.10.1", "end_ts": "2026-02-06T05:56:37.712642+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:56:37.648988+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2026-02-06T05:57:14.721945+00:00", "index_texts": [ "(/favicon-32x32.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/manifest.webmanifest) (/icons/icon-48x48.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-72x72.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-96x96.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-144x144.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-192x192.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-256x256.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-384x384.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-512x512.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) Getting the main thing right (seangoedecke.com RSS feed) (/rss.xml) (seangoedecke.com RSS feed) (/feed.xml) (seangoedecke.com RSS feed) (/atom.xml) (/webpack-runtime-e8d9e6470a0bba848f04.js) (/framework-ddca7dd446fc76edf1f1.js) (/styles-3959adbb69757b17e30b.js) (/app-b05ce3c0906e5d46d5fd.js) (/commons-814c64de73b8ea4567bc.js) (/component---src-templates-blog-post-js-054278363c6e0eebd484.js) (/page-data/getting-the-main-thing-right/page-data.json) (/page-data/sq/d/1146911855.json) (/page-data/sq/d/3764592887.json) (/page-data/app-data.json) (/page-data/tags/good engineers/page-data.json) (/page-data/index/page-data.json) (/page-data/tags/tech companies/page-data.json) (/component---src-templates-tag-page-js-2049bcac69396108d399.js) (/component---src-templates-blog-list-js-a288fa8e2cbefa74f6b5.js) (/component---src-templates-tag-page-js-2049bcac69396108d399.js) (/) sean goedecke February 5, 2026\u2502(/tags/good engineers/) good engineers , (/tags/tech companies/) tech companies Getting the main thing right When you\u2019re running a project in a tech company, understanding that your main job is to ship the project goes a surprisingly long way. So many engineers spend their time on peripheral questions (like the choice of technology X or Y) when core questions about shipping the product (for instance, how all the critical paths will actually work) are still unanswered1 . If you\u2019re able to reliably ship projects, you can get away with being slightly abrasive, or not filling out your Jira tickets correctly, or any number of other small faults that would cause other engineers to be punished. You could see this as a special case of the (https://en.wikipedia.org/wiki/Pareto_principle) Pareto principle : the idea that 80% of consequences often come from 20% of causes. But I think in many contexts it\u2019s even more extreme, closer to 90/10 or even 99/1. If you get the \u201cmain thing\u201d right, you can get away with a lot of mistakes. This principle holds in many other areas. When saving money, it doesn\u2019t matter if you save a few dollars by hunting for deals if you then buy a car or house that\u2019s on the edge of your budget. If you\u2019re writing, clearly expressing your point will make up for awkward grammar or other mistakes, but even beautiful prose is bad writing if it doesn\u2019t say what you mean. If you\u2019re trying to get fit, consistency and avoiding injury is far more important than finding the most efficient program or the best gear. And so on. Identifying the \u201cmain thing\u201d How do you identify the main thing? This is a pretty deep question. I have written extensively about this when it comes to working in large tech companies: you can read (/where-the-money-comes-from) Knowing where your engineer salary comes from , or browse my posts tagged (/tags/tech%20companies) \u201ctech companies\u201d . In under twenty words, I think it\u2019s \u201cdelivering projects in order to increase shareholder value and make the ~2 layers of management above you happy\u201d. From the way I\u2019ve phrased it, it should be clear that I think this is the \u201cmain thing\u201d for working in tech companies . It\u2019s not the main thing for life in general, or for being a fulfilled software craftsperson, and so on. Those two domains have completely different main things2 . Sometimes the main thing seems too simple to be important. Plenty of software engineers think something like \u201cof course it\u2019s important to ship the project, but that only happens as a result of writing all the code\u201d, underrating the set of complex factors (both in code and elsewhere) that have to come together for a successful ship. The only general reliable method I know is to carefully look at cases of success and failure, and to identify what the successes had in common. Pay particular attention to successes or failures that surprise you. If you thought a project was going really well but the people who ran it weren\u2019t rewarded, or you thought a project was a complete disaster but it ended up being celebrated, that probably indicates that you\u2019re mistaken about what the \u201cmain thing\u201d is. Did someone get a staff promotion but you think they\u2019re terrible? Is someone beloved by senior leadership, but you can\u2019t see them doing anything that useful? Those people are probably getting the main thing right3 . It\u2019s hard to even try The first step in correctly identifying the main thing is to try . In my experience, it is surprisingly hard to motivate yourself to focus on the main thing . It\u2019s much more natural to just jump into something that looks probably useful and start working immediately. Why is this? One obvious reason is that it just feels bad to sit around contemplating all the things you could focus on. It\u2019s much easier to account for your time - both to others and to yourself - if you look busy. What if you can\u2019t come up with anything, and you\u2019ve just wasted all the time you spent reflecting? Another, less obvious reason is that many people are afraid that they might not like the main thing . Recall my description of the main thing at tech companies: \u201cdelivering projects in order to increase shareholder value and make the ~2 layers of management above you happy\u201d Lots of software engineers really hate that this is the most important thing. I wrote about this at length in (/a-little-bit-cynical) Software engineers should be a little bit cynical and (/knowing-how-to-drive-the-car) You have to know how to drive the car . If you don\u2019t like this goal at all, it\u2019s going to be tough to spend time thinking about how you can achieve it. In fact, I think it\u2019s actually more important to think about the \u201cmain thing\u201d if you hate it . This is why I\u2019m suspicious of \u201cdo what you love\u201d advice. If you love performance engineering but your company doesn\u2019t, I think you\u2019re better off doing it in your spare time and creating shareholder value at work, instead of trying to do as much performance engineering at work as you can. Half-assing creating shareholder value a few hours a day (and doing performance engineering the rest of the time) is more valuable than locking in to the wrong \u201cmain thing\u201d for ten hours a day. In my experience, it\u2019s also likely more burnout-resistant, since there\u2019s no faster path to burnout than working really hard on something that isn\u2019t valued. Caution: the \u201cmain thing\u201d can rapidly change In 2015, being easy to work with was the most important thing in many tech companies. If you were a pleasant colleague, you had to be really bad at other aspects of the job to face serious professional consequences. On the other hand, if you were abrasive and hard to work with, it didn\u2019t really matter how technically competent you were. Many engineers made successful careers by maximizing pleasantness: attending and hosting work social events, making friendly connections in different teams, and in general becoming a known engineer in the company. In 2026, it\u2019s still important to be pleasant. But now that tech companies are (/good-times-are-over) tightening their belts and feeling more pressure to ship, the most important thing has shifted to being capable of (/how-to-ship) delivering projects . If you\u2019re able to do that, it can go a long way towards redeeming a difficult personality. Like love, shipping (https://www.biblegateway.com/passage/?search=Proverbs%2010%3A11-13&version=NKJV) covers all sins . This transition has been a bumpy ride for many software engineers. A lot of very pleasant \u201cknown engineers\u201d have been laid off in the last three years. I suppose the lesson here is something like this: even if you\u2019re doing great and are well-adapted to your niche, the environment can change and screw you over anyway . What can you do about it? If you\u2019ve spent a good chunk of your career developing one set of skills, you can\u2019t instantly transfer all that experience to a different set of skills when the environment changes. Maybe the underlying lesson is more like this: instead of over-specializing to a single niche, hedge your bets by being pretty good at multiple things . Final thoughts The lesson here is that you should spend a lot of time and effort trying to figure out what to focus on . In the extreme case, even spending half of your time doing this is worthwhile, if it puts you on the right track and you\u2019d otherwise be neglecting the main thing. This can seem pretty unintuitive. It feels safer and more productive to be doing something . But if you can force yourself to focus on the meta-question of what you ought to be doing - even if you don\u2019t like the answer - you\u2019ll be in a better position to achieve your goals. I write about this at length in (/how-to-ship) How I ship projects at large tech companies . \u21a9 I leave filling out what those are as an exercise to the reader. \u21a9 Or some people just get lucky! But that\u2019s rarer than you might think. Getting the main thing right often looks like \u201cconstantly getting lucky\u201d from the outside. \u21a9 If you liked this post, consider(https://buttondown.com/seangoedecke) subscribing to email updates about my new posts, or(https://news.ycombinator.com/submitlink?u=https://www.seangoedecke.com/getting-the-main-thing-right/&t=Getting the main thing right) sharing it on Hacker News .Here's a preview of a related post that shares tags with this one. You have to know how to drive the car There are lots of different ways to be a software engineer. You can grind out code for twelve hours a day to (https://www.youtube.com/watch?v=B8C5sjjhsso) make the world a better place . You can focus on (https://www.noidea.dog/glue) glue work : process-based work that makes everyone around you more successful. You can join the conversation with your product manager and designer colleagues to influence what gets built, not just how it gets built. You can climb the ladder to staff engineer and above, or you can take it easy and focus on your hobbies. But whichever of these you choose, you have to know how tech companies work .(/knowing-how-to-drive-the-car/) Continue reading... (https://buttondown.com/seangoedecke) subscribe \u2502 (/about) about \u2502 (/podcasts) podcasts \u2502 (/popular) popular \u2502 (/tags) tags \u2502 (/rss.xml) rss Search seangoedecke.com () (Search posts) Search " ], "output": "htmltotext.txt", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:57:14.689650+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://www.seangoedecke.com/getting-the-main-thing-right/" ], "cmd_version": "2024.10.7", "end_ts": "2026-02-06T05:57:22.507185+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:57:16.922624+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://www.seangoedecke.com/getting-the-main-thing-right/" ], "cmd_version": "2.2.3", "end_ts": "2026-02-06T05:57:14.646622+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:57:10.823354+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmpxuqsstcg", "https://www.seangoedecke.com/getting-the-main-thing-right/" ], "cmd_version": "0.0.11", "end_ts": "2026-02-06T05:56:55.330097+00:00", "index_texts": [ "When you\u2019re running a project in a tech company, understanding that your main job is to ship the project goes a surprisingly long way. So many engineers spend their time on peripheral questions (like the choice of technology X or Y) when core questions about shipping the product (for instance, how all the critical paths will actually work) are still unanswered1.\nIf you\u2019re able to reliably ship projects, you can get away with being slightly abrasive, or not filling out your Jira tickets correctly, or any number of other small faults that would cause other engineers to be punished.\nYou could see this as a special case of the Pareto principle: the idea that 80% of consequences often come from 20% of causes. But I think in many contexts it\u2019s even more extreme, closer to 90/10 or even 99/1. If you get the \u201cmain thing\u201d right, you can get away with a lot of mistakes.\nThis principle holds in many other areas. When saving money, it doesn\u2019t matter if you save a few dollars by hunting for deals if you then buy a car or house that\u2019s on the edge of your budget. If you\u2019re writing, clearly expressing your point will make up for awkward grammar or other mistakes, but even beautiful prose is bad writing if it doesn\u2019t say what you mean. If you\u2019re trying to get fit, consistency and avoiding injury is far more important than finding the most efficient program or the best gear. And so on.\nIdentifying the \u201cmain thing\u201d\nHow do you identify the main thing? This is a pretty deep question. I have written extensively about this when it comes to working in large tech companies: you can read Knowing where your engineer salary comes from, or browse my posts tagged \u201ctech companies\u201d. In under twenty words, I think it\u2019s \u201cdelivering projects in order to increase shareholder value and make the ~2 layers of management above you happy\u201d.\nFrom the way I\u2019ve phrased it, it should be clear that I think this is the \u201cmain thing\u201d for working in tech companies. It\u2019s not the main thing for life in general, or for being a fulfilled software craftsperson, and so on. Those two domains have completely different main things2.\nSometimes the main thing seems too simple to be important. Plenty of software engineers think something like \u201cof course it\u2019s important to ship the project, but that only happens as a result of writing all the code\u201d, underrating the set of complex factors (both in code and elsewhere) that have to come together for a successful ship.\nThe only general reliable method I know is to carefully look at cases of success and failure, and to identify what the successes had in common. Pay particular attention to successes or failures that surprise you. If you thought a project was going really well but the people who ran it weren\u2019t rewarded, or you thought a project was a complete disaster but it ended up being celebrated, that probably indicates that you\u2019re mistaken about what the \u201cmain thing\u201d is. Did someone get a staff promotion but you think they\u2019re terrible? Is someone beloved by senior leadership, but you can\u2019t see them doing anything that useful? Those people are probably getting the main thing right3.\nIt\u2019s hard to even try\nThe first step in correctly identifying the main thing is to try. In my experience, it is surprisingly hard to motivate yourself to focus on the main thing. It\u2019s much more natural to just jump into something that looks probably useful and start working immediately. Why is this?\nOne obvious reason is that it just feels bad to sit around contemplating all the things you could focus on. It\u2019s much easier to account for your time - both to others and to yourself - if you look busy. What if you can\u2019t come up with anything, and you\u2019ve just wasted all the time you spent reflecting?\nAnother, less obvious reason is that many people are afraid that they might not like the main thing. Recall my description of the main thing at tech companies:\n\n\u201cdelivering projects in order to increase shareholder value and make the ~2 layers of management above you happy\u201d\n\nLots of software engineers really hate that this is the most important thing. I wrote about this at length in Software engineers should be a little bit cynical and You have to know how to drive the car. If you don\u2019t like this goal at all, it\u2019s going to be tough to spend time thinking about how you can achieve it.\nIn fact, I think it\u2019s actually more important to think about the \u201cmain thing\u201d if you hate it. This is why I\u2019m suspicious of \u201cdo what you love\u201d advice. If you love performance engineering but your company doesn\u2019t, I think you\u2019re better off doing it in your spare time and creating shareholder value at work, instead of trying to do as much performance engineering at work as you can.\nHalf-assing creating shareholder value a few hours a day (and doing performance engineering the rest of the time) is more valuable than locking in to the wrong \u201cmain thing\u201d for ten hours a day. In my experience, it\u2019s also likely more burnout-resistant, since there\u2019s no faster path to burnout than working really hard on something that isn\u2019t valued.\nCaution: the \u201cmain thing\u201d can rapidly change\nIn 2015, being easy to work with was the most important thing in many tech companies. If you were a pleasant colleague, you had to be really bad at other aspects of the job to face serious professional consequences. On the other hand, if you were abrasive and hard to work with, it didn\u2019t really matter how technically competent you were. Many engineers made successful careers by maximizing pleasantness: attending and hosting work social events, making friendly connections in different teams, and in general becoming a known engineer in the company.\nIn 2026, it\u2019s still important to be pleasant. But now that tech companies are tightening their belts and feeling more pressure to ship, the most important thing has shifted to being capable of delivering projects. If you\u2019re able to do that, it can go a long way towards redeeming a difficult personality. Like love, shipping covers all sins. This transition has been a bumpy ride for many software engineers.\nA lot of very pleasant \u201cknown engineers\u201d have been laid off in the last three years. I suppose the lesson here is something like this: even if you\u2019re doing great and are well-adapted to your niche, the environment can change and screw you over anyway. What can you do about it? If you\u2019ve spent a good chunk of your career developing one set of skills, you can\u2019t instantly transfer all that experience to a different set of skills when the environment changes. Maybe the underlying lesson is more like this: instead of over-specializing to a single niche, hedge your bets by being pretty good at multiple things.\nFinal thoughts\nThe lesson here is that you should spend a lot of time and effort trying to figure out what to focus on. In the extreme case, even spending half of your time doing this is worthwhile, if it puts you on the right track and you\u2019d otherwise be neglecting the main thing.\nThis can seem pretty unintuitive. It feels safer and more productive to be doing something. But if you can force yourself to focus on the meta-question of what you ought to be doing - even if you don\u2019t like the answer - you\u2019ll be in a better position to achieve your goals.\nIf you liked this post, consider subscribing to email updates about my new posts, or sharing it on Hacker News. Here's a preview of a related post that shares tags with this one." ], "output": "readability/", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:56:52.522250+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://www.seangoedecke.com/getting-the-main-thing-right/" ], "cmd_version": "8.10.1", "end_ts": "2026-02-06T05:56:51.228722+00:00", "index_texts": null, "output": "Getting the main thing right", "pwd": "/data/archive/1770357387.077353", "schema": "ArchiveResult", "start_ts": "2026-02-06T05:56:51.206223+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "TimeoutExpired: Command '['/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://www.seangoedecke.com/getting-the-main-thing-right/']' timed out after 60 seconds", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Getting the main thing right", "warc": null, "wget": null }, "link_dir": "/data/archive/1770357387.077353", "newest_archive_date": "2026-02-06T05:57:22.557082+00:00", "num_failures": 1, "num_outputs": 8, "oldest_archive_date": "2026-02-06T05:56:34.436665+00:00", "path": "/getting-the-main-thing-right/", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01KGRRBVW1D08341A60172H1P6", "snapshot_id": "83feac11-6230-4ad8-bb46-c9d24e2886c6", "sources": [ "/data/sources/1770357386-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1770357387.077353", "title": "Getting the main thing right", "url": "https://www.seangoedecke.com/getting-the-main-thing-right/" }