Posted by aaronbrethorst 21 hours ago
Personal example: I had a software engineering colleague who was the best coder of financial management systems I've ever encountered. He gained these skills through years of in-the-trenches development. One of the things he told me, and that I also observed, was that the vast majority of financial experts (basically, the people in the accounting department of companies) had an extremely difficult time just telling him what the rules of any particular transaction should be. But what they could do was tell him whether the handling of any particular transaction was right or wrong. So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec.
In my experience, that is the primary difference between people I've known who are good software engineers and those who aren't: people who can specify the detailed rules of any system, vs. folks who take a "well, I know it when I see it" approach.
I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years. As an analogy, it's kind of like asking a native speaker for the grammar rules of their language. Often times they can't, but they'll just say "well, that sounds wrong." They may be "domain experts" in their language, but they'd have a hell of a time prompting an AI system on how to grade a test for grammar correctness.
In fact, I've never known an industry so keen on levelling its own moats as the software industry. We regularly invent things like 4GL, graphical programming and frameworks and engines such as Unity just to enable more people to do programming. People will happily teach programming for free in outreach programs (I am just one example). No other profession does this. Perhaps with the exception of mathematicians and other fields that are very close to programming.
I could teach an economist enough programming in a weeks that they could write an ERP module, but I could not learn enough economics in a week to write one. If the language was the barrier, we could invent a more effective one. We invent new languages weekly anyway. Having seen how quickly beginners can make things with Unity or Godot, I seriously doubt an LLM agent could improve much on this. Of course, if the job is writing yet another CRUD React app with a Java or Python backend, then sure, the LLM will be very effective. But compared to doing same app in something like Excel or MS Access? Not that much.
Still, imagine how hard other skills are to acquire. How much civil engineering can you learn in two weeks? How much violin playing? But you could absolutely get basic grasps on a general purpose programming language. With something specialized like Unity or Excel you would get tons of useful output.
The hurdle around assignment operator is as old as symbolic languages. That's why legends such as Niklaus Wirth wanted to use another operator, ":=", a notation that is still being used.
Anyway, it can be a hurdle, but one I find that most people get over pretty quickly.
Well, sure; but more generally, the ability to accept other meanings for symbols (and keep subtly different symbols straight in one's head) is a mental skill, and individuals vary in their aptitude for it. (Presumably, this one is also relevant to natural language learning, since one must reckon e.g. with false cognates.)
You're right on the money on this.
Earlier this month I went to visit a company for a complete demo prototype of a full one-to-one train simulator trainer mostly designed and programmed by a former civil engineer using Unity engine. According to the company, they could not do it if Unity engine (or similar) is not around because it will be prohibitively expensive to develop.
In a related news, Unity recently released AI eco-system namely Unity AI Suite [1].
[1] Unity AI Suite:
we don't like doing the hard things e.g training juniors so they can be skilled seniors via good apprenticeship programs i.e on the job. now we r delegating to stochastic parrots.
in terms of systems thinking which is one skill you need to be a domain expertise - very few people are ever curious & are not willing or able to ask critical questions. hence the groupthink that's prevalent in the industry.
no wonder the quality of software never goes up - while the building blocks have gone up in quality. an analogy is like having super strong bricks but making brittle structures
Another analogy I like is a beginner playing a $100k Stratavarius probably can't produce anything near a professional violinist playing a $50 violin.
Personally I use LLMs to level up my systems thinking. I describe the domain, I have it brainstorm some scalable solutions, I look them up, I bring them up to the team, and we discuss, and I implement. It's a great workflow imo.
We have internalized more knowledge than we can explain sounds like the textbook definition of Polanyi's paradox:"Polanyi's paradox, named in honour of the British-Hungarian philosopher Michael Polanyi, is the theory that human knowledge of how the world functions and of our own capability are, to a large extent, beyond our explicit understanding" [0]
> Polanyi's paradox has been widely considered to identify a major obstacle in the fields of AI and automation, since programming an automated task or system is difficult unless a complete and fully specific description of the procedure is available.
It also goes the other way; A a good engineer can build experiments and discover the domain even without an oracle on the team; reading protocols or manuals or specs, for example. In other words, learn to be a domain expert themselves.
Personally I find the most efficient way to learn a concept to be building it; you are immediately faced with your blind spots. AI for sure helps improve cycle time on these discoveries if you use it that way; time writing boilerplate goes to ~zero and you can spend your time figuring out how to answer the real questions.
I do think that we as a profession need to learn new architectural and craftsmanship patterns to make it easier to learn from our code; concepts like Literate Programming which were too fussy for fast-moving teams may end up accelerating in the agentic world; I need to read a lot more code than I write now. But also things like Acceptance Test Driven Design; not new concepts, just newly increased in value.
https://dictionary.cambridge.org/us/grammar/british-grammar/...
Temporal, kausal, Modal, Lokal
https://www.olesentuition.co.uk/single-post/tekamolo-how-to-...
Once I built a little domain-specific language for them, that was tested against old jobs to see if they contradicted the past; it was a nifty project and since then I am convinced that DSLs are underrated as a way to encode expertise.
## 1A Rule name
Some prose explaining the rules liking to official documentation.
``` if municipality and inhabitants > 10000 then functionA else functionB ```
Then a trivial parser would extract the rules, the DSL was then handled by Lark[1]. So pretty simple, but it made collaborating with experts easier as simulated results would also output some markdown they could read.
Depending on the domain, this may either be the domain expert themselves, or someone else trained in formal logic, data structures and organizing information into coherent hierarchies. If this is neither the domain expert nor the programmer, then it must be someone in between. In the old world, this role was called "business analyst".
I'm the daughter and granddaughter of programmers, and I learned the basics of how to code as a kid. I'm good at it and have a knack for it, but I didn't want to do it for 8+ hours a day and then spend my nights on it as well, so I didn't pursue it as a career. I did an undergraduate degree in Linguistics, which has been really helpful for having an intuitive sense for what 'language as data' can accomplish and for a strong understanding of the difference between language as data and language as meaning. I studied formal logic systems. Then I did a graduate degree in Library Science and worked in libraries for a decade and a half.
I can organize and define systems very well, and I'm trained in how to wheedle information people don't consciously know out of them without them knowing I'm doing it. I've spent enough time around actual devs to understand where my limitations are and when to loop in someone who knows more to check my work, and when it's important for the work to be super accurate versus when I can learn by fucking around. (Front end and design? Fuck around! Database structure? Fuck around but with an exceptionally robust backup system kept outside of the AI tools' purview + don't fuck around in prod. Storing credentials and people's information? Ask someone.)
The problem companies are going to have is I'm very disinclined to work for them doing this, particularly if they want us because they think we're going to be cheaper. Most people who are in this category a.) could be devs and opted not to, and there's a reason for that and/or b.) are the children, cousins, etc. of programmers. We're not stupid: we know we're just as disposable as they're trying to make devs.
100%. I think, intuitively, software developers understand that there's a strong connection here, but most fail to translate that into practice. It always amuses me when someone comments on the triviality of creating CRUD apps. Setting aside the fact that people usually get the mechanics of it wrong (despite it being a solved problem), they overlook the difficulty of producing a good information design.I've developed software in a variety of industries, and I would say maybe 5% of the designs I inherit are well-done and represent the concepts they're trying to model in an elegant, parsimonious way. Rather, most examples are replete with ambiguity, orthogonal concepts smashed together into single elements, and misleading naming and relationships.
And even when there is a well laid out information design, it often is laid out from the wrong point of view. Elegant information design should create a pattern subconsciously enabling people to build a mental model of the tool they're using without realizing they're doing it. But software whose information design works wonderfully from the point of view of a SDE is not going to be approachable to the average user. There are so many tools I've used where I can very clearly see the reasoning behind the decisions and the design and use it well and also be aware I could never explain how they work to the average person.
I've frequently been credited as a person who can really string all the disparate elements of tacit knowledge together into a unified fabric in our particular subdomain, and helped a lot of people plug Swiss cheese gaps in their knowledge that way and come away with the feeling that it's all been tied together theoretically.
However, it's not immediately obvious to me how, in our LLM psychosis cultural moment, this facility shoots to the top of the value chain.
What they're not saying is that they think we're more valuable because they think we'll be cheaper. They think they can have us do 2 jobs and pay us for 1: probably less than a decent SDE made in 2019.
Personally, I think it's likely to be a shitshow and backfire if that's how companies decide to try to go that route (especially the largest ones). First, if we wanted to be devs, we would be (like you). Most people with the knack for programming and thinking in systems know they have that knack, and if they haven't jumped ship to SDE before now, there's a reason. I could definitely hack a junior SDE role, skill wise, but I don't want to. Second, finding people like us is difficult. The hiring process (which is becoming more and more Gilliamesque by the day) is really bad at identifying us. There aren't credentials, and this sort of work tends to reside in the gaps, as you identified. It's harder for it to show up on a resume. Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions. I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context. Thirdly, I can't speak for you, but I've developed this perspective over decades and if people want it, they're going to pay appropriately. If they think I'm going to do any of this at my current salary level, they're deranged. And lastly, while most people in our position might roll our eyes at some techie discussions and culture, we do fundamentally like techies/devs and we tend towards placing a greater value on things like relationships than a pure SDE does. (Just speaking in generalities). So 'is willing to replace and/or toss out a category of people I like and respect' is a hint to us to start out assuming this is a hostile negotiation. (Whereas SDEs as a cohort over the last 20 years extended a lot of goodwill at first). We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing, especially since as a population we're more likely to have devs who will work with us as non-technical founders. Someone who's decent at marketing/sales/the stupid 'people stuff', understands a domain, and understands when a proper dev tells them what is and isn't possible and can even help with some of the most boring, rote parts of the technical side if needed/in crunch is an excellent non-technical founder, and as a group we're also more likely to have access to the technical connections that we'd need if we wanted to build something beyond our ability.
Thoughts that really stood out for congruence with my own experience:
> Most people with the knack for programming and thinking in systems know they have that knack
> Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions.
> I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context.
> We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing
But I don’t think we should be calling these people “domain experts”. I think we should reserve that name for the other group, for the people who truly and deeply understand the domain, the whys and whats and why nots.
I've spent a lot of time in my career extracting info from the business and I think most do understand the whys/why nots but aren't practiced at organizing all of those decades of experience into a higher level abstract model that can easily be communicated.
It's typically layers and layers of information with dependencies in many directions littered with exceptions. Just like our software design+dev experience, it takes a lot of practice to try to organize all of that info into a coherent presentable model.
They will do that on examples tho. They will recognize and explain every single exception they see - but they are not able to list all exceptions up front. Because, that is highly unusual task
Right, so the spec is derived from examples, an interactive process that doesn’t require a programmer.
Talking to engineers and mathematicians gets you there.
Lossy decompression probably won’t ever be really good at this. If it’s missing from the data, then it won’t be there.
The AI math proofs were probably already out there in tiny pieces and nobody got all of the pieces together. That is valuable. It’s different from making a piece that is missing. And the AI will just hallucinate.
This combination of requirements is the business in most domains. Software or otherwise. Codefying different rules and executing them.
And they were really annoyed at being asked math questions.
It could be that whatever lackluster expertise you can squeeze out of an LLM is good enough to discourage investment in the real thing since unlike NP-complete problems, expertise isn't generalizable.
Works for me.
Already learned two or three problem domains well enough and now it is starting to compound.
This is the part I disagree with.
In a non-agentic world, the expert and the programmer are two different people. If the expert finds a bug in the software, they have to describe that bug, send it over to a programmer to fix, wait for a new release and until that scenario occurs again, realize that their description was actually wrong, send a corrected description, rinse and repeat for a few iterations until the bug is finally fixed for good.
In a world of agents, the expert finds the bug, asks the agent to fix it, realizes that the fix is incorrect because of sloppy thinking, does a few iterations until the feature works correctly, and that's it. Bug fixed; with 10 minutes of work instead of a few weeks.
If the domain expert doesn’t understand the generated code, they can only discover incorrect logic by specific examples (specific inputs), which is usually impossible to do exhaustively. The programmer, on the other hand, can see incorrect logic directly, generalized over all possible inputs and states. It’s the difference between testing and proving correctness.
That would require clearly (a) knowing what you want, and (b) expressing it unambiguously and in detail, including all edge cases. Essentially producing a spec.
Most people are not able to do either. Talking to an LLM does not change that.
As long as the expert don't run of patience, he may be able to do that.
Consider finance sector -- the industry is powered by excel spreadsheets made by non-programmer having no clue how programming works.
We were working through many complex business flows and running into exactly what you describe in many areas. Some of the project people with less experience complained that we were spending too much time on exceptions and slowing down the project. We had to explain that when each exception happens 100 times a day with significant impact on business productivity, then it doesn't matter whether you call it an exception or not, it's important to solve for.
Who are the 1/3 of the population that does not reason by analogy?
It’s not that the 2/3 can't think abstractly, it’s just that they use analogies as a temporary processing step to get there, while the 1/3 starts there.
Maybe they need a build a hybrid expertise of "domain" and "software engineering". For example, robotic surgery requires expert surgeons to build sufficient expertise in robotics
Also, noticed a pretty high karma for a throwaway account.
I've spent most of my career working with the same people--even people who have some coding experience but they never catch the low probability stuff. Or even not so low probability: business procedures were that the customer was quoted an all-inclusive price. Try to work backwards, what is the pre-tax amount? Um, that's not guaranteed to have a solution. My concerns get ignored, I go ahead and implement with code that will catch the offending penny and label it roundoff correction. While I'm not sure what happened I think some auditor hit that. I ended up having to walk them through the calculation, okay, what's the answer here? Only when they couldn't solve the problem could they accept that what I had done was the only answer. (The actual odds of such a failure are equal to the tax rate. I had not originally worked that out, just saw success was not guaranteed.)
The domain experts make this sort of mistake routinely in dealing with code. AI won't fix that.
It's also the main reason why very structured AI agent orchestration for software engineering modelled on rigid processes fails to really provide much value.
A mental model I use for this is that we have users, builders and experts when creating AI products. For most individual use cases a person is the user, builder and expert: I make a prompt about how to write code in a way that I like that I will later use. Coding agents moved into the direction of builders that were also experts in the field iterating on a product for third-party users. The next frontier will be finding the right patters for teams to capture expert knowledge handle the collaboration between engineer/builders and experts. Just having PMs handle that interaction will be a super bottleneck.
My cofounder and I are actually working on a project in that direction (https://www.getvalmar.com) --> we'd love any input on how engineers prefer performing feedback loops and getting input from subject matter experts :)
Here's an example I encountered last week:
Someone in my neighborhood is a 75 year old chemical engineer who likes computers and got into Linux a few months ago. I see him from time to time when walking around, he's a nice guy and overall has a scientist's mindset. He doesn't make a lot of assumptions and tries to think things through but sometimes he has big blind spots in unfamiliar fields.
I helped him install Linux and also hook up an SSD to one of his older machines and now it flies.
On his own he had an old sound card that he wanted to use on that machine. He asked me if the card is compatible. I told him it almost certainly is because the Linux kernel has drivers for a ton of devices. His motherboard's built-in sound card was fine but he likes tinkering with audio in general.
He managed to physically install the card correctly but called me and said there's no sound playing. Then he says he spent 12 hours troubleshooting the issue, using ChatGPT and Googling for assistance.
Over the phone he told me he tried many different things. Installing, tweaking and configuration ALSA, PulseAudio and PipeWire related tools and tweaking everything you can imagine. Nothing worked, no matter what happened, it never played sound through his speakers.
He asked me if I could come over to help so I did.
In 30 seconds I solved the problem.
I went to his sound settings in his desktop environment and saw that his sound card was being picked up. I looked at the back of his machine and noticed this card had 2 black ports with the bigger style jack for headphones. There was no usual green port which is usually used for output. I shined a flashlight to look closer. One of the black ports was labeled headphones and the other was unlabeled. His was connected to the unlabeled one. I swapped it to the other port and everything worked right away.
All of that to say, as a software engineer I have second hand embarrassment that a trillion dollars invested into AI didn't think to respond with "did you double check to see which port you connected the speakers to?". I asked him if AI ever suggested that and he said no, it immediately went into polluting his system with a bunch of unnecessary tools and chasing incorrect rabbit hole after rabbit hole. AI understands nothing.
Searching about common Windows issues results in misleading blogspam. Suggested "solutions" resemble blindly applied folk remedies.
I'm no stranger to breaking my desktop Linux after an hour of misdirected troubleshooting and desperately messing with core libraries. I'm still glad I can quickly find my way to ArchWiki.
I was on a fishing trip. I asked the charter if he’d want to check out a free app I work on (https://oceanconnect.ca) in case it might be useful for his work.
I don’t know how people on the ocean use ocean data. I don’t really know what they want to know, or why. I wasn’t totally prepared for the incredible onslaught of questions and information pertaining to how people use the data or what we can do with the data, and it was so cool and exciting to get that perspective.
It was a good reminder that models are not the same as the systems they abstract, and knowledge to develop them has almost nothing to do with using them. This guy was a wealth of knowledge about how they use weather data on the water. In a sense, he knows more about the data than I do (even if he doesn’t realize it, or doesn’t understand it in its digital representation), and would be far better equipped to make a useful application for people like him if he could program.
I found myself thinking people like him could actually do amazing stuff with LLMs if they sat down and got their ideas out on a screen. I’d really like to interview people on the water daily some day to refine the product if we ever have the funding. That domain knowledge is highly, highly specialized and people know things you’d never guess after living in a complex domain for decades.
I think AI is going to force most software engineers to pick up this skill in some form. Building is easy; knowing what to build is the hard part.
They can, and they are. You just don’t hear about it on places like HN because those people are not on this website. Which is why some people here make smug statements like “if LLMs are so good at programming how come we haven’t seen any useful apps made with LLMs???”
This has always been true since the dawn of programming.
Whole TFA doesn’t take into account reason why software development was actually so valuable.
Single specialist in any domain is not that valuable. You may charge $200 for hour of his time sure. But to grow company you now need N specialists.
What software was doing was not making specialist obsolete replacing a specialist by encoding his knowledge - well many tried to do so but failed even in 80’s “expert systems”.
What software was doing was making it possible to structure specialist work, make it possible for a single specialist to serve more customers at the same time, make it possible to hand over work in a structured way to junior specialists, making it easier for senior to take over edge cases and spot check work of those junior specialists.
This setup allows company to not being tied to number of specialists to grow, this setup allows company to charge less per customer but take over more of the market share.
Whole premise that now each specialist will waste time dabbling in AI software development is ludicrous, especially if each specialist would be building his own tooling somehow.
Whereas in larger technology firms, yes that happens to some degree, but only with the highest level specialists such as PEs, fellows, etc.
They are already so wildly profitable and valuable by the simple nature of computing itself: it scales second only to money with regards to compounding effects. Once you have software someone can use, it scales near infinitely to more users, thus value is extracted from the work of a single specialist for all time. No need to complicate it with trying to abstract work juniors can do (and fail) and then have seniors correct. What would they be doing in non-extractive firms?
A SWE who has always worked in DevTooling companies will always be preferred by DevTooling companies over a generalist. A SWE who has always worked in AdTech will always be preferred by AdTech companies over a generalist. etc etc.
Software fundamentals - though useful - are table stakes skills at this point. No business wants to deal with the headache of on-ramping employees who have never worked in a specific domain or industry because it takes too long for a generalist employee to build the intuition needed to understand that segment of the industry.
I'm having a difficult time even seeing what we're talking about here. I see "seniors" in our industry that don't know what I would call the fundamentals of programming or software development; apparently not all fundamentals are created equal.
Historically, startups were the traditional path for a generalist to build domain expertise because most startups couldn't be picky with talent, but the market has changed.
In all honesty, too much fat did develop in the tech industry over the last 6 years. Traditional hiring pipelines (eg. Limiting early career recruiting to grads from top 10-20 CS/ECE/EECS programs nationally along with Vets and some grads from decent regional programs) still net good calibre talent worth their weight in gold, but others just aren't working out.
On the other hand, hiring a mid-career SWE who spent much of their career in one domain who is transitioning to another is a significant risk without additional social proof such as referrals where someone actually vouches for their skills.
The usual sickness. If you don’t train people to become specialists and just expect them to fall from the sky, it’s only a question of time until you run out of specialists.
The places it falls flat is domain expertise that isn’t well documented, like specific business processes. Knowing something will fail because X in dept A won’t like it and will undermine it (politics) or some silly process I didn’t know about forbids it.
So it’s not domain expertise, it’s idiosyncratic expertise that shines these days. Knowing where things deviate from a domain or the standard and being able to adapt around that. Years ago there’s a group I worked with and I was at the mercy of about 3 people I could ask questions to in order to make sure I was doing things correctly because digging into that domain was time prohibitive. Now, I can sit down one evening and dig fairly deep into a domain. I can understand common practice, approach, acronyms, nomenclature, so on. I can find other popular competing systems. I can rapidly figure out what I need.
The same is true for software, agents don’t collapse software they help people build fairly usable systems but they don’t find the expertise a senior level engineer has where designs or implementations may fail in practice. The idiosyncrasies of software and software systems, especially in your very specific set of constraints you need to operate in that may deviate from the rest of the world.
And you will not notice the obvious errors in its answers to even basic questions, because you are no expert and should have really consulted with one.
When talking about their own area of expertise, almost everybody immediately notices the glaring faults. But then they are very impressed and take LLMs as gospel when talking about anything else. I do not get it.
Lets take banks - knowing how banks work in general means little for that one specific bank who is paying you, which has different portfolio than most, different processes because everything is homebrew over decades of doing business and they differentiate from rest of the market in many ways and thats their key proposition, different data infra, set of internal apps, protocols and so on. There is no general llm knowledge you can distill in few minutes that would help you much.
You need to know your specific company, no way around it. In fact, to be proficient in those deliveries, you need to know those internal politics, processes, their quirks and so on, 100x more than some code fast delivery since this is majority of any bigger project. You need some reputation to get things done effectively.
This, for some time, won't be something llm can massively improve, unless those companies change themselves.
Of course there are ways around it. For example you can build the foundation yourself (which will cover the 80% that is shared across every company in that industry) and give users the ability to build the rest themselves inside the software. This type of abstraction-based architecture is how platforms like Salesforce took off and became ubiquitous.
If you’re a great generalist software engineer today, you aren’t jumping to some random domain to escape AI. Software is your domain. You’re sticking with it as it expands and transforms.
This has always been the most valuable person. A skilled software developer who is also deeply experienced in their target domain is untouchable. They can always move the ball forward at some rate, assuming they're making any attempt at all.
It takes a really long time to absorb some domains. The most painful one I've experienced is the banking industry. It took me a solid decade in the trenches before I felt comfortable running a status call with a bank's operations staff without a babysitter.
I like to think of this as a sort of cube of capability. The X axis is technical expertise, the Y axis is domain expertise and the Z is physics (ai/tools/computers). The volume of this space is what we are interested in. Scaling up to a wild amount of AI capability with the best developers on earth (infinite x-z plane) is still going to perform like shit (zero volume) if you have no practical domain expertise available.
Specificity, availability and recency are perhaps the most important parts of domain expertise. None of these tend to be in ample supply with frontier language models. You can get a general sense of how a bank operates from chatgpt, but the FDIC would take over your bank in the middle of the first night of operations because you didn't learn the secret handshake (how to interact with your customers, competitors, regulators, etc).
I even went as far as setting up their IDEs, configuring their environments, and encouraging them to just vibe-code. It seems that the mental friction involved in switching domains is too high for most people to justify the reward. Perhaps the reward itself is not compelling enough, or perhaps this is simply the limit of adult motivation.
I started programming with Python around the time GPT-3 arrived, when Cursor had generous free tiers and excellent starter plans. A few Raspberry Pis, laptops, desktops, and countless hours of tinkering later, I discovered how much I enjoyed solving problems with software. There is so much to learn from the programming world: the concept of open-source software, the idea that people from anywhere in the world can collaborate on the same codebase, and the fact that many do so with little or no expectation of reward.
As this post points out, in the project I am currently working on—a comprehensive Clinical Decision Support System—it feels almost second nature to translate the rules, hidden rules, social dynamics of hospitals, and the common mistakes that we and our juniors make every day into software. Taking those observations and turning them into systems that work is surprisingly intuitive.
Perhaps the most valuable thing I gained from medical school, combined with my own personality, is the desire to keep learning. I naturally gravitated toward systems thinking, and the path forward seems clear to me: become a true expert in whichever specialties I ultimately practice, while simultaneously becoming highly skilled at systems thinking.
As for systems thinking itself, I find it useful to create rules not only for the codebase but also for the testing harnesses and development processes around it. The goal is to build systems that can enforce quality automatically as the codebase grows, ensuring that standards scale without requiring constant manual oversight.
It will never be organized, never fully optimized, and it will always be custom — because it has to cater to the reality of wildly different tastes, contexts, and localities. There may be some good tools, raw materials that show up once in a while.