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 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 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.
Straight up guys, this feels like the next great social network. Think technical chat roulette, but the people have stored their qualifications and interests so an algorithm can choose who to connect you to (assuming they are logged in to their office hours).
1 on 1 conversations or mentoring is the absolute best. Last year, I taught a guy a little bit of EE in exchange for him looking at the Java I was teaching myself and adding comments, but it was all on IRC. I have to admit, I really like the idea of doing this on Skype.
Does anyone else have major lightbulbs coming on at a really rapid clip because of this post?
If you just have a proposal, I think it is going to be tough to attract the right talent. I am not necessarily a hacker (or maybe I am, who freaking knows), but I am taking that role on so I can make the first versions of my product. If I can show some traction, I know I won't be wasting anyone's time with my business. Furthermore, the first version doesn't have to be pretty, it just has to be good enough to get by.
Excellent point. You could toss in assembly as yet another choice for the very highly constrained environment (very cheap microcontrollers, although many now have abstractions so you don't actually have to code in assembly directly, it is sometimes necessary).