This is a great response. I would add that this is how any larger project gets evaluated and prioritized. In smaller companies, especially startups, I have seen the friction show up when the company is too small to have any staff dedicated to working architecture and engineering facing engineering systems, but big enough that their past choices are creating friction. At that unique point in time, it's really an organizational issue more than anything.
> I have seen the friction show up when the company is too small to have any staff dedicated to working architecture and engineering facing engineering systems, but big enough that their past choices are creating friction.
It's funny you say that. My career hasn't been as wide and varied as many. My roles have been across wildly different industries, but I only have one person's life to live and my average tenure has been around 5 years. I've had a lot of time to reflect on these sorts of issues in depth, but not to see how they apply across as many situations.
That _exactly_ describes the organizations I had in mind when I was writing that. I have no extra useful insight to add or anything, just that you've definitely given me something to chew on there.
I agree with this. I want to add a product perspective here too. If your product partner routinely tries to understand your suggestions and translate them into the things that matter to themselves and the broader organization, that's a good partner.
And on the subject of things that are good to learn early in your career, everyone should know that every business is barely good enough for what it is. If it was materially better at something else that mattered, for example to its market or its economics, it would be a different business. For profit businesses are pretty effective equilibrium finding entities. I used to get really frustrated that people didn't care about improving things that I wanted to improve, until I realized that in most instances those things wouldn't really change any outcome in the business. In the cases where it would really change the business outcome, I realized the company couldn't prioritize effectively.
This is one of the worst attempts to handle a corporate dispute that I have ever seen. Forget all of the he said he said arguments for a second and see what a random person who decided to use WordPress will see.
If Automatic gets mad at the company I use to host this site, they will randomly start holding my site hostage by deactivating services. No host is safe. I probably shouldn't use WordPress.
I don't care who is wrong or right here. This is peak "cutting off your nose to spite your face" behavior.
I wouldn't ask HN. I would go ask consumers and businesses to find out who has the problem. Then I would go with whichever group actually has the problem. If neither of them have the problem, then I wouldn't launch for either one.
I would like to point out that systems that control physical equipment frequently fall into the domain of electrical engineering as much as they do software.
I write code that directly controls physical equipment. I work specifically for the Software Development department and we are the only people who have control & responsibility for software. While the electronic aspect of the systems are controlled by our EEs, Software has complete responsibility for the code.
I think this is a mis characterization. Mechanical engineering is a much older, much more mature field than computer science/software engineering. As a field of engineering study matures, many of the solutions to possible problems become commonplace, or at least they become trivial. New problems to solve are less and less frequently actually new, but rather just novel deviations from a commonly solved type of problem. However, capping the well is a completely new type of problem. It is one that has not been solved so many times that accounting for all of the variables is easy. Think about that next time before you criticize other disciplines.
