How to Learn to Learn to Code

This is list of things I wish that someone had told me as I was first starting to learn to code. There were a lot of places where I got hung up or thought I was doing something wrong during that process, that turned out to have been relatively simple once I did know them. This list is definitely incomplete, and probably inaccurate in places, so feel free to post additions or corrections in the comments.

  1. If you don’t know where to start, start with a scripting language. Python or Ruby are the standouts here; once you know one you’ll be able to pick up the other, so don’t worry about which too much. The important thing is that you be able to create programs by creating a file in a text editor and run them from the command line.
  2. Find a website that can teach you the basics– something where you write a bit of code and it gives you feedback immediately. I recommend Code Academy but there are a lot of options. Find one that clicks for you.
  3. There are a lot of very important things about coding that this website won’t teach you, like how to get a program running on your own computer.
  4. Get a copy of Notepad++ (Windows) or Sublime (Mac)
  5. Installing your chosen scripting language may be surprisingly hard the first time. You’ll get the hang of it, but you may run into problems that you haven’t learned yet how to diagnose. If you get stuck, find someone who’s done it before to help you.
  6. Get a reference book to your chosen language and its standard library, and never be afraid to look up how to do even simple things. The best programmers I know regularly look things up– coding is not about memorization.
  7. That said, it’s worth getting a sense of what your language’s standard library does so you can go “oh, I bet there’s a standard string method for this, lemme go look that up” when you need to.
  8. If you’re working on a Mac, get Homebrew. Package managers will make your life easier. If you’re working on Windows, consider learning how to use VirtualBox to run a Linux VM, for the same reason.
  9. Find someone who you can ask questions about definitions. There’s a ton of implicit knowledge in programming that people who already have it take for granted. Also, programmers are often bad at naming and describing things.
  10. Your $PATH variable is just a list of places that the operating system looks when it receives a command, (like “python <filename>”) for an executable that executes that command. Just add stuff to it. It doesn’t have to be elegant, and as long as you don’t delete anything you won’t break anything.
  11. A “dependency” is a “a thing that if it changes might break the system I’m talking about.”
  12. A “stack” is “the collection of different technologies that make up this application.”
  13. An “environment” is “the things that code might interact with or depend on in the system that it’s running on.” “Setting up a development environment” means “installing tools and configuring settings on my computer so that I can write code more easily.”
  14. An “API” is “the method that a system or library gives to other systems for using its internal commands.” A coding language itself is an API of sorts, for giving instructions to the language’s implementation, and that implementation in turn uses the operating system’s API to give commands to the host system’s CPU, hard drive, and so on.
  15. At some point, get either virtualenv (Python) or rvm (Ruby). These let you tie your project to a specific version of the language, and then to install libraries only for that project. You won’t need them immediately, but when you start working on projects that use multiple libraries, and sharing them with other people, they will make your life easier.
  16. You don’t need a framework to make a simple website. There’s a way in your language of choice to install a simple web server and write a few lines of code that will make it serve HTML, CSS, and Javascript files from a particular folder.
  17. You can do a lot of web stuff with just HTML, CSS, and plain Javascript, and it’s worth learning to do.
  18. You will do a lot of debugging by inspecting the values of objects and printing the results to the console. This is fine and good.
  19. Learn TDD. Better yet, find someone who can pair with you to get better at TDD.
  20. Learning to read API documentation is hard. It will get easier once you’ve done it a lot, and once you start writing similar code yourself.
  21. One of the best ways to learn to code better is to read other people’s code. Even better, read it, run it, and then make changes to it and run it again. (Of course, learning how to do all of that is an exercise in itself.)
  22. It’s okay to write code the simple way, rather than the clever way. When you read code that takes a lot of work to figure out how to read, that doesn’t always mean that the person who wrote it is a better programmer than you, even if it’s doing something cool.

Confidence or Information?

When context-driven software testers get together or talk online about testing, a lot of what we’re really talking about is bug hunting. Finding bugs, figuring out whether they matter, and communicating them efficiently to stakeholders are the main skills that I’ve noticed that people in the community care about. We tend to describe our role on teams as “looking out the window” or “holding the flashlight.” Testers, in our view, gather information and then package it for an audience, generally one or more stakeholders.

But I’m not sure that this is what our clients expect of testing, and even what testers outside of the context-driven conversation see their jobs as. In general, in fact, I think they see the tester’s product not as information, but confidence. They’ll say “test it and make sure it works. Even if they’d agree that’s not possible if you asked about it, I think that phrase reveals a lot about people’s basic beliefs about what testing does, and why they want it.

And honestly, they’re not wrong to want that. The value of a bug free product is obvious; the value of information is a a little more ambiguous. I mean, heck, the reason that the CDT community cares so much about information isn’t that we care about it as an end in itself, it’s that we see information as the primary tool for removing bugs, and making good decisions about the software project.

So maybe there’s no conflict here. Maybe confidence is the ultimate product of all that knowledge of that we’re so good at gathering. We focus on getting a good flashlight and deploying it skillfully, and our clients don’t care as they feel like they know enough about what’s out in the darkness.

I think it goes a little deeper than that, though. In fact, my private theory is that this is one of the big reasons it can be so tough to pry people away from test scripts and massive test plan documentation and certifications. None of those things help you find out about the product, but they’re great at creating the illusion of certainty. People who really want confidence will happily take fake but convincing certainty over real but uncomfortable knowledge.

Is this just a terminology problem? Does good information gathering inevitably lead to confidence? Is this a general problem for exploratory testers, or is this just my particular challenge, due to the way I approach testing? I’m still working on the answers to those questions, and a bunch more, but the more testing I do, the more this issue has been gnawing at me.