I could have sworn I already had an article here.
There’s story that’s occasionally pulled up from the ditches about some demo of technology that was supposed to be object-oriented, and some guy raises his hand and says “That’s not object oriented!”
“Well what would you know about object oriented?” the demonstrater replies
“I invented the term.” the interluder protests.
This may have happened at Xerox PARC some years ago. And the guy who claimed to have invented the term probably was Alan Kay. But just because Alan Kay says he invented object oriented programming, that doesn’t actually mean he did.
First, let’s look at the common sense argument. The dominant languages that are classified as object oriented today are some static languages like C++, C#, and Java, as well as dynamic ones like Python and Ruby.
Alan Kay is also known for having said: “I invented OOP and C++ was not what I had in mind”. Well, if an inventor is saying he created X, and the most popular version of X is C++, and he’s saying C++ isn’t X… one of two things may be true:
- We’ve somehow come very far from the inventor’s original vision (which I believe Mr. Kay is implying here)
- Or the guy claiming to have invented X didn’t actually invent X
C++, in particular, is a good example in this common sense argument. It takes its roots from a very old language, Simula, which Wikipedia claims to the first object-oriented language.
To sum up the story so far, one of Alan Kay’s targets here – C++ – that he’s argued is not really object oriented, apparently derives quite closely from the first object-oriented language. Huh. So if C++ isn’t object oriented, neither was Simula?
That leads us into the second, historical argument. Of course, that’s weird, because Simula was one of Alan Kay’s own inspirations for Smalltalk, the language that never really took off that he bet his hat on and is now so cranky no one uses.
So there’s basically two different interpretations of what an object-oriented language is – one that includes C++, Simula and Smalltalk, and one that only includes Smalltalk. And of course, the guy who writes mostly in Smalltalk is quite happy to keep telling you he invented OOP and thus should be listened to.
Let’s talk about one final argument here – what if Alan Kay was merely saying he coined the term ‘object oriented’? So in this interpretation, Alan Kay isn’t going around trying to convince everyone he’s a genius and invented OOP and why don’t we all use Smalltalk, but rather, he merely coined a clever phrase to help other people.
Well, this runs afoul of the common sense argument again – what’s the use of coining a term if no one actually uses it that way. If most people think of C++, Java, and Smalltalk when they think of OOP, then you claiming you coined the term to only mean Smalltalk again runs afoul of two conclusions:
- It either doesn’t matter what you said because most people have used a substituted definition anyway
- Or you’re lying
In fact, doesn’t it all beg the question? If Alan Kay meant Object Oriented to mean Smalltalk, yet everyone else thinks it means C++ as well… well, who’s going around and spreading that ugly rumor?
In this world that Alan Kay is trying to present to us, he cleverly defines a term, then goes out to tell everyone what great work he’s done. And scoundrels like the people who designed C++ and Java try to ride his success. What ungrateful wretched tricksters, convincing us all that Object Orientation may not mean what Alan Kay is so sure it means!
And somehow, they were all so successful in convincing us that Object Orientation was something Alan Kay says it’s not, and Alan Kay was so unsuccessful, that that is why today we’re all confused.
That may be how things have happened. But let’s see what’s more likely – is it more likely that tricksters emerged to try and get their own languages adopted by hopping on the OO bandwagon “in name only”, meanwhile the one true and good language Smalltalk languishes… Or, is it more likely that OO was tied at the time more to what the inventors of C++ and Java claim it was tied to: Simula.
What we’re asking here is what a word meant in the 80’s, and while Alan Kay has made quite a fuss in the late 90’s and 00’s about what he meant then, he didn’t seem to be making much of a fuss in the 80’s when C++ and Java were being written up.
So let’s look at this version of events – here we have a whole bunch of languages being inspired by Simula: Smalltalk, Java, C++ and others. They all adopt a very similar view of the term ‘object oriented’ in that they have classes, objects, inheritance and the like. So far, so good.
Then some guy, Alan Kay, starts getting cranky that Smalltalk isn’t getting adopted and so starts trying to use what fame he had from Xerox to rewrite history.
Frankly, I believe the latter if only because it requires fewer tricksters. The first version of history requires everyone but Alan Kay trying to trick us, while the second only requires Alan Kay trying to trick us.
This is what frustrates me so much about this – we have some guy, using the fact that most other inventors are dead or in other non-English speaking countries, running around claiming his off the wall interpretation of OO is the one true way.
It’s like the ultimate archetypical asshole machismo asshole programmer, willing to ruin others careers and say terrible things to get his own time in the spotlight. He knows he isn’t going to be challenged because Simula was invented somewhere else, and he has a whole bunch of kids to try and teach his own version of history to. He exemplifies the lone genius programmer who is “smart and gets things done”, and perpetuates that myth in the middle of programming’s diversity and teamwork crisis.
Every time I hear the Alan Kay story, I think – someone else has just learned not to listen to others, not to work with others, not to give credit to others, to believe that everything’s been built by themselves and that every miscommunication is someone else’s fault. Culture is wrong, not me, and that’s why I don’t get along with everyone.
And that’s just fucking dangerous.
The largest difference between what you do in Code Combat and what you’ll be doing in the rest of these chapters is about developing on your local box. To do that, we’ll need to get a slew of tools set up.
For the most part, you can probably just install some off the shelf version of Python and get cracking. But these chapters are about proper engineering. This means, what do you need to learn to code complex systems in large teams. Simple scripts aren’t going to cut it – you’re going to need tooling.
Many of the tools below are how you build high-quality complex systems, and rarely are they taught in school! They’re always learned on the job, and people struggle with the problems that these tools solve – sometimes their entire career. Not you, you’re going to learn how to do things right, right from the beginning.
Shaving The Yak
This also will be an exercise in configuration and probably a little frustration. Every time someone starts a new job, they have to get the code building on their box – get all the right tools, libraries and everything else downloaded and configured in precisely the right way.
Every time you screw up your box, which is probably a few times a year as a coder, you might have to rebuild it from scratch. Which again, means configuration work. Every time you want to try out a new tool or library to see if it solves a problem you have, you’ll have configuration work. This isn’t covered in Code Combat, but it’s something that you’ll hit throughout your career as a coder.
Might as well jump in.
While this isn’t the only time this phenomenon occurs, it may be the first time it occurs in your coding career so you need to get used to this too: Yak Shaving.
Watch the above Gif. Seriously.
Yak shaving is when you set out to do a thing – you want to write a script that does X. And to do that, you need to install a library. To do that, you need to update your dependencies. To do that, you need to update your compiler. Before you know it, you’re shaving a yak and you’re not quite sure how you got that far down the rabbit hole.
In the following instructions, you’re almost sure to screw up something or run into a path I didn’t anticipate. You’ll have to attempt to find out what’s wrong and find a workaround that gets you to the end.
This will probably require some googling, which is good practice to figure out what to search for, as well as some experimentation. You may also want to read help documents on the sites I’ll be sending you.
As a last resort, if you can’t get a certain thing installed, contact your mentor – but don’t do that first. Use it as a challenge to see if you can get your environment working!
In addition to practicing your research skills, we’ll also begin challenging your project management skills. The key to successfully shaving a yak is to – when you’re stuck – remember the following options:
- Use google or other resources to see if others are having your issue
- Experiment to see if you can find a workaround
- Take the smallest steps possible from known working system to known working system
- Be willing to step backward – maybe the problem you’re trying to solve is impossible because you screwed up something earlier. Be willing to start over from scratch. (That means you need to know how to UNDO what you’ve previously DONE)
- Be willing to make compromises that ultimately get you to the end goal but maybe not using the same method or process you originally set out to do, or the method or process you thought you were supposed to follow.
Without further ado, please complete the following:
1. Read this
2. Install Anaconda
Anaconda is a great Python distribution – it comes with the runtime, the IPython replacement REPL, and virtually every library you might want.
3. Introduction to IPython, the super Python REPL
4. Introduction to py.test, the awesome testing suite
5. Introduction to pip, the Python Package manager
6. Introduction to pdb/ipdb, the python debuggers
7. Git and Github
variable_1 = 1variable_2 = 0
- Navigate and list directories
- Tab completion
- Historical completion
- Use the ? and ?? commands, as well as the help and dir functions.
The Command Line
Computers have two main interfaces, one of which you’re probably very used to, and one of which you may have used very little. The GUI, or graphical user interface, is what you drive with your mouse. You may have a start button at the bottom left, or an icon strip, or what have you. You click on your internet browser to start it, click around on the web, and so forth.
The command line was the original interface with the computer, and it still remains the most powerful of the two. GUI applications tend to be less powerful though have a lower learning curve than command line applications. The main benefit to command line applications is that they are designed to be interacted with programmatically – sometimes called ‘scripting’ – so that you can write programs that run a bunch of command line applications to get a job done.
We need to get you used to some basics in the command line so that you can install Python and other tools, as well as learn how to navigate your computer only from the command line.
The command line is also sometimes called the console or the terminal, although technically these things are all different things. This series will use the terms interchangeably.
Command Line Basics
Instead of being mouse driven, the command line is keyboard driven. There won’t be much clicking to do, although depending on your terminal (Mac and Windows differ here) it may be easier or harder to do things like copy and paste to and from the command line.
You’ll be typing commands into the command line, which will then print out feedback of what happened in the same window. The same abstractions apply at the command line level as at the GUI level, though. For instance, you’ve probably navigated nested folders on your desktop GUI to find a file. In the command line, the same folder structure exists, although the tend to be called ‘directories’ when you’re using the command line.
We’ll need to get used to the command line ultimately to install Python later. Moreover, nearly all your programming work is going to be command line heavy.
Windows Command Line
- Watch This Video
- Read This – Do at least chapters 1, 2 and 3. Can skip Windows 10 stuff unless you have Windows 10.
Mac OSX Command Line
Do the following:
Once you’re comfortable navigating the command line, you need to be able to open files new and old with a text editor – you’ll be using this editor to do that. The text editor is similar to the window you typed your code in for Code Combat.
I’m going to recommend you download and install the atom editor to do this, primarily because it’s cross platform and has a shallow learning curve compared to others.
Do the following:
- Download and install Atom
Do a screen share or live session with your mentor, and show them that you can do the following:
- List, create and remove a directory
- Interactively navigate your file system based on what your mentor asks you to look at
- Open a new file in Atom, write some text, save the file and close Atom, then reopen the file – all from the command line.
This is the first in that series, for the absolute beginner and novice. No requirements are necessary at this point other than a computer (with a web browser) and a mentor.
If you haven’t managed to find a mentor by this point, take heart. You can still make your way through the novice portion, however, you’ll most likely go a bit slower and miss some big picture items that your mentor would bring up. You won’t be able to move on to the Advanced Beginner portion, though.
Code combat is where you are going to spend the bulk of your time during the Novice stage. Out of all the different resources available to you, why Code Combat?
Code Combat is a video game – it draws from role-playing game and real-time strategy roots. It creates a bunch of compelling problems to solve from this game, and is addictive in the same way that Starcraft or Farmville are addictive – there are levels to beat, enemies to battle and treasure to loot.
You will be more able to stick to this than many other resources.
It’s At Your Level
Code Combat excels, more than other resources I’ve seen, at starting you off very simply. It assumes absolutely no knowledge and builds you from there. There are a plethora of interesting resources out there that tend to have a steeper learning curve.
It’s Live, and Builds Intuition
Being able to actively watch a program run – in Code Combat, this is done by watching your character interact with other allies and enemies – is called ‘visual debugging’ when done on real world programs. It is one of the best ways to understand something unfamiliar.
The largest handicap for a traditional computer science program is that you have to write a program from scratch, find out at the end it doesn’t work, then slowly hack at it until it does. You’re never taught how to debug, so actually looking at the state of your running program is usually left as an exercise to you.
Code Combat starts you off early seeing the exact state of what’s going on. The more practice you get translating your code to the game’s actions, the more you build up your ability to think intuitively about code. I’ve never seen a resource better at building coding intuition than Code Combat.
There are free and paid levels, and you should be comfortable working with your mentor to decide if you’d like to take them up on their paid services. Certainly, they’re a great company and deserve your support. But part of the assumption of this curriculum is that people will only need a computer and a mentor.
It’s a Lot of Hours
To learn something, you have to do that thing. And to learn it well, you need to do it a lot. Often, traditional computer science programs may have one homework assignment a week, or multiple if you’re taking multiple classes. The bulk of learning coding in computer science degree programs is through this homework – not in the lecture hall or textbook reading.
Code Combat provides a lot of exercises. By the time you’re done, you’ll have completed as many exercises as someone half way through a computer science degree program. But it won’t feel like that since you’re assignments will have been fun.
The exercises tend to grow at a slower pace than a traditional degree program, so don’t feel bad if a friend of yours throws out complex terms like polymorphism or lambda calculus and you’re still working with while loops. This is, in my opinion, a good thing.
Building an intuition for the basics is far more important than name dropping on advanced concepts. Coding is not like mathematics, or traditional engineering where having been exposed to a bunch of very different toy problems and their toy solutions will make you a more productive programmer. Coding is much more like playing a musical instrument, and lots and lots of steady, progressive practice will give you a leg up in actually doing your job over someone from school.
Get an account on Code Combat, and get hacking. They’re always expanding to new levels and new worlds. Generally, we want you to work on Code Combat until you start to get a bit bored… and then some. This happens around the Sarven Desert, usually.
Go ahead and complete the Web and Gaming mini worlds as well – even if you never intend on entering either of those industries. They’ll give you your first exposure to what is called ‘architecture’ in coding – largely assumed patterns in code that different industries use to solve reoccurring problems.
Somewhere inside Sarven Desert, you can start looking into the Advanced Beginner program to pick up progress again. At that point, you’ll usually be doing two things at once to stay motivated, and can continue Code Combat while mixing in the Advanced Beginner modules until Code Combat again becomes monotonous, at which point you’ll switch to a more advanced exercise.
This Novice Portion, as well as the rest of the series, is going to be written with the Python programming language in mind unless specified otherwise. Python was designed in the late 1980’s as a teaching language – it has an intuitive syntax that’s easy to learn and is not filled with a lot of ‘gotchas’ or ‘magic’. It’s a dynamic language, which means you won’t have to figure out how to compile anything, and is multi-paradigm, which means you won’t have to jump through hoops to make your program do something as simple as say “hello world”.
It’s advisable to try and get your mentee to coalesce a list of questions for you on a weekly basis for either a face to face meeting or email. Code Combat gives some introductory explanations for computer science ideas like variables, arguments, parameters, functions and the like, but it’s taught from a highly pragmatic point of view. For this first phase, you are your mentee’s traditional computer science education.
Let them come to you so that you can plug in answers to their questions from the theory, but don’t add anything on top. Theory needs to wait for skill to catch up, and overwhelming someone with technicalities before they need them to solve their problem is just going to turn them off. They won’t remember it anyway.
Work with your mentee around boredom points – encourage them to stick with Code Combat past a handful of boring levels to truly see if they’re bored, or just have mastered a concept early and Code Combat isn’t really ready to move on yet. Eventually, they’ll get bored enough that it’s time to give them something more challenging to mix in from the Advanced Beginner portion, and this is largely your job as the mentor to decide.
Finally, the large focus on online exercises during the Novice phase also serves as a wash out period. It takes quite a bit of time, and despite the fun, can be challenging. It conserves your own effort to have them complete the Novice phase first, to truly see who’s interested and who’s merely dabbling. We want to generate more coders to enter the workforce, build open source projects, and the like. We don’t necessarily want to spend mentor hours on folks who want to write a “hello world”
This series of posts is derived, and will continue to be evolved, from my experience mentoring others in learning how to code.
Coding is something that many people are interested in doing – and it’s certainly sexy right now to claim to be learning to code. But out of the plethora of resources out there, which ones are the best? And what does best even mean?
Expert Review of Available Resources
I’ve reviewed many available resources online for you, from the perspective of someone who already knows how to code. I’ve considered them both in terms of “I wish I had this when I was learning!” factor, as well as what I know about education – keeping people interested, engaged, even addicted to learning good habits and skills.
Emphasis on Engineering Skills
In addition to reviewing resources online, I’ve reflected on things I wish I had learned in school and compiled a set of more traditional curricula to teach these things. Often, these skills, which I will generally refer to as ‘software engineering’ skills, revolve around design and quality. Exercises we do online, or even in computer science classes, are often so small that they don’t run afoul of many problems with complex software. They’re often done alone, so they don’t run afoul of the many problems with software written by teams.
Engineering principles are there to help us move from people coding up toy problems, to people who can work together to iteratively build large projects and solve big problems.
A Designed Curriculum
Finally, I’ve coalesced all the above into one linear curriculum – step one, step two, step three – that will give you what you need to learn not only how to code, but also how to code well.
What Do You Need?
First, you’ll need a computer, obviously. The original curriculum was written for someone who came from a Windows background, however, I’ll be attempting to add hints for Mac users as well. That’s the only piece of technology you need to be comfortable with from the start – I’ll start at the very beginning.
The other thing you’ll be required to have is a mentor. While research skills are something to be learned along the way, having someone you can call upon to ask technical questions is invaluable. Moreover, during the later stages of this curriculum, a mentor is required to check and grade your work.
Finding a mentor may be hard. However, if you already know how to code and would like to help others, I encourage you to use this curriculum and be their mentor! Furthermore, if you’ve used this curriculum all the way through, I implore you to become a mentor for someone else. To become a truly expert coder, you need to teach others!
For all of the beginning portion of the curriculum, I’d highly advise you to do the exercises using the Python programming language.
Python is a very easy language to learn and was designed as a teaching language. It’s got a simple syntax that is easy to not get mixed up in the gotchas and magic of other languages. The Zen of Python says “Explicit is Better than Implicit”, and the language was evolved with that in mind.
To get the most out of Python, find a mentor who’s willing to teach Python – she doesn’t have to be an expert in it, any “dynamic” language (like Ruby, Perl or Lisp) experience would probably make them valuable.
You can ultimately stick with Python your entire career as it’s used in games, devices, mobile apps, the web, and backend supporting programs. It’s particularly popular in ‘big data’ and ‘machine learning’ circles. I wouldn’t advise this, though, as the best Python programmers got that way by learning other languages as well, though we’re not going to do that anytime soon.
A Note on Pedagogy
I think many CS degree programs can be faulted by focusing too much on theory and not enough on practice.
The practice of programming, of building complex things in teams, is what coders do day in and day out. We don’t talk about finite state machines or discrete algebra, and you don’t need to know how those things work to be an accomplished coder.
Often theory can take away time that a student needs to practice! You can often tell productive programmers from unproductive ones based solely on the number of hours they’ve spent coding before reaching you – especially coding problems that are new to them or require them to push themselves. Understanding how to encode binary, quaternions or regular grammars has never made anyone a more productive programmer.
The worst aspect of the focus on theory, though, is that it turns people off of theory! Theory is beautiful and elegant, and – assuming you already have a solid handle on skills – it can lead you to designs you would never have built on your own that are both orders of magnitude more performant and maintainable. But only if you attempt to apply the theory! Unfortunately, so much theory is pushed on students too early that they memorize it to pass a test and promptly forget it. They don’t see how useful it is because they’re still struggling to get an intuitive grasp of programming in the first place.
Unfortunately, so much theory is pushed on students too early that they memorize it to pass a test and promptly forget it. They don’t see how useful it is because they’re still struggling to get an intuitive grasp of programming in the first place.
My advice – both to students of this curriculum and to mentors – is focus on the practice of programming from the outset. Learn how to code, then learn how to code well, and then you’ll find yourself with dozens if not hundreds of questions that will be answered in your discrete algebra textbook. Until then, just do the fun part – because theory can be fun too, but only when you have practice in mind.
Without Further Ado…
I’ll borrow from the Dreyfus Model of Skill Acquisition to break apart the larger linear curriculum into stages – Novice, Advanced Beginner, and Competency. If this is successful, I’ll attempt to provide guidance for the Proficient and Expert levels.
The Table of Contents of the Curriculum will be updated below, so keep this page bookmarked!