It's always good to have a target in sight, but building a physical product with no experience will be a long, expensive journey.
I make physical and digital products as a consultant, the first thing I tell entrepreneurs is get to your first prototype. Not even an MVP, just something functional with the core features. Some times these are partial prototypes that work out various sub-systems. In this case, the actuation mechanisms, the heating elements with power, digital / physical controls, etc.
After that, the real work begins. You need to get to a complete working prototype. The other thing I like to say is just because someone else has made it, or something similar, doesn't mean I know how to make it. It just means it's technically feasible.
If you start looking at the parts of the toaster, you need to electrical engineering, mechanical engineering, material science, embedded software engineering, probably some industrial design and user experience design if you get that far. Even user research if you want to better understand the user and market.
Once you get to a first iteration, and typically before, you need to engage UL and FCC, usually through third parties to start testing for certifications and engineering refinement. You also need to start engaging contract manufacturers to understand how to work within limitations of their capabilities and your design.
A toaster may seem simple, but I assure it is not.
Then couple all of this with legal considerations as mentioned in other comments and whether or not it's even a practical business model. This is quite a large endeavor.
I would disagree that example is a slippery slope, but more of a leap across a vast canyon.
Going from providing information and requesting an action, to making an automated decision and action, is much more difficult as you pointed out. Therefore I'd be very surprised to see this actually occur.
Are you being specific about the word darken? Because LCDs are design to either allow or block light. So technically an LCD can "darken" incoming light. But I think the point of inconsistent lighting from the environment would be the biggest challenge.
Okay, I think this reply helps frame your stance much better. You are not necessarily proposing no C ever, but saying at least start a new project with a C++ compiler / IDE and if there are reasons to use C code or rules like "don't use dynamic memory allocation", when there is a substantial reason, then that is acceptable
On Arduino, from my experience, it is easy to run into memory constraints, especially when using dynamically allocated memory like strings. And I'm taking about both the flash memory for code and the ram for data, stack, and heap.
I don't think C is always a win, but to say to never use for new projects seems overly biased. Why is your opinion about C so strong? I am curious.
An 8-bit microcontroller where memory is constrained and all the vendor libraries are written in C, is a good example.
Your 32-bit ARM M3/M4 cores are probably crossing that line where the memory cost of using C++ is worth it, but I would say there are still real world reasons to use C.
Though I would love to see more microcontroller vendors (or any) support C++ or Rust as part of they HAL libraries, but I think you will still find C to be perfectly viable for the low cost microcontroller application.
I find your comment very similar in tone as the article: someone who is a interface designer that has had bad experiences with UX designers.
I think this is unfortunate, because I think UX design just a definition of the process that product (digital or physical) design was already doing, and now there is a common (though still evolving) language to be able to communicate the challenges of the full product design lifecycle.
To me UX is the superset for user centered design and User Interface design is a subset of it. They are both important. UX is not UI because they are not comparisons, but parts of the same thing.
From my internet researching a while ago the main difference, and why MLMs are legal, is that an MLM sells a product, whereas a pyramid scheme sells people. That is, you can make money solely by acquiring more people who pay to be apart of it, in a pyramid scheme.
I'm still not sure how I feel about MLMs. If it's actually a good product maybe it's not a bad thing, but when it is not, that's where it seems to get sketchy.
I think it really depends on what you want to do. If you want to work with physical systems, computation, or data-science, then I think engineering physics is a good path.
Where I went to college, all engineering physics majors concentrated (which is essentially a minor) in one of the other engineering disciplines (mechanical, electrical, civil, computer science, etc).
If you want to work on digital only products that don't utilize what you learn with a engineering physics degree, then you may want to consider another degree.
I can't speak directly about a physics only degree, since I did engineering physics, where I took all of the same core classes as engineering students.
Motivation, experience wherever you can get it, and knowing people / networking, will get you pretty far, so I would also say, take the path that's interests you the most. Also, physics is hard.
I have a degree in Engineering Physics where I concentrated in Electrical Engineering. I also minored in Industrial Design. I currently work at a product design firm as an "Embedded Systems Engineer", where I primarily design and write software for embedded microcontrollers and microprocessors and couple that with user experience design.
I have been able to utilize my understanding of physics to work on things like designing sensors into products that require real world math (motion, position, motor control, etc), though not as extensive as it could be if it were academic research. And have used my circuits foundation to understand how to get answers in the realm of embedded micros.
The thing I emphasize the most though, is understand where you want to have an expertise and make it happen, work on it. Mine is embedded software with a user focused design process.
Fresh out of college, your degree is not going to separate you unless it's coupled with experience from internships, school projects, or personal projects.
My opinion is that a degree in engineering provides foundation, but real world experience is where you grow and learn for your career.
Side note: You mentioned "other than learning code", I think that is a valid option to supplement this degree. I started writing code in eighth grade, so it was something I was already doing and interested in. I never wanted to be a plain ol' software developer, so this path was good for me.
TL;DR Went to school for Engineering Physics, I am happy with my career path, but took it upon myself to find a way to provide value beyond the name of my degree.
Unfortunately this comment is conflating two ideas.
Nothing in this article conflicts with the idea that a UX designer knowing how to implement their designs in code would be a benefit.
I don't see a problem with the author (and others like myself) wanting the tools to be more capable.
Have you developed a design system? Do you understand the context of this domain? I don't ask this to be rude, but the issues that the author mention are some of the key problems with the state of being able to maintain design systems.
It's more about the ability to efficiently generate and document the design intent and iterate on the design. This then needs communicated to the full team, whether that's stakeholders or the team implementing the design.
I think the authors suggestions are very good and valid.
Depending on the application, I'll use a Finite State Machine pattern, but if I need something more complex I'll use QM QP/C (which is uses a hierarchical state machine pattern).
So it's good to see others using Quantum Leaps RTOS. It take a little bit to set up the environment and understand some of the bounds, but I really enjoying using their QM Modeling tool[1], I would recommend it. I would mainly use it for the logic and abstract out the code in separate files, so that you are not maintaining code in the GUI tool.
> Software is so complex that nobody really understands it.
Unless this statement is trying to imply something deeper than what it states, I would disagree.
I work with embedded systems and connected devices. To me it's not a problem of complexity, but a problem of not having a strong standard of practices on both the device side and the facility side.
Have sensitive data on your network? Separate it from the rest of the network, or don't put devices on the network that don't meet your security needs.
Is running software/application in the Linux environment deem it a derivative work? Does Honeywell have to adhere to a GPL if they aren't modifying the Linux kernel?
It's not clear to me that they would need to follow GPL.
Also I'm making the assumption it is for profit since they started off with "I'm wanting to start a business"