Teaching coding from the Metal Up or from the Glass Back?
Sponsored By
Maria on my team and I have been pairing (working in code and stuff together) occasionally in order to improve our coding and tech skills. We all have gaps and it's a good idea to go over the "digital fundamentals" every once in a while to make sure you've got things straight. (Follow up post on this topic tomorrow.)
As we were whiteboarding and learning and alternating teaching each other (the best way to make sure you know a topic is to teach it to another person) I was getting the impression that, well, we weren't feeling each other's style.
Now, before we get started, yes, this is a "there's two kinds of people in this world" post. But this isn't age, background, or gender related from what I can tell. I just think folks are wired a certain way. Yes, this a post about generalities.
Here's the idea. Just like there are kinesthetic learners and auditory learners and people who learn by repetition, in the computer world I think that some folks learn from the metal up and some folks learn from the glass back.
Learning from Metal Up
Computer Science instruction starts from the metal, most often. The computer's silicon is the metal. You start there and move up. You learn about CPUs, registers, you may learn Assembly or C, then move your way up over the years to a higher level language like Python or Java. Only then will you think about Web APIs and JSON.
You don't learn anything about user interaction or user empathy. You don't learn about shipping updates or test driven development. You learn about algorithms and Turing. You build compilers and abstract syntax trees and frankly, you don't build anything useful from a human perspective. I wrote a file system driver in Minix. I created new languages and built parsers and lexers.
- When you type cnn.com and press enter, you can pretty much tell what happens from the address bar all the way down to electrons. AND YOU LOVE IT.
- You feel like you own the whole stack and you understand computers like your mechanic friends understand internal combustion engines.
- You'll open the hood of a car and look around before you drive it.
- You'll open up a decompiler and start poking around to learn.
- When you learn something new, you want to open it up and see what makes it tick. You want to see how it relates to what you already know.
- If you need to understand the implementation details then an abstraction is leaking.
- You know you will be successful because you can have a FEEL for the whole system from the computer science perspective.
Are you this person? Were you wired this way or did you learn it? If you teach this way AND it lines up with how your students learn, everyone will be successful.
Learning from the Glass Back
Learning to code instruction starts from the monitor, most often. Or even the user's eyeballs. What will they experience? Let's start with a web page and move deeper towards the backend from there.
You draw user interfaces and talk about user stories and what it looks like on the screen. You know the CPU is there and how it works but CPU internals don't light you up. If you wanted to learn more you know it's out there on YouTube or Wikipedia. But right now you want to build an application for PEOPLE an the nuts and bolts are less important.
- When this person types cnn.com and presses enter they know what to expect and the intermediate steps are an implementation detail.
- You feel like you own the whole experience and you understand people and what they want from the computer.
- You want to drive a car around a while and get a feel for it before you pop the hood.
- You'll open F12 tools and start poking around to learn.
- When you learn something new, you want to see examples of how it's used in the real world so you can build upon them.
- If you need to understand the implementation details then someone in another department didn't do their job.
- You know you will be successful because you can have a FEEL for the whole system from the user's perspective.
Are you this person? Were you wired this way or did you learn it? If you teach this way AND it lines up with how your students learn, everyone will be successful.
Conclusion
Everyone is different and everyone learns differently. When teaching folks to code you need to be aware of not only their goals, but also their learning style. Be ware of their classical learning style AND the way they think about computers and technology.
My personal internal bias sometimes has me asking "HOW DO YOU NOT WANT TO KNOW ABOUT THE TOASTER INTERNALS?!?!" But that not only doesn't ship the product, it minimizes the way that others learn and what their educational goals are.
I want to take apart the toaster. That's OK. But someone else is more interested in getting the toast to make a BLT. And that's OK.
* Stock photo by WOCInTech Chat used under CC
Sponsor: Big thanks to Telerik! They recently published a comprehensive whitepaper on The State of C#, discussing the history of C#, what’s new in C# 7 and whether C# is the top tech to know. Check it out!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
January 06, 2017 6:18
I learned from the metal up but that was purely a product of the times. I learned to program on a Commodore 64, where you could barely do anything interesting without going to assembly language and setting hardware registers. :-)
Carson
Glass back, thank you. I may have learned from the metal up, but I didn't get really interested until there were graphics and a user interface to play with. That's what hooked me.
I think I was a metal up learner at first then learned to become a glass back learner by necessity when I actually had to feed myself.
As a kid I enjoyed taking things apart to figure out how they worked. Nothing was safe from disassembly around me.
My first experience with HTML was trying to open up some saved web pages I had on a floppy disk. My old 468 had a ruined Windows install and I was only able to use DOS, so when I tried to open a web page all I found was markup. It didn't take me long to figure it out. I started making my own web pages by writing the markup in MS-DOS Editor, saving it to a floppy, then viewing the result the next day at school. Before long I was building entire web sites with knowledge gathered from viewing the sources of other sites I liked.
For a few years my knowledge of front-end development was garnered from a combination of "view source" and highlighting page contents to see how web developers used transparent GIFs to force they layouts they wanted.
Once I started building sites with purposes (e.g. I ran an online petition to bring back the TV show seaQuest), I quickly got into server side programming, primarily ASP. A few years of making some fairly interesting things, from a B2B web app for managing projects like Highrise to an online family cookbook with features not unlike Facebook and the now-defunct Tastebook, my dad approached me with an idea he had been working on for years.
As a veteran service manager in automotive dealers, he had tried to develop scheduled maintenance menus that were priced according to the vehicle's build, but failed because, as we later found, the software necessary to accomplish this was quite complicated. His Excel-voodoo just wasn't enough. I spent the better part of a year building a multi-user web app that auto dealers could use to present customers with the exact cost of the recommended maintenance their vehicle needed. Along the way I had to build UIs, authentication and authorization systems, logging, tools for manipulating relatively massive datasets (there are hundreds of millions of combinations of vehicle builds), lots of database work and SQL optimization, reporting tools, as well as manage the infrastructure it was all built on.
I didn't have time to poke around small pieces of code, rather I had to focus on the big picture. I once wrote a VIN validator that could bulk-decode over 100 VINs per second and was quite happy with myself, that is until I realized I still had to build the entire batch data import system it was a part of. I quickly realized I needed to start using pre-built components if I was going to get anything done.
I started with UI stuff, opting for pre-built ASP.NET components over building my own. They sucked, generated disgusting HTML and would often pollute the already bloated Viewstate to the point of obscenity, but they "worked" and I didn't have time to screw with it. I would find myself stuck on a problem, Google around until I found something that sort of worked, then cut and paste it and hoped for the best, often without knowing how it really worked. All because making a finished product was more important than the shiny turds it was made out of.
I wish I had more time to really dig into things and learn how they work, but for me, now, my priority is to get things done, knowledge of inner workings be damned.
Wow, what a wall of text.
As a kid I enjoyed taking things apart to figure out how they worked. Nothing was safe from disassembly around me.
My first experience with HTML was trying to open up some saved web pages I had on a floppy disk. My old 468 had a ruined Windows install and I was only able to use DOS, so when I tried to open a web page all I found was markup. It didn't take me long to figure it out. I started making my own web pages by writing the markup in MS-DOS Editor, saving it to a floppy, then viewing the result the next day at school. Before long I was building entire web sites with knowledge gathered from viewing the sources of other sites I liked.
For a few years my knowledge of front-end development was garnered from a combination of "view source" and highlighting page contents to see how web developers used transparent GIFs to force they layouts they wanted.
Once I started building sites with purposes (e.g. I ran an online petition to bring back the TV show seaQuest), I quickly got into server side programming, primarily ASP. A few years of making some fairly interesting things, from a B2B web app for managing projects like Highrise to an online family cookbook with features not unlike Facebook and the now-defunct Tastebook, my dad approached me with an idea he had been working on for years.
As a veteran service manager in automotive dealers, he had tried to develop scheduled maintenance menus that were priced according to the vehicle's build, but failed because, as we later found, the software necessary to accomplish this was quite complicated. His Excel-voodoo just wasn't enough. I spent the better part of a year building a multi-user web app that auto dealers could use to present customers with the exact cost of the recommended maintenance their vehicle needed. Along the way I had to build UIs, authentication and authorization systems, logging, tools for manipulating relatively massive datasets (there are hundreds of millions of combinations of vehicle builds), lots of database work and SQL optimization, reporting tools, as well as manage the infrastructure it was all built on.
I didn't have time to poke around small pieces of code, rather I had to focus on the big picture. I once wrote a VIN validator that could bulk-decode over 100 VINs per second and was quite happy with myself, that is until I realized I still had to build the entire batch data import system it was a part of. I quickly realized I needed to start using pre-built components if I was going to get anything done.
I started with UI stuff, opting for pre-built ASP.NET components over building my own. They sucked, generated disgusting HTML and would often pollute the already bloated Viewstate to the point of obscenity, but they "worked" and I didn't have time to screw with it. I would find myself stuck on a problem, Google around until I found something that sort of worked, then cut and paste it and hoped for the best, often without knowing how it really worked. All because making a finished product was more important than the shiny turds it was made out of.
I wish I had more time to really dig into things and learn how they work, but for me, now, my priority is to get things done, knowledge of inner workings be damned.
Wow, what a wall of text.
"and people who learn by repetition"...yes, like, pretty much all people.
Apart from that, nice. Your approach may even vary, over time, over area of expertise. I also like to think of islands of understanding, and then building relationships between them.
Apart from that, nice. Your approach may even vary, over time, over area of expertise. I also like to think of islands of understanding, and then building relationships between them.
I was taught metal up but if anything I think I'm a mixture of metal up and glass back. In other words I don't care about assembler or any of that low level stuff, I like to see the end result and then work back, but when I work back I want to do know the detail.
This post rings very true. It's not just a different way of learning, it's a different way of getting people interested.
I had computer science classes in high school and university as part of the curriculum, but not as my specialization. I never once considered a career in programming or software development in that time; it was just another class I had to take.
Some time later, I just wanted to build myself a website, because I had a friend on IRC who had their own personal website. So I learned HTML. Then I wanted to make it do cool things. So I fiddled with PHP and basic JS. Now, years later, I'm a polyglot software developer building awesome products, and I couldn't imagine myself doing anything else for a living.
The classes I had to take were from the metal up and I wasn't interested. I stumbled upon what's behind the glass and found my career.
I had computer science classes in high school and university as part of the curriculum, but not as my specialization. I never once considered a career in programming or software development in that time; it was just another class I had to take.
Some time later, I just wanted to build myself a website, because I had a friend on IRC who had their own personal website. So I learned HTML. Then I wanted to make it do cool things. So I fiddled with PHP and basic JS. Now, years later, I'm a polyglot software developer building awesome products, and I couldn't imagine myself doing anything else for a living.
The classes I had to take were from the metal up and I wasn't interested. I stumbled upon what's behind the glass and found my career.
I'm probably a metal up kind of guy. But there is something else, I've notice. I like to read the ENTIRE book on something before I even consider touching the keyboard. It seems most others prefer to skim through the first chapter, play around with it and then read the details as they realise they need them.
I am definitely a metal up guy. I've always liked disassembling things to understand how they work. I can and do learn the glass down way when I need, but it doesn't feel as satisfying. I am always trying to learn how thing work and I can almost hear a "click" in my brain when I get the inner workings of something and things get a lot easier and more intuitive to me after that.
Great post Scott. It'll change my approach when trying to teach something from now on. I kind of always had a good grasp of how to explain stuff and mainly got the job done, but this will make the process a lot smoother and faster when teaching people that don't think quite like me.
Great post Scott. It'll change my approach when trying to teach something from now on. I kind of always had a good grasp of how to explain stuff and mainly got the job done, but this will make the process a lot smoother and faster when teaching people that don't think quite like me.
Interesting article - one of those that puts a name to a concept that's already in your head, and formalizes it somewhat.
I'm definitely a metal up guy - having come from the dark ages of assembly language, acoustically coupled modems and punched tape - but try to use a glass back approach when dealing with clients.
I'm definitely a metal up guy - having come from the dark ages of assembly language, acoustically coupled modems and punched tape - but try to use a glass back approach when dealing with clients.
You only want to take the toaster apart? That's nothing Scott...
If you want a bit of light reading then I can recommend "The Toaster Project" by Thomas Thwaites - he decided to build his own toaster... but starting from crude oil and metal ores (quite literally from before "the metal up")!
If you want a bit of light reading then I can recommend "The Toaster Project" by Thomas Thwaites - he decided to build his own toaster... but starting from crude oil and metal ores (quite literally from before "the metal up")!
I learned "metal up"... because that was how you learned CS. I was comfortable there, but it was never my strong point. When I first got into UI stuff and how to make life easier for my customers, I was hooked. Now, that is my strong point.
I never really looked at it until today... I'm definitely a "glass back" person.
I never really looked at it until today... I'm definitely a "glass back" person.
"But this isn't age, background, or gender related from what I can tell."
Seems like a pretty strong gender split to me, judging from the comments, your post, and personal experience.
Seems like a pretty strong gender split to me, judging from the comments, your post, and personal experience.
Hi Scott,
I haven't heard about these two concepts before. They are brilliant, where did they come from? A very insightful post.
After reading this, I know that I'm a Glass Back guy. My toaster will add butter just after it's done - before the bread cools off. BLT thing is next.
I haven't heard about these two concepts before. They are brilliant, where did they come from? A very insightful post.
After reading this, I know that I'm a Glass Back guy. My toaster will add butter just after it's done - before the bread cools off. BLT thing is next.
24yrs: I learned on Angular, Express, Node, JS
34yrs: I learned on C#, .NET
44yrs: Shss! I learned on C, posix
54yrs: Haw! I learned APL, assembly
64yrs: That's nothing, I learned assembly, machine code and punch cards
74yrs: Beat ya all, I learned using Ones and Zeroes
84yrs: Nothing, nothing, nothing; It's so long ago we only could program using Ones
34yrs: I learned on C#, .NET
44yrs: Shss! I learned on C, posix
54yrs: Haw! I learned APL, assembly
64yrs: That's nothing, I learned assembly, machine code and punch cards
74yrs: Beat ya all, I learned using Ones and Zeroes
84yrs: Nothing, nothing, nothing; It's so long ago we only could program using Ones
Great article. I'm a definitely a 'metal up' person when it comes to working on my home projects. (Maybe that's why so few of them ever get completed.) But I have to be a 'glass back' person for my employer since as I work for a manufacturing company, the results are what they care for. The methods and reasons are of how the software is developed is of absolutely no concern to them. Just that it works and can be maintained in some minimum fashion.
I started out on Turbo C++, a little assembly, lisp, and Basic in a pre-internet world. So for a lot of things you hand to understand what was going on cause you didn't have instant access to a library to do the work for you.
When I got into web work later on I switched to being 'glass back' to a point. Once I learned HTML then I wanted to learn how HTML was parsed so I could use it for something else. (Didn't know about XML at the time.)
I think this also describes the one of biggest differences between computer science and software development and also to the extent of Web Development too. At least the way they are taught today. Each is an abstraction further away from the previous where the amount if low level detail is needed less and less to the point of confusion as you get higher level.
I took an software development associate program a few years ago and was shocked how little implementation or lower level concepts were taught. (For instance the differences between all the data structures and sizes of numerical data.) Just use int for integers and double for reals. That's it. You learned base objects to use for storing data and anything about why or how they worked was mentioned in passing. (Had one class that went over it but it went over all of them in one section of one chapter as one of those read on your own time not going to be on a test.)
I tried explaining to someone coming from a javascript world to java how to you needed to know the type of numbers and all he could comprehend is they all "look like a number so what does it matter".
I started out on Turbo C++, a little assembly, lisp, and Basic in a pre-internet world. So for a lot of things you hand to understand what was going on cause you didn't have instant access to a library to do the work for you.
When I got into web work later on I switched to being 'glass back' to a point. Once I learned HTML then I wanted to learn how HTML was parsed so I could use it for something else. (Didn't know about XML at the time.)
I think this also describes the one of biggest differences between computer science and software development and also to the extent of Web Development too. At least the way they are taught today. Each is an abstraction further away from the previous where the amount if low level detail is needed less and less to the point of confusion as you get higher level.
I took an software development associate program a few years ago and was shocked how little implementation or lower level concepts were taught. (For instance the differences between all the data structures and sizes of numerical data.) Just use int for integers and double for reals. That's it. You learned base objects to use for storing data and anything about why or how they worked was mentioned in passing. (Had one class that went over it but it went over all of them in one section of one chapter as one of those read on your own time not going to be on a test.)
I tried explaining to someone coming from a javascript world to java how to you needed to know the type of numbers and all he could comprehend is they all "look like a number so what does it matter".
I know i need to step my blogging game up. This was a good read. Very good writing. Flows nice. :)
So true! I am definitely a "metal up" person at heart but, during the past 15 years of teaching, have learned to slide the other way a bit when the audience calls for it (or I at least try to meet them halfway).
Love this post.
Though I'm left wondering if maybe most people are differing combinations of the two.
Though I'm left wondering if maybe most people are differing combinations of the two.
I think Tom has got it right.
Depends how old you are and when you came into coding. In the early days you had to do it all. You had to build the guts and the interfaces, and most were pretty bad - so for those guys it was always going to be a "Metal Up".
Now days you get a lot of help from pre-built tools, library's etc., so people tend to get into the UI first and work down. It's just the way it is - neither is right or wrong, as with all life - it takes all sorts.
Nice article.
Depends how old you are and when you came into coding. In the early days you had to do it all. You had to build the guts and the interfaces, and most were pretty bad - so for those guys it was always going to be a "Metal Up".
Now days you get a lot of help from pre-built tools, library's etc., so people tend to get into the UI first and work down. It's just the way it is - neither is right or wrong, as with all life - it takes all sorts.
Nice article.
That's a very interesting question.
I think I learned from the metal up, by necessity: I started off writing my own programs on the TI-99 and Commodore 64, and that's sort of the instinctive approach I have to writing a new program even today. If you don't understand how things work underneath, the final result will never be 'good' (ie: performant, bug-free, secure, resilient, etc). However I also find that I only consider my code to be "well written" if I redo it with a glass back approach, since metal up is horribly unmaintainable, and often poorly architected. (Caveat: Take usual hindsight bias into account.)
As an interesting analogy, I was recently pondering how I would approach teaching someone how to develop a program using the MVVM model. What I finally decided was that the single most important component of that was the view model (VM), and that the program should be developed outward from there.
While the model is strongly biased towards metal up, and the view biased towards glass back, they need to simultaneously be developed in the opposite direction as well, and shortening the reflection distance makes that much easier. The VM then becomes an abstraction of the metal for the view, and an abstraction of the glass for the model. It's at the boundaries where things are both most interesting, and most difficult, and many instructors fail to grasp that, giving you a boundary-less stretch all the way from glass to metal, and no reflection, under the assumption that you can only go one way or the other.
That also provides an interesting view of commandline programs. With a commandline program, the 'VM' layer is nearly non-existent, and the user is interfacing directly with the model. It's almost impossible to not be a metal up approach, because there is no 'glass' to work back from. From that point of view, a lot of things make a whole lot more sense.
I think I learned from the metal up, by necessity: I started off writing my own programs on the TI-99 and Commodore 64, and that's sort of the instinctive approach I have to writing a new program even today. If you don't understand how things work underneath, the final result will never be 'good' (ie: performant, bug-free, secure, resilient, etc). However I also find that I only consider my code to be "well written" if I redo it with a glass back approach, since metal up is horribly unmaintainable, and often poorly architected. (Caveat: Take usual hindsight bias into account.)
As an interesting analogy, I was recently pondering how I would approach teaching someone how to develop a program using the MVVM model. What I finally decided was that the single most important component of that was the view model (VM), and that the program should be developed outward from there.
While the model is strongly biased towards metal up, and the view biased towards glass back, they need to simultaneously be developed in the opposite direction as well, and shortening the reflection distance makes that much easier. The VM then becomes an abstraction of the metal for the view, and an abstraction of the glass for the model. It's at the boundaries where things are both most interesting, and most difficult, and many instructors fail to grasp that, giving you a boundary-less stretch all the way from glass to metal, and no reflection, under the assumption that you can only go one way or the other.
That also provides an interesting view of commandline programs. With a commandline program, the 'VM' layer is nearly non-existent, and the user is interfacing directly with the model. It's almost impossible to not be a metal up approach, because there is no 'glass' to work back from. From that point of view, a lot of things make a whole lot more sense.
I am too a metal up learner, and sometime feel how can someone code without knowing the internals. But as you said its individual thing. Great post :)
With dad's help I learnt basic programming on commodore when I was 8 years old. It was really cool to see that you could command and ask computer to print 1 to 100 on TV. However, I liked playing games more!
When I finished high school, I decided to study software engineering. After getting accepted in the university entrance exam. I rang one of my best friends whose dad had a software company and I asked if she knew what programming language his dad's programmers were using. She said, her dad has mentioned VB few times. I went to lots of bookstores and asked about VB until I found only one book. With dad's help I installed VB on the PC and learned VB6.
When I started at Uni I already knew how to do basic programming with VB6. I was so excited that if I could learn these cool stuff by myself at uni I would learn extra amazing stuff. I was wrong! At uni they have started to teach us metal up as you named it.
I didn't understand why did we need to learn so much low level concepts which you never use them in your real life. Why did we need to learn how to write our own compiler! Worse than above, why we were learning Pascal on Dos operating system! It was really disappointing and I didn't have any good mentor to tell me one day you might really need to care about big O!
The main reason I didn't drop out was, I needed my bachelor degree to be able to get a job as software engineer and would be able to work on the real world projects.
If I knew about these two ways of learning that you mentioned in your article when I was at uni, I would have put more effort to learn.
Thanks
When I finished high school, I decided to study software engineering. After getting accepted in the university entrance exam. I rang one of my best friends whose dad had a software company and I asked if she knew what programming language his dad's programmers were using. She said, her dad has mentioned VB few times. I went to lots of bookstores and asked about VB until I found only one book. With dad's help I installed VB on the PC and learned VB6.
When I started at Uni I already knew how to do basic programming with VB6. I was so excited that if I could learn these cool stuff by myself at uni I would learn extra amazing stuff. I was wrong! At uni they have started to teach us metal up as you named it.
I didn't understand why did we need to learn so much low level concepts which you never use them in your real life. Why did we need to learn how to write our own compiler! Worse than above, why we were learning Pascal on Dos operating system! It was really disappointing and I didn't have any good mentor to tell me one day you might really need to care about big O!
The main reason I didn't drop out was, I needed my bachelor degree to be able to get a job as software engineer and would be able to work on the real world projects.
If I knew about these two ways of learning that you mentioned in your article when I was at uni, I would have put more effort to learn.
Thanks
I wonder if a DFS (Depth-First-Search) and BFS (Breadth-First-Search) terminology covers the same differences? Some people are goal-oriented and search deep, then possibly stops when the first viable answer or solution is found. Others orient themselves among possible alternatives before taking it another layer deeper.
I became a developer because I am a glass back person. I started a degree program for SysAdmin. I got annoyed with it because I wanted to know how things worked in Windows Server not just "push this button to make x happen". I took a scripting course, and really enjoyed seeing how the programming internals work and how it let you peek under the hood so to speak. I switched majors to development and never looked back.
In the first few month of my very-first career as a software developer, I always wondered how would some of my colleagues build & release software products without knowing what really happens underneath the hood. I told to myself: "they didn't care about it at all! how would it be possible!".
After a few month of work and getting familiar with the culture of the company, I realize that as like as every other stuffs in the CS you have to "trade off"! trade off between time, software costs, business demands on one side and endless temptation of understanding the implementation details on the other hand!
Now I think this trade off is somehow related to what you said: metal up or glass back learning styles.
After a few month of work and getting familiar with the culture of the company, I realize that as like as every other stuffs in the CS you have to "trade off"! trade off between time, software costs, business demands on one side and endless temptation of understanding the implementation details on the other hand!
Now I think this trade off is somehow related to what you said: metal up or glass back learning styles.
Comments are closed.