Javascript Has Gamified Programming

Modern Javascript has gamified programming by creating more micro-success moments (aha! finally got it!).

But we know there is No Silver Bullet[1], so it couldn’t have created more moments where you finally solve your hard problems (“essential complexity”). Instead, it has created many opportunities to beat problems you wouldn’t have in another environment (“accidental complexity”) and made it fun to beat them.

All these small annoyances create a mounting pressure in the Javascript programmer to do anything but work on front-end code, resulting among other things in the Cambrian explosion of development tools that modern Javascript is so famous for, and which is also the source of most of the accidental complexity. Tooling annoys programmers, causing them to create tooling that annoys programmers… A positive feedback loop!

Another way this pressure releases is by writing technical blog posts. Which is to say, I have an important deadline for tomorrow morning. OK, OK, getting back to work.

[1], probably the most important software engineering essay you’ll ever read

Used Car Salesmanship

I was sick this weekend and was surfing the net hoping to find a good distraction.

Among the content I was reading I found this dubious ad:

Since I was looking for entertainment, I decided that reading a sales pitch for a fake Perpetua Mobila was actually worth my time.

So I clicked the ad…

… and arrived at a sales video.

Continue reading

Becoming a Programmer

Continuation and contrapunct to Should you Learn To Code?

There are many paths you can walk to become a programmer. If you bear with me, I will try to sketch a few below. But first, let me give you a few navigational tips…

Know This

If I must tell you one blatant lie about learning that will serve you well in everything you do, it is this:

Walk a path that you enjoy every step of.

I like to learn playing musical instruments almost as much as I like playing them. Watching myself repeating the same motions again and again and suddenly become fluent in them, observing how, when not touching an instrument for a month and returning to it, I play better than when I left, the experience is a most amazing window to how the mind works.

There is one parameter by which I choose which instruments to take up:

I should enjoy the sound I make when playing it completely untrained.

If, when I just begin, I can already sit for hours and listen hypnotized to my own playing (or, in the first few days, noise), then I will stay long enough to improve. I’ll just never quit because I’m enjoying myself so much.

The same goes for everything you learn. Find a resource you enjoy learning from, and you’ll never quit. If you find yourself bored while learning, somebody else probably teaches it (or something similar) in a way you’ll enjoy more.

The Best Learning Environment

I had the great luck to study programming together with a group of friends in the same non-obligatory class. Every day at least one of us would do something awesome (relative to what we knew how to do), show it to everyone else, and we’d all run home and try to improve on it or outdo it.

I attribute mainly to this great learning environment that I fell in love with programming so strong and fourteen years later am practicing it professionally. Every member of our group was still programming last time I heard from him.

Find friends to learn with. Show each other stuff you did, try to improve on what others did, try to figure stuff out together. Play. It’s the best possible drive. Even if you’re a loner at heart like me.

If you need, bribe your friends to start learning with you (but not so hard that there is any doubt whether they are still friends). Invite them once a week for a night of programming, pizza and drinks. Go out of your way to be a good host and make those nights the best party in town. Go out of your way to make learning fun for all of you. The pizza and time spent will cost you much less than university tuition and you’ll gain much more.

Sketching A Few Paths

A Path In Red

He likes to hang out online, and he hears that today’s adventurers are doing startups, so he figures he’s gotta learn how this whole web startup thing goes. He asks on some forum how to make an MMORPG, they wisely explain to him that it’s the wrong question to ask before you have 10-20 years of programming experience but he can learn web development easily.

So he picks up Rails, maybe follows a written tutorial or a few videos on PeepCode and decides to build a forum software for his favourite boards because he can’t stand how the admins don’t allow signatures larger than 1024×768. He has a demo pretty quickly to show to his friends with lots of stuff you can click, and the praises keep him driven to try some other stuff (he got bored with the forum software when it dawned on him how much logic there is to write that does absolutely boring things).

Eventually he decides to get together with some friends and build the browser turn based strategy game to beat all browser turn based strategy games. When he’s done with this or bored with it, he finds that by now he knows quite a lot about this web-dev stuff and he can actually get a job doing it, so he does, and at work he learns good practices.

