Ask HN: What are well-paying alternative jobs to being a software developer?

I looked back through your comments and noted you posted a similar Ask HN a couple months back... look if you are a CTO and have a reasonable network (or can quickly build a network) there are plenty of companies that would take you in a sales / pre-sales engineering type capacity on the basis that you:

a) presumably understand tech / can learn quickly b) will have street cred from your past experiences c) will presumably bring some kind of network / rolodex with you

So, don't stress - if you can put a confident foot forward, you probably have more going than you realize. It's just a matter of how you sell it to a future employer.

The first job I was offered was a sales engineer role. The interviewer said sales was easy. Understanding the product (oscilloscopes) was not and required at least a degree. The target market didn't care if you were charismatic, they just wanted the right to for the job.

There's plenty of highly technical things from databases to Jira that appreciate dev experience more than sales experience.

Look for companies on the smaller to mid size businesses that do IT services consulting. Companies and the expectations of sales on the product side are much different from what I have seen (or enjoy).

I travel serially :) After covid settles a bit, I'll continue trawling south america, until then new zealand, who knows.

There are often jobs that pay more, but they're either the fixed-price ones, or have fewer hours.

Do you live in a particularly expensive area?

Well you knnow, after all this time you can find a place to "coast" with your skills.

Example, I've always been a bit put off by the plethora of syntaxes and frameworks in javascript, and I lawnmowered my toes off with angular one fine july, but recently discovered svelte-kit.

It's a cinch, a few practice projects, a few paid ones, and one upwork refund later, I'm getting quite confident in my abilities to turn out decent stuff fast.

And the "fast" is the most important thing, with my new found impatience for not being thirty anymore.

That's an incredibly long time!

I'm not the person you originally replied to, but just to give a bit of perspective as an EM myself: I think this depends a lot on the person and the team. One part of the gig is just being an effective project manager, and those skills are somewhat more objectively measured.

Much more subtle is the relationship you have with the team you're leading. If you have a culture/vibe of mutual trust and respect, and know when the manager helps ICs versus when ICs help the manager, then the line is blurred, and the team kind of sinks or swims together. You're all playing on the same team, and your role is to some extent a metaphor of the team/product as a whole. What is a lead singer without a band, or vise versa?

If you foster an adversarial relationship, or an overly top-down, bossy kind of vibe, that schism between you and your team can devolve into something that won't withstand the downturns. Bad managers and situations lead to finger pointing and nastiness. Who gets canned in that scenario? Depends on the company and the relationship each person has with the folks up the ladder. But before this kind of situation has come to pass, there should have been some red flags raised. As a manager, if you don't/can't get along with your team, you should find a different team to manage, because you can't ever be effective without their support.

Firing (due poor economics) is usually the result of bad management. A healthy company won’t have any need to fire an IC or manager, at least not because of economical reasons. I‘ve been in extremely stable companies (+500 employees) where no one has been fired for decades. People usually just quit when they don’t see career advancement or better opportunities. No need for an Up-or-out or bottom-10% strategy you sometimes see in big consultancies to have a healthy workforce.

I've survived many rounds of layoffs as long as I have (decades) by refusing all attempts to move me into management. It is always the middle managers that get the boot during layoffs. I have almost never seen developers get laid off (at least not as part of mass layoffs, usually they are laid off because they are plain bad).

As an (ex)EM, I don't think the likelihood of a first-level manager getting fired is all that different. What is different is the timeline - it takes longer to see whether the manager is underperforming (vs helping the team get out of a rough patch). There's also the consideration that a manager can at best influence their team's outcomes, while being fully accountable for them. This gets worse as you climb up the ladder, as the influencing gets more and more tenuous, while accountability only grows. The stress of this should not be underestimated by folks considering a move into management.

It's mixed and depends a lot on the specifics of the situation. I'd say that business-critical engineers (i.e. ones who have deep knowledge of a profit-center codebase) have more job security than non-business-critical managers (i.e. those who run "nice to have" projects), but business-critical managers have more job security than business-critical engineers and non-business-critical managers have more security than non-business-critical engineers, particularly senior ones.

