Passion is used as a code word nowadays by many hiring managers. It means “will work a lot of extra hours for free”. Rightfully so, many people are turned off by this idea about passion, about passionate developers, about looking for passionate hires.
But you have to give the mislead hiring managers a little slack. After all, they’ve been asked to hire good talent, so they look around at the company and they ask “well, who’s good here, and how do we hire more of them?”
They see some of your best people putting in hours on the weekend, staying late, and taking their work very seriously. And they – without much critical thought – think, “Ah, yes, it’s those type of people we want. I’ll just hire more of them!”
But here’s the problem – those people aren’t passionate they’re engaged. And there’s a huge difference.
Passion is hired. Engagement is earned.
In fact, even the above is a simplification, since ‘passion’ is so hard to find. You really have to find boy-geniuses (and they’re almost always males) fresh out of school who seem to know the latest technology and be willing to work all hours of the night because they don’t know any better.
Then they churn out some hacked together crap as fast as possible, and seem to provide evidence that you have to hire passionate people who are “smart and get things done”. People who are worried about “work-life balance” or “working smarter, not harder” aren’t going to fit into your “workplace culture” – you hire passionate people and expect the best!
But you have no diversity, which means your innovation sucks. And you have no senior developers, which means your quality and repeatability sucks. You have software that sometimes works and is a few months away from crumbling under its own weight. You wrote facebook in PHP and have no idea how to add new features to stay competitive – everything seems to take forever to change.
Engagement is frequently confused for passion. Engagement is “I believe in this company and this project.” Can you hire engaged people? No, how would you? You can’t truly believe in a group of people or what they work on until you’ve… worked with them. Usually for awhile.
There’s no question you can ask in the interview process that’s going to determine whether someone will be engaged or not. That’s because everyone is capable of it. Everyone can become engaged – they can believe in the people they work with, and the project they work on, and when they do that they become internally motivated to push hard for those two things.
So instead of hiring for ‘passion’, try hiring good all around talent and build a team that people are proud to be a part of, and a project that they’re proud to work on.
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.
Are there resources you’ve found you found particularly useful? Are some of the listed resources redundant? Please let me know so we can keep this clean and up to date!
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”