From my lived experience in Helpdesk and DevOps before I fully jumped into programming, having the OSI Model and troubleshooting as a background has dramatically improved my learning and retention of programming concepts.
On the model, understanding it allows you to abstract and understand where your code or portion of your program is operating, and if you have to think about things differently depending on how deep in the model you are. Some frameworks do a lot of the lower-level thinking for you (Laravel, React, Vue, etc), but understanding what is going on will save you headaches on bugs later.
Layers 1-4 are often going to be back-end development, wheras 5 on will usually fall underneath front-end development. The design choices you make for each level might look like (and if my examples are wrong, let me know and offer what you would think is a development use case at whichever level):
1) Physical:
Most everything has been solved at this level. These are the building blocks we don't usually have to play with to make things work. If you are working on things at this level, my understanding would indicate you are working on some sort of networking hardware or some other physical system to inform the data link (like signal processing and logic), but not to tell it where to go just yet.
2) Data Link:
At this level, this is you setting up the infrastructure and traffic-lights (or 4-way stops, or roundabouts, etc) as well as cameras to check for accidents (error checking/handling transport). At this level, you are dealing with packets and flow of them, so any of the work you're doing here is more often than not still backend development.
3) Network:
If the first two layers are the city level infrastructure, Layer 3 is the highway that connects the cities together. At this level, this is where you are dealing with more ip handling and routing, hosting (everyone has to have an address), and more. This level is the playground of most networking developers and is still very much a backend part of the stack. Not that you cannot make front-end decisions at this level, but most I have come across do not.
4) Transport:
Layer 4 deals with logistics and reliable transport. This is where you would be messing with sockets and multiplexing, and complex routing to carry larger loads of data. Again as with the previous layers, this is a back-end part of the stack, and unless you really like rolling your own solutions, there are so many frameworks and resources out there to achieve a good portion of this development work for you.
5) Session:
This layer is now where the front-end and back-end get a little muddy. At layer 5, you are starting to deal with a user of some kind, and measuring and reacting to their inputs/outputs accordingly. Online video is beholden to this layer for making sure that audio and video match. It's the equivalent of a warehouse or shipping center, where all of these separate objects are coming from different places, and need to be sent on to their destination as complete as possible. Javascript and XML would make sense to me at this level, as they are performing the sorting tasks, but there could be better examples. Mostly back-end, but ties to the front most of the time in my current experience.
6) Presentation:
This layer is where you are almost showing the user what the thing looks like, but it is still relaying and handling the logic that doesn't need to be seen by the end user. This is the storefront that the packages come to, or the mailroom/mailbox for your place of residence. You know that things show up there, but how it gets there is not front-of-mind. PHP and similar languages would fall into this layer for me, as they deal with the heavy lifting of whatever you do on the front.
7) Application:
This is where you get to do any fancy visual stuff. The protocols for this layer are still back-end heavy, but to me, this is where there is more overlap in the model for the work you would be doing here. Understanding what is happening on the backend is useful to know if your work on the front is feasible, or if it provides problems deeper than you realized. Knowing your stack is important to make sure that you are not missing things or opening yourself to future vulnerabilities. At this layer, you're dealing with UI/UX decisions, and the frameworks/languages/build tools that come with that.
And my favorite, and most overlooked layer
8) People (The space between chair and keyboard):
The human layer is the most fickle, and the one that will bring you the most pain. Programing at this level is more of a test of your communications skills, project management, and design ability. By 'design integrity', I mean that you can take an issue and abstract it into the business logic needed to solve for the issue at hand and NOT allow someone outside of the process to influence the design. Know your tools, their limits, and don't break your tools because someone who doesn't use them thinks that they are better equipped than you to wield them.
Hopefully this made sense and helps. If not, let me know how else I could improve on how I approach this :)
Creative, Curious Maker, I have 10 years in Tech, and I am a Software Developer at a mid-sized enterprise. Hardworking and collaborative, likes to help others. Hit me up!
Awesome! Thanks so much for posting all the details here. This is great stuff, I actually have an IT background ass well, so it's nice to know I'm not alone, making that transition.
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.
From my lived experience in Helpdesk and DevOps before I fully jumped into programming, having the OSI Model and troubleshooting as a background has dramatically improved my learning and retention of programming concepts.
On the model, understanding it allows you to abstract and understand where your code or portion of your program is operating, and if you have to think about things differently depending on how deep in the model you are. Some frameworks do a lot of the lower-level thinking for you (Laravel, React, Vue, etc), but understanding what is going on will save you headaches on bugs later.
Layers 1-4 are often going to be back-end development, wheras 5 on will usually fall underneath front-end development. The design choices you make for each level might look like (and if my examples are wrong, let me know and offer what you would think is a development use case at whichever level):
1) Physical:
Most everything has been solved at this level. These are the building blocks we don't usually have to play with to make things work. If you are working on things at this level, my understanding would indicate you are working on some sort of networking hardware or some other physical system to inform the data link (like signal processing and logic), but not to tell it where to go just yet.
2) Data Link:
At this level, this is you setting up the infrastructure and traffic-lights (or 4-way stops, or roundabouts, etc) as well as cameras to check for accidents (error checking/handling transport). At this level, you are dealing with packets and flow of them, so any of the work you're doing here is more often than not still backend development.
3) Network:
If the first two layers are the city level infrastructure, Layer 3 is the highway that connects the cities together. At this level, this is where you are dealing with more ip handling and routing, hosting (everyone has to have an address), and more. This level is the playground of most networking developers and is still very much a backend part of the stack. Not that you cannot make front-end decisions at this level, but most I have come across do not.
4) Transport:
Layer 4 deals with logistics and reliable transport. This is where you would be messing with sockets and multiplexing, and complex routing to carry larger loads of data. Again as with the previous layers, this is a back-end part of the stack, and unless you really like rolling your own solutions, there are so many frameworks and resources out there to achieve a good portion of this development work for you.
5) Session:
This layer is now where the front-end and back-end get a little muddy. At layer 5, you are starting to deal with a user of some kind, and measuring and reacting to their inputs/outputs accordingly. Online video is beholden to this layer for making sure that audio and video match. It's the equivalent of a warehouse or shipping center, where all of these separate objects are coming from different places, and need to be sent on to their destination as complete as possible. Javascript and XML would make sense to me at this level, as they are performing the sorting tasks, but there could be better examples. Mostly back-end, but ties to the front most of the time in my current experience.
6) Presentation:
This layer is where you are almost showing the user what the thing looks like, but it is still relaying and handling the logic that doesn't need to be seen by the end user. This is the storefront that the packages come to, or the mailroom/mailbox for your place of residence. You know that things show up there, but how it gets there is not front-of-mind. PHP and similar languages would fall into this layer for me, as they deal with the heavy lifting of whatever you do on the front.
7) Application:
This is where you get to do any fancy visual stuff. The protocols for this layer are still back-end heavy, but to me, this is where there is more overlap in the model for the work you would be doing here. Understanding what is happening on the backend is useful to know if your work on the front is feasible, or if it provides problems deeper than you realized. Knowing your stack is important to make sure that you are not missing things or opening yourself to future vulnerabilities. At this layer, you're dealing with UI/UX decisions, and the frameworks/languages/build tools that come with that.
And my favorite, and most overlooked layer
8) People (The space between chair and keyboard):
The human layer is the most fickle, and the one that will bring you the most pain. Programing at this level is more of a test of your communications skills, project management, and design ability. By 'design integrity', I mean that you can take an issue and abstract it into the business logic needed to solve for the issue at hand and NOT allow someone outside of the process to influence the design. Know your tools, their limits, and don't break your tools because someone who doesn't use them thinks that they are better equipped than you to wield them.
Hopefully this made sense and helps. If not, let me know how else I could improve on how I approach this :)
Awesome! Thanks so much for posting all the details here. This is great stuff, I actually have an IT background ass well, so it's nice to know I'm not alone, making that transition.