Hacker News Reader

Comment by smallnamespace | Hacker News Reader

> This, coupled with the fact that few programmers were trained in fields like stochastic calc,

Anecdotally though, I've met plenty of coders who did this to themselves by refusing to learn more about the domain or the business.

They basically silo'd themselves, then wondered why their colleagues didn't treat them as an integral part of the team when they couldn't speak the language or understand the concerns.

Taught myself enough stochastic calc to change and validate pricing models while on the job.

Coders who understand their domain well are immensely valuable, and are easily worth at least 3x, because they don't over- or under-engineer a solution, and because they can conjure up with technological solutions for problems that nobody else in the company can even conceive of.

View on HN

> Coders who understand their domain well are immensely valuable, and are easily worth at least 3x, because they don't over- or under-engineer a solution, and because they can conjure up with technological solutions for problems that nobody else in the company can even conceive of.

This is a crucial point to me. Being able to code is good, but being able to code well while also having an intermediate or expert understanding of the domain that you are working within is what is going to set you apart in the long run.

In the industry, developing software can usually be seen as the process of creating a tool that will help to better solve a problem. It seems strange to me that you would want someone who doesn't have a solid understanding of the nature of the problem (or the solution) to be designing and building the tool, just because they claim to be good tool-makers.

> It seems strange to me that you would want someone who doesn't have a solid understanding of the nature of the problem (or the solution) to be designing and building the tool, just because they claim to be good tool-makers.

I couldn't agree more and this is my main objection to "AI will replace [insert any job here]".

A lot of problems are inaccessible to programmers just because not enough of them seem to be willing to understand them. Complex rules about accounting in large companies seems to be one of them for example. This is why I think AI will certainly overtake many professions but mostly professions that are required on a large scale and that are easy to understand: driving, cleaning a house, building a house, ironing, cooking, assembling objects, etc. For complex accounting or legal issues, I am a lot more skeptical. You don't need complex AI to run accounting systems, they can easily be done with regular software. However in large companies you still have huge accounting departments booking and maintaining these complex logics by hand (excel), a lot could be automated now. And the same reason why they haven't been automated in C# now will apply to AI in the future.

Re your AI thesis, I think it’s the exact opposite. Deterministic, rule-based processing applied to lots of similar data are perfect for AI-fication. It’s all in the computer, and you can kick out to a human-driven exception process when required.

All that physical, real-world stuff you mentioned (cleaning, cooking etc) is vastly more complicated, riddled with experience-driven subjective judgements (is this paper on the floor trash or should I put it back on the desk?) and highly situational. Extremely difficult to generalize and handle with an AI. Not to forget it’s messy stuff in the real world, with engineering and hardware and grease and failures.

Most of the complex accounting and legal questions that these departments are doing manually aren't completely trivial either (we are not talking about just adding assets). But the determination of whether the paper on the floor is trash or not is something that pretty much any AI professional can apply his mind on (and will likely do given the size of the market), whereas very few will apply their mind on how IFRS should treat a tax asset in consolidation when the corresponding tax treatment under USGAAP is a still in discussion.

If you look at self driving cars, they are already doing the sort of wizardry of your trash example when analysing the other objects in sight.

And again it's not so much a matter of technical complexity, it's a matter of the domain being inaccessible to those who can best automate it.

>Most of the complex accounting and legal questions that these departments are doing manually aren't completely trivial either (we are not talking about just adding assets).

These are exactly the types of problems that machine learning is perfect for. Problems which involve chains of nebulous decisions that would be difficult to program traditionally.

Couldn't agree more. I have met so many programmers in banking who seem to actively avoid having to learn anything about a bank, not even complex math.

In theory, project managers are supposed to bridge the gap between the business and programmers, however my experience is that they usually understand neither the business nor the IT side, and are only adding more confusion.

People with both knowledge of both worlds are incredibly rare and valuable.

what then is the best approach to learning how a bank works? where would one such programmer start?

Work for a bank.

I could not have formulated this better myself.

All but a few programmers I have met have tried to understand the underlying reason for their employment and the businesses issues they are employed to solve.

This approach have caused programmers to loose a lot of influence and status.

10 years ago companies had developers develop their own customized CRMs, which can really benefit a company if their domain-specific needs and processes can be integrated to such core-business software.

Nowadays, Adobe Campaign have a cake walk selling their bloated, general and non-tailored “CRM” solution to business.

How can they Adobe etc do this? They approach the marketing and sales team and offer a nice slide show.

Why does not IT or programmers even get involved before the purchase? Because no one likes talking to the idiots in IT that does not understand the businesses needs. They only nag about some “technical debt” (that no matter how much money is poured on the teams never disappears) and the need for re-writes of fully functioning parts of the system that introduces new bugs.

>Anecdotally though, I've met plenty of coders who did this to themselves by refusing to learn more about the domain or the business.

Anything outside of learning enough to do your job should be at the business's expense.

1) some fields are not good for self-teaching. It leaves the possibility open to misunderstanding and writing code to that misunderstanding

2) the business will probably have a good idea of conferences and workshops that impart the knowledge the business is looking for

3) this is more fuel for "unpaid studying outside of work hours"

Based on posts like this, it seems really dumb to enter software first -- better to get a degree in some other technical field and just teach yourself to code.

In many environments, you probably can do a lot of that learning at work, just by talking more than strictly necessary to people having the knowledge.

> Anything outside of learning enough to do your job should be at the business's expense.

There's no "should" here — it's an open market with a lot of agents. You're free to pursue certain working conditions and then look for employer that will agree with them. And another developer is also free to go an extra mile and ask something extra in return.

This is why I'm against any kind of unionizing for developers, by the way — too many different situations and opinions about what our working conditions should be.

If it increases your value and allows you to demand a higher salary, that is at the businesses expense. You are a business expense.

It'd add even more value if companies spent more on proper training. Maybe even training geared for software devs learning the field from that perspective if that's available.

But if they think I can become a domain expert by reading junk on the internet with no one really verifying my skills, I'm happy to take their paycheck.

Reply on news.ycombinator.com