The Code Doesn’t Care

One of my favourite things about programming is that the code doesn’t care who I am or what I do with it.

The code is inert until I give it purpose. When I’m writing code, I’m in charge. What goes on is between me, my compiler, and nobody else.

Whatever you create in your development environment on your computer is private and yours alone until you make it otherwise. Nobody else knows what you’re writing; this is between you and your compiler^*, and all the compiler cares about is whether or not the program runs. This is a tremendous sort of freedom.

Beyond that, the only accountability you have is to yourself in the early stages of writing a feature or program. The only person there to judge what you write is you. Forget about what anybody else might think; know that the code itself has no opinion of the matter and experiment to your heart’s content. Treat your development environment as a playground when you’re just beginning something new.

I have a lot of people asking me how to tell if their code is good when they’re just starting out with programming for the first time. If you worry too early about whether or not your code is ‘good’ before you even have something working, you’ll be wasting your time and sometimes you won’t even get to programming. You’ll spin your wheels and doubt every line you write or don’t write and eventually you are beating yourself up about code you haven’t even written yet. You’ll procrastinate while you worry about details that don’t matter, and then you’ll wonder why programming is so hard. It’s not hard, but you’re doing things in the wrong order. Your desire for goodness is healthy but the satisfaction of it must be delayed.

Get it up, then get it right.

When you’re just starting out—whether you’re learning to program for the first time, or maybe learning a new trick for your trade—you should measure your success by only one criteria:

Does the program do what I want it to for the end-user? (If you’re a beginner, then this is probably yourself.)

And that’s all. If you can answer this question with ‘yes’, then what you are making is good. Don’t worry about what anyone else might think about your code. Don’t even worry about what you think of your code yet.

You don’t have to show what you’re making to anyone until you’re ready, if at all. Get it out dirty and fast and messy if you need to, with passion and without remorse. Nobody has to see your first draft. A novel is not written from beginning to end and then shipped to the publisher without being edited or revised. Code is not written once and then deployed to the users without testing and iteration. Write something, anything, and then come back to it; put your ego aside so that it’s just you and your creativity and your fingertips.

^* Note that for all intents and purposes in this piece, ‘interpreter’ can be substituted for ‘compiler’ to reflect your language of craft accordingly.

When you are not programming, you are still a programmer too

When you are not programming, you are a programmer still. It doesn’t leave you.

When you walk down the street after work and you leave your computer behind, your analytical mind stays with you. If you really want to get better at programming, start finding ways to solve the same kinds of problems you see in your code everywhere else in your life. Probably you are solving many of them already every day and you don’t even notice it. The last time you travelled to complete errands, did you try to take the route that you thought would take the shortest amount of time? Do you try to do your dishes while you have a load of laundry in to parallelize your household tasks? Have you ever followed an algorithm of pictographs to assemble IKEA furniture? Have you ever played a video game and tried to find ways to get the highest score? If we are aware of our penchant for problem solving, then we can embrace it. Good problem solving is at the core of good programming practices.

Always ask why about everything in front of you. I think this is something we are told to do as kids, but as adults many of us become a little arrogant and pretend we are beyond needing this skill. We become smart adults doing adult jobs and we pretend that we know enough and get lazy and we stop asking why to the little things we take for granted. Why do the doors on our office building push inward instead of pull out? Why is the elevator slow — how does it make its decisions about what floors to stop on? Why did the designer of that poster use that particular typeface to convey their message? Always ask why, why, why in and out of your domain. Ask why in some of the most unfamiliar situations and then try to use your reasoning and other programmer skills to come up with a solution. It doesn’t matter if you ever know what the right answer is, only that you’re making an effort to try and solve the problem for yourself. Have fun with it and be creative, and find friends who take pleasure in this pastime as well. You’ll end up having interesting conversations that lead you back to working on your problem solving skills.

