Live data from Hacker News

Ask HN: Career paths to consider if I am better at supporting than creating?

news.ycombinator.com

21–30 of 34 posts

Re: Ask HN: Career paths to consider if I am better at supporting than creating?

#21

I'll be blunt rather than couch it: all the things you've listed will make you a ralph loop target in the org. You are adding human in the loop where the industry is moving in the opposite direction. This is generally true across all roles, but first impact will be working that is more trivial for an agent or n8n flow. So consider this and pick roles wisely, where you can see this existing for a bit. All the best.

I find this a very engineering/technology focused point of view. Most business related functions run on this “human in the loop” with zero hints from industry this will change anytime soon - quite the opposite.

Even if we take purely engineering, support and operations functions, there is still plenty of “human glue” in the organizations that allow for them to function - the larger the org, the more often you need to interface people between each other, and corner cases become more complex.

Big Tech which is the most vocal about their technological savviness is a great example: pretty much nothing has changed on business and cross-functional side since the 90th and earlier, all key decisions are made via Powerpoint, memos and personal contacts. Jeff’s innovation of preparing and reading a one page of problem statement and proposal at the beginning of a meeting was considered breakthrough in this field. No LLM in sight that can magically fix this [semi-ironically] beautiful mess.

And don’t get me started on B2B Sales and Partnerships.

Re: Ask HN: Career paths to consider if I am better at supporting than creating?

#22
> I am just much more comfortable supporting existing software than building new software.

> It honestly gives me a huge sense of accomplishment when I get to see a customer making use of our products, and helping them investigate why something may not be working.

> I've learned that money isn't everything.

Put this at the top of your resume, send it around to a few headhunters and see what comes back.

Many (most?) developers are not very interested in supporting someone else's work. The customer seems to get it even worse. AI has turned the ego trips up to 11. You have an advantage if you genuinely feel this way about these topics and can sell that feeling to others.

Re: Ask HN: Career paths to consider if I am better at supporting than creating?

#24
A few years into my career I realized that I was not cut out to code. Luckily I worked for a good employer and they told me that code was 5% of the business regardless of what the sign over the door said. Over the next 20 years I spent time doing QA, tech support, product management, professional services, and sales engineering.

Rightly or wrongly there is a hierarchy of job roles and QA and tech support are low down on that list. But if you want to stay in the industry that your org serves (eg healthcare, energy, telecom etc) they are good ways to gather real industry experience.

Product is hard but devs do appreciate someone who can clearly tell them what is needed without micromanaging them (and tell the customer what is possible and what is not).

Pro services is great if you have good human skills but it can be a tough sell (some orgs treat it like a body shop, some customers think they dont need it, some sales orgs throw it in for free meaning you are underwater immediately).

Sales Engineering can be lucrative and fun, but only if you are paired up with a good sales team that doesnt treat you like a demo and slideware robot.

Re: Ask HN: Career paths to consider if I am better at supporting than creating?

#25

Perhaps a sales engineer? > I am just much more comfortable supporting existing software than building new software. Having technical skills is required, but you'd be doing little to no coding or design work. > Being an interface between business and tech. A sales engineer matches this almost by definition. > Just working with people in general! The job is essentially entirely about working with people, both with the…

I think I can second this. I was offered an FAE job (essentially the sales engineer of hardware) and they were going to pay me more money to write no code and spend most of my time in the road talking to people about products. But I like writing code. Presumably a great job for somebody who doesn't/can't.

Re: Ask HN: Career paths to consider if I am better at supporting than creating?

#26
Smaller or faster growing companies often need versatile people that can speak to customers and developers.

Or find a tiny niche where you can leverage technology to make a customer life easier. Then do that for more customers.

Or experiment in a consultant capacity outside of the day job.

Stepping back to big picture, your comments about versatility and helping the customer scream small business opportunity rather than big corporate.

And when I say small I think that’s a great thing (autonomy, financial independence) in contrast to Silicon Valley venture capital culture.

Re: Ask HN: Career paths to consider if I am better at supporting than creating?

#27

Perhaps a sales engineer? > I am just much more comfortable supporting existing software than building new software. Having technical skills is required, but you'd be doing little to no coding or design work. > Being an interface between business and tech. A sales engineer matches this almost by definition. > Just working with people in general! The job is essentially entirely about working with people, both with the…

This is honestly a career path I’ve never really considered, but after reading about it a little bit the role sounds like it would be right up my alley. I’m going to explore the market for sales engineers here in Sweden and see what kinds of roles are available. Thanks for your comment.

Re: Ask HN: Career paths to consider if I am better at supporting than creating?

#28
* Business analyst and Scrum Master

* Test Automation Engineer

If you want to remain technical I strongly advocate for the second option. It can be super technical and if you end up in an organization where the primary developers suck at what they do (or their management keeps them locked up as infants) you can end up doing more engineering than the developers you are supporting.

Post reply on HN