If you're a CEO planning a layoff, your #1 priority is to minimize disruption to the organization. The worst employee is one who is still on the payroll but demoralized; hopelessness is contagious, so not only are they probably not productive themselves, but they make everyone around them unproductive. If you lay off a good manager, they're gone, but you've also demoralized all their reports. You get the same effect if you lay off a core engineer, one with deep knowledge of the codebase that everyone goes to for questions. However, you can lay off a garden variety IC, one that keeps to themselves and just does their job, without any serious repercussions to the org. And you can lay off a whole division without serious repercussions for the rest of the org, because everybody who knew them will no longer be there. This is why many companies try to structure layoffs as "We are exiting this line of business, and that is why the people who worked there are no longer with us."

The one big exception is executives, who usually have less job security than either ICs or managers. I've heard this as a reason why executive salaries are so high; few qualified people will take the job without the knowledge that they'll get F-U money in 2-3 years, because there's a decent chance they'll be fired and unhireable by then. This also fits into the framework above: typically, when an executive gets fired, it's because the business they lead is underperforming and the staff is already demoralized. At this point you lose nothing by getting rid of the executive in charge, because everyone wants to see him gone anyway.

The same logic applies to bad managers; you can and should fire these quickly, because they demoralize all of their reports.

It occurred to me recently that this may be why we have layoffs at all. The fairest approach, and one that maximizes general welfare, is to give everyone an equal pay cut when the company's revenues go down. The problem is that this demoralizes everyone. The good people will leave anyway, while the bad people will sit and do nothing useful while bleeding the company dry of the rest of its cash. So instead, companies create much greater pain across a smaller number of people, and then ensure that the people most affected are no longer with the company so they don't affect overall company morale. The ones left behind are more inclined to think of themselves as lucky, or skilled, or grateful they weren't the ones canned, which are all positives for performance.

I've made personal contact with various people on HN over the years. I'd be glad to bounce ideas around about your current career or other options, just share your contact info in some way and we'll set up a call.

I was freelancing when I made the move to real estate, so in that regard I was already comfortable in a self-employed role. Many people in tech (myself included) are excessively introverted. If this describes you, you'll want to consider how you feel about a career move where lots of contact with the general public is necessary, and how you'll cope with that for yourself.

Yes, the licensing is straightforward - I'm licensed in two states and am considering getting my license in a third. That said, it's a lot like how we talk about the 10x engineer in software - there's a huge gap between having a license and actually being a skilled professional. The average US agent makes something like $60K a year, whereas the top earners (and of course market matters...) make many multiples of that. Real estate is not a monolith - there are many different directions you can take a career. If you aren't comfortable with being an entrepreneur / self-employed person, you'll have a harder time of it.

Again, happy to talk more about licensing, how to choose a brokerage, finding your niche, etc. Likewise, if you go down that path I'm happy to introduce you to mentors, contacts, etc where possible.

> I have been interested in software sales as well but that seems like it could be hard to break into as an engineer.

I am currently in technical sales (Presales is the name of my org).

This absolutely is not the case. There aren't a ton of folks crossing over but one of my team members did so and has been quite successful.

While it wasn't from a software engineering role, I moved to technical sales from the org's support group so I have the faintest sense of what pitfalls that you may go through.

At the end of the day, many folks in Support groups and R&D groups can fall into the trap of thinking narrowly about a problem. Let us take the problem of getting data into an application. In this scenario a customer asks you if your tool supports 'real time data'. The direct answer is no, it takes time for the tool to fetch / process / present the data from the source system. From a technical lens, this is absolutely, 100% correct. From a selling lens, it's helpful to redirect the conversation towards the customer's goal. Their goal is that they have the lowest latency data possible. This isn't a binary yes / no situation like the previous question.

Now it's relevant to ask questions like:

- What is the source system?

- Is the source truly the originator of the data or is it a downstream consumer of a pipeline?

- If it's not the originator, then how frequently is this pipeline run? Real-time? Micro-batch? What is the latency here?

- Is the source a fixed price system or a cloud-native platform (e.g. Snowflake, BigQuery, etc) where there are marginal costs per query?

- How many consumers will there be of this data? 1? 100? 1000? 10,000? Data approaches often can be cost / performance effective at one scale but flounder at another.

The net result is that the key question that you have to ask involves focusing on the _problem_ the potential customer wants to solve, not just the mechanics of how to solve it.

That plus

- the politics of the deal