Now he’s become really good at this, he’s done a bit of everything you can do in the web, he knows a bit of graphic design (and knows CSS inside-out) from the days when he built stuff for himself, he figures he’s ready for his first Web 2.0 startup.

A Path In Blue

He likes to build robots, and though at first programming them in some awful graphical programming environment seems sane to him for lack of knowing better, eventually he needs more computing power than the chips powered by graphical languages can give.

So he gets an Arduino and installs the IDE for it. Learning the weird dialect of C that powers this particular controller is a very daunting experience, but he persists only by his strong love for robots and his deep need to make them do more awesome things than what he could before.

Eventually, he wants to figure out something like path-finding algorithms or conputer vision. He downloads some libraries, maybe gets a book, plays with it a bit, and to really do what he wants he’s forced to learn how to really use C to its fullest. Maybe (poor guy) he even has to learn some C++.

He finds that this whole AI thing is actually very interesting. So by now he moves to simulations of robotics on a PC, which allow him to use saner dialects of C, and he may even hear that Ruby and Python exist, with which he can simulate things with much less effort (but he’s already gained the technological courage that comes from starting in a very low level environment where you need to tackel the bits once in a while, he knows what’s going on down there and he’s not afraid to dive in if there is a need).

He gets more and more into academic stuff, DSP, Computer Graphics, algorithms, cryptography, all of which he finds extremely elegant, and eventually decides to get his CS Ph.D. and work as an algorithm researcher for a big high tech firm.

Side note: That DSP link is to one of the best textbooks I’ve ever seen, and though it doesn’t deal with programming and almost doesn’t talk about it, it might turn out to be a great way to get into programming, because what it teaches is such an awesome application of it.

A Path In White

He enrolls to CS in university because it sounds nice, without ever having looked into it to see what it means.

At university they teach him to program, and some other stuff which is more relevant to CS research, and he figures pretty fast that all that mathy stuff is not for him.

So he graduates, gets a job, and at work they teach him how to program. Hopefully he gets his job in a shop full of smart professionals passionate about their occupation and not in a code monkey farm, otherwise he would be in grave danger of never knowing better.

A Path In Black

He spends most of his time playing computer games.

One day, one of his friends shows him a cool program that can “find” cheats for games. You just tell it “now I have 96 life points”, play for a while, tell it “now I have 77”, play, tell it “now I have 31”, and it tells you, “Found”. Now you can press a button in the program and have infinite life points.

Usually, every game has cheat codes the developers put there. But this program can let you create new cheats that perhaps the developer didn’t want to put there. He thinks this is pretty neat, and being a very curious person, asks his friend how it works.

His friend doesn’t know, so he asks online. Someone explains to him that a game’s memory is full of numbers, and one of those  numbers represents his life points. So if the cheat program knows where it is stored, it can simply write whatever number it wants there. To find that number, the program remembers all memory cells that have the number 96, later drops all those that didn’t change to 77, then drops all those who didn’t change to 31, and now it is left with only one cell, so that must be the correct one!

Armed with a new way of thought, he ventures further and finds that he can change the monsters’ stats in the game by changing a text file in the game’s directory. He figures the images must also be stored somewhere nearby so he asks again online and they explain to him that they’re in a proprietary archive format and give him a program he can use to edit it.

He is now interested in cheat programs not because of the amusing in-game effects, but because of the technical pleasure of venturing into a game’s internals and figuring out how it works and how it can be changed to your whim.

But he all he knows is how to use tools other people created and how to do simple changes, like finding text files with game content and changing them. He asks the guy who wrote his favourite tool how to learn more interesting techniques, and gets send to learn reverse engineering.

The tutorials teach him how, by understanding the way code is represented in EXE files, he can crack copy protection mechanisms. He quickly understands how the same information is relevant to cheating in games. Just like he learned to find the “conditional jump” that decides whether he gets a nag-screen about not having bought the software and change it to never show that nag-screen, he can find the “conditional jump” that decides whether he did super-damage and change it to always do it.

Now he’s drinking this knowledge up. He spends all his days doing reversing tutorials, doing “crackmes” – reverse engineering exercises, and creating cheats by reversing and patching games.