Strive, with consistency, toward self-awareness. I mean this in a very practical and pragmatic way, not in a new age fluff kind of way. This is basically a different application of the previous point of asking why. In the previous paragraph, I explained that it is important to ask why about the world around you. Perhaps more important than that is asking why about yourself. Why do I like to play the piano? Why do I procrastinate the things I love sometimes? Why did I write an email I sent in the tone that I did? Even the act of selecting what to wear in a given day is a design problem waiting to be solved depending on who you expect to see and what role they play in relationship to you. Pretend you are an anthropologist specializing in the study of you, and ask why, why, why. You will understand your own patterns of decision-making, and eventually your own cognitive biases. You will understand why you do the things that you do and that will include why you program the way that you program.

When you question everything, you find the places in structures and organizations around you and within you that can be improved, and from that comes meaning and purpose when you are rewarded by that awesome feeling of solving a problem. When you come back to the computer you will have better questions to ask that will make you a better programmer.

This pastry box cupcake is dedicated to Natalie Goldberg, the inspiration of which is taken from the first two sentences of her piece “Be an Animal” in Writing Down the Bones — the best book on writing that I have yet to read.

How to know you’re not a beginner anymore

Once, at a conference, someone bragged to me that they were really pleased that their entire development stack was implemented in one language. I can see how this would be a good thing in certain circumstances. What it’s not good for is your breadth as a programmer. It’s good for your core competency of the syntax of a particular language, but it’s not good for your problem-solving brain because it only teaches it one philosophy or methodology. When it comes to JavaScript, for example, a big revelation as to how I thought about solving problems came when I realized how much JavaScript really is a functional language in disguise. I wouldn’t have noticed this as early as I did, though, if I hadn’t exposed myself to LISP before.

In the last year I’ve written code in C, Objective C, Ruby, MUSHCode, JavaScript, Lua, and Java, and so I tell myself that I can say I am not a beginner at programming because I can demonstrate a core set of fundamental skills that transcend language. This was a really satisfying moment because I’ve been trying to think of better ways to represent achievement to people who are learning to program. Sure, success is getting your program to run but eventually that’s not enough and you start asking yourself how you can make it better. That means knowing how to write good code which is really, really non-obvious to someone who’s just come from their first steps as a beginner. Similarly, I wondered to myself by what criteria I could say I’d mastered ‘beginner’ programming topics so that I could define them and the goalposts for someone else. I think that we can say that someone is no longer a beginner at programming if they are not afraid of programming in another language, and maybe on their way to being a more sophisticated programmer for not being averse to it.

Signs of Programmer Expertise

Last month I baked a strudel about how to know you’re not a beginner anymore. I found this exceptionally useful as a kind of lower-bound I could put on my skills and knowledge; I could say that there were topics I could move forward from and thus move towards more advanced material with confidence. This month, I’m baking a cookie about how I know that I’m not a master at programming. In fact, I’d even go as far to say that there are no masters.

There is no such thing as a grand ultimate master of programming because the goalposts will always keep moving. If we were to take the top ten percent of programmers, we could say that those programmers are probably experts. We would still have the problem of defining what criteria includes people in that ten percent, which is an altogether different matter. But a master? The term ‘master’ in the context of ability is usually reserved for someone who has studied an art or science so thoroughly that they have complete knowledge and skill over said art or science. When it comes to programming, there are no masters because the landscape of programming changes dramatically as new technology is forged.

There are always new tools. There will be new languages. The hardware will change. The software will have to adapt. You will have to change. You will have to adapt.

Sign of Programmer Expertise #1: The programmer understands that the learning will never stop and is at peace with how quickly the tools and landscape change.

The expert who you look up to — you know the one, they’ve written that sweet library you use so much, and you’ve read all of their books — cannot and should never halt on the notion that they have achieved mastery. Programming will move on without them. Maybe they’ll have mastered programming circa the year 2013, but the rest of us will go on without them if they stop there.

So what about that top ten percent? We know it is unrealistic to say we will be masters of this domain. We made peace with that at the end of the last paragraph. How do we approach criteria that describes someone as an expert programmer? The dialogue is ongoing, and I hope that through it we’ll eventually be able to convey to those who want to learn programming the kind of expectations they have to meet to be the best of the best.

Sign of Programmer Expertise #2: If you are an expert at programming, in at least one language you must be able to code as though you have a gun to your head, without a language reference.^*

