Hacker News Reader

Comment by MichaelRo | Hacker News Reader

As a "senior" (expert) software developer you got a slight edge over a junior as long as you work in the same domain of expertise. As soon as you change project, you're at loss.

General intelligence helps but can't make up for domain-specific expertise. Example: move from accounting software to map navigation software. Clueless. Move from map navigation software to financial software. Within financial software move from quantitative pricing to exchange interfacing. Clueless.

Sure, you mostly get away with it but inevitably problems will arise that you have no idea what's causing them or even that they are a problem, so you spend days and weeks chasing what the expert figures out in minutes.

That's why I prefer to keep the domain when changing jobs because it adds up to being just a software developer.

View on HN

I disagree, because in high specialty domains you even cannot reuse knowledge as it might be proprietary.

On the other hand patterns are universal. You sit in a meeting where someone raises problem of „database slow, we have 50M of log entries, we need to delete them” and all the familiarity bells already ring.

The open domain knowledge IMO is something that can be extracted from LLMs. Ask LLM for disk-based data cache and it will happily provide. But it won’t ask how many writers or readers you have. For me even imagining this scenario makes my spidey sense tingling.

What's the problem with 50M log entries and deletion, and a disk-based cache?

A great question, which I'll allow myself to not respond _here_. Please check within a week, as I try to migrate my blog to something simpler. I'll put description there and link here once done.

FYI - I still remember, but got sidetracked.

While that is true, you also end up learning foundational concepts which are frequently common between fields. You get a major head start when learning.

For example, when learning electrical engineering, you might be forced to get good at vector calculus, and then when you move over to mapping software or physical chemistry, it turns out you use the same vector calculus.

The application of vector calculus might vary but it sure takes way longer to learn vector calculus than to learn how to apply it differently.

Vector calculus probably isn’t the best example but you get what I mean. I just find juniors learn new things so slowly. Hell, when I look back at my university days, it took me a long time to learn anything compared to now.

The edge is not slight. And usually in a new domain you're usually not completely clueless. There is value in growing a truly deep expertise by spending a lot of time in one domain, but a lot of the deeper skills do transfer (or partially transfer) and having mastered a few domains tend to give you deeper meta-skills.

Disagree. A lot of experience comes from a long career of changing projects and domains. You keep on encountering the same issues and problems in different contexts. I've been doing that for thirty years or so. Getting productive in new projects quickly is a good skill to have. It requires being efficient and mastering new things.

This is also the number one skill you will learn by getting a good education. Education can come in many forms. Some people never go to university for this and are self taught. It's easier than ever to teach yourself whatever you want to learn. In the end it's not about the stuff you learn but about learning to learn stuff. And having learned a lot of stuff, makes learning a new thing relatively straightforward. It's more of the same.

I don't agree. Domain-specific expertise is valuable (even essential) but can be learned, and usually rather more easily than learning to become an expert software engineer.

I've worked in a number of almost completely disparate domains over my career, each one needed maybe a year or so to become reasonably knowledgeable on, but it's not the same as resetting back to a complete software novice each time.

Also, the people who have been deeply embedded into a domain for a long time tend to overestimate how much it takes. I've seen exactly this with your example of financial software; yes there is domain knowledge but the clear industry lesson has been that it's far easier for software engineers to learn that than for the domain experts to learn software engineering.

Domains are often not very deep, as a lot of people need to understand them.

I've seen smart people quickly figure things out and propose upgrades in a matter of weeks, on points lifelong experts overlooked, or were too lazy to dig.

Reminds me of a company that was looking for people good in both the domain and software, to bridge the experts/devs gap (which is often a bottleneck, information flow between brains being slow and unreliable). They found out that it was much easier to teach the domain to devs, than to teach software to domain experts, i.e. that software was the hard skill.

Reply on news.ycombinator.com