{ "archive_path": "archive/1778994942.137096", "base_url": "www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise", "basename": "why-senior-developers-fail-to-communicate-their-expertise", "bookmarked_date": "2026-05-17 05:15", "canonical": { "archive_org_path": "https://web.archive.org/web/www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=www.nair.sh", "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.nair.sh", "downloaded_at": "2026-05-17T05:15:49.171920+00:00", "downloaded_datestr": "2026-05-17 05:15", "extension": "", "hash": "1GX10Z8J7AYTD522BF02", "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.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise" ], "cmd_version": "8.10.1", "end_ts": "2026-05-17T05:16:54.747330+00:00", "index_texts": null, "output": "https://web.archive.org/web/20260517051637/https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:16:32.456042+00:00", "status": "succeeded" } ], "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.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise" ], "cmd_version": "131.0.6778", "end_ts": "2026-05-17T05:16:09.257678+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:15:59.478893+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.nair.sh" ], "cmd_version": "8.10.1", "end_ts": "2026-05-17T05:15:52.117851+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:15:49.482969+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.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise" ], "cmd_version": "8.10.1", "end_ts": "2026-05-17T05:15:52.217313+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:15:52.155950+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2026-05-17T05:16:24.819287+00:00", "index_texts": [ "(/_next/static/media/797e433ab948586e-s.p.09zddjkbdep5a.woff2?dpl=dpl_A778H4SvsBgcnmR4cRCc9fHMGQAM) (/_next/static/media/7b3954b250246604-s.p.16y2v1gf61amr.woff2?dpl=dpl_A778H4SvsBgcnmR4cRCc9fHMGQAM) (/_next/static/media/9e9f04e3c37952ab-s.p.07uvnuj.ona6k.woff2?dpl=dpl_A778H4SvsBgcnmR4cRCc9fHMGQAM) (/_next/static/media/caa3a2e1cccd8315-s.p.09~u27dqhyhd6.woff2?dpl=dpl_A778H4SvsBgcnmR4cRCc9fHMGQAM) (/_next/static/chunks/0jcoazuycx4st.css?dpl=dpl_A778H4SvsBgcnmR4cRCc9fHMGQAM) (/_next/static/chunks/0mb86i6um43s4.js?dpl=dpl_A778H4SvsBgcnmR4cRCc9fHMGQAM) Why senior developers fail to communicate their expertise | nair.sh (https://nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise) (/favicon.ico?favicon.144epmj.v.9m~.ico?dpl=dpl_A778H4SvsBgcnmR4cRCc9fHMGQAM) (/) nair.sh (/books/copywriting-after-ai) Buy my new book Copywriting after AI Open menu (/10x-content-outreach) 10x Cold Content Outreach (/guides-and-opinions) Guides & Opinions (/books) Books (/guides-and-opinions/communicating-your-expertise) \u2190 Communicating your expertise Why senior developers fail to communicate their expertise Tuhin Nair 7 min read 12th May, 2026 (Hand-drawn cover illustration for the opinion piece 'Why senior developers fail to communicate their expertise.') What do you feel about the following sentence: \u201cAI agents are the future of software development. We won\u2019t need developers anymore to slow down the progress of a business.\u201d If you\u2019re a senior developer and you think this is true, I\u2019m somewhat suspicious of your expertise (I\u2019ll explain why; I\u2019m not needlessly antagonistic). But if you\u2019re not a senior developer and you think this is true, I think you\u2019re probably right. Huh? What\u2019s going on here? Copywriting is, in its essence, about matching a message to an audience. And so, to me, a copywriter, what\u2019s happening here is that the same message is meaning two different things to two different audiences. If you\u2019re a senior developer, and if you\u2019ve played with the agents and skills and models and all the other things that are blowing people\u2019s minds, and if your intuition is still telling you something is off in how people are proclaiming your job obsolete, then here, in this post, I\u2019m going to try and put words to your intuition (as a good copywriter does). But wait a minute! Many seasoned and famous developers are also proclaiming the death of the developer. How\u2019s that? Whose intuition is right? And what\u2019s causing this split? \u00a7 01 A senior developer is a problem avoider When I join a team there are two kinds of senior developers I meet. The first kind says things like: \u201cI found this new tool and it\u2019s pretty cool ...\u201d \u201cThis company does things this way, so \u2026\u201d \u201cHere, look at this HackerNews post that says this is best practice, we should probably \u2026\u201d I don\u2019t like this kind of senior developer. A little self-protective, lots of time spent in the industry, probably a good people person. But not my wavelength. Then there\u2019s also this kind of senior developer: \u201cDo we really need that?\u201d \u201cWhat happens if we don\u2019t do this?\u201d \u201cCan we make do for now? Maybe come back to this later when it becomes more important?\u201d Ah, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can. Why? Because they hunt a singular monster in professional software development: complexity. Special cases, if conditions, new database tables, new components. All yuck yucks. The senior developer wants as little of this as possible, spending lots of time making sure they absolutely need to add more code. Because adding to a system is risking more complexity. Yes, yes, of course this is simplistic. There are senior developers who excel at taking on unsolved problems and finding new creative designs. But eventually, if you\u2019re taking responsibility for a working system, you\u2019re scared of complexity. Now, why is that? What\u2019s the downside of complexity? And why doesn\u2019t anybody else get it? \u00a7 02 The rest of the business is scared of uncertainty We\u2019re going to be simplifying what a business is using two loops. This is the first loop; marketers, salespeople, product managers, the CEO, they all live here: (Hand-drawn diagram of the business's first loop: marketers, salespeople, product managers and the CEO take ideas to market and feed what they learn back into the next attempt.) The main goal of this loop is to try and learn. The business wants to take things to market and then get feedback on whether they\u2019ve got something valuable or not. The monster, for people in this loop, is uncertainty. And uncertainty is cruel because no strategy is guaranteed to work. When combined with time (compensation for marketing/sales, or payroll for founders, or data for product managers) it can feel like taking things to market as fast as possible is the only way to reduce uncertainty before a deadline. The more you can take to the market, the more you can get feedback from it, the more you can (potentially) reduce uncertainty. This loop, and all companies start with this loop, is about pure, raw, speed. But what happens when a business gets customers? \u00a7 03 Senior developers care a lot about stability Ah, now, here\u2019s our second loop. People paying for a service. (Hand-drawn diagram of the business's second loop: paying customers using the existing service while the team works to keep that service running.) This loop is where a lot of senior developers find themselves in. The main goal in this loop is the continuation and guarantee of service. Keep things working, keep things understandable, keep things debuggable, keep things fixable, keep things teachable, keep things stable. Senior developers worry about stability because they take responsibility for the business to continue serving customers. And what risks all of that? Complexity. It makes a system less understandable, less debuggable, less fixable, less teachable, and ultimately, less stable. Rising complexity = lowering stability = senior developer failing responsibility = bad bad not nice, payments interrupted, everybody sad. So, if the first loop\u2019s goal was uncertainty reduction, the second loop\u2019s goal is complexity management. But why does this lead to communication failure? Because once you have customers, both loops are running simultaneously. A business needs to both explore possibilities and serve customers at the same time. (Hand-drawn diagram showing the business's two loops running side by side: one chasing market feedback, the other keeping paying customers served.) Ok, now you might be able to spot my answer to the question in the title of this post. Depending on which loop you spend your time on, your problem is framed differently (which is why I think developers get split in their opinions on AI; some work more on one loop than the other) (Hand-drawn diagram showing the same development work framed differently by the people in each loop \u2014 uncertainty versus complexity.) This was the story of the people in the first loop: (Hand-drawn diagram of the first loop's story: requests pour in, the team races to ship them so the business can learn from the market faster.) But this was the story of the senior developer in the second loop: (Hand-drawn diagram of the second loop's story: every new request adds complexity, threatening the stability of the system the senior developer is responsible for.) The stories don\u2019t match. The more requests to build and add to the system the senior developer gets, the more the senior developer wants to respond with \u201cuhhh, no complexity \u2026 maintenance costs \u2026 understandability \u2026 speed of continuing development \u2026 productivity over time \u2026\u201d. But that does nothing to address the rest of the business\u2019s need for reducing uncertainty. The copywriter\u2019s diagnosis: You can\u2019t explain away someone else\u2019s problem using your own problems. And the copywriter\u2019s prescription: You need to describe your solution as a solution to their problem as well. Senior developer\u2019s fail to communicate because they express their problems in terms of complexity management when they should be expressing their solutions in terms of uncertainty reduction. By acknowledging that what the rest of the company is seeking for is uncertainty reduction, the senior developer can use their expertise to help. And what\u2019s the most useful skill a senior developer has? The reluctance to build what\u2019s not necessary; the ability to spot an opportunity to re-use something already built. Need to collect survey data? Google forms, baby. Need to build a whole new feature to test it? Have you tried putting a button in the existing UI and seeing if people click it? Need new analytics service? What\u2019s the most important decision we need analytics for? Can we start with one decision, one chart, one metric? You want to bake me a whole birthday cake? Just put a candle on my sandwich. This is what senior developers learn to do: they learn how to give people what they want by being resourceful with existing software. But how do you communicate this without sending people whole essays? Copywriters love boiling down multiple signals into singular phrases. And so, here\u2019s the magical phrase every senior developer must learn: \u2018Can we try something quicker?\u2019 The use of \u2018quicker\u2019 acknowledges what they\u2019re really looking for; \u2018something\u2019 implies another way of achieving it; \u2018try\u2019 implies imperfection, but also the possibility of it being good enough. It perfectly cuts down to the requirement of the rest of the company, speed to reduce uncertainty, while allowing the senior developer to exercise their expertise: reduce, re-use, and if life is truly a blessing, avoid. That\u2019s it. That\u2019s my answer to the title of the post: senior developers talk in terms of complexity when everyone else is worried about uncertainty. But! Big but! AI now seems to make all of this pointless, doesn\u2019t it? Why reduce? Why re-use? Why avoid? The AI can build so much in so little time. Ah, well, it can\u2019t yet do the one thing senior developers still do. Take responsibility. \u00a7 04 Senior developers as editors more than writers Senior developers care a lot about understanding the system because understanding allows fixing it when things go wrong. It allows extending it intelligently when the system needs to grow. It allows, more than anything, the continued, reliable servicing of paying customers. AI threatens this understandability. It is incredible at improving the speed of taking things to the market, but it also affects the other loop, the one the senior developers are responsible for. If you have a bunch of AI agents, junior developers, non-developers, and your investors and their mothers adding code into the system, you get a system that overcompensates for speed by giving up stability. This was the business in two loops: (Hand-drawn diagram showing the business's two loops running side by side: one chasing market feedback, the other keeping paying customers served.) And this is how AI affects the two loops: (Hand-drawn diagram showing AI accelerating the first loop while destabilising the second \u2014 extra speed at the cost of understandability and stability.) Forget maintaining stability, AI is a downright destabilizer. It worsens understandability, fixability, debuggability, teachability, guaranteability, all the bloody bilities. AI does this and takes no responsibility. Not nice. This is the senior developer\u2019s main worry that\u2019s being brushed away. Luckily, senior developers have a few tricks up their sleeve. Namely: decoupling. For the longest time, software developers were the only ones who could build software. They were responsible for both loops. (Hand-drawn diagram showing a single software system that historically supported both loops, with developers responsible for speed and stability at once.) That\u2019s one system supporting two goals. What if we had two systems, one for each goal? An analogy: a fiction writer rushes to complete a first draft (often called a vomit draft) and later extracts what\u2019s working and gets rid of what\u2019s not. There\u2019s an editing process after the first initial rapid write. The editor\u2019s job is to take the bits that are working well and shape it all into a cohesive whole. What if we had one system just for speed? Everyone focused on bringing things to life could work here. AI agents, our own generated and unreviewed code, junior devs, marketing etc. We could call this the \u2018Speed\u2019 version of the system. It\u2019s not meant to be understandable, the goal is getting things good enough to take it to the market for feedback. And then what if we had a second system focused on stability? We could call this the \u2018Scale\u2019 version of the system. It\u2019s designed by senior developers to be stable, understandable, and scalable. The \u2018Speed\u2019 version allows the rest of the business to continue learning from the market, as the senior developers build a trailing version of the system that\u2019s well-reviewed and understandable. Plus, the design of the 'Scale' version is influenced by what worked and what doesn\u2019t work in the 'Speed' version of the system. (Hand-drawn diagram showing the proposed split: a Speed version of the system for rapid market learning, and a Scale version stabilised by senior developers behind it.) Features get built on \u2018Speed\u2019 but then stabilized on \u2018Scale\u2019. What this looks like in practice might be unclear, but the idea is to have a well-communicated de-coupling that explains that there\u2019s a difference between going for speed and going for stability. Imagine you get asked to build something ambitious, and you say: \u201cSure, I\u2019ll have the Speed version ready in 3 days. Then the Scale version in about 6 weeks.\u201d They get what they want, speed and momentum. You get what you want, observation and design. Maybe? Your thoughts, senior software developer? Or should I say, senior software editor? More Read my guide on using pattern recognition for creativity: (/guides-and-opinions/communicating-your-expertise/how-to-use-a-spreadsheet-for-creativity) How to use a spreadsheet for creativity (/guides-and-opinions/communicating-your-expertise) \u2190 More in Communicating your expertise Tuhin Nair (https://x.com/tuhin_nair) \u00a9 2026All rights reserved. " ], "output": "htmltotext.txt", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:16:24.786687+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.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise" ], "cmd_version": "2024.10.7", "end_ts": "2026-05-17T05:16:32.391116+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:16:27.421469+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise" ], "cmd_version": "2.2.3", "end_ts": "2026-05-17T05:16:24.750656+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:16:21.769637+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmp23c10d3u", "https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise" ], "cmd_version": "0.0.11", "end_ts": "2026-05-17T05:16:12.742330+00:00", "index_texts": [ "\u00a701A senior developer is a problem avoiderWhen I join a team there are two kinds of senior developers I meet.The first kind says things like:\u201cI found this new tool and it\u2019s pretty cool ...\u201d\u201cThis company does things this way, so \u2026\u201d\u201cHere, look at this HackerNews post that says this is best practice, we should probably \u2026\u201dI don\u2019t like this kind of senior developer. A little self-protective, lots of time spent in the industry, probably a good people person.But not my wavelength.Then there\u2019s also this kind of senior developer:\u201cDo we really need that?\u201d\u201cWhat happens if we don\u2019t do this?\u201d\u201cCan we make do for now? Maybe come back to this later when it becomes more important?\u201dAh, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can.Why? Because they hunt a singular monster in professional software development: complexity.Special cases, if conditions, new database tables, new components. All yuck yucks. The senior developer wants as little of this as possible, spending lots of time making sure they absolutely need to add more code.Because adding to a system is risking more complexity.Yes, yes, of course this is simplistic. There are senior developers who excel at taking on unsolved problems and finding new creative designs.But eventually, if you\u2019re taking responsibility for a working system, you\u2019re scared of complexity.Now, why is that? What\u2019s the downside of complexity? And why doesn\u2019t anybody else get it?\u00a702The rest of the business is scared of uncertaintyWe\u2019re going to be simplifying what a business is using two loops.This is the first loop; marketers, salespeople, product managers, the CEO, they all live here:The main goal of this loop is to try and learn. The business wants to take things to market and then get feedback on whether they\u2019ve got something valuable or not.The monster, for people in this loop, is uncertainty.And uncertainty is cruel because no strategy is guaranteed to work. When combined with time (compensation for marketing/sales, or payroll for founders, or data for product managers) it can feel like taking things to market as fast as possible is the only way to reduce uncertainty before a deadline. The more you can take to the market, the more you can get feedback from it, the more you can (potentially) reduce uncertainty.This loop, and all companies start with this loop, is about pure, raw, speed.But what happens when a business gets customers?\u00a703Senior developers care a lot about stabilityAh, now, here\u2019s our second loop. People paying for a service.This loop is where a lot of senior developers find themselves in. The main goal in this loop is the continuation and guarantee of service.Keep things working, keep things understandable, keep things debuggable, keep things fixable, keep things teachable, keep things stable.Senior developers worry about stability because they take responsibility for the business to continue serving customers.And what risks all of that?Complexity.It makes a system less understandable, less debuggable, less fixable, less teachable, and ultimately, less stable.Rising complexity = lowering stability = senior developer failing responsibility = bad bad not nice, payments interrupted, everybody sad.So, if the first loop\u2019s goal was uncertainty reduction, the second loop\u2019s goal is complexity management.But why does this lead to communication failure?Because once you have customers, both loops are running simultaneously. A business needs to both explore possibilities and serve customers at the same time.Ok, now you might be able to spot my answer to the question in the title of this post.Depending on which loop you spend your time on, your problem is framed differently (which is why I think developers get split in their opinions on AI; some work more on one loop than the other)This was the story of the people in the first loop:But this was the story of the senior developer in the second loop:The stories don\u2019t match.The more requests to build and add to the system the senior developer gets, the more the senior developer wants to respond with \u201cuhhh, no complexity \u2026 maintenance costs \u2026 understandability \u2026 speed of continuing development \u2026 productivity over time \u2026\u201d.But that does nothing to address the rest of the business\u2019s need for reducing uncertainty.The copywriter\u2019s diagnosis: You can\u2019t explain away someone else\u2019s problem using your own problems.And the copywriter\u2019s prescription: You need to describe your solution as a solution to their problem as well.Senior developer\u2019s fail to communicate because they express their problems in terms of complexity management when they should be expressing their solutions in terms of uncertainty reduction.By acknowledging that what the rest of the company is seeking for is uncertainty reduction, the senior developer can use their expertise to help.And what\u2019s the most useful skill a senior developer has? The reluctance to build what\u2019s not necessary; the ability to spot an opportunity to re-use something already built.Need to collect survey data? Google forms, baby.Need to build a whole new feature to test it? Have you tried putting a button in the existing UI and seeing if people click it?Need new analytics service? What\u2019s the most important decision we need analytics for? Can we start with one decision, one chart, one metric?You want to bake me a whole birthday cake? Just put a candle on my sandwich.This is what senior developers learn to do: they learn how to give people what they want by being resourceful with existing software.But how do you communicate this without sending people whole essays?Copywriters love boiling down multiple signals into singular phrases. And so, here\u2019s the magical phrase every senior developer must learn: \u2018Can we try something quicker?\u2019The use of \u2018quicker\u2019 acknowledges what they\u2019re really looking for; \u2018something\u2019 implies another way of achieving it; \u2018try\u2019 implies imperfection, but also the possibility of it being good enough.It perfectly cuts down to the requirement of the rest of the company, speed to reduce uncertainty, while allowing the senior developer to exercise their expertise: reduce, re-use, and if life is truly a blessing, avoid.That\u2019s it. That\u2019s my answer to the title of the post: senior developers talk in terms of complexity when everyone else is worried about uncertainty.But! Big but!AI now seems to make all of this pointless, doesn\u2019t it? Why reduce? Why re-use? Why avoid? The AI can build so much in so little time.Ah, well, it can\u2019t yet do the one thing senior developers still do.Take responsibility.\u00a704Senior developers as editors more than writersSenior developers care a lot about understanding the system because understanding allows fixing it when things go wrong. It allows extending it intelligently when the system needs to grow. It allows, more than anything, the continued, reliable servicing of paying customers.AI threatens this understandability. It is incredible at improving the speed of taking things to the market, but it also affects the other loop, the one the senior developers are responsible for.If you have a bunch of AI agents, junior developers, non-developers, and your investors and their mothers adding code into the system, you get a system that overcompensates for speed by giving up stability.This was the business in two loops:And this is how AI affects the two loops:Forget maintaining stability, AI is a downright destabilizer. It worsens understandability, fixability, debuggability, teachability, guaranteability, all the bloody bilities.AI does this and takes no responsibility.Not nice. This is the senior developer\u2019s main worry that\u2019s being brushed away.Luckily, senior developers have a few tricks up their sleeve.Namely: decoupling.For the longest time, software developers were the only ones who could build software. They were responsible for both loops.That\u2019s one system supporting two goals.What if we had two systems, one for each goal?An analogy: a fiction writer rushes to complete a first draft (often called a vomit draft) and later extracts what\u2019s working and gets rid of what\u2019s not. There\u2019s an editing process after the first initial rapid write. The editor\u2019s job is to take the bits that are working well and shape it all into a cohesive whole.What if we had one system just for speed? Everyone focused on bringing things to life could work here. AI agents, our own generated and unreviewed code, junior devs, marketing etc.We could call this the \u2018Speed\u2019 version of the system. It\u2019s not meant to be understandable, the goal is getting things good enough to take it to the market for feedback.And then what if we had a second system focused on stability?We could call this the \u2018Scale\u2019 version of the system. It\u2019s designed by senior developers to be stable, understandable, and scalable.The \u2018Speed\u2019 version allows the rest of the business to continue learning from the market, as the senior developers build a trailing version of the system that\u2019s well-reviewed and understandable.Plus, the design of the 'Scale' version is influenced by what worked and what doesn\u2019t work in the 'Speed' version of the system.Features get built on \u2018Speed\u2019 but then stabilized on \u2018Scale\u2019.What this looks like in practice might be unclear, but the idea is to have a well-communicated de-coupling that explains that there\u2019s a difference between going for speed and going for stability.Imagine you get asked to build something ambitious, and you say:\u201cSure, I\u2019ll have the Speed version ready in 3 days. Then the Scale version in about 6 weeks.\u201dThey get what they want, speed and momentum. You get what you want, observation and design.Maybe?Your thoughts, senior software developer?Or should I say, senior software editor?" ], "output": "readability/", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:16:10.070676+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.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise" ], "cmd_version": "8.10.1", "end_ts": "2026-05-17T05:16:09.327354+00:00", "index_texts": null, "output": "Why senior developers fail to communicate their expertise | nair.sh", "pwd": "/data/archive/1778994942.137096", "schema": "ArchiveResult", "start_ts": "2026-05-17T05:16:09.301625+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "https://web.archive.org/web/20260517051637/https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Why senior developers fail to communicate their expertise | nair.sh", "warc": null, "wget": null }, "link_dir": "/data/archive/1778994942.137096", "newest_archive_date": "2026-05-17T05:16:32.456042+00:00", "num_failures": 0, "num_outputs": 9, "oldest_archive_date": "2026-05-17T05:15:49.482969+00:00", "path": "/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01KRT5S47CFAD28EA301W6D8A9", "snapshot_id": "a96dde61-77ae-421b-997e-15733866a149", "sources": [ "/data/sources/1778994941-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1778994942.137096", "title": "Why senior developers fail to communicate their expertise | nair.sh", "url": "https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise" }