The history of this site goes back to a document I prepared at work called “Mind your Ps and Qs”, which I wrote in Microsoft Word, printed out and pinned to my corkboard. I was the only full-time programmer at the IT department at the time and “Ps and Qs” was nothing much more than a checklist and a handfull of reminders to myself. Some examples of what I put on it:

• Set the background color of the form to Khaki within #IF DEBUG clauses, so users can tell if you’ve accidentally pushed a debug build into production again (yes, I did this all the time, and users ended up wasting their time writing to the devel copy of the database instead of the production copy)
• Never push an update to production until you’ve done an SVN COMMIT
• Log every INSERT, UPDATE and DELETE before you do it

 and so-on. At first it filled only a single printed page, but as the company expanded and I had to hire more programmers, it grew until it had a basic style guide and a list of “dos and don’ts”. Now I was printing and binding a copy for each new programmer joining the team, which was great for me because it kept them busy on their first day while I tried to think of an assignment they could do.

 Yet what I’d begun to notice was a steady improvement in my own coding skills, directly related to how much thought I was putting into writing these booklets of mindless programming tips. Pride had become engaged in quality control: I hated it when I wrote something that turned out to be wrong because it hurt my pride, so I spent extra effort in research and review–making sure what I wrote at the time was right, and combing through prior tips to verify and correct what I got wrong.

 Like when you return to old code and make a “nasty smell” face at it, returning to old tips months or years later made me feel sick with embarrassment. It got to the point where I had to stage a self-intervention one day when I realized I’d just spent the better part of a work week editing the “Ps and Qs” rather than writing code for my employer.

 This hadn’t been my first taste of writing about programming. Back in high school we had a rather excellent computer science department, headed by a man I’d come to consider my best and favorite teacher–Mr. Vagliardo. Mr V. had an unusual teaching style aimed to make his students think for themselves. On the first day of class he instructed us to give him a spoon with our name taped to the handle. Why? He wouldn’t tell us, it was our job to figure it out. I do remember seeing the drawer he kept them in–hundreds of spoons from students throughout the years. My spoon had the British Airways logo impressed on the handle, taken from our migratory flight over here. 

 Mr V. also posed a puzzle for us to solve: How is Mickey Mantle related to Honeysuckle Drive? For days we lobbed conjectures at him: did he used to live there? Is there a Mickey Mantle museum located there? Is it an anagram for something related to Mickey Mantle? Is there a ball park on Honeysuckle Drive that Mickey Mantle played at? Of course, Mr. V. wouldn’t give us the answer. Soon we discovered that “Honeysuckle Drive” was a label for a street in a map diagram of the computer science textbook we used for the class, which fed a new round of conjectures. Still we didn’t have the right answer. 

 I was thinking until smoke came out of my ears, trying to overcome the disadvantage of growing up in a culture without Baseball, but then I sought to enroll the help of my dad. He’d never heard of Mickey Mantle or Honeysuckle Drive either (he’s more British than I am), but he promised to ask his friends about it at work. The next day he came back, “I think I know what it is, son!”

 “Whuzzat?”

 “Well I was telling someone about it at work, and when I mentioned Mickey Mantle they said ‘Oh! Old Number 7!’”

 Mickey Mantle’s uniform number, retired by the Yankees the same day he did, was #7. The diagram of Honeysuckle Drive was on page 7 of the textbook. Go figure.

 Mr. V’s mantra was “Everything is related to Everything”, and these puzzles were just part of his agenda to make us see beyond the page, beyond even the code, and to realize that computer programming–like art and sports and coincidence–is part of and connected to everything else in the world, by no matter how thin a thread. Everything is related to Everything. Maybe it’s no surprise, then, that it was he who introduced me to Gödel, Escher Bach.

 Then came the day well known by CS students in every school, the day we dealt with pointers. In colleges this is usually the day before half the class switches majors. In high-school the dropout rate was less visible, you just had some kids who switched-off inside but kept coming to class every day anyway. Particularly hard to grasp was the linked list, which you either “got” or did not, and because I “got” it and had the gene for explaining things to people, I set about trying to explain pointers and linked lists to the other students. The primary conduit for this was a document, written in Ami Pro 3.0 (still the best word processor ever made), that I called “101 Linked List Analogies”. An example of one went like this:

