Wednesday, June 29, 2016

It's time to declare war on "Hello, World"

Whoa there. Harsh title? 

Perhaps. War is such a strong word. However, through experience, I have reached the conclusion that this teaching approach cannot be tolerated anymore, and forceful removal is necessary. Stumbling blocks being what they are in this industry, I feel it's time to talk about this, and without any beating around the bush. Let's start with an analogy:

Danny wants to be a board game player. He looks up how to play a board game on the internet. He selects checkers as it's a simple game to learn for someone new. After playing the game a time or two, he feels confident enough to sign up for a beginner board game competition. He is assigned to play chess - which is also a board game, so he figures he can apply what learned from checkers and figure it out as he goes along. His first turn, he moves a piece and feels good about that. The next move that ensues from his opponent leaves him scratching his head. He doesn't understand it exactly, so he decides to shake it off and move another pawn. That's how he learned to do it with checkers, so it can't be that different. It's just a board game. The game progresses with each move from his opponent removing his pieces, one by one, and he can't seem to confiscate any of their pieces in return. Even though he was moving his pieces forward, he didn't understand that each TYPE of piece represents different levels of capabilities. Before he knew it, he was outwitted and checkmated. All he knew was how to move a piece forward one space, like in checkers. But this was not checkers - this was chess. While both games, on a board, with some movement - how you get to the end of a real game is vastly different.

Danny failed to learn the strategy and approach to the game. 

This is what new developers, or experienced developers switching to an unfamiliar tech stack, experience often. As teachers, we believe in breaking things down to it's most basic and simple level. When presenting a quick reference of help, like on Stack Overflow or in the comments section of a blog, this approach is welcome. But when you prepare a tutorial, article, video course or speaking session, you have a greater responsibility to show a more complete application.

Wait a minute. Hello World was not designed to teach people design patterns and architecture. It's just to communicate a small example of what a particular thing does. Why is there a problem with this?

Teaching how to do something that is REAL WORLD in how you would be expected to execute it shouldn't be a concept that we leave behind for the sake of brevity. Documentation examples are notorious for this. One of the fundamentals of clean code is to handle naming in a human readable fashion, as robust as is necessary. Most would agree that getTimezoneAbbreviation() is clearer than the shortened version getTAbbr().

I don't have time to arrange the holy grail of teaching courses. I'm just going to put all my code in one file so I don't have to worry about a bigger structure. As long as it runs and proves the point of the functionality I'm showing, I call it good.

Sure, you could do that. In fact many of the authors of instructional code do this. It doesn't make it good for the student to learn. Why set up the learner for failure? It doesn't really take that much longer to JUST DO IT RIGHT in the first place. At the very least you show proper placement in a real environment, and what kinds of hurdles will have to be overcome in relation to the rest of the application. In addition you also educate, indirectly, how good architecture can work. Reinforcing the fundamental best practices of thoughtful development is the responsibility of all of us. Why take time out to do it any other way? Common sense programming doesn't exist until we make it commonplace.

The reign of Hello, World has had it's time, but a new approach should be considered that can assist the learning curve and make more sense. That is a tutorial style I know I'd be more likely to dive into. Therefore, I issue everyone the challenge to craft more of your examples this way whenever possible. Perhaps we can refer to it as:

Hello, Real World.