I know what you’re thinking, that most programmers always have a browser tab open with an API or language reference. Nobody actually codes without at least some of that stuff in their day-to-day job. I know I do. This makes sense for when you are trying to make something for someone else and you are on a budget of time, money, or both. Often it makes sense for you personally too, when you’re on your own time making your own wonderful thing. Because you value your time, you want to have all the resources you need so that you don’t have to remember the name of a function that you’ve forgotten while you remember the essence of what that function is supposed to do. You want to accomplish building something for yourself in a reasonable amount of time.

This is good for building things and shipping them, but what it’s not good for is your mastery of programming.

This may seem in direct contradiction to what I said last month. In my last pastry, I explained that you have to be able to program in different languages than the one you are most comfortable with to say that you really know programming and not just the language. This is true. However, this is like saying that if you are learning to swing a sword, you should be able to use almost any sword. There are differences between a broadsword and a rapier, but by understanding the basics you can probably figure out how to use each reasonably well. Despite this, a swordsperson probably has a preferred type of sword, and since there are all subtle differences between them the swordsperson will probably only be able to become an expert with one or two. The same is true with programming languages. While you can broadly apply your skills to any language to create something, it is the concise practice of a few languages that will yield you the most satisfying results.

Sign of Programmer Expertise #3: The programmer is not merely satisfied with solving the problem, they insist upon solving it in an efficient and robust manner.

I’ve had so many people ask me, ‘how do I know if my software design patterns are good, and how do I measure that? ’. Write tests. Measure execution time, function complexity, memory usage, and whatever else you can think of. Benchmark your code against other code. If you can balance your optimizations with code readability, then your design pattern is probably pretty good. The numbers won’t lie, so stick to those and don’t worry about much else.

Sign of Programmer Expertise #4: The programmer knows how their parser/compiler/interpreter works. Intimately.

The programmer who wants to get better at designing software will inevitably get to a point where they can only optimize so far without an understanding of how their language is parsed, processed, compiled, etc. To know the nuances of how the machines speak your language is as big an endeavour as learning the language itself. It will require you to think about your language by picking it apart instruction by instruction to see how it was designed. At some point, you should aim to write a programming language or compiler/interpreter just to understand what the designers of a language or compiler/interpreter had to consider when making the ones you work with every day. You’ll understand the concessions and caveats that cause the quirks of your language that you never had reason to understand before. This will help you learn your language inside and out — I mean you will literally know it’s insides.

Sign of Programmer Expertise #5: ???

As I’ve mentioned before, this is an ongoing dialogue. I’m hoping that the few ideas I’ve exposed here are enough to get you thinking about where you want to go next with your programming skill, and that someone out there will tell me what the #5, or #6, or #7… in this list should be. I have no idea. I’m just doing the same thing that the rest of you are doing; I’m trying to navigate my way through the ridiculous amount of information available to pick and choose the most reasonable course for success. So, if you know what comes next — tell me. I’m all ears.

*Baker’s note: Please don’t ever, ever put a gun to your head even as a joke.

Impostor Phenomenon

If you write code, if you participate in the act of programming, then you are a programmer. We can add a clause to this that suggests regularity — someone who programs often is a programmer. That’s all it takes to be a programmer. It doesn’t matter if you’ve just started and worked your way through the fundamentals like control structures and taming functions. It doesn’t matter if for some reason you don’t feel like a programmer. It doesn’t matter if someone pays you or not, unless you really find it important to be a professional programmer. If you program and you do it over and over, you become a programmer.

Last week I had the privilege of being amongst the speakers at JSConf 2013. The best part about this particular speaking opportunity was that I was able to give a non-technical talk about programming that I’d wanted to give for a long time. It was a culmination of all the things regarding learning to program that I’ve talked about here on The Pastry Box stitched together with further anecdotes and advice. It talked about cognitive biases and tried to convince people to get their biases out of the way so they could realize their potential. One of the slides in my presentation addressed impostor syndrome (known as impostor phenomenon in peer-reviewed, formal research) as it relates to the craft of programming, but really the point I was trying to make could be applied to anybody in any field.

