Hacker News Reader

Comment by exdsq | Hacker News Reader

The thing that changed my career as a software engineer, in terms of seniority & remuneration by time and effort, was by changing my efforts from learning arbitrary tech to learning the domain I worked in. Asking useful domain-related questions gets you noticed in stand ups and helps you write the right code. I work in fintech so the best bang for my buck I’ve had was reading an entry level cert in investment finance.

I think the generic bit of this advice is to excel as an engineer is to focus on the business, not the tech.

View on HN

Big +1. Most corporate software is pretty straightforward (the company likes it this way so that it's easier to onboard new engineers). So, you stand out by delivering something other engineers can't, deep insights into how software can solve specific domain problems.

This has been my experience as well. Beyond a level an engineer creates value by being at the intersection of product/UX, business, and tech; by being able to seamlessly transition between them.

As a consequence if one changes jobs say every 2-3 years (different domains) then they become generalist engineers.

In my experience one has to spend 10-12 months at a company to pick up a domain by being deliberate at it. It may look like a big investment but the payoff will be significant once they have sufficient context in their head.

Totally agree! I have a background in government data science. As I rose up the ranks at the government contractor where I work, more and more of my job focused on corporate stuff that was outside of my wheelhouse. I used to be intimidated by phrases like "That's SG&A, don't take it off the topline." I told me professor friend and she gifted me a copy of Berk & DeMarzo. It's been more useful than any single programming book I've read. Turns out corporate finance isn't that hard, it just has its own language that takes effort to learn.

This is good advice for something like finance. But many software companies are out to "disrupt" very broad areas, and unless you intend to stick in one such area, I doubt there is a whole lot of benefit to doing that.

For example, if you are developing software at Uber, there is no "domain" to speak of. Ditto for a search engine at Google. The company pioneered information retrieval in the internet age, so what's the relevant "domain" there?

Of course, if you are writing MCAS software for Boeing, having a good understanding of Control Systems, or Aeronautics (which you can gain by attending nontraditional programs in colleges or universities) will be very helpful. Same thing for something like trading firms (where it's practically formalized and there are programs that turn out quants), accounting firms (e.g., Intuit) etc.

From your examples, it seems that you make a distinction between B2B (with possibly internal clients) and B2C.

The general advice that would still apply to both would be: understand who your client is and what they need in the context in which they evolve, be they consumers in a country you're not familiar with or mechanical engineers you barely know the job of.

Uber:

- "Hey, I saw a statistic that females are anxious about taking taxis at night in France. Why don't we add a feature to let people share their locations with others?"

- "In London taxi drivers have to pass The Knowledge, a test on roads! Have we considered adding a similar pre-requisite test for drivers in that city?"

- "I noticed a lot of drivers on Reddit have been complaining that the tips aren't viewable on the app, but we have the data. Why don't we add that to the drivers UI?"

Etc... The sources of this information would be user channels like Reddit, taxi-related news sources in countries you operate in, and keeping up to date on legislation. Sure you might not have the ability to make any of these changes yet but if you stay ahead on these factors it's definitely the way to move into a position where you can have that level of impact.

Would you mind sharing the investment finance cert you read?

https://www.cisi.org/cisiweb2/cisi-website/study-with-us/fou...

I believe it was this one with a slightly different name

Thanks!

Take a bow. I was given this wisdom right on my first job and its the best advice I have ever received. Software is pretty useless without the business context so merely talking about software is not helpful.

And it's one of the rare good advice. Communication failure (or even slow) is so expensive, being the guy who can translate ideas clean and fast will make a lot of things better.

Exactly. Programming is ultimately pretty simple. The hard part is the specific domain knowledge of the business.

If youre doing simple stuff then its simple i guess

Writing individual programs is often quite simple, but developing software products is often not. It's a combination of taste, hard-won experience, a feel for the organizational dynamics at play, and of course, raw programming ability. Note that the things on the list, other than programming, are often pretty complicated!

You kind of have to be a rebel to get that knowledge. Most teams don’t want developers talking to customers or spending time understanding the domain beyond their next ticket, and even in that case they’ll get a product managers distilled version. If the industry has courses/exams and a path of its own that’s helpful so you can get the knowledge that way.

I don't think that is the case, or atleast that has not been my experience. Most teams would be happy if you do these, but not affecting the next deliverable. So if you are willing or can spend extra hours that becomes manageable, but one can't always be in a position to spend more hours working (priorities, family etc.). What would be best is team encourages your involvement and factors that in deciding the target date of your deliverables. This would win for both since knowing domain makes one to understand the problem better and program beetter.

"[...] ultimately pretty simple" you mean if you ignore everything making it hard?

I must admit that this kind of attitude triggers me. I have worked in the energy sector, in engineering (but not IT) heavy companies, and many have this attitude. "its easy to learn programming", "we just need to teach the engineers python" etc etc, and I have seen MOUNTAINS OF SHIT so tall you would faint. It's easy to get tricked, because being both the user and developer at the same time can be such a boost. But the moment there are more users things get hard. The moment the code base gets so large that you can't keep it all in your head, it gets hard.

Software development is easy until its not, and it surprisingly quickly gets to the "it's not" stage. And then you get excel sheets in python.

Some "subject matter experts" make good programmers, but in my experience its not because their background, but because they are smart and have talent for it.

Reply on news.ycombinator.com