Because context matters.


  1. I've struggled with this as both a teacher and a learner. As a learner, sometimes I need "Hello World" -- particularly if there is an environment I'm unfamiliar with (wait, what's Yeoman? How do I get that?).

    As a teacher (with limited time), I could show a "real" application. The problem is that it's too easy to get lost in the convolutions of the business requirements when we really want to concentrate on how to learn one particular technical concept. This is particularly a problem when looking at architectural techniques like dependency injection.

    I'm not always happy with the approach for the exact reasons you mention, but I've found that it's effective with a particular group of people. Sometimes we need to learn to walk before we can run.

    I completely agree that we should not be teaching bad practices. I'm not sure what the right answer is. Perhaps we should ditch tutorials and head toward apprenticeships. Working side-by-side with someone is an effective way to see how the real world works.

    1. Appreciate your comment, Jeremy.

      We can make better programmers sooner if we just reinforce basic clean coding standards when we do tutorials. The takeaway from the instruction will be more meaningful and readily adaptable to a real project. You can do that with sticking to at least breaking out your methods properly, handling some basic dependency injection, etc. That is fundamental to even front end developers. There is nothing wrong with discussing which libraries to include, and create a super quick interface for the methods you are trying to access. It allows a more linear train of thought that the developer will go through when applying this new functionality to their projects.

      I believe very much in the apprentice/journeyman/master approach. However, our industry is known for being more independent in our learning. We become the masters by publishing our articles. You may never know the apprentices that will learn from you, but you can affect what they see.

  2. For a beginning programmer in C++ learning how to include libraries was painful at best. Making sure that you had stdio.h and stream.h in order to output cout << "Hello World" << endl; would be an appropriate lesson for a beginning programmer. As well many older languages had limitations on the number of characters allowed in a command string. The real world at the time was getting a console output to display data and using cin >> variablestring(n); to get your data. These are fundamental concepts (outputting a string and gathering data) that have to be understood before you get into more complex methodologies. The biggest issue is that instead of expanding on the basic hello world application many teachers drop it the next lesson and move on to something else.

    SML was notorious for short string commands and limited variables. Being a completely recursive language just outputting "Hello World!!!!!" was an exercise.

    Back in the good ol' days we didn't have this fancy object oriented programming. Most languages were linear in nature and took many constraints from Assembly just due to constraints on the system. If you are learning ADA or Fortran you didn't call a bunch of libraries and extra functions that were already there.

    The other facet of this is determining the strengths and weaknesses of the people you are teaching. Personally I hate programming because I find that most instructors assume that I know what they know. I can talk to you about networks till you are bored to death (and have done so) but when it comes to programming sometimes you developers don't make sense.

    There is also a psychological basis behind the simple program. "OMG IT COMPILES!!!!" is a joke just because the feeling of accomplishment after getting a piece of code written has always been well received. In your instance if a beginning developer tried to make a complex program without the understanding of the constraints they will be frustrated by the amount of work and issues to try to get it working.

    1. The main issue is gauging your audience, for someone who has never seen code before a simple hello world program is a good place to start. For an experienced developer who's written millions of lines of code it's not as useful.

    2. Thanks for your input on this.

      I am not necessarily looking for beginners to create complex programs. I am looking for us to teach good habits wherever we can, because for the first few years most developers copy/paste code solutions. It's just the way it goes. You don't have to do away with exercises, but you should make them more relatable to a real life scenario with proper naming conventions, single responsibility principles, etc - and through repetition, new developers will become comfortable with these practices. Then teaching them about design patterns will be easy - because they've already been doing them all along. It honestly doesn't need to be super robust or complicated. I am an advocate for simplicity. But it should be demonstrated CORRECTLY. Clean code first. You educate this way and it will become intuitive for the student at a much earlier phase than having to wipe their brain of all of the incorrect coding they've been doing because that is how they've been shown how to do it.

  3. I love the thought but I've had the opposite experience.

    I've taught:

    1. Beginning programming to kids and adults with no experience programming
    2. New languages and approaches to experienced developers
    3. Formal classes for programmers with 2-20 years experience programming including new languages or styles (object-oriented from procedural or functional from imperative)

    In classroom situations, I've always had better luck with "classroom" exercises. Building to production guidelines has gotten in the way of teaching.

    I did try to write a book for kids that was test first. I based the narrative on the style used in the Mythbusters. Fun exercise for me as the author but even those tests were far more coarse than those I use in production code.

    I have had good results with using code reviews to teach. Then you are looking at production code (and hopefully tests). I talked about it at Omaha Bar Camp:

    But, I'd be interested in your findings as you teach using SOLID principles and the like!