More than the sum of its parts

To program a computer is a surprisingly invigorating and engaging task given how sitting and squinting is involved. You can leap from idea to idea, and wrestle with conflicting “objects” and “behaviors” for hours, despite the fact that you aren’t dealing with anything physical at all. Nonetheless, programming brings the satisfaction of instilling a little order in a diverse universe of systems and goals. In my first few positions in the IT industry, as a web programmer, I had the privilege of guiding some pretty expensive servers to outcomes that I had minutely chosen. When it worked, it was very powerful and rewarding. Of course, there are also the myriad of ways it fell apart; objects squirming out of my grasp, connections forged one day would break down the next, and little tiny currents of logic that were humming along just fine for weeks would suddenly crash into each other. This usually happened in the development phase of course, not in a “live” program.

I found that for me the most rewarding form of programming was front-end web programming. In that arena, my code was responsible for the presentation and control of webpages on e-commerce sites. But that’s such a dry way of putting it. Really my code took the customer by the hand and guided them through experience of shopping with us and our products. Each click of their mouse and each scroll of the page is crafted by my commands. In this, the code begins the relationship with the customer. And without the customer knowing it, I was walking them through this massive and interdependent network of hundreds of computers, databases, data-queues, fail-safes, and error-handlingsystems. They are exposed to power of a database containing millions of products, to see reviews of from thousands upon thousands of other customers, and are able to put in motion the fulfillment and shipping systems to obtain their desired item. My work saves the user from having to venture into that forest of systems on their own, and it’s a pure thrill to know that it’s my choices I have made in the code that are successfully coordinating the clicks and actions of so many people. My goal is that each of their experiences was just as pleasant and as simple as walking into physical store and asking a real person for help, if not more pleasant.

But that’s the big picture. The actual act of coding day-to-day is a little less thrilling (but only by a little). Coding a new web page or web system is like painting a new work of art for me. Each command of code is a brush stroke in a scene being presented to the user. Simplifiying this a bit, the work I produce is a series of lines of text, each one with it’s own meaning. A line of text boasts one or more english-looking commands, such as “Write $greeting” or “call errorMessageDisplay”. The verb-like words in this example are comands that a computer can understand. It’s not that it comprehends the directives literaly, but that it can marshal a lot of…well, I’ll call them “dictionaries”, each containing the definitions of millions of commands. When you instruct a computer to execute a command, it first finds its definition. The definitions are in turn composed of several other separate commands, which, just like the original, are themselves collections of other commands too. It would appear that the directionaries could keep refering to deeper and deeper entries until you’ve run out of words too look up, but the final piece of the puzzle comes from a hand full of commands that the computer actually knows intimately, and which don’t need to be looked up anywhere else.

These baked-in commands are wired into computer’s microprocessor and are executed in its physical circuitry. They are very simple actions like add-these-two-numbers, subtract-these-two-numbers, save-this-new-number, and get-the-next-number, etc. The intel processor chips have a few hundred basic commands that handle most all microsoft windows based computing.¹But they can be chained together in a sequence that does something useful and executed again and again at astounding speeds. So if you’re looking at a picture from a family vacation on your computer screen, the microprocessor would have run thousands of operations designed to move individual numbers stored on the harddisk to locations the screen can read – each number representing a small piece of information about the image you wanted to see. The microprocessor is not aware of the idea of an image or the idea of family trip you took – it is simply moving small peices of bite-sizedinformation, one at a time. So, computers are amazing at doing very simple things, again and again. Displaying all the millions of bytes of data that make up the family picture took a fraction of a second.

In contrast, as a programmer, your work rests on the other side of this equation. Instead, we can comprehend the big picture. As humans, were not able to perform billions of repetitive actions. We can look at an image and respond with the conceptions “beach”, “vacation”, and “fun”. We can hold very high-level concepts in our heads with ease; without even trying, we dream in highlevel concepts. So our work as a human programmer is to identify and codify those large brush-stroke ‘ideas’ as new commands, based on a collection of smaller commands. We first locate the language of instructions that will help us fulfill the goal of the project, and then we list out individual new instructions for the computer to execute, manytimes bundling them up into a new command. We may create commands that tell the system to show the customer an image of a set of products, or to present them with an option to search for a new product. And it can be such a pleasure. It’s a giant cross-word puzzle where you get to decide how the billions of bytes and miles of microcircuitry should all march together.

Resonance through good team work – Agile vs Waterfall

I’ve had the privilege to see my work blasted out across the internet and downloaded by millions of users. To achieve this scalability and adoption, I’ve worked on many projects and technology teams at BarnesAndNoble.com. The most effective projects I’ve launched were those executed in an Agile – or near-Agile – plan of attack. Having everyone involved in the creation of a product present and accounted for each day generally made all the difference in the health of an endeavor. I’ve seen firsthand how one or two team members working through the challenges in their roles and giving their best tends ripple through the team and inspire everyone to re-double their efforts – a product manger can inspire a developer, or a designer inspire a QA-specialist. And when each person’s role is focused on a single project, it is that much more likely they will reach out and rely on each other to solve problems – problems that would normally be insurmountable when working alone.

When co-location is not possible, I like to strive to help create the sense of a cross-functional team as much as possible. Even if my team is not sitting together, I like to make sure my work is visible to everyone, each day. I like to avoid surprises at the end of a project where suddenly the long-awaited demo reveals that we’ve been misunderstanding each other about what the new program should do. I also like to re-double the efforts to separate out the requirements into independent morsels, allowing each to be explored, estimated, negotiated, and even coded and tested separately. I’ve seen disparate and nebulous teams still work effectively when the goals of the mission were accessible and bit-sized.

But I’ll always prefer a tight-knit, dedicated group of specialists representing the skill-sets needed to bring a large-scale new product to the customer. Our success is tied to the success of each other’s work, making us self-regulated. Our daily goals can routinely revolve around unblocking others from waiting, making our focus the success of single new feature, and steering us away from unnecessary overhead or wasted time that is unrelated to the project. And our celebration in a successful launch is shared across the team, making the effort that much more rewarding and visible to the rest of the company.

So, when you find yourself at the end of a project with an outcome that makes you proud, grab a friend and walk through the code together, find the parts that you both like, sketch a little map showing how you think it could be improved, and learn from each other’s observations – from what each of you is drawn to. And your different passions and insights will not go unnoticed by the customer.

I also have a quick page about my past coding work.