4 ms·

> Great engineers understand computers all the way from the silicon up through the different layers and protocols and systems. I find this a bit limiting, cert

> Great engineers understand computers all the way from the silicon up through the different layers and protocols and systems. I find this a bit limiting, certainly they should think across multiple layers but some of those layers exist beyond the systems.

pm90 8y ago
What is it limiting? What are you referring to as being existing beyond the systems? It was probably not made clear but he seems to be talking about systems engineering in particular.
- itronitron 8y ago
  Specifically, I am referring to the layers that describe how humans understand and use systems, cognitive psychology, neuroscience, anthropology, etc.
jsolson 8y ago
It's challenging to think about how things will scale beyond out immediate stellar volume, though. We have so little high quality data. Or did you think "systems" ended at some smaller scale? ;)
bleair 8y ago
As a people style thing I’ve encountered two broad types of engineers - the intuitive types, and the detail types. Neither type is wrong but it’s a different set of desires and interests. The detail type wants to ponder every corner case and every possible use (that the specific engineer cares about). The intuitive type can find this infuriating. They’d rather just build it and learn as they go. They have aesthetic tastes and feelings about different layers and they just go with their gut. I’ve seen both types be very effective. An intuitive type with good taste Will just have a sense of what to build and roughly why, but with many specifics left open. A detail type who is good can get to the neatest parts of a problem(maybe even rephrase the problem a bit differently) and solve it well, so well that it builds a foundation that everything else fits into easilt and with less grief. I think for both types a key aspect is being curious about the right things. Everyone has a different list of things they find interesting and other things they find to be grunt work and/or limiting as you said. Being aware of your own list of these is useful. Adding things to the list that the industry will hire you for could be called career management
- therein 8y ago
  Very good comment. It is certainly important to acknowledge that both can be effective and that the generalist type (and I use that term loosely) can be good for setting up a solid foundation/skeleton for others to build upon.
- nickthemagicman 8y ago
  One downside about detail types is often they'll plan with alot of detail however business is complex and changes rapidly so the problem may be very different down the road. "The best laid plans of mice and men".
- cbzoiav 8y ago
  I think I fit both of those. When I start working with something I just want to throw something together and get it working learning as i go. I believe you never fully understand what you need to build until you've tried it. But then I like to step back, read up on the underlying components and rebuild from scratch making sure i understand every possible flow.
crdoconnor 8y ago
The leakier the abstractions across layers, the more necessary it is and vice versa. As abstractions have improved and become less leaky over over time, the necessity has decreased. Older programmers will thus tend to feel this much more strongly than younger programmers. I think it used to be very true, it is less true than it was and it is becoming less true every day - with the exception of environments where foundational technology is engineered shoddily.
rcfox 8y ago
The system is the sum of the parts. Once, while investigating the cause of occasional bursts of static in audio, I eventually narrowed it down to misconfigured pull-down resistors on the ADC data lines. (Okay, not quite silicon.) EEC memory, a not uncommon upgrade for servers, guards against data corruptions due to thermal noise (a silicon-level concern), among other things. Okay, it's rare that the lowest levels will affect most projects, but without a little bit of understanding, some bugs can be impossible to even fathom.
whack 8y ago
I've worked as both a hardware & software engineer. I've generally found that people who make statements like the above, don't really have proficiency across all the layers from silicon to code. Heck, there are probably a few layers that they aren't even aware exist. And yet, despite this "gaping" hole in their knowledge, it barely hinders their productivity at all. Software, and life in general, is an exercise in abstraction. How do you effectively use abstractions that others have used, without knowing how they really work. How do you figure out which sub-abstractions and intricacies you can safely overlook, because they aren't relevant to your current priorities. And how do you shortlist the ones that you do have to care about, because they have a big impact on your project's success. These are the key skills that effective engineers possess. Trying to avoid the above problems by brute-force learning everything, is going to get you stuck in a quagmire.
- acpetrov 8y ago
  Tricky part is when one of your underlying systems doesn't quite behave as you thought. Once you figure out the problem (which could take a while since you won't expect it to be there) you get a sense of how much complexity you're building on top of