- answering the question at the right level of grain for an audience (engineers get different frames of the same answer than VPs / Executives)

- positioning your differentiated techniques and technologies early in the deal to nudge out competitors (they will be doing the same)

- explaining broad or complicated techniques in a consumable fashion (aka a ton of PowerPoint slides) and a number of other aspects

Feel free to ping me (email is in my profile) if you want to chat more about this.

Appreciate the sentiment, and I’m glad to have been afforded the opportunity to have a faster track into this than most. Another reason why there is such a lack of working appraisers now is the same reason why it was easier for me to find a supervisor to train me: You either have family in the industry, or a close friend that gets you a foot in the door.

I will be a 3rd generation appraiser, following in the footsteps of my father (who has been in the industry at different levels for 30+ years), and his father (who got into the profession my answering a newspaper ad for FHA appraisers). For the longest time I balked at going into “the family business”, and it took me beating my head against a wall at places that didn’t give a shit about me or my skills to find the one place both of those things were taken seriously.

A side note for those reading this that have ADHD, I cannot stress how much of an overlap there is with appraisers and having some sort of attention disorder. This is not a bad thing, but a pattern I’ve noticed in talking to appraisers from around the US, but many of us seem to have self selected into a profession that works really well with the way that some forms of ADHD work. The specific report forms we fill provide structure and readability of the written reports we prepare, but the randomness and dopamine hit of a new subject and comparable sales to analyze every report keep it fresh.

Any questions anyone has, more than happy to answer!

You're looking at it from the SW dev angle, but DevOps is very interesting from the management angle too and you can leave stuff like K8s to some DevOps engineers after you've done your consulting.

I mean stuff like GitOps/trunk-based development, release management, feature management, monitoring, review apps (see on Gitlab), Git itself (still not universal) and so on.

I was a contractor for a few F500 and all of them had separate DevOps teams that we were supposed to interface with; we didn't even have access to the cloud console. But I was also a contractor for few large companies (but nowhere near F500) and we did all DevOps ourselves and had full access to the cloud panel.

Both models had DevOps consultants though - someone who advises the management on the best ways to do DevOps so each developer doesn't do it in their own way & so never-ending discussions about what's the best way are avoided (those didn't write a single line of code).

It’s totally possible. Aside from a stint “embedded” on an implementation team to launch a critical product, I’ve been doing exclusively exploration, architecture, devops, and documentation for the last two years or so.

Yea, piloting is fun, but a long, loooong grind. It takes a while just to start making peanuts flying regional jets. By the time you are in the big bucks range, you could have done a bachelor’s in biology, med school, your residency and become a doctor.

And starting in air traffic control has an age limit of 30 years old[1], so it might be too late for you already. Talk about even worse ageism than software!

1: https://work.chron.com/many-years-college-need-air-traffic-c...

Having been a pilot (though not for an airline) and now being a software engineer I feel somewhat qualified to speak to this. Doesn’t really matter since airline pay is public and I think levels.fyi does a good job.

Captain at a major airline is attainable, it just takes time. Looks like that’s capping out at $270k right now (I’m sure I’m missing some benefits or something). Pilot pay isn’t nearly as affected by geography and multiple days of work mean an otherwise insane commute (like multiple states) is possible. An airline captain in a small town in Iowa is doing better than a software engineer. But the software engineer in Silicon Valley is doing way better. This was all prepandemic and I imagine that’s shaken up remote work pay a lot. So who knows.

But if you want to get out software because it’s a grind, stay far far away from the airlines. Sure you don’t have a scrum master breathing down your neck. You have complete autonomy to do the exact same thing over and over the exact same way until you retire. Imagine building the same app for the tenth time but no, literally, it’s the exact same app and it’s not the tenth it’s the thousandth.

Other commenter is right that a Bachelors and passing the exams are required. The work certainly does get boring, but is extremely stable with, usually, excellent work life balance. It's very possible (in the US) to spend ~7 years working/studying to pass the exams and now you can make 150-200k USD/year while averaging 35 hours week for the remainder of your career.

One major difference in comparison to software is the extremely long project timelines. Loss model refits/remodels are planned years in advance, it can easily take 6 months back and forth waiting on states to respond to filings, etc.

Typically requires a bachelors degree, ideally with a background in math. In order to progress in the career, one has to take and pass actuarial exams.