When I interviewed college students for co-op jobs when I worked as a Network Administrator I always questioned them about their knowledge of the OSI Reference model. Not one of them had any idea about what I was talking about. Harkening back to my undergraduate college days, I was in the same boat. In 1988 I graduated with a BS in electrical engineering. Looking back in those days I was filled with theory, but lacked the 50 foot view that I later developed when I pursued a Masters Degree in IT Management and by my independent studies.
The OSI Reference model is always something I learned to depend on to get me "out of the forest". As a project manager, I was able to stop a project because the vendor was going to use a protocol that was incompatible with our phone system. So many vendors feel that when questioned they need to give a quick answer. It's an ego thing. I would rather have a well thought out answer than a quick wrong one. That's how teams get stuck down a rabbit hole. I picked up a book recently called Business Dynamics Systems Thinking and Modeling for a Complex World by John D Sterman. It's one of those books that can help IT folks "get out of the forest" and into the real productive world.
You're naming the distinction I didn't make explicit enough: the OSI model only becomes systems thinking when it's wielded as a sovereignty tool—boundary enforcement, failure anticipation, governance fluency. You used it to veto a protocol. That's recognition, not recall. Most engineers know the layers but never make that leap.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When I interviewed college students for co-op jobs when I worked as a Network Administrator I always questioned them about their knowledge of the OSI Reference model. Not one of them had any idea about what I was talking about. Harkening back to my undergraduate college days, I was in the same boat. In 1988 I graduated with a BS in electrical engineering. Looking back in those days I was filled with theory, but lacked the 50 foot view that I later developed when I pursued a Masters Degree in IT Management and by my independent studies.
The OSI Reference model is always something I learned to depend on to get me "out of the forest". As a project manager, I was able to stop a project because the vendor was going to use a protocol that was incompatible with our phone system. So many vendors feel that when questioned they need to give a quick answer. It's an ego thing. I would rather have a well thought out answer than a quick wrong one. That's how teams get stuck down a rabbit hole. I picked up a book recently called Business Dynamics Systems Thinking and Modeling for a Complex World by John D Sterman. It's one of those books that can help IT folks "get out of the forest" and into the real productive world.
You're naming the distinction I didn't make explicit enough: the OSI model only becomes systems thinking when it's wielded as a sovereignty tool—boundary enforcement, failure anticipation, governance fluency. You used it to veto a protocol. That's recognition, not recall. Most engineers know the layers but never make that leap.