[Syntaf]

It was never about the code.

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.

[elendilm]

You are wrong. Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed.

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.

[microtonal]

Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code.

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.

[elendilm]

A implies B doesn't mean B implies A. Not all programs have to be efficient and scalable.

But mental discipline required to write efficient and scalable code is insane that most domain expertise is feeble by comparison.

[bonoboTP]

Right. If you're spending your time among developers to whom the code part is second nature, the differentiating thing becomes domain knowledge. If you spend your time among people of that domain who have no coding skill, to them it will appear to be the opposite.

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.

[wiseowise]

> Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed.

Programming is the easiest part! (c) decade+ experienced senior developers

[dapperdrake]

Seriously doubt you ever did serious financial math.

Coding is way easier.

[Syntaf]

Lol truly. A short list of just a few things that haunt my dreams: Distributions, American/European waterfalls, Carried interest, Management fees, and basically every single detail about Master feeder fund economics

[elendilm]

Funny. Sure. Kernel development and truly scalable architectures must come easy for you. Management fees must be so hard. :)

[Syntaf]

I imagine Kernel development is quite difficult, as might be designing infrastructure that can handle 10K+ RPS. I don't quite understand why you're being so passive aggressive, this isn't reddit; I'm not interested in being correct/incorrect -- you're welcome to share your opinion with me and I'm more than willing to hear your side.

Like anything in life, "it depends" -- but I do have the opinion that the vast majority of software engineering jobs are orders of magnitudes simpler in requirements than the two examples you've given. On the grand scheme, many engineers need to be experts in their domain to succeed; it doesn't matter if you can support 1k RPS if you only have a few hundred clients and don't understand their needs well enough.

Most startups don't fail because they don't have the right tech, but because they don't capture the right market or understand their customers well enough. There have been many startups with absolutely brilliant tech, but if your company (and your engineers) aren't experts in your product the tech won't matter _until_ you hit a scale in which you require that sort of expertise.

[elendilm]

Seriously doubt your reading skills. Read again. Hint "efficient" and "scalable". Go figure. I seriously doubt you have written scalable code. Financial math is laughable by comparison.

[Capricorn2481]

> Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code

"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.

[dapperdrake]

Scalability stems from domain knowledge.

Sometimes you need two orders of magnitude. Sometimes you need five. Sometimes you need less than one.

[elendilm]

Are you kidding me. What has domain got to do with efficiency and scalability.

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.

[bostik]

To be fair, I'd consider hard-core scalability/reliability software engineering skills to be their very own speciality domain.

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.

[Toutouxc]

> 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.

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.

[elendilm]

Writing scalable and efficient programs are extremely hard. This matters for serious projects but for small projects, honestly who cares.

[dapperdrake]

The almost all problems are "small", by your standards. Giant market.

[runeks]

> 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.

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.

[elendilm]

I run a small profitable business. I avoid those who doesn't care about efficiency or scalability like the plague. Laziness shouldn't be promoted.

[dapperdrake]

User-latency is key.

[jrvarela56]

“Teaching and engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.”

Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!

[chasd00]

Hah very clever :)

[dapperdrake]

Am available.

Maybe we can grab a coffee.

[to11mtm]

IDK, there's a tipping point where at best domain expertise without skill leads to a LOT of tech debt.

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.

[nomel]

Tech debt is what most orgs/managers ask for. If nobody is complaining, there's no problem. Nobody but you knows what's behind the scenes until they ask for something new that the tech debt makes take longer than you think it should. But they don't perceive it that way, because they're probably not software people. They just see it as a new ask that will take a bit longer than expected.

Nobody cares about quality, if they can't perceive it. They want practical results. AI will give that to them, to some degree. Most people don't see software as deterministic anyways, so sometimes not working doesn't register as the monumental, show stopping, failure that it would me or you.