Teaching Someone To Code Is Partly A Hardware Problem
medium.com
medium.com
I've used a screen no larger than 13" for probably nearly a decade now, for all development work. Cmd+Tab (as the author mentions) is virtually as fast as moving my eyes to a second monitor would be -- even when working on a huge monitor, I honestly don't care, it's just not any faster at all (but I totally understand that other people find it helps).
I hate to say it, but I don't think she "needed" five entire windows open simultaneously -- it's nice, but to say it's "needed" just sounds spoiled, and not having multiple huge monitors is not a "hardware problem", any more than not owning a Ferrari is a problem in learning how to drive.
Note: I use 3 displays (currently 2 because of moving) and I wouldn't go back.
I prefer having 2 or 3 monitors where I can
1 the main ide 2 database ide 3 browser
And I have in the past had my dev server on my desk with a extra screen.
And I agree with the article - a huge part of learning to program is learning how to keep all the important pieces (variables, meanings, program flow etc.) in one's active memory, and learning which pieces are important. In case of a short-term memory "cache miss", which happens way more often when you're a novice, having everything open on a huge monitor makes it much faster and less painful to look up the info you need. Most people have very good spatial memory, so it's easy for them to remember that they "left" a piece of information in, say, the bottom left of the screen. Changing tabs/windows, on the other hand, is an interruption/context switch and requires much more work for the student to find what they're looking for.
It may not seem like much (a few extra seconds and a few wasted braincycles) but this is exactly the type of friction that eventually adds up to a lot of frustration and keeps more people from learning how to code. I could easily see how having a huge monitor and good window placement could be the difference between a student burning out and "making it over the hump" of really understanding programming concepts and taking off.
TL;DR Huge external monitor = training wheels for programmers.
So I pretty strongly agree with the article's thesis that learning to program is in part gated by the availability of a high-quality desktop-grade set of gear. (Whether it's truly a desktop computer or a laptop made to behave like one is a detail that I don't really care about; though I've never seen a laptop with three dual-link DVI ports.)
I agree that once you use a large display, you absolutely do not want to go back to a small display. I contend that if I could buy a 50" high-DPI display for my desktop that once used, all of my current 30" monitors would feel antiquated and feeble. Suitable for the recycle bin. And I'd love that.
Moving my eyes and/or turning my head is so much faster and productive than flipping through a stack of windows using even the best window manager.
Also, I'm not sure why there's a thread here that says that some languages may see less benefit from large displays. Java is cited by name. I do Java web development and with Eclipse, code is compiled and hot-reloaded by the application container as I work. Modern Java is definitely sufficiently fast-paced to benefit dramatically from lots of screen real estate. One way to put it is that my app has been recompiled and hot reloaded well before I can find the browser window on a small display.
One of the biggest hurdles for me in moving to a language on a computer was setting up a compiler, IDE, etc is tough for a 12 year old who doesn't know the vocabulary. From my experience at university, it is tough for college students who don't know the vocabulary and haven't done anything like it before.
I eventually started coding in Python since it is easy to install and use IDLE to run code.
A lot of people have the aptitude to learn to program, but this would be much easier if you could just "Download C++" and download the compiler, a simple IDE with a compile+run button, and have the installer do all of the PATH wiring, etc. I have seen many people give up trying to get started just because this process can be so finicky.
The next biggest hurdle for beginners is usually grasping basic design patterns or the request response pattern of client server interaction. This is usually difficult because a lot of the nomenclature isn't there yet. But that is nothing in comparison to the struggle it is to walk someone through basic environment setup for RoR even node.
A lot of people are looking for a good teaching language, but really I suspect almost all languages are fine, and syntax is less important than an environment where you can jump right in without a lot of fuss.
I am so glad he forced me/us. He spent a day explaining Makefiles and their power, mentioning some people make their living fixing those up and paying attention could potentially help you out. That summer, I finally started using Linux, for personal interest, and I was so glad that class allowed to compile my own device drivers (back when wifi cards were still a novel PITA) and understand the basics of what was happening.
Good times.
It's bundled with the Mingw compiler, and basically works as you mention out of the box. I was delighted when I found it, a few years ago when my main systems were windows.
[1] http://www.cplusplus.com/forum/articles/36896/
[2] http://clicktobegin.net/programming/why-you-shouldnt-use-dev...
[3] http://www.daniweb.com/software-development/cpp/threads/3707...
[4] http://blog.vucica.net/2011/01/reasons-against-advising-begi...
Those existed?! I remember reading articles on Z80 assembly language at ticalc.org as a teenager and desperately wishing I had some kind of calculator-native text editor and assembler that I could use to program in math class -- at least, that's how I would phrase it now. I assumed that none existed, and setting up a cross-assembler was beyond either my capabilities or comprehension at the time (not to mention, at the time programming was most fun in school when I was supposed to be working, not at home on a PC with a million other distractions). I didn't get that assembly language programming experience until years later. Instead, in between games of GALAXIAN and FALLDOWN, I messed around with horribly slow, illegible TI-BASIC, a language so crude that even Pong is an exercise in futility to write in it.
I just searched the ticalc.org archives, and yep, here's at least one such assembler, loaded up with the familiar MirageOS:
http://www.ticalc.org/archives/files/fileinfo/403/40304.html
I'm not going to lie, I'm kinda sad right now, wondering what might have been, if only I had known the correct keywords to search for at the time...
Anyway, I totally agree with the premise of your post. There's almost always too much to configure for novices to get a handle on, and novices don't know what the hell they're supposed to be looking for in the first place. If setup involves one step too many, or the novice is expected to figure too much out on their own before they can start, they think "I'm stupid, why can't I do anything" or "these programs are stupid, I wanted to implement that thing I read about but I wasted X hours setting up this completely unrelated thing and copying magic commands," and you'll likely lose them for good.
Which is, incidentally, why I think anyone that prefaces their programming tutorials with "you should learn to use a real text editor like vim or emacs" deserves a swift kick in the ass.
I was (sorta still am) a pretty active member of the TI community over at http://cemetech.net/ (probably the biggest community since unitedti shut down). That on calc assembler you linked to was what I used, and it was made by my friend Brendan Fletcher (calc84maniac is his TI community handle) when he was 13 or 14. He went on to make various gameboy emulators for TI calcs. He's a year or two younger than I am, and I remember when he joined the community about a year after I did. He was slightly below my level at TIBASIC (neither of us did ASM yet) but very quickly soared past me in skill and made his on calc assembler (I started ASM with that). I just remember being blown away by how bright he was. Probably one of the more gifted programmers I've personally known. I think he's a sophomore in Uni now.
Not terribly related, but a TI anecdote nonetheless.
Also, for compiled languages, coding may not be a reactive process.
I do believe that hardware is becoming a problem, though. iOS devices are permanently crippled, Android and ChromeOS are crippled by default and Windows is heading that way as well. This is the real danger to learning.
Another area I found tricky, as a self-taught developer, was objects and classes, and nomenclature of these things and functions between different languages. I've since done a lot of work in JavaScript, and somewhere along the way it all started to click. I'm finding it easier to read and understand parts of new languages, but there's still a big curve if the syntax differs greatly and seems unusual (I just started with Objective-C, and a year ago it was too odd to handle, but I think it's easier to pick up on now).
Its probably a sign of how shallow a lot of peoples knowledge is these days - I had one developer who did not know how to use a cli to work with MySQL to get round the limitations of phpMyAdmin
How to do 2+2 in language x yes
How to do do anything slightly complex you might have to spend a while digging.
Another big reason I like having screen space is that I can display my required specification/ design doc/ uml/ ms paint, whatever it may be while coding.
It used to be you could tell bad places to work by the power of the chips on the machines they would give employees. Now it's monitor size that's more important.
Tying back to the original story, I think this is highly underrated in learning. And also to their point why it's hard to learn in a coffeeshop.
Also, the standard staggered layout is not quite symmetrical. 6 is slightly to the left of the midline between the two index finger home keys of F and J, closer to the left hand.
If you're an accountant touch-typing lots of numbers, breaking it to 12345 and 67890 would make sense. But for anything that involves more of the keyboard, certainly including programming with frequent use of the - and = keys in the top row, breaking 123456 and 7890-= makes more sense.
That's one of the surprising things about teaching web programming - a lot of it is stuff most of us don't think about, like using a file system and remembering keyboard shortcuts. Often times, that's the first hump for students to get over (like for the HTML first exercise), and once they're over that hump, they're good to go for a while.
I also wrote an article about how bad hardware actually made me a better programmer: http://www.randomshouting.com/2010/12/14/Scarce-hardware-as-.... Not trying to spam my articles or anything, I just feel like it's an interesting contrast to this article.
I have two 27 inchers and one 24 inch monitor. And recently I've discovered that I'm more productive on a 15 inch XP laptop gone ubuntu from 2003 than on my high-end PC at home.
Workspaces are almost as fast as looking at another screen and I'm able to concentrate more at the task at hand.
I otherwise love the hardware, but I would readily chuck it for something with a "cellphone-class" CPU, if it looked like this:
http://images.businessweek.com/ss/08/02/0215_laptop_history/...
It's not handy for putting on your lap, but for coffeeshop use it'd be great. 18" screen, weighs five pounds, no laptop keyboard getting in the way. Making it play well with Linux seems to be a bit of a challenge, from the forum posts I've seen, and an upgrade to Haswell would be nice.
Less so for when you're at a stage where you can do large projects - because you're not redoing things as often, but when it's just short snippets where you want to drill multiple variations to try out ideas and to get the stuff wired into your head, it seems to be advantageous to have that sort of dialogue with the computer.
Between that and getting browser hotkeys into muscle memory, I managed to shrink my development/debug environment down from 2 19" monitors to a single 13" laptop screen. And when it's been necessary, I can happily go smaller.
To use a higher-level example, I found learning and adopting new JavaScript frameworks was hugely more enjoyable and easier thanks to build systems that set up continuous testing/automatic-reloading right out of the box (yeoman.io, for instance). Sure, running the bash command to compile CofffeeScript and run the tests takes just a second to type and execute...and hitting Cmd-R to reload a webpage after editing the files even less, but those seconds build up, to the point where development because more of a burden than it should feel like. And, well, if I stop programming because I'm tired, I'm not learning.
So I could see how inadequate hardware would be a major impediment to learning to code. The frequency that novices fail to close parentheses and quotation marks (and the inexplicable errors that leads to) is bad enough on a good keyboard...I can only imagine how frustrating it'd be if your Shift key worked only half the time you expected it to.
That said, I disagree with the author's specific examples. His rationale for a bigger monitor, especially. If a novice is using five programs (2 chrome windows, Sublime Text 2, Evernote, and Github(???)) to do simple HTML/CSS tracing...then I would argue that she is trying to do too much and that more of the concepts should be taught in an orthogonal way.
The OP defends his student's habits, saying that instead of learning to do Cmd-Tab to switch, she should work off a 30-inch monitor. I think that's the wrong way to approach the situation, even if you ignore the monetary realities of buying a bigger monitor. Novices not only don't know the concepts, they also don't know how to learn the concepts. The pattern that the student has apparently adopted does not seem like a best practices one.
A tangent discussion could be started on how one might structure the HTML/CSS lessons so that the student doesn't have to have 5 windows open at once...but I'll stop at arguing that the OP presents a sort of false dilemma here. It's not that either the hardware improves, or the student's education will be harmed. There's also the ability to restructure the concepts so that they can be handled one at a time, and the discretion to push the student towards more efficient habits.
To use one more example: in typing class, our teachers made us cover our hands with paper...it wasn't comfortable nor what we would do naturally, but this helped enforce the concept that typing is ultimately done fastest when not looking at the keys.
At the very least you need to have both the editor and the browser open. Switching between these two to see changes is more friction than necessary. The additional windows are: 1. to see the lesson 2. to see the website she is copying off 3. I forget. but it doesn't matter anyway. The task of switching between all these windows is enough to shatter the mental context of the real task, which is building the website, making a particular modification.
That's the other thing- the workflow aspects haven't necessarily been offloaded into the novice's unconscious mind yet. Switching between a window needs conscious attention that breaks the coding context, and the coding context must be reestablished again and again, on every change.
None of these realities go away because of your opinions about how a "real" programmer should be working.
Sure, you an have 2 browser windows size by side along with a code window and a log window and a documentation window. But, you can only effectively look at about 45% of the screen at one time. The rest of the time you look like a chicken bobbing your head around.
It is so much faster to hit a keyboard shortcut to go to another window/application or switch to another desktop. The bonus of it is you don't need to move your head since you can see the whole screen. Every computer user, especially anyone technical enough to be a developer or designer, is going to know alt-tab, so there's nothing to learn.
A resolution like 1366x758 is simply not enough to do work on. Sure, plenty of us use it on our MacBook Airs but we also breathe a huge sign of relief when we plug into an external monitor at our desks, and stretch our figurative legs on the 1440x900 screen of a 13" Air.
At bare minimum, enough screen real estate is needed to see your browser window alongside a web inspector. Using a resolution of 1366x768 causes you to shrink the fonts or spend half your time scrolling.