Hacker News Reader

Looking at the original article, it seems the author was working for a software company that was in denial about being a software company:

> The amount of customization by far exceeded the initial offering of the services, and had to be done within the constraints of each individual technology stack. > > This accumulated in hundreds of partially overlapping systems, wired together with brittle ad-hoc integrations.

They had a software solution and were officially spending zero dollars on software development. You can't beat that. Never mind the huge amounts of time they spent keeping it working. All of that money showed up in other places on the bottom line. Maybe a lot of it was IT, but a lot of the expense was probably people whose job title had nothing to do with technology spending hours doing repetitive and error-prone integration work with third-party systems, emailing around spreadsheets and CSV files, manually tracking down and fixing bad data, and answering the phone for confused customers. As soon as you start employing software developers to create a more efficient system, it looks like you're spending 100x more for software, on a trajectory to take a very, very long time to achieve parity with the existing system.

> Big solutions to the big problems. Exactly what consultancies sell.

The problem is most consultants are not good at what they do. It why the sales guys for the consulting company are not the devs. Most the time consultants come in for 3-6-12 months, cause some trouble and then just leave the mess to the company to address later. There are some good consultants but most are just people that couldn't work in house because they are not up to par for long term engagements of products that need to stand the test of time to add legitimate value.

> It's hard to quantify their revenue so they are treated as an expense not cost saving or revenue generating.

This depends on the business, most the time, unless you make software you are an expense. The company makes their money in different departments and making money is the name of the game. It's takes a different set of skills (albeit better/stronger, industry knowledge and communication skills) to be an in-house developer vs a contractor.

>The company makes their money in different departments and making money is the name of the game.

The challenge here is that under this model the different departments get credit for the revenue they generate. What their relationship is with the in-house dev team is very much something that one should be aware of if they choose to be in that situation. It's not too dissimilar a situation to every single 'change management' model that has executive commitment as the number one success factor.

I agree. It's a different animal that being just a developer at a consultancy. You are supporting other departments to become successful. If you are undeniably helpful people/departments/executives will know that. I personally do not care for credit at all for tasks accomplished. It's always the journey I find more rewarding. Give me my salary, benefits, opportunities to grow, etc... and Im good, but I know not everyone is like that, especially users on HN.

That's the thing unfortunately there exist places where the opportunities to grow are non-existent because not every executive realize what you are bringing. And their n+1 will hear about conflicting opinions and make their mind about that. You and people you helped may not have enough political power to save your ass.

That is true, there are always bad places to work at. But by and large Ive worked at more places that appreciate good ancillary work than oppose it. It's important to work efficiently and economically (which is the antithetical to consultancy), communicate well, (what are you doing, why its important and why it will help the company tomorrow) especially to non-technical people. It's good to be able to speak clearly to C-level individuals spending their annual budgets on "IT services" and to also speak well to the people implementing those services. Seeing the broad big picture, keeping it in focus and getting the job done to help the company is invaluable.

When I first got into manufacturing, I encountered this too, but I saw it as an opportunity. I was the sole (and first) developer when I came onboard, and within a few years, I had a team. A decade later, and the entire company depends on my team on a daily basis, because we've automated tasks and provided tools for every department. Not to mention that I've broken company records for salary increases on multiple occasions throughout my journey here. So, maybe it was a little more work for me to get them to "get it" with regards to software development, but I did it. That said, I do understand that not everyone wants to have to put in that extra work, but it does feel damn good if you do.

> That said, I do understand that not everyone wants to have to put in that extra work, but it does feel damn good if you do.

I do think this is valid, but feel I should add: that willingness needs to go both ways. You were willing to put in the extra work, and your employer was willing to "get it".

There exist organizations that will never "get it" despite the extra work, and these are the places others are talking about when they say "run away".

I experienced both variations of this earlier in my career. I was successful the first time, and tried to apply that success in a larger environment.

The lack of organizational willingness to "get it" in that second environment is what motivated me to move to a place where building software is the primary reason for existence. I do not intend to look back.

The lack of organisational willingness is usually a combination of managerial debt and veeps/senior managers whose annual bonus depends on keeping things as they are.

Managerial debt can happen anywhere, including tech firms. It's where you're dealing with people who don't understand what recent technology can do. Maybe they got it 10-50 years ago. Maybe they were very good at it 10-50 years ago. But today they're behind the curve and unwilling or unable to understand that a working modern solution is possible.

They may also be risk averse for perfectly rational reasons, in which case you need to sell damage management security promises and fall backs with any upgrades.

The bonus issue is a very real problem. If there's pushback from that level it's often because those people can see dollars moving from them to the newcomers. And they'll do almost anything they can to prevent that.

These are very difficult issues to deal with, because they're usually hidden behind spurious excuses and rationales and passive blocking actions.

I think it comes down to if the company views your job as a cost center or a profit center.

Software developers at software companies/tech companies generate profits, so they are treated as such.

Software developers at more "traditional" businesses (retail, industry, manufacturing, etc) are often seen as an expense and something that should be treated like any other expense - try to minimize it.