pm90 8y ago

What is it limiting? What are you referring to as being existing beyond the systems? It was probably not made clear but he seems to be talking about systems engineering in particular.

itronitron 8y ago
Specifically, I am referring to the layers that describe how humans understand and use systems, cognitive psychology, neuroscience, anthropology, etc.

jsolson 8y ago

It's challenging to think about how things will scale beyond out immediate stellar volume, though. We have so little high quality data. Or did you think "systems" ended at some smaller scale? ;)

bleair 8y ago

As a people style thing I’ve encountered two broad types of engineers - the intuitive types, and the detail types. Neither type is wrong but it’s a different set of desires and interests. The detail type wants to ponder every corner case and every possible use (that the specific engineer cares about). The intuitive type can find this infuriating. They’d rather just build it and learn as they go. They have aesthetic tastes and feelings about different layers and they just go with their gut. I’ve seen both types be very effective. An intuitive type with good taste Will just have a sense of what to build and roughly why, but with many specifics left open. A detail type who is good can get to the neatest parts of a problem(maybe even rephrase the problem a bit differently) and solve it well, so well that it builds a foundation that everything else fits into easilt and with less grief. I think for both types a key aspect is being curious about the right things. Everyone has a different list of things they find interesting and other things they find to be grunt work and/or limiting as you said. Being aware of your own list of these is useful. Adding things to the list that the industry will hire you for could be called career management

therein 8y ago
Very good comment. It is certainly important to acknowledge that both can be effective and that the generalist type (and I use that term loosely) can be good for setting up a solid foundation/skeleton for others to build upon.
nickthemagicman 8y ago
One downside about detail types is often they'll plan with alot of detail however business is complex and changes rapidly so the problem may be very different down the road. "The best laid plans of mice and men".
cbzoiav 8y ago
I think I fit both of those. When I start working with something I just want to throw something together and get it working learning as i go. I believe you never fully understand what you need to build until you've tried it. But then I like to step back, read up on the underlying components and rebuild from scratch making sure i understand every possible flow.

crdoconnor 8y ago

The leakier the abstractions across layers, the more necessary it is and vice versa. As abstractions have improved and become less leaky over over time, the necessity has decreased. Older programmers will thus tend to feel this much more strongly than younger programmers. I think it used to be very true, it is less true than it was and it is becoming less true every day - with the exception of environments where foundational technology is engineered shoddily.

rcfox 8y ago

The system is the sum of the parts. Once, while investigating the cause of occasional bursts of static in audio, I eventually narrowed it down to misconfigured pull-down resistors on the ADC data lines. (Okay, not quite silicon.) EEC memory, a not uncommon upgrade for servers, guards against data corruptions due to thermal noise (a silicon-level concern), among other things. Okay, it's rare that the lowest levels will affect most projects, but without a little bit of understanding, some bugs can be impossible to even fathom.

whack 8y ago

I've worked as both a hardware & software engineer. I've generally found that people who make statements like the above, don't really have proficiency across all the layers from silicon to code. Heck, there are probably a few layers that they aren't even aware exist. And yet, despite this "gaping" hole in their knowledge, it barely hinders their productivity at all. Software, and life in general, is an exercise in abstraction. How do you effectively use abstractions that others have used, without knowing how they really work. How do you figure out which sub-abstractions and intricacies you can safely overlook, because they aren't relevant to your current priorities. And how do you shortlist the ones that you do have to care about, because they have a big impact on your project's success. These are the key skills that effective engineers possess. Trying to avoid the above problems by brute-force learning everything, is going to get you stuck in a quagmire.

acpetrov 8y ago
Tricky part is when one of your underlying systems doesn't quite behave as you thought. Once you figure out the problem (which could take a while since you won't expect it to be there) you get a sense of how much complexity you're building on top of