If you are a technologist/generalist, aiming for small companies is a good strategy. If you're not in SV even better, you may end up in a real grass roots business and a really interesting problem domain that is ostensibly Not Software.
I personally, cannot stand the software for software industry. You, me, we have all built such arbitrary bullshit machines that link together in a web of unnecessary business. We lambast redundant jobs and useless management, but a moment of reflection for our industry and just how much software we have built for entirely self-serving purposes. So many man hours spent on the ephemeral whims of software. Sorry for the cynicism.
Less cynically, I feel the smaller the company, self-funded, the more likely a generalist will thrive and the business domain will be real-world and impactful. If it's venture funded and can pivot to advertising, it probably will. If you move away from tech hubs the wages are lower, but you might find a more fulfilling role.
It’s hard to break in to, but industrial automation can be incredibly satisfying. The code itself is quite simple compared to ‘real’ software engineering, but you’re solving actual real physical problems in the real world, with tangible (and often lucrative) physical results. It’s extremely cross-disciplinary so if you like getting on the tools that’s always an option, it’s like the ultimate ‘full stack’ development role.
It's an incredibly messy space and the particulars are going to vary wildly based on the company. A company in a more regulated space may have the finances to standardize on Siemens or something similarly fancy, but smaller manufacturers may not have any standard at all and you'll be looking at a mix of Rockwell, Allen-Bradley, Honeywell and even more niche brands and PLCs. Many vendors have "proprietary" languages, but they're all going to be very basic stuff that is essentially Visual Basic, C, or JavaScript-ish. It's not going to be a formal software development environment like you're used to. In less regulated environments, a lot of the time you'll find that the PLC/automation component is being handled by the MAINTENANCE or FACILITIES people.
So for an example of a problem I'm facing, we have some Vacuum Furnaces. Essentially before you can turn titanium into a useful implant, you have to bake titanium at a temperature above its ignition point so that the molecules can loosen up enough and release the stresses that accumulate in the forging process. As part of this process, there's eight thermocouples of different sensitivities and at least three pressure/vacuum sensors all physically wired into a "chart recorder". The thermocouple "data" is literally a voltage reading, and the chart recorder is interpreting that and converting it into an integer and storing that in RAM. These devices are about 20 years old, and it can only hold about 24 hours of data, so you have to network it with a server that can store those readings in case you ever need to prove to someone that this step of your process was done right. It's not technically complex, but these devices aren't easy to interact with and often require physically connecting to them to make changes.
There's all sorts of possibilities for really meaningful integrations with other manufacturing systems, ERP systems, data analysis and visualization, and basically a million "low hanging fruit" problems in the space that simply don't get done because don't have enough people with any technical skill at all. Most companies I've worked for literally don't care about what the solution is, so you get a ton of leeway on architecting the solution.
IMO, the best part is that it feels like you're accomplishing something. Making a real impact. You can walk the floor and see the code you wrote building things. Doing things. You know the engineer who came to you with a problem, and you delivered a solution that makes his life easier. Not to make some abstract number go up for a quarterly report, but to actually make things that are useful.
not OP but I once took an entry-level role at a small museum exhibit fabricator as their "tech guy", and many people i worked with there (vendors / external co-fabs) were showing me PLC / ladder logic stuff
By hiring other people who actually know what they’re doing - product managers, marketers, designers, etc - and then, here’s the crucial part: listening to them. There are a whole set of people who are _not_ technologists, who do things that are _not_ building shiny widgets, and who have skills that are useful nonetheless and that we cannot trivially replicate just by thinking about it a lot.
As a side note, I find it interesting the way people will write explicitly about their job experience at companies like this, naming where they work, dropping anecdotes about the CEO, about colleagues.
To borrow John Cale's rephrasing of a proverb:
"Meet me on the staircase on the way down; we'll see if there's been a mistake".
I talk about where I have worked; I have in the past written about it. But I find it interesting how people don't seem to grasp that often you should change the names to protect the incompetent or guilty, and should probably avoid simply spilling out anecdotes that an LLM will thread together.
Don't get yourself a reputation for being indiscreet simply for a blog post.
This post seems to take the stance that we need to cultivate failure so that we can learn. We don’t need to cultivate failure, there’s plenty of failure to be had. I mean people need to be allowed to make their own mistakes but that’s not the same thing.
There’s a difference between cultivating failure and cultivating willingness to fail in the pursuit of success. Many people are too scared of failing (or of being perceived to have failed) to actually try anything that’s not 100% safe.
Sure all I’m saying is there’s a difference between saying that it’s hard to convince people of this good advice if they don’t have the benefit of experience and we shouldn’t force them to follow it if they don’t believe it, versus we shouldn’t try to give people this advice because it may deprive them of the opportunity to fail.
> We were downstream of the business model; our job was simply to wait and prepare for its eventual success.
Hard thing to learn and to stomach. The you are essentially a few nodes downstream from the decision makers who commissioned the software in the first place. They have some long-term view even if you can identify in the short-term that things won't be working out well long-term. Hard to reconcile that with a steady paycheck.
You can then get yourself into product decisions, to try to steer the direction a bit, working wirh sales, but that has all its own issues too (the article mentions "selling whatever we thought would entice the salespeople enticing the salespeople enticing the brands." at one workplace)
How does anyone find fulfillment when this is the long-term prospect at most companies for software?
... and after a while, you have a long-term view, are making the decisions, but there's someone a few nodes downstream who can identify some problems with your idea?
Get out from under the VC playbook and start asking yourself and the people around you what should exist. What is the world missing? Use AI as your cofounder as prototype with basic tech - html, css, js, sqlite. Gain traction. See the truth about the audience by doing your own customer service. Then when you find something with true traction, talk about scaling it. You will learn far more and do better.
> What is the world missing? Use AI as your cofounder as prototype with basic tech - html, css, js, sqlite.
As long as you don’t ask AI. It keeps giving the same bland startup ideas and I imagine the governance / regulatory evidence gathering market is going to be pretty crowded with startups.
Answering what should exist and what the world is missing requires a vision for what you want the world to become. The question where to go should come after answering where we are, before that one should ask where we came from, what were things like before? Then, how did we get where we are from where we came from.
There are no correct answers. It should probably be more of a subjective journey than we like to imagine.
Ultimately you get to decide what you want people to become. Even if you do it in ignorance.
To quote a wise man. If the revolution doesnt have singing and dancing im not comming.
> Answering what should exist and what the world is missing requires a vision for what you want the world to become.
Nonsense. All that's needed is asking around, and listen. You could literally throw the dice, go to random country X, and ask the 1st person you meet what would make their life better.
Maybe the gutter on their roof is leaking, and they need someone to fix it. If so, maybe there's more people with the same problem, and a gutter-fixer would make people happy.
Sure, if you have a 'grand vision' and (again, by asking around) find there's others sharing that vision, by all means go work on that. But to find something useful to work on, any 'vision' is really not required.
I was an engineer that build core tech. Saw the effort expand exponentially as they tried to be trendy with new tech. Went back to basics. Built https://www.dreamlist.com and https://santawho.com - never had so much fun as I do now and I can keep going without asking anyone for permission.
This is where I landed as well. If your company takes funding, then unless you're new and green, you should already know where it's heading. I cringe when I get contacted by recruiters touting their big funding rounds and valuations, as though it should mean something positive to me.
It also seems increasingly focused on b2b, which is probably representative of greater imbalances in the economy. What consumers can buy is becoming a slowing trickle down in itself.
The weird thing is that we learned this lesson in the dot com era, and then there was a reactionary shift to self-funding, and now we've forgotten; I guess that's just the nature of human generations.
The really odd, undelivered thing about LLMs is that if they are as productive as they seem, software people simply should not need VCs. Because you can self-fund a massive team of AI developers, you should be able to get your product ready for market in absolutely no time, and you should more or less be able to roll it out with nothing more than a tiny amount of seed capital and a suburban garage.
I think it's because technologists are easier to manage.
Product engineers, on the other hand, are actually quite ambiguous to evaluate. Many methodologies have been introduced, starting from Barry Boehm, but over time they gradually stop fitting, and there are many points that are hard to assess. It's essentially a matter of organizational management theory. The ideal of organizational management theory is that diversity comes together to create synergy, but conversely, such diversity means that decision-making within the organization slows down.
Technologists, by contrast, are very easy to observe in terms of speed or code quality. In fact, most people choose a career of learning technology and making money rather than founding a startup, and from that perspective, since "career" tends to be emphasized as an employee's career rather than a founder's career, isn't that why technologists are emphasized?
What companies value as a capability is ultimately an evaluation that can be measured. And product engineering, when you think about it, presupposes discussions with decision makers.
'Is it necessary to implement this feature?'
'Do customers actually need this feature?'
'Isn't the business model wrong?'
Most decision makers are people high up in the hierarchy, and friction with them is unavoidable. In other words, it crosses existing role boundaries, which means more frequent conflicts in organizational dynamics.
Whether that is ultimately a gain or a loss for the organization is something nobody can konw
I personally, cannot stand the software for software industry. You, me, we have all built such arbitrary bullshit machines that link together in a web of unnecessary business. We lambast redundant jobs and useless management, but a moment of reflection for our industry and just how much software we have built for entirely self-serving purposes. So many man hours spent on the ephemeral whims of software. Sorry for the cynicism.
Less cynically, I feel the smaller the company, self-funded, the more likely a generalist will thrive and the business domain will be real-world and impactful. If it's venture funded and can pivot to advertising, it probably will. If you move away from tech hubs the wages are lower, but you might find a more fulfilling role.
So for an example of a problem I'm facing, we have some Vacuum Furnaces. Essentially before you can turn titanium into a useful implant, you have to bake titanium at a temperature above its ignition point so that the molecules can loosen up enough and release the stresses that accumulate in the forging process. As part of this process, there's eight thermocouples of different sensitivities and at least three pressure/vacuum sensors all physically wired into a "chart recorder". The thermocouple "data" is literally a voltage reading, and the chart recorder is interpreting that and converting it into an integer and storing that in RAM. These devices are about 20 years old, and it can only hold about 24 hours of data, so you have to network it with a server that can store those readings in case you ever need to prove to someone that this step of your process was done right. It's not technically complex, but these devices aren't easy to interact with and often require physically connecting to them to make changes.
There's all sorts of possibilities for really meaningful integrations with other manufacturing systems, ERP systems, data analysis and visualization, and basically a million "low hanging fruit" problems in the space that simply don't get done because don't have enough people with any technical skill at all. Most companies I've worked for literally don't care about what the solution is, so you get a ton of leeway on architecting the solution.
IMO, the best part is that it feels like you're accomplishing something. Making a real impact. You can walk the floor and see the code you wrote building things. Doing things. You know the engineer who came to you with a problem, and you delivered a solution that makes his life easier. Not to make some abstract number go up for a quarterly report, but to actually make things that are useful.
By hiring other people who actually know what they’re doing - product managers, marketers, designers, etc - and then, here’s the crucial part: listening to them. There are a whole set of people who are _not_ technologists, who do things that are _not_ building shiny widgets, and who have skills that are useful nonetheless and that we cannot trivially replicate just by thinking about it a lot.
To borrow John Cale's rephrasing of a proverb:
"Meet me on the staircase on the way down; we'll see if there's been a mistake".
I talk about where I have worked; I have in the past written about it. But I find it interesting how people don't seem to grasp that often you should change the names to protect the incompetent or guilty, and should probably avoid simply spilling out anecdotes that an LLM will thread together.
Don't get yourself a reputation for being indiscreet simply for a blog post.
Hard thing to learn and to stomach. The you are essentially a few nodes downstream from the decision makers who commissioned the software in the first place. They have some long-term view even if you can identify in the short-term that things won't be working out well long-term. Hard to reconcile that with a steady paycheck.
You can then get yourself into product decisions, to try to steer the direction a bit, working wirh sales, but that has all its own issues too (the article mentions "selling whatever we thought would entice the salespeople enticing the salespeople enticing the brands." at one workplace)
How does anyone find fulfillment when this is the long-term prospect at most companies for software?
... and after a while, you have a long-term view, are making the decisions, but there's someone a few nodes downstream who can identify some problems with your idea?
As long as you don’t ask AI. It keeps giving the same bland startup ideas and I imagine the governance / regulatory evidence gathering market is going to be pretty crowded with startups.
There are no correct answers. It should probably be more of a subjective journey than we like to imagine.
Ultimately you get to decide what you want people to become. Even if you do it in ignorance.
To quote a wise man. If the revolution doesnt have singing and dancing im not comming.
Nonsense. All that's needed is asking around, and listen. You could literally throw the dice, go to random country X, and ask the 1st person you meet what would make their life better.
Maybe the gutter on their roof is leaking, and they need someone to fix it. If so, maybe there's more people with the same problem, and a gutter-fixer would make people happy.
Sure, if you have a 'grand vision' and (again, by asking around) find there's others sharing that vision, by all means go work on that. But to find something useful to work on, any 'vision' is really not required.
This is where I landed as well. If your company takes funding, then unless you're new and green, you should already know where it's heading. I cringe when I get contacted by recruiters touting their big funding rounds and valuations, as though it should mean something positive to me.
It also seems increasingly focused on b2b, which is probably representative of greater imbalances in the economy. What consumers can buy is becoming a slowing trickle down in itself.
The really odd, undelivered thing about LLMs is that if they are as productive as they seem, software people simply should not need VCs. Because you can self-fund a massive team of AI developers, you should be able to get your product ready for market in absolutely no time, and you should more or less be able to roll it out with nothing more than a tiny amount of seed capital and a suburban garage.
Product engineers, on the other hand, are actually quite ambiguous to evaluate. Many methodologies have been introduced, starting from Barry Boehm, but over time they gradually stop fitting, and there are many points that are hard to assess. It's essentially a matter of organizational management theory. The ideal of organizational management theory is that diversity comes together to create synergy, but conversely, such diversity means that decision-making within the organization slows down.
Technologists, by contrast, are very easy to observe in terms of speed or code quality. In fact, most people choose a career of learning technology and making money rather than founding a startup, and from that perspective, since "career" tends to be emphasized as an employee's career rather than a founder's career, isn't that why technologists are emphasized?
What companies value as a capability is ultimately an evaluation that can be measured. And product engineering, when you think about it, presupposes discussions with decision makers.
'Is it necessary to implement this feature?'
'Do customers actually need this feature?'
'Isn't the business model wrong?'
Most decision makers are people high up in the hierarchy, and friction with them is unavoidable. In other words, it crosses existing role boundaries, which means more frequent conflicts in organizational dynamics.
Whether that is ultimately a gain or a loss for the organization is something nobody can konw