+15 years experience, something I wish I started doing on day 1

[u/CooperNettees]

I've read a lot of different questions and suggestions on things early developers might want to consider but this is one I actually haven't heard as much and something I wish I had started doing day 1 of my career.

When I started out my focus was on trying to learn software development. I'd take a bit of time each week to dig into the technologies I was using at work to try and find non-functional areas we could improve in as I was grinding out functional stuff. over time this built up to an okay understanding of the SDLC overall.

there are plenty of areas I'm still not very strong, but at this point I have enough experience with enough different things that its relatively uncommon i encounter problems totally out of band from what I've seen before, and have a fairly decent understanding of many of the popular technologies used today across a wide span of problems.

Ive worked in a lot of different domains over my career. ive generally left most of the parsing of those domains to domain experts. sure, I'd pick up things here or there, enough exposure to particular verticals will do that, but I generally focused my time and energy on developing my tech knowledge, as it is more portable between jobs than domain specific stuff.

that said, I can now see the limits of this approach. I've been working in the same shop now for four years and I wish I had spent a little bit of time each week better learning the domain I am working in from first principles. I dont feel like I am lacking in technical ability. I have enough technical tools at my disposal. I feel I am lacking in domain specific insight, and so are the others surrounding me.

If i had been studying my current domain a little bit more here and there over the past 4 years, I suspect I wouldn't feel this way. I suspect I would be able to crack some of the tough nut problems we've been dealing with sensibly.

looking back, there were plenty of times in past roles where I wasnt able to see the forest for the trees as a result of a little too much domain blindness & outsourcing of that knowledge to others who perhaps didn't know the domain all that well either.

anyways, the advice I wish I had gotten was to carve out a bit of time for myself to learn the domain I was working in outside of the context of tech and programming. SWE skills are important, and most of the time we can learn the bits and pieces of a domain we need at the time, but some insights are locked behind both a general understanding of the tech and the domain.

[u/EverBurningPheonix]

Can you give an example of domain, and what a newbie should learn from that?

And what do you particularly mean by domain?

[u/CooperNettees → u/EverBurningPheonix]

Imagine if you work on banking software. the domain is banking, the tech stack may be cobol + java.

learning the domain means learning about how banks work outside of the context of what the software your working on does; trying to learn to see the software like some of your users might.

a newbie can start to learn to see how different approaches might be better or worse for your end users and for the domain they are working in without needing to rely on a product owner, analytics, contact reports, or whatever. it also makes interactions with stakeholders much more interesting, since its an opportunity to test ones understanding of their domain & be corrected.

[u/EverBurningPheonix → u/CooperNettees]

Thank you for giving an example, this actually made me better understand the point youre making. Basically, in a sense, understand the market youre building software for.

[u/CooperNettees → u/EverBurningPheonix]

yes, with the only distinction I might add being to understand it as the people in that market understand it.

its possible to understand the macros of a market really well but not have a good understanding of the realities on the ground.

[u/Ab_Initio_416 → u/EverBurningPheonix]

I agree. Software is created to fulfill stakeholders’ objectives. If you don't understand their domain, it’s tough to deliver products that actually meet those objectives.

Otherwise, you end up with gems like the system a hospital ordered, where the developers didn’t realize doctors sometimes need to back-date notes. The software cheerfully locked out any date except “today”, technically correct, but utterly useless in practice.

Understanding the domain isn’t optional homework. It’s the difference between building what was asked for and building what will actually work.

[u/lurk876 → u/Ab_Initio_416]

Understanding the domain isn’t optional homework. It’s the difference between building what was asked for and building what will actually work.

A large part of my job is thinking about "Are we building the correct thing?"

[u/whispsecret]

Don’t disagree- You are solving a business problem first and technical problem after that. You’re working on part of a business first and people have helped boil it down to a technical problem after.

[u/daredeviloper]

100000% agreed. 

There’s so many developers who can’t see past a function or the repository. 

They make their little code changes and move on. 

I’ve been like that and I’m still like that in a way but I’m now trying to expand my scope. 

I respect perfecting the software craft with perfectly abstracted organized code   but at the end of the day we’re trying to solve some sort of problem.

And it’s a spectrum too I imagine. Those that focus on just the code vs those that focus on just the feature vs those that focus on how it affects the customer vs those that focus on what customers want vs those that focus on what customers will eventually want vs those that focus on the “domain” itself (finance, health etc etc)

[u/tkyang99]

I would add that you dont necessarily have to understand the domain, whats crucial is you understand how your company is making money.