Hacker News Reader

Comment by noduerme | Hacker News Reader

I've watched this happen to so many coders in the land where people write code for companies that sell code. Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever, although in a new project you'll have more flexibility to pick the right tools than you would in a software company that's obsessed with the newest thing.

View on HN

Having worked at both, the latter type of company also has it's downsides. Primarily: a) the inverse is also true...you'll be working on some old technology that only your industry utilizes and isn't well optimized for modern use cases or is extremely niche; despite there being plentiful use cases to make the switch, it'll never be "in the budget", b) your payrate is generally going to be quite a bit lower than industry standards at app/tech companies and c) you won't get the same treatment as an engineering focused company.

The latter two are very much variable by company, but those are the general trends. They'll also vary in importance to different people. The former item, however, can be just as burn-out/tedium prone as tech company stack whiplash.

Maintaining old systems and not getting the chance to exercise your hottest take on how they should be rebuilt is often tedious as hell. But I find a lot of comfort in it. I usually find that the future road maps that stick in my head for a year or more are the ones worth a 10-year overhaul, and I like to be able to tell clients that when enough of their stack is reaching end of life, we should do this major rewrite but I already am fairly certain they won't have to do it again for another 10 years. e.g. I have yet to deploy any production code for a client running on Nodejs, but I've written enough dependable systems in it on my own free time in the last 5 years that I think I might now finally advocate for it under certain circumstances, knowing the strengths and weaknesses.

It does help - as you point out - to be in the position where the non-tech company will almost always take your advice if you tell them they need to change platforms. But the most effective way of getting yourself in that position is to prove that you exercise that option only when it truly is in their best interests.

> your payrate is generally going to be quite a bit lower than industry standards at app/tech companies

And so will be the workload. No semi-mandatory after-work drinking, no constant "hustling", no bullshit.

This is completely anecdotal, but I was far more overworked as an engineer at a non-engineering company than at any engineering company I've worked at. The entire reason I went back to that work environment was because I was tired of "wearing multiple hats" (e.g. doing three people's work) for 2/3 the pay of wearing one of those hats at some random adtech company.

I agree that it's dull but the fact that I still know ColdFusion 20 years later gets me a lot of work. No, it's not Silicon Valley money but it is Fairfax County money, which ain't bad.

Having a lifetime gig is worth more than all the startup stock options in the world.

But then again, I like my own yard and sitting by my fire pit with a beer, and I don't spend too much time worrying what other people have.

> you'll be working on some old technology that only your industry utilizes and isn't well optimized for modern use cases or is extremely niche

But it's easier to get a company to upgrade from old cruft to a commonly-used technology, of your choice and which you push, over trying to get the company to drop a new fad they've bought into ("You know, we don't really need all of those Docker images, and VMs, and Amazon Cloud services - let's just write an executable which does the thing and can be configured.")

I work for a company which sells code and we are a counter example. We make gradual changes in the development stack and processes, every change needs a reason, and even though some changes are necessary, they will not be implemented soon.

Some possible factors are that the company is not that big and we have a feature list to deliver. We are not VC, so we cannot afford to burn money. The devs churn is low, so we don't need to be attractive to many people all at once.

TBH, I don't like it all the time, but it works and our clients are happy with the results.

Hah. That sounds like my dream job. A software company that's not controlled by VC, not burning money, actually shipping a product, and (presumably?) turning a profit... that's an actual unicorn these days...

Isn't this just normal business-to-business apps? They're mid-size companies that are everywhere.

Profitable to the best of my knowledge. Not sure if the initial investment has been returned yet, but moving in that direction.

This is all fine but... the rest of the world is not freezed. Let's say you are happily mantaining a stable, boring ERP app for your... cigarette lighters plant.

Out of the blue, one of your main suppliers declares they will accept orders only through a REST interface starting next quarter. And that you can/must use it to track your orders, instead of sending an email to one of their employees.

One week later, you are required to provide invoices in PDF instead of just printing on paper.

And your accounting system will switch to Oracle Finance in October...

Your ERP was developed on Progress ABL, and nobody really cared to port the old code to a web-based architecture because it was just for "internal use" and Putty was fine.

Well, I can't tell you how many dozens of times I've had to learn some stupid company's API and integrate it into software just because a client decided to do business with them. That comes with the territory, and you set up whatever you need to make it work. When it happens, it's a sprint, and you migrate everything you need to. But that's very different than migrating it because you're bored or want to sell the client a new shiny thing.

Of course, but I was just trying to explain that sometimes you are forced to innovate due to external interfaces/dependencies.

And maybe these were introduced in other companies because their IT depts. are run by "fashion of the month", but whatever the reason, you now have a problem. And if your sw and your skillset has remained frozen in jade since the early 90s... this will be painful and probably require at least one false start before getting it to work reliably.

I have noted a tendency in people who work always on "very stable" technologies to go in crisis mode as soon they have to (for example) produce a file in XML or JSON format after 2 decades of CSVs... this unfortunately almost routinely ends in stuff which is very brittle ("XSD? you do not understand, we need to produce an XML, ... I dunno what an XSD is or has to do with this requirement - except that they both start with an X, maybe - so please do not make things unnecessarily complicated and just go back to coding, we were supposed to start testing one week ago.")

I've worked for a small company that does an old boring ERP. In C. The oldest files in the library date to the late '80s. The whole thing runs on a dime, is super fast, and a few developers could manage the needs of tens of clients.

Implementing orders in REST was probably done in a couple of weeks of work. PDFs have been there since ever.

This too. If the foundation is solid, it's easy to shift the outputs.

>>in the land where people write code for companies that sell code.

That is not always true, it also depends on who they are selling code do..

I know a few Orgs that by code from others, and pay $$$$ to ensure it never changes... or rather only changes in measured approved ways not drastic changes that would up in business workflows.

So I would amend your statement to where people write code for companies that sell code to startups or technology companies

if you are selling code to a 100 year old manufacturing company, or some other legacy space (healthcare, education, etc) then most likely they want stability not the new shiny

This is how you get stuck working with XML in 2023, as is the case with a woman I was just talking to the other day at my co-working space.

Another way is to work at one of the many places where XML (and related technologies like XSLT) make perfect sense both then and now. Working with transforming documents from one representation to another is a work that will not disappear anytime soon.

Reply on news.ycombinator.com