|
Even though there isn't a formal theory, there definitely is a big difference between a person capable of doing good system design and one who isn't. I don't think all people are capable of becoming a systems designer or architect. It is not always required for projects, but when it is necessary it can make a great difference, putting a project on the right track from the beginning and keeping it on track, making sure it all becomes something good in the end. I've done it enough to know that I couldn't do it while keeping my IC-type role as well. For me, personally, I approach systems design in a sort of breadth first search for a solution to the entire problem space, whilst deep-diving into particular areas where I am less certain. For other parts my experience lets me brush over details quite quickly. However, that is quite different from an IC-type role, where you'll typically run into a multitude of practical engineering issues that can be frustrating and take a lot of time. Tool issues, cloud issues, bug hunting, smoking out every little detail, write unit tests, review others code, etc. That would completely throw your mental cycles in the wrong bucket. I don't think you should do system design without having plenty of experience from IC-type roles though. You have to have understood so many different aspects; capabilities of the people at hand, the organization at large, tools, frameworks, technologies, etc, and be very, very willing to communicate the picture over and over again and take in feedback as the project progresses. It's technical leadership at one of the hardest levels. But realise at the same time that even software development itself doesn't have anything resembling a universal theory, common processes or frameworks. It's all changing, being reinvented, and rediscovered on a continuous basis. It is equally true that many things even in medicine or construction aren't based on any solid science. |
Yeah? Prove it. You can't. That's the big problem here. The only thing you can give me at best is some vague metric on some anecdotal experience. We don't even have data on this. Replace "system designers" with ICs who have the same breadth of IC experience who produces the better design? What does "better" even mean?
My personal opinion on Systems design is that it's pretty easy if you got the "IC" part down. It is largely just arrows and boxes.
>I've done it enough to know that I couldn't do it while keeping my IC-type role as well. For me, personally, I approach systems design in a sort of breadth first search for a solution to the entire problem space, whilst deep-diving into particular areas where I am less certain. For other parts my experience lets me brush over details quite quickly.
I think of system design as something that is tediously hard. It's not something that requires a massive amount of skill. But it does take a lot of time to come up with a design. It's like building the Eiffel tower out of toothpicks. Anyone with the relevant domain knowledge (as opposed to design knowledge) can do it. So yeah it does make sense you can't be an IC at the same time.
>But realise at the same time that even software development itself doesn't have anything resembling a universal theory, common processes or frameworks. It's all changing, being reinvented, and rediscovered on a continuous basis.
This is the whole point. Anything referred to as "design" is largely an artistic endeavor. Arguably much of these frameworks have been changing in a manner that cannot be characterized as "improvement". Just endless horizontal progress and endless genetic drift because we can't know if one design is better than the other.
This is the same with system designers. The skill level is horizontally stacked because we literally can't prove shit.
>It is equally true that many things even in medicine or construction aren't based on any solid science.
Medicine is a highly quantitative endeavor. All medicines go through rigorous quantitative verification for efficacy. The same is definitely not done with system designers.