Impostor phenomenon, explained simply, is the experience of feeling like a fraud (or impostor) while participating in communities of highly skilled participants even when you are of a level of competence to match those around you. Impostor phenomenon is highly correlated with individuals who are successful; arguably success here means success as perceived by others. The important thing to note is that this experience isn’t isolated to people we perceive as experts, only that it is a counterintuitive notion: one might assume that as they develop their skills in a craft further that their confidence should increase and their insecurity about whether they are good and whether they belong would fade away. It turns out that this is not the case for a lot of people.

I found myself wondering if my talk was going to be all that useful to the people I perceived as experts; I questioned whether or not the smart people I admired that I knew would see it were going to find value in this thing that I had made to share with everyone.

I gave the talk, and afterwards several of them thanked me for that slide. Some of them my heroes, they took me aside and confided their thanks. They confided their relief.

In the end I wasn’t shocked that the successful people I admired had experienced impostor phenomenon and talked to me about it — I was shocked that I somehow thought the people I see as heroes were somehow exempt from having it. I did the one thing I didn’t want to do: make that assumption about anyone.

We’re all just doing the best we know how to when it comes to programming, it’s just that some people have more practice coming across as confident than others do. Never mistake confidence for competence, though.

I’m just going to put this out there: to anyone of any skill level who reads this, if you’re ever feeling like you’re a fraud in your field; if you ever feel alone or if you worry that you’re not smart enough or good enough as the next programmer, just come talk to me. I’m a busy person by design because I can’t stand to be idle, but I’ll make time for you because feeling this way is isolating, lonely, and not constructive. I think of all the missed opportunities I let pass by all because I was worried about making mistakes, not being perceived as an equal by my peers, and all the code I never wrote just because I was intimidated by all the great code and smart programmers out there.

I want to listen to what you have to say, to tell you that you’re not alone, and that your heroes are human too just like you.

A Quick Follow-up on the Importance of the Language We Choose

In my recent article on The Pastry Box I specifically chose to use the term ‘impostor phenomenon’ instead of ‘impostor syndrome’ throughout the entire article. In most of the peer-reviewed research I read I saw this reflected as ‘impostor phenomenon’, but it has been pointed out to me that ‘imposter syndrome’ is used fairly often to describe the same thing.

In fact, the latter is used colloquially far more often than ‘impostor phenomenon’.

I made the choice to use ‘phenomenon’ because the word ‘syndrome’ carries with it a host of negative stigma that is wholly unproductive. The term ‘phenomenon’ in this case is at worst a fairly neutral term. Whether or not we recognize that ‘syndrome’ is, in fact, a clinical term that could apply here is orthogonal to the impact that using the term has on those experiencing these feelings, emotions, and experiences.

It has negative stigma. Negative stigma is not helpful to anyone.

Whether we like it or not, words take on cultural additives as we use them. A word may begin it’s career as an idea meaning one thing, but eventually evolve to mean multiple things or something else entirely.

We are all very impressionable. Unconsciously so, even those of us who like to think that we have a thick skin. You cannot escape the unconscious processing of subtle meaning, if you think you can you are a fool. If anyone is interested in talking about this particular point — there is a host of cognitive science research waiting for you.

That being said, the words we use are immensely important, and so I implore you to use the term ‘impostor phenomenon’ when describing these experiences. It makes a difference.

Whenever I hear someone complain that advocates of careful language are trying to be ‘too politically correct’, ‘sugar coated’, or ‘too nice’ I feel sorry for them. I feel sorry for them because they don’t understand the difference these things make, and worse they don’t understand how vulnerable they are. They lack the self-awareness that will set them free if they’re ever upset about something someone has said about them.

“Sticks and stones will break my bones but names will never —”

Wait, wait. I know this one. Sticks and stones will break my bones. Those will heal up, because biology can do wonderful things like that. But words? “Names will never hurt me” is usually how the rest goes. Those words can still be with you months, years, decades later. They can torment you when you’re trying to fall asleep, apply for a job, or make a new friend.

Words have power because they have meaning: treat them with respect, and treat others with respect accordingly.