3 ms·

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.

by Syntaf 4mo ago

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.

to11mtm 4mo ago
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 4mo ago
  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.
dapperdrake 4mo ago
Am available. Maybe we can grab a coffee.
elendilm 4mo ago
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.
- Capricorn2481 4mo ago
  > 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.
  - elendilm 4mo ago
    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.
    - runeks 4mo ago
      > 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 4mo ago
        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.
jrvarela56 4mo ago
“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 4mo ago
  Hah very clever :)

by Syntaf 4mo ago

to11mtm 4mo ago

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 4mo ago
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.

dapperdrake 4mo ago

Am available. Maybe we can grab a coffee.

elendilm 4mo ago

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.

Capricorn2481 4mo ago
> 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.
- elendilm 4mo ago
  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.
  - runeks 4mo ago
    > 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 4mo ago
      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.

jrvarela56 4mo ago

“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 4mo ago
Hah very clever :)