My company sells robots, not software, and treats us like royalty. Perhaps “tech companies” fall under the umbrella and I’m just misreading you?

Edit: I’m confused then: if robots have software therefore it’s a software company, then tons of companies are software companies. But so many of those products, the software is just a hidden detail that no customer ever thinks about or cares about. Where do you draw the line?

Robots require software to work, right? So you’re officially part of the revenue generation chain.

Yeah, it's about proximity to the core business. People usually don't join FAANG to be HR or lawyers, but developers. I'm sure it's the same at other places - why join a bank as a programmer, or a law firm as a designer? Go where you're valued.

Obviously you're a software company, you just happen to have to sell the platform for the software to run on as well.

(There is an interesting discussion to be had about where the boundary between "software" and "hardware" companies is, but an environment with a high level of wilful misreading isn't one of them)

A robotics company is still a software company. Unless there is a human standing at a bank of switches directly controlling the robot. I'm talking about non-tech companies. The start a inhouse devteam when they really needed a consultant.

"Sells robots with software on it" still counts. Here the software is part of the product, unlike a furniture store.

By your definition a company that sells refrigerators could be considered a software company.

There's a large class of products for which the software is essentially an after thought. And it shows.

Appliances are an obvious example. But also things like cameras to a large degree. Or auto infotainment systems until Apple and Google software was integrated. (Embedded is sort of a different category that is functionally essentially part of the hardware.)

Ok, but for the article example of a travel booking company, you could easily argue the booking experience is part of the product.

Not the same thing. Robots are literally programmed to perform a task. A travel booking agency? I don't give a shit if it's AI or 1000 gnomes making hotel reservations. In the former the software is part of the product, the later travel is the product.

Actually I might prefer the gnomes

The parent is likely referring to companies that needed a square space/Wordpress site and maybe a Shopify account but instead hires 3 scrum teams to build their e-commerce platform.

The software output at such a company is confused at best. Usually with some exec pitching digital transformation without definition. No one wants to deal with the tech team, pay and expectations suck, getting hardware can be a years long process, and eventually someone pulls the plug.

You mentioned pay, the pay at these places is terrible. I got an Engineering Manager offer for a company I worked with years and years ago, the top end of their budget was $90k. For the manager. Devs (there were five) were making $30-45k. At that level of pay you're simply not going to get good people. Even if you get one or two who are decent engineers, they're not sticking around when most of the team isn't that great. WLB is important but there are plenty of places paying $80-100k for mid-levels in LCOL/MCOL areas where a 40 hour week is the max.

Software company here means somewhere where the software is part of the product, not part of the facilities.

It easily gets tricky though.

By that definition google is not a tech company, their product is selling advertising space. Tech backend just enables that.

Or Netflix. Certainly not selling tech or software, they rent movies.

Both Google and Netflix have unique software products that make their main business functional. I've worked on internal projects and the difference in management attitude toward them and the real product is rather palpable.

Any company that builds physical products that require programming (either firmware or software), is a software company.

For most companies building the physical product is a loss leader, what they’re selling is their custom software.

I think we really need better terms. What is meant by software company in that whole discussion is actually two things (at least):

- companies for which software is the sold product (or its support, hosting...)

- companies selling a service or a product that requires inhouse made software

It could be argued that this second one could be split in two as the software may not be delivered directly to the client but the border is a bit blurry when it is a website/app platform like netflix.

Some hardware companies expect the software people to work around the under-specification of the hardware that has already been designed and sold.

Is your code somehow tied to revenue? Woot. If not, you're just overhead to the PHBs. No matter how much money you save, misery you prevent.

So generally, IT vs product development.

I have been on IT projects (internal development) tied to revenue. It was pretty sweet while it lasted.

This hasn’t been my experience, I prefer working for non software companies tbh

I was an in house dev and have friends that do it. Con is low pay. Pro is usually great WLB, as delays and confusion aren't up against a hard deadline.

The pay isn't really all that low when you factor in all the OT tech companies typically require. Also, the retirement packages are typically much better outside of the world of tech companies.

I think such companies will tend to be replaced by companies built around IT - because they can gain the benefits of software, of flexibility etc (compared with physical objects, anyway).

> Sometimes you'll find out a 100 year old furniture company only has a dev team because the grandson thought it was a good idea.

/r/oddlyspecific :)

Scene: Mid-city warehouse district. Me at job interview early 2000s.

Me: So what is it you do here. The job description says you are looking for a developer?

Them: Oh, we make and sell boxes.

Me: Like the cardboard boxes you get delivered?

Them: Yes, exactly!

Me: Okay, so where does software fit in that? Are you aware of development cycles? {Other interview questions I can't remember}

Them: Oh, we don't know the technical part too much. We want to automate some of it.

Me: ...

That's a job for a regular engineer.

I have been in the same boat. It wasn't 100 years old, and it wasn't a furniture company, but it ended exactly the way yardie described it :-) No one wants you there because they see you as a waste of money and a threat. A lesson to be learnt I guess.

They're well positioned to build whole new platforms.

Amazon does all software development in-house. However the founder was a programmer so perhaps that is an exception to the rule.