After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.
We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.
Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code.
Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.
Not all code has to be efficient scalable code. I know some domain experts that were not programmers. They picked up enough Python or Swift + UIKit (this was pre-LLMs) and their applications are now widely used in their domain. In some cases, they contracted some software companies in the past to do the work. However, they did not understand the problem domain well, requiring the domain expert to iterate with them over and over. In the end it was more efficient to let the domain expert to learn enough programming do it with some guidance from experienced programmers.
Also remember that a lot of domain-specific apps do not need to be huge. E.g. I was once at a factory in the 90ies and they needed to do time-consuming calculations for a particular expensive machine. So, someone who worked at the factory wrote a small program in Excel + I think VBA. This accelerated their work extremely and probably saved them 10,000s or 100,000s in manual labor. It was easy for a non-programmer to write, because they knew all the details of the machine and the calculations, since they had done it over and over again. But it's not a enterprise web app or anything and it does not matter if the program runs in 1 or 4 seconds.
By the way, I also consider efficiency to be a specific knowledge domain, or architecting a very large project. So in the end it really depends on how narrow or wide your definition of 'programming' or 'coding' is.
But mental discipline required to write efficient and scalable code is insane that most domain expertise is feeble by comparison.
Coding is way easier.
Programming is the easiest part! (c) decade+ experienced senior developers
I think there is some prestige factor in the background too. Being seen like some kind of code monkey is to be avoided like the plague. Business people really don't value the math savant engineer nerd archetype who just codes and codes.
Highest prestige is always taste and judgment, not correctness and skill. This is why people will also talk about how business soft skills, communication etc are more important than hard skills like programming, math, etc. I think one should be careful with this. On the one hand it's true that career progression is quite dependent on soft social skills, but there are also really hard kinds of software jobs where cognitive horsepower and technical experience are absolutely crucial and soft skills won't save you.
"efficient scalable code" is just as vague as good code. How are you going to know your code is scalable if you don't understand your domain? Scalability is not something you sprinkle onto code.
Sometimes you need two orders of magnitude. Sometimes you need five. Sometimes you need less than one.
Efficiency is about using minimum cpu cycles or minimum memory or minimum network round trip or more generically using minimum/optimum resources to get something done.
Scalability is about minimizing bottlenecks and linear scaling so one can just copy and execute by adding more nodes/resources and expect correctness and increased throughput.
Both of these have nothing to do with domain expertise.
But I'd also claim that these things fall on a spectrum. At the extreme end we have exchanges and HFT-like trading systems, where absolute accuracy and latency are not even constraints but industry fundamentals. At the other end we have "toy" applications that handle tens of requests per second, tops.
Scalability problems are definitely near the extreme end. Only instead of raw latency, you get to deal with complex failure modes, throughput, capacity problems, read amplification and thundering herds... all the while being constrained by available CPU cycles and bounded memory.
Yes, technically, but note that this entire thing can be anything from crucial to completely worthless depending on the domain.
You need insane scalability for a social network or a streaming service, you don’t need any real scalability for (completely made up) managing a fleet of airplanes or the internal logistics of a zoo.
No profitable business wants to pay you for writing code that uses "a minimum" of a resource. It wants to pay you to find the right balance between resource usage, time-to-market, operating cost, code complexity and probably several other factors.
Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!
Maybe we can grab a coffee.
In fact about half of my career has been dealing with 'domain knowledge at least present enough to get the ticket/epic closed but leads to a lot of tech debt'.
i.e. a good portion of my jobs have involved a lot of a good amount of:
- Review PRs with a fine tooth comb because despite domain knowledge, people are human and can either don't know any better, make mistakes, or willingly refuse to integrate feedback, or worst refuse to double check what the coding agent wrote for them.
- 'refactor this thing because it was technically correct but written so poorly that it leads to timeouts and/or a Manager/DBA is screaming' [0]
> We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.
A truly good software engineer is able and willing to learn the domain, but there has to be a way for them to learn. I say that because I've been at shops where various levels did that (i.e. sometimes the company itself, sometimes the team, sometimes colleagues) and I've been at shops where everything is lip service and at best you can only glean from what's in the JIRAs and what you can glean from what people outside of IT say in meetings you are in.
> After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.
I think a big paradigm shift especially in the past 5 years has been that most companies are expecting folks to work to the bone, and it winds up being counterproductive because it prevents anyone from being able to have the important conversations.
Culture is a huge factor in this, I've worked at shops where at the very least you could easily have a side conversation or a meeting, and shops where you might as well sign a change.org petition to request time to talk about it properly.
Still, you are right at the crux; Requirements matter more than code at the end of the day. I've been at shops where a person's definition of 'Correct' meant a feature got delayed despite all requirements being met, because they didn't like they way it was written after they were gone the whole time it got implemented and the rest of the team approved all design decisions.
[0] - Next thing you know you learn about a 'batch process' has %numberOfRecord%*10 inserts, possibly with additional fetches given a poorly designed data model to where it is doing SQL upserts in the most wrong way (i.e. doing a get from the DB and then adding a record to be inserted if not present.) and they keep doing more and more questionable things to 'improve performance' rather than rethinking the data layer's query pattern. Seen it more than once in my career.