One time he even has a dream in bits, bytes, and DWORDs.

Along the way, he learns how to program so he can release cheat tools with nice GUIs. It comes very easily because he’d spent months reading other people’s code by reversing it, so he already thinks in code, he just had to learn the tools.

One day he learns about buffer overflows. With the same knowledge of how programs are executed, he learns a technique that lets him patch the software to do what he wants just by crafting input to the runnnig program, without any need to edit its EXE file! But more importantly, the technique is technically amazing! He finds there is nothing he enjoys more than to deconstruct a program so he can craft bits in the shape that will trigger a specific program to eat his input as new code to run, against it’s creator’s intentions. (Seriously, I need at least two hours and a blackboard to explain it, but this is the awesomest thing in the world. A truly amazing experience. Unfortunately, I personally never found time to practice it.)

So he finds buffer overflows (and more advanced kinds of vulnerabilities, like heap overflows) in software, writes tools to exploit them and publishes the tools to his friends on the scene, which use them to hack into computers. He reads a bit about hacking and figures that it’s like what he used to do with games, except with other kinds of systems, like other people’s computers and web servers, so he gets into that a bit, using his own tools and his friends’ to cheat servers around the world to do whatever he wants.

Eventually he’s out of high school and needs a job, so he either uses his computer hacking skills to perform online crime (or sell tools to those who do for loads of money) or gets a job in the security sector finding holes in software so his company can report them to the company who wrote it (and earns loads of money… as far as I know security is the highest paying sector of high tech).

A Path In Phosphorous Green

There was one computer at school and it cost $50K. The only things you could do on it were play Pong and program in BASIC. So after he got bored with Pong, he learned how to program it by studying the Pong code and trying to make changes and seeing what works and what doesn’t.

Then he found a book in the library about programming, but it was for a different brand of computer. He gulped it up cover to cover and then spent his days in school writing programs in his notebooks, for a computer that he didn’t have access to, with no way of knowing wether they’d have bugs in them or even run at all.

After school he’d stay in class to have time with the computer.

His teachers eventually figured out he gets excited by computers, so they got him a book about programming the computer that was in school, so he learned that. Only later he was told that programming in Assembly language, what the book taught, is supposed to be much harder and only meant for grown-up professionals.

He’d stay in school every day until dinner, writing small Assembly language programs, later learning from a magazine how to draw things on the screen fast enough for it to seem animated and creating a few games.

From here on, everything else he did with computers was much easier than how he began, so he progressed quickly. I’ll spare the descriptions because this post is becoming too long already and you can find a ton of these stories here for example.

Today he’s one of the masters. Those I aspire to become like, and mourn not having started with something as hard which would’ve taught me much better habits and given me much more courage to face hard problems. On the other hand, I’m not sure, had I taken such a hard path, if I’d still be programming or if I would’ve given it up.

Today, the closest there is to taking this path (except for getting a Commodore 64 for $25 on eBay and learning to program it) is something like this or this. I’ll repeat: I believe (with only anecdotes to prove me right) that learning the lowest-level programming first makes you a much better programmer, but it is much harder and less “visually” rewarding (it will take you the longest to have something pretty on screen) than other paths and may kill your drive to learn it.

So Choose Your Own Path

Among these and many others, there might be a path you’ll enjoy every step of. Walk with a confident step!

Lecture 1: What We Now Know

“The only fallacy in that is that you assume your first customers will be in the mainstream. It turns for most startups your first customers are going to be crazy people like you.”

I would summarize lecture 1 as stating, “This is how a big company does things, it is irrelevant to startups because it rests on the assumption that you know what your customers want”.

Continue reading

Should you learn to code?

Should you learn to read and write?

There is a discussion on the boards revolving around the eternal question of whether “non-techie” startup founders will put their time to good use by learning to code.

Five years ago, there was still some room for discussion. These days, I believe discussing it is a waste of time:

Yes. Learn to code.

As simple as that. But perhaps it is not as obvious to you as it is to me. Worry not! I will explain, give examples and even recommend where to start.

Since this is very relevant to my interests, I will create shorter and shorter version of this essay as time passes, incorporating your feedback, hoping to eventually converge on a version that passes the message. Continue reading