October 30, 2012
Check Yourself Before You Wreck Yourself

For the past few months, I’ve been exploring software design patterns, both at their roots and in their modern implementations. I’ve been exploring new languages and deepening my understanding of the languages that I already use. Man can I ever tell ya, it’s been exhilarating.

I started reading a new book last night, given to me by a CS professor who has been extremely kind to me. It was written in 1979, published by IBM: “Structured programming, theory and practice“. In the preface to the book, the authors discuss the beginnings of the software development field (originally an afterthought to hardware, and an error-prone, cut-and-try process) and its evolution into a true discipline where a programmer could solve a problem correctly, the first time, with no mistakes. I found one statement incredibly profound, contrasting ad-hoc spray-and-pray methods with true precision: “A programmer can gain 10 years of experience, or a programmer can get the same years experiences 10 times over.” Wow. How true.

If there is any fundamental evil in the profession of software, it must be that horrible trial and error loop that is the result of a lack of understanding – about the problem at hand (if it has even been defined), the tools at your disposal, existing solutions, or all three. When we allow ourselves to subsist in such a state, we waste the little time we have on this planet. We become triflers and busy bodies, always scurrying about in a rush yet never accomplishing anything of significance.

Have you ever met someone who has been in the field for years, yet still seems to have abilities only slightly better than that of a novice? I have. In contrast, have you ever met a “whiz” who seems to make incredible progress in short amounts of time? I’ve met a few of those as well.

In Daniel Coyle’s “The Talent Code: Greatness isn’t Born, it’s Grown,” the process of building skill is discussed and examined at length. The book opens with a story about a girl who does a month’s worth of practice in five minutes, without even knowing it. This seems like a fantastic claim from the outset, but as the book progresses Coyle makes his case. Coyle claims that while duration of practice is indeed important, the method of practice is a far more effective mechanism for building talent. Coyle examines Russian Women’s Tennis Champions, South Korean Golf Champions, Brazilian Soccer Players, World Class Musicians and Singers, Surfers, Chess players, elite magnet schools and more. His argument is that in all cases – elite performers don’t simply spend lots of time in their respective courts – they spend their time doing completely different things. Elite performers focus on developing a fluency with the fundamentals. They “chunk” their learning such that each piece is mastered independently of the whole.

I feel software development is a field where this is especially true. From my own experiences, I know that my greatest personal gains have come from:

- Deep study of fundamentals. Language fundamentals. Programming paradigms. Data structures. Repetition of those fundamentals.
- Application of those fundamentals in more holistic contexts.
- Closely examining (not just reading, but PORING OVER) code written by more capable programmers

Conversely, I can say that my own gains plateau when I find myself debugging code I don’t understand, using tools I don’t understand, and staying in my comfort zone (ie writing code and designing systems I already know how to write and design). The longer I subsist in this state, the harder it is to get back to doing it right. Complacency and ignorance breed the same.

CS Lewis states in the preface to “The Great Divorce” that “when a man faces a fork in the road and chooses incorrectly, he will never reach his desired destination by continuing. He must backtrack to where the error was made and begin again on the correct path.”

A programmer will never grow in a state of willful ignorance and repetitive, mindless busy work. A commitment to knowledge and understanding, being guarded against error, a passion for our craft; These are the building blocks of growth. This is how we evolve…quickly.”

Evolving by Calvin Froedge

October 7, 2012
Programming conventions as signals

"In the end, this is a really simple idea: when you have several different ways to do something, your first choice should be the way that signals what you are trying to accomplish in a natural and obvious way. That may mean borrowing an idiom from a language that expresses that idea more succintly or more directly.

And when you eschew the natural and obvious idiom, it should be to signal that you have a different intent, that your exception to the standard idiom reflects the code’s exceptional nature.”

August 25, 2012
Poignant Advice from Rob Pike

After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, “I know what’s wrong.” He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he’d intuit where the model was wrong or where our code must not be satisfying the model.

Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.


July 24, 2012

How long will you need to find your truest, most productive niche? This I cannot predict, for, sadly, access to a podium confers no gift of prophecy. But I can say that however long it takes, it will be time well spent. I am reminded of a friend from the early 1970s, Edward Witten. I liked Ed, but felt sorry for him, too, because, for all his potential, he lacked focus. He had been a history major in college, and a linguistics minor. On graduating, though, he concluded that, as rewarding as these fields had been, he was not really cut out to make a living at them. He decided that what he was really meant to do was study economics. And so, he applied to graduate school, and was accepted at the University of Wisconsin. And, after only a semester, he dropped out of the program. Not for him. So, history was out; linguistics, out; economics, out. What to do? This was a time of widespread political activism, and Ed became an aide to Senator George McGovern, then running for the presidency on an anti-war platform. He also wrote articles for political journals like the Nation and the New Republic. After some months, Ed realized that politics was not for him, because, in his words, it demanded qualities he did not have, foremost among them common sense. All right, then: history, linguistics, economics, politics, were all out as career choices. What to do? Ed suddenly realized that he was really suited to study mathematics. So he applied to graduate school, and was accepted at Princeton. I met him midway through his first year there—just after he had dropped out of the mathematics department. He realized, he said, that what he was really meant to do was study physics; he applied to the physics department, and was accepted.

I was happy for him. But I lamented all the false starts he had made, and how his career opportunities appeared to be passing him by. Many years later, in 1987, I was reading the New York Times magazine and saw a full-page picture akin to a mug shot, of a thin man with a large head staring out of thick glasses. It was Ed Witten! I was stunned. What was he doing in the Times magazine? Well, he was being profiled as the Einstein of his age, a pioneer of a revolution in physics called “String Theory.” Colleagues at Harvard and Princeton, who marvelled at his use of bizarre mathematics to solve physics problems, claimed that his ideas, popularly called a “theory of everything,” might at last explain the origins and nature of the cosmos. Ed said modestly of his theories that it was really much easier to solve problems when you analyzed them in at least ten dimensions. Perhaps. Much clearer to me was an observation Ed made that appeared near the end of this article: every one of us has talent; the great challenge in life is finding an outlet to express it. I thought, he has truly earned the right to say that. And I realized that, for all my earlier concerns that he had squandered his time, in fact his entire career path—the ventures in history, linguistics, economics, politics, math, as well as physics—had been rewarding: a time of hard work, self-discovery, and new insight into his potential based on growing experience.


— via Robert Weisbrot

July 22, 2012
"How I explained REST to my wife"

We learned about REST this week. The simplicity of Ryan Tomayko’s explanation in How I explained REST to my wife made me smile. I don’t know much about previously used distributed systems’ architecture like SOAP or WSDL, but would probably appreciate an explanation of each in Tomayko’s style.

A quick and accessible read. Kudos, Ryan!

Liked posts on Tumblr: More liked posts »