A mountain climbing expedition has got itself stuck half a mile up Mt. Everest, and due to a particularly bad misjudgment are all dangling over a precipice, hanging only by the safety rope tied to each member. Each rock climber is connected to the next climber above him, with the exception of the team leader who is the anchor point and still clinging onto solid rock. The team leader is your first node in the linked list, and each other climber is another node. The rope represents the pointers between nodes. Now as it happens, one of the members halfway down has a piece of equipment that the team leader needs to pull them all up to safety, but the only way to get this equipment to him is for that member to ascend the chain. For this to happen, the member has to remove himself from the chain without losing all of the climbers below him on the chain. If he disconnects the line connecting him to the climber above, then both he and all the climbers below will plunge to their death. If he disconnects the line connecting him to the climbers below, then he will be okay, but all the climbers below him will plunge to their death. In order for him to ascend the chain without half the team plunging to their death, a pointer (rope) has to be transferred from the climber above him to the climber below him.

 This was probably the last one I wrote, somewhere around analogy #31 or so before I ran out of steam. There’s only so many analogies you can write before someone grasps the concept of a simple linked list, after all.

 The upshot of all this is that I had been one of the first students that year to begin implementing linked lists in my programs. I even remember Mr. V. leaning over my shoulder, looking at my screen at a Pascal Record I was writing, and remarking “that’s a linked list, we haven’t covered that yet.” I guess I was totally “into programming” at the time, reading chapters ahead into the textbook.

 And so I was becoming dimly aware of a trifecta that helped me advance in programming skill and knowledge. I was reading as much as I could about programming, then trying out what I was learning in my programs, and then writing about programming in an effort to teach others.

 Two decades later (boy does that make me feel old), I started this site. “Yacoset”, or “Yet Another Collection Of Software Engineering Tips, began by copying my rambling collection of crap written in Microsoft Word into a new Google Sites account. Every now and then I’d think of something else that I could write about and–for better or worse–submitted it to the world. Much of the feedback was positive, but the best feedback came from people smarter than me on Reddit and Hacker News telling me I was full of shit. What happened is that I just went back and did more research, purchased more books, swotted until 2am some nights, and fixed the damn articles.

 Mr. Vagliardo did not want to spoon-feed his students, he wanted them to learn for themselves. He used an act of symbolism to get them to give up their spoons and begin looking for answers to puzzles on their own. And he did get us started on the third leg of the stool–writing about programming–by making us write an essay about why Everything is related to Everything. My copy of the essay is probably lost to time now, kept on a 3.5″ floppy disk that I don’t have the equipment to read anymore, if I could find that disk among all my junk.

 My bookshelf has expanded since I began “Yacoset”. Fowler’s Refactoring, the Gang of Four’s Design Patterns, Abelson and Sussman’s Structure and Interpretation of Computer Programs, and lots more I could presumably earn a few Amazon affiliate bucks from. But key to all of it is the writing. It completes the learning process. A programmer must not be afraid of writing something wrong so long as he or she has the humility to fix it after someone finds error–even when they’re not particularly nice in the manner by which they point it out.

 It doesn’t matter what the medium is, it doesn’t matter if you blog, or do essays, or write comments on other people’s work, just as long as you attempt to condense your knowledge. This feedback loop, for me, is what it’s all about. I emphatically do not believe that it comes just from writing code for years and years, because some of the worst programmers I made the mistake of hiring had resumes covering 20 years or more of programming experience, and yet couldn’t code their way out of a paper bag.

 To become a better programmer you must have a reason to be a better programmer. Around this reason, this impetus, you will be driven to practice all of the things that all of the best programmers do by instinct. Such as:

1. Read and follow code written by other programmers, even bad ones. Think about why it’s bad, or why it’s good
2. Read your own code a year after you’ve written it, then refactor it to improve it, to make it faster, more efficient, and easier to understand and modify
3. Read books about programming, not “Become a C Programmer In 29 Days” or “PHP For Morons”, but books about general programming concepts. Read even the books about technologies you don’t think you’ll ever build or use yourself, such as compilers, functional languages, or machine-code assembly languages
4. Write about what you think you’ve learned. Let other people read it. And have a stomach for the feedback you’ll get

 I don’t really know or care if it takes 10 years or 10,000 hours to become a good programmer. It certainly didn’t happen for me overnight. In my opinion, everyone should learn how to program computers and–in the future–I believe it’ll be as important as basic literacy, be a required course in grade schools, and required for all but the most menial jobs. 

 Even the original approach of “Ps and Qs” had the kernel of an important idea. Little did I know, but at the time the world of medicine was being quietly revolutionized by nothing more than the humble checklist. Peter Pronovost, a critical care specialist at Johns Hopkins Hospital, had embarked on a program to convince ER doctors to follow a five-point checklist for inserting a central line in a patient. Pronovost’s checklist was merely a compilation of basic medical hygiene:

1. Wash your hands with soap
2. Clean the patient’s skin with chlorhexidine antiseptic
3. Cover the entire patient with sterile drapes
4. Put on a sterile hat, mask, gown and gloves
5. Put a sterile dressing over the catheter after the line has been inserted

 This checklist, combined with support from the administration and nurses given the authority to literally body-check a doctor who didn’t follow the list, resulted in an infection rate that dropped from 11% to zero percent. Much could be said about the importance of following correct procedure, but much more can be said about thinking about procedure to the point where you discover what that procedure actually should be. Programming and IT could learn a lot from Dr. Pronovost.

 Programming is communication, and only the novice would believe it’s just communication with the computer. Not so. Programming has to count what you teach to the biggest computer of them all. All code must be debugged. All code must be maintained. Few programs die with their creator. To be a better programmer, it is imperative to be a better communicator with other humans.

 And, by the way, “Mind your Ps and Qs” comes from a bartender saying that’s short for “Mind your Pints and Quarts”, or keep an eye on how much your patrons have consumed that evening.