This semester, I finally took the cross-department course from the Business School that I was dreading. My school’s program is a joint-degree, Computer Science and Information Systems, with the CS stuff coming from the Engineering school and the IS stuff coming from the Business school. The degree has a number of requirements but one of them is that you must take at least one PhD-level class in each school. This means that I am able to take nothing but pure-CS courses, except I have to take one PhD-level course in the Business school. I’ve been dreading this since I started, somehow hoping this requirement would be removed before I had to take it, but this was not the case, and I had to take it this semester. With the credits I am able to transfer from my Master’s degree, this actually completes all of my course requirements, but because I was interested I also took a course on Graph Theory, which was a class crosslisted as both an undergrad and master’s level class. And once again, I somehow managed to get stuck grading.

I started the semester taking three courses on Coursera as well, but quickly decided that doing so contributed to my sense of being overwhelmed last semester, so I quickly dropped them and decided to download all of the lectures when the classes ended, and hence won’t be mentioning them further.

Classes

Applied Graph Theory

Textbook: Graph Theory, a Problem-Oriented Approach

Like I said, Graph Theory wasn’t a course I took because I needed it, I took it because I felt like it would be low-key and fun, and a lot of the problems I’m interested in for research relate to Graph Theory in some way or another.

A great deal of the material had been covered in the same professor’s Graduate Algorithms class, but not as much as I was expecting. There was lots of new stuff that I learned, and I really enjoyed it. This particular professor is a very good lecturer; I always enjoy her classes, and this one was no exception.

The course is strange because its quadruply cross-listed. It is cross-listed as both a CS class and a Math class, and also cross-listed as an Undergrad and Graduate class. This led to an interesting mix of students in class, many lacking the math background of others, many lacking the CS background of others still. All together, there were 13 CS Undergrads, 15 Math undergrads, and 5 CS grads including myself (no Math grads). Due to the makeup of the class, the material was definitely taught at a level catering mostly to the undergrads, which made for a pretty easy class for me and the other graduate students. After the last semester’s overwhelming workload, this was welcome.

Graph Theory!

Graduate students were required to also do a semester project and present it to the class at the end of the semester. As was the case last time I had a similarly-structured course, once I got into my research project I found it hard to focus on the rest of the class material due to being obsessed with my own project. My understanding and retention of the first half of the class material is definitely better than that of the second half. Because the professor drops the lowest homework grade, I didn’t even do the final homework for the class, electing instead to put more work into my project.

As the only PhD student in the class, my project presentation was allotted an entire class period for the presentation (the other students each got half of one), which consisted mostly of me lecturing on the background material not covered in the class before presenting my research. For the project, I was given an interesting, NP-Complete Graph Theory problem to try and optimize, which I attempted to find a solution to by implementing a Genetic Algorithm search. The code for this project is here, my presentation slides here. In the end, I was unable to actually solve the problem, but I had a great time trying.

I had an absolute blast with this project, and my presentation went very well. I actually coded it up so that the students all met in the PC lab on campus instead of in the regular classroom, and they each ran their own copy of the search algorithm and uploaded their best result automatically to a server I was running connected to a projector. This turned the search into something of a competition, and the interactive component was a lot of fun. I somewhat regret shifting my focus too far away from the class material once I got invested in my project, but overall I had a great time and really enjoyed this class a lot. I wound up with an A in the class.

Topics in Analytical Research Management

Textbook: None

Like I mentioned, this class is a requirement, the one Business School class that CS students needed to take as part of the degree requirements. I had been dreading it since I heard about it, as I have no interest in anything I could learn from the business school, and even less interest in this particular class subject.

I hated, hated, hated this class. I hated every second of its 3-hour length. I hated the fact that I had to stay downtown after work and grab food before its 6:00pm start time instead of eating dinner with my wife at home. I hated the complete lack of common ground between the few CS students taking the class and the overwhelming majority of business-school types in the same room. I hated the fact that almost all of the material was built on previous classes that the business school students had taken before but the CS students had not. I hated every lecture, every assignment, every student presentation I had to sit through. I hated the over-reliance on Powerpoint for lectures. I hated all the business-buzzword talk that I try so hard to avoid in my day job. I hated that I never saw a single mathematical proof of anything being discussed. I hated having to use Blackboard. Most of all, I hated how it was the only course I took not because I thought it sounded interesting, but because the department required me to. I deeply, deeply resented having to sacrifice an evening at home with my family every single week to take a course I had absolutely no interest in, that I felt I should not have to take at all, with a bunch of people with whom I had nothing to talk to about. I hated this class.

I did not hate it due to workload, which was relatively minimal. Let me first start out by saying that, at no point during the semester did I actually understand any of the class material. I mean that literally, it all seemed built on classes in the business school prior to this one, classes I did not take, and I never understood anything. Almost every lecture may as well have been in French, I didn’t even recognize the vast majority of the words being used, let alone understand the sentences they were in. At no point did my understanding of the material reach a level above a D or D+. By all rights, a D or perhaps an F is what I deserved.

However, the assignments were extremely easy, though occasionally time-consuming. Four of them were to simply read a paper from a list of possible papers and write a review, akin to the kind of review one might write if reviewing for an academic journal. Of course, none of these articles were CS articles, they were all business-type articles. The most interesting paper I saw was on the subject of machine learning, and the opening paragraph talked about how it could be used to increase return on investment for businesses and my interest was instantly sapped. I just have no patience for this money-centric worldview.

I managed to get an A on all four of these articles. I never read a single one of them. I read the abstract, the introduction, and the conclusion section of each. I rarely understood any of these sections, and I didn’t even attempt to read the stuff in the middle. Yet they were enough to write my “reviews”, which largely consisted of finding a detail and generically referring to it as “under-explained” or something similarly vague. Every one of my article reviews was complete and total bullshit, an attempt to make it look like I understood the articles when I absolutely did not. My lowest grade was on a review of a paper that the professor was a co-author on, where my same generic criticisms were met with defensiveness, explaining that the content I felt was missing was cut out due to the journal’s length restrictions.

There were also a number of assignments that involved a lot of calculations in Excel. I never understood the purpose of these calculations, or what they meant. But I was consistently able to look at the professor’s example Excel files, re-use the formulas out of one column and put them into my Excel sheet, just changing the cell numbers to use what appeared to be analogues in my worksheets to the cells in his. These assignments were, for me, exercises in pattern recognition, a skill at which I’m quite adept. I was able to get decent grades on these assignments as well, only occasionally did my pattern matching skills fail me.

A month or so before the midterm, I decided that I was being lazy. I decided I was only having trouble understanding the material because I disliked it, and that’s no excuse. So I went to the professor’s office hour, with one goal in mind: to walk out understanding exactly one thing. We’d covered dozens and dozens of different concepts by this point in the class, and I understood none of them. I decided to pick one that was referenced a lot, and fully understand it. Sure, I’d still be crazy behind, but at least it would be an improvement.

I asked my question and he immediately launched into a tirade of nonsense that baffled me. I asked him to hold on, slow down, go back and explain so-and-so first. I took up an entire hour trying to get him to explain things more simply before eventually the professor shrugged and said “you know, this stuff is pretty basic statistics, maybe I should have had a statistics class as a prerequisite.” He then gave me a URL to a web page with hundreds of written pages about statistics and told me to read it. He didn’t direct me to a particular thing to read up on, just the URL which had at least two semesters worth of reading material alone. First of all, I have what I consider basic statistics knowledge, I took statistics in high school at the very least. What he was referring to was more like graduate-level statistics, which I’ll admit I don’t know much about, largely because I have little to no use for such a thing studying theoretical computer science. Secondly, this course is already a course I’m required to take and don’t want to, the idea that he’d add another one as a prerequisite was infuriating. And finally, it certainly didn’t do me any good right now, so thanks a pantload.

Synergize our opportunity platform to facilitate tiger team knowledge management

So I gave up. I was mentally done with the course. I felt like I gave it an honest effort to understand something, anything from class, and the professor basically told me to fuck off. From this point forward, I resigned myself to the knowledge that I’d fail the midterm, but with the decent grades I got on the assignments and the fact that I’d be able to work with a partner on the final project, I’d probably manage to get a C in the class, which would be enough for it to count. I spent every lecture from this point on working on my Graph Theory project on my laptop, I never looked at another one of the professor’s slides again. I honestly don’t even know what many of the lectures were even about, I just used the class as a 3-hour work session for my project.

Sure enough, when it came for the midterm, I did poorly. There were 4 total questions, 2 of which I actually understood relatively well due to reviewing the material with another student in the class (who was able to explain, in about 10 minutes, what the professor could not explain to me in an hour). The final question — worth the most points — was, once again, barely English for me. I didn’t even understand the words in the question, let alone how to answer it. So once again, I just wrote garbage down. I wrote 6 paragraphs, each exactly one sentence long. Each sentence was a statement that was true, which I knew from having memorized random sentences from the slides from class. Did any of these statements answer the question in any way? No idea. I just knew they were true statements about things, and that they were stated in class. I got the second lowest grade on the midterm in the class, but when I compared my answers with the other student I studied with, he was dismayed when he saw that he and I got the same number of points on the final question despite the fact that I clearly did not understand it. I got a B- on the midterm, not because I understood the material at a B- level, but because of how it was graded.

There were only two more graded artifacts left. One was to read a paper of our own choosing and present it to the class, similar to the paper reviews from before. I did extremely well on this one, because I was able to select a CS paper and I’m pretty good at giving presentations (he actually said it was one of the best he’s ever seen). The final assignment was a project, and I was able to work with a partner (the one I studied with before). We selected a very CS-oriented project and did a very cool experiment, which utilized a fraction of classroom material. He was largely responsible for the research and the paper, whereas I did a lot of the gruntwork, writing scripts to generate data sets as well as all of the slides and the project presentation to the class, which is here. This division of labor worked well for us because he understood the class material better than I did, but I was better at giving talks. In the end, we got a low A- on the project. We were the only group who not only designed an experiment, but actually performed it and got real results. Everyone else designed experiments that they couldn’t actually do, so it sort of drives me nuts to know they got a higher grade for utilizing more material from class and doing absolutely nothing with any of it.

These assignment and project grades were actually enough to make up for my midterm grade, and I wound up with an A- in the class. In a way, I actually wish I’d gotten a B, since my project partner, who scored only a few points higher than me on the midterm and otherwise had the same grades, got an A. This means my grade was damn close to the A, and is now the lowest grade I’ve received in all of my classwork, and this is the one class ruining my perfect 4.0 GPA. This kind of enrages me since I never wanted to take this class to begin with, but I have to try and keep things in perspective. I did not understand the class material at an A- level. I still do not understand much of anything from this class, and by all rights I should have failed. But due to the structure of the class and the grades, I managed to get an A-, so I don’t have to retake the class and it counts towards my degree, which is really all I needed.

Grading

Believe it or not, I once again got roped into grading. The professor for Graph Theory asked if I could grade her class. I said I didn’t really want to, but I didn’t want her to be in a jam, so she should go ask everyone else on her list and if she can’t find someone, come back to me. She found another grader, but the other grader could only do it part-time, so she wanted to know if I would be willing to be a second grader and grade part-time as well.

I’d only have to grade half of the six quizzes, and I’d have one office hour per week instead of two. I figured this was tolerable, so I reluctantly agreed. Then after the semester started, the other grader got re-assigned by the department to grade another class, and I was the only one left for Graph Theory, so I had to double my office hours and grade all of the quizzes. It was too late to get anyone else, so I was stuck with it.

This was the first time I was grading written work instead of compiled programs, which meant I had to deal with handwriting, lack of descriptions, poor English, errors in proofs, and crazy, off-the-wall answers from left field. I also had to figure out for myself how many points I’d take off for particular errors, whereas with my previous grading effort I was given a rubric by the teacher. Grading this type of work is much more time consuming and much more difficult. I hated it. I also had to have office hours every week so students could come by and argue with me about the points I took off. I hated this more than anything else – nobody ever came to me and asked why they got the answer wrong because they wanted to understand the material, they almost always acknowledged they got it wrong but felt I took off too many points. This type of crap annoyed me to no end, particularly considering how obscenely lenient I was with points. I was giving 50-75% of credit to answers that I’m sure the professor would have given a 0 to. I know this is the case, because the only grading feedback I ever got from the professor was that I was being too generous with points.

You may have also noticed the name of the course I graded was “Graph Theory”. Wait, isn’t that the name of the course I was also taking? Why, yes, yes it is. PhD students in the department are allowed to take and simultaneously grade the same class, the professor grades the TA’s work, and the TA grades everyone else. If that sounds a bit strange to you, let me assure you that you have no idea how strange it is.

I had to sit, every class, with students whose grades were lower than they wanted because of my grading. I had to hear the comments about what “bullshit” their grades were as their quizzes were handed back with me standing right there. Worst of all, I had to present a full lecture on my semester research to what I can only describe as a maximally hostile audience, who I was certain would have enjoyed nothing more than to see me stumble and fail as karma for taking 10 points off that one time when I “totally should have taken off like 2 or 3, max.”

I had no friends in the class, and no other students I could talk to when I was having trouble with the material myself. I had to figure everything out early, before my office hour the day before assignments were due, which was inevitably when everyone would show up to ask me questions. The sense of being completely alone and an absolute outsider in the class transformed what would have otherwise been an awesome class into something awkward and uncomfortable. It placed far more stress on me in terms of needing to understand material out of fear of humiliating myself or telling a student something incorrect. This alone turned my “low-key, easy class” into a stressful burden.

The value I got out of this was that it has made it abundantly clear that I do not want to teach. I actually really enjoy lecturing and teaching people, but I detest with every fiber of my being grading their work and having stupid little grade-grubbing conversations with them where I spend 30 minutes listening to them explain why they deserve 2 extra points while in my head thinking how they really deserve a 0 and I was already being nice by giving them partial credit. The lecturing part of teaching is fun, but the evaluating/grading portion has made it crystal clear that teaching is not for me.

I know I’ve said this before, but this time I totally, seriously, super-duper mean it: I am never going to be a grader again. Dammit.

Conclusions

This semester was tough. I hated one of my classes more than any other, even Artificial Intelligence (where I at least liked the material), and the one that was supposed to be low-stress and fun wound up being highly stressful and unpleasant due to the grading situation. It was my second semester in a row where my overall level of enjoyment of school was low due to overwhelmingly negative reactions to a particular class. I had two semesters of awesome school, and then what wound up being another two semesters of unpleasantness. Considering that the only reason I’m in school is because I thought it would be fun, you better believe I was wrestling at least once a week with the question of just dropping out. Usually in the minutes before the Business School class started.

I stuck with it, largely because the one constant in the courses that I didn’t enjoy was that, when I was doing a project or research for the semester, I was loving it. As much as I hated the business school class, I’m really proud of the experiment my partner and I designed and I really had a lot of fun working on it. As stressful as Graph Theory was due to my “other” status, I absolutely loved my project, and really enjoyed presenting it, even to a hostile audience. Last semester, I hated the A.I. workload, but I had a blast doing the semester project. And even in my Computational Complexity class, which I really enjoyed but was disappointed with due to the infrequency of class, the highlight was my independent literature review.

Since the end of this semester actually marks the end of all classwork for me, I slogged through the rough semester hoping that the next semester, where I’ll be doing research completely on my own, will be a lot more of the thing I liked from the classes that I did not. I came to the school looking forward to actual classroom material, sitting in a physical class instead of taking classes online like I did for my Master’s degree. I enjoyed that experience most of the time, but I’m definitely at the point where I’m ready to be done with classes and doing research.

I had hoped that this semester would be low-key enough that I could spend lots of time figuring out what I wanted to research, but unfortunately both classes wound up being more time-consuming than I had hoped (particularly at the end where I was juggling two large projects). I’m not as far along in the “what do I want to research” process as I was hoping to be, so I’m hoping to catch up a bit this summer.

I wish I could have enjoyed all of my classes as much as I enjoyed some of them, because I think it would have been possible to do so for all but the Business School class if not for particular circumstances. In a way, I’m sad to see the chapter of classwork for my PhD close with a little under half of that time marked by disappointment in some cases and outright hatred, but close the chapter has, and it’s time to buckle down and start doing my own research.

This period will be marked by self-doubt, I’m sure. Even now I don’t really know what I want to research (though I’ve developed quite a reading list), and I don’t really know if I’m up to the task of coming up with something truly original and novel. I know that I enjoy the process of research, as it’s been the only aspect of more than one course that I actually liked, so I’m hoping I can find a problem or a set of problems that I’m both passionate about as well as confident I can solve. I hope next school year is better than this one was, if I reach the point where 2/3rds of my time in school has been unpleasant, I don’t think I can possibly justify sticking with it.

Last month, Heather Arthur posted on her blog about an unfortunate incident in which some people on Twitter had found some code she wrote in GitHub, and people started trashing her on Twitter for it. Some of those people are considered leaders in the Software Craftsmanship movement, in particular Corey Haines. Corey immediately apologized for acting like an asshole, and I think his apology was sincere because I’ve met Corey and frankly the guy is almost annoyingly nice (he went around RubyConf 2012 taking a picture with every damn person there). But Ted Neward saw this turn of events and concluded that Corey’s actions were not orthogonal to his involvement in Software Craftsmanship, but actually influenced by them, and he posted as such on his blog.

Neward’s basic point is that this is the exact kind of behavior we should expect as a side effect of the Software Craftsmanship movement. By it’s nature, it attempts to create a segregation between those who are “in the know” and those who are not, and he felt the behavior of Corey and others was a byproduct of this segregation. They saw Heather as an “other” and were overly harsh in their criticisms, emboldened in so doing by their sense of Craftsmanship. Neward took a lot of shit for this view on Twitter, with most people arguing that this was done by Software Craftsmen, but it wasn’t done because they were Software Craftsmen, and it makes no sense to criticize the entire movement based on the action of a few members, regardless of how high their profile is. Neward responded to all of this feedback in a second blog post, where he reinforces his original point.

Uncle Bob Martin, one of the first five signers of the Software Craftsmanship Manifesto and author of Clean Code and The Clean Coder, then responded to all of this drama with his own post. Bob takes particular issue with Neward’s promotion of what he sees as the opposite of a Software Craftsman, a Software Laborer. In Neward’s words, a Laborer is someone “who cranked out one crappy app after another in (what else?) Visual Basic [...] their apps were sloppy, bloated, and ugly…cut-and-paste cobbled-together duct-tape wonders.” At the end of the post, Neward bows “with respect to the “software laborers” of the world, who churn out quality code without concern for “craftsmanship”, because their lives are more than just their code.”

Bob finds these kinds of developers to be problematic, as his experience suggests that people who make a mess of their code create lots of defects and headaches for themselves and other developers. Finally, Ted Neward responded to Bob as well with one more defense of himself in another blog post which he proclaimed on Twitter as his “last word on the subject.”

It was this last post that inspired me to post my own thoughts. I’m not going to speak much about the drama itself, or the definition of Craftsmanship vs Laborer, follow the links above if you’re interested in that debate.

Something in Neward’s final post struck me.

Know what? I think one thing that got lost somewhere in all this debate is that value is only value if it’s of value to the customer. And in a lot of the “craftsmanship” debates, I don’t hear the customer’s voice being brought up all that much.

You remember all those crappy VB apps that Bob maligned earlier? Was the customer happy? Did anybody stop to ask them? Or was the assumption that, since the code was crappy, the customer implicitly must be unhappy as well? Don’t get me wrong, there’s a lot of crappy code out there that doesn’t make the customer happy. As a matter of fact, I’ll argue that any code that doesn’t make the customer happy is crap, regardless of what language it’s written in or what patterns it uses or how decoupled or injected or new databases it stores data into. Value isn’t value unless it’s value to the person who’s paying for the code.

This, to me, is the heart of the Software Craftsmanship movement. Neward intended this as a critique of Craftsmanship, but I see it as it’s greatest strength.

I see the Agile Manifesto as being customer-focused. It’s values are interacting with people, collaborating with customers, releasing working software, and responding to change quickly. These are things that customers have a good reason to care about. I want every customer of mine to know that I consider myself an agile developer because I think that conveys to them a certain set of principles that they might value.

But Ted’s right, customers don’t care much about if code is crappy, and they don’t care if all of these craftspeople meet regularly after work to “hone their craft”. These are, indeed, not of much concern to customers, at least not directly. The Craftsmanship movement is for me, not about developers focusing on their customers, but about them also focusing on other developers.

I don’t write well-crafted code or go to meetup groups or steadily add value (even if it’s not requested) for the benefit of the customer. I do it for the other developers I work with, and for those who maintain my code when I can’t. It’s this additional layer, the “not-only”s of the Software Craftsmanship manifesto that appeal to me: the adoption of a view that we must not only make our customers happy, but make our fellow developers happy as well.

I’m signatory #214 of the Software Craftsmanship Manifesto, and my self-given title on LinkedIn is “Software Craftsman and Computer Science Geek”. Every so often I see my own LinkedIn profile and this title strikes me as pretentious and annoying, and I consider changing it, but I never do. I always decide it’s more important to leave it and risk looking like a bit of a pompous, self-important jerk. Why do I do this?

I do it because I consider it something of a pirate flag for other developers. It’s important to me that they see this flag, because the label conveys, to my mind, a great deal of meaning to the reader. It’s a shorthand, it lets other developers know an awful lot amount me with two short words, including that I might be a bit of a pompous, self-important jerk. It tells other developers what they can expect of the quality of my work, and what I expect of theirs. It is a label that I adopt solely to aid communication between myself and other developers, not customers.

Sure, I think hiring a team of Craftspeople will be beneficial for customers. I think the codebase will be more easily adaptable to change, I think they’ll get more honest and accurate assessments of when work will be done, and I think they will generally have more positive interactions with their team. But at the end of the day, this team of Craftspeople has chosen their outlook on software development not out of concern only for the customer, but also out of concern for each other.

If Neward wants to sing the praises of his VB-slinging, cut-and-pasting Software Laborer, that’s fine. Such a person may make customers very, very happy, and good for them. But I know that it would make me unhappy if I had to work in or maintain their code, just as I know it would make someone else unhappy were I to be a Software Laborer myself. Frankly, I don’t have much interest in working with Software Laborers as Neward describes them, which is why I fly my Craftsmanship flag high. Does this make me an elitist snob? Yeah, a bit. I’m not trying to be a dick about it, I just know I’d just come home frustrated and drained if I worked for 8 hours a day with a team of people who are just trying to sling enough code to make the customer happy and didn’t care about the codebase itself. The mentality of “the customer is all that matters” is a fine stance to adopt, particularly from the perspective of the customer, but it’s no way to build a team of happy developers.

-Rod Hilton, Software Craftsman Godammit.

I took two 7000-level PhD courses at once (previously I had only done one in a semester) which was part of the problem. Originally I was planning on doing three, but quickly decided that was insane and dropped one of the classes, which I’ll now be taking in the Spring. One of these two remaining classes was material I had never been exposed to at all, and it also happened to be structured in a way that would have made it exceptionally difficult even if I had, while the other was material to which I had minimal exposure. I also took two courses on Coursera during this period of time, both of which I took quite seriously, as though they were credit courses. And if all of that wasn’t crazy enough, I managed to once again get roped into grading.

Campus Classes

Artificial Intelligence

Textbook: Artificial Intelligence, 2nd ed.

I had never taken an A.I. class as an undergrad, and I always regretted it. I felt like I should at least be see what it’s about, and I was always really interested in things like evolutionary algorithms, genetic algorithms, and other metaheuristics. This class was taught by a professor I hadn’t yet had, so this was a real gamble for me.

I actually wound up intensely disliking the class. Not the material, which I found mostly very interesting, but the actual class itself. Rather than having a challenging homework due every two weeks like my other classes had been, this class had one homework due each week, on Monday. Since I work full-time, this meant that every single weekend during the semester was spent working on homework, I never had a full weekend to relax or catch up on anything else. This had a pretty serious impact on my home life and I really grew to dislike it.

It wasn’t just the number of homeworks that was the issue, but the nature of them. The homeworks often asked us to solve very easy problems whose solutions were incredibly time-consuming to write out, and to make matters worse they often asked us to solve nearly identical problems in the exact same way over and over. It never tested my knowledge any differently to do the same problem twice in exactly the same way, but it was incredibly time-consuming to do these problems by hand. Homeworks often took 10-14 hours to complete, and like I said I could only work on them during the weekends, so my entire weekend was consumed by homework, every weekend, for 12 weeks. What infuriated me was that these homeworks didn’t take time because I didn’t understand the material, the amount of effort required was almost completely disconnected from my grasp of the topic.

My lack of weekends also led to me falling behind in my other classes, it felt like I was struggling to keep my head above water all semester long. This semester felt the most like my undergrad days, pulling all-nighters to complete assignments just before they were due, doing the bare minimum on an assignment just to get it checked off my list and move on to the next one, and always feeling stressed.

Worst of all, this class, which I took as an elective for fun just to see what it would be like, was a constant time distraction, pulling my attention away from my Computational Complexity class, which I had been looking forward to since going back to school. Another PhD student who has taken a lot of classes with me actually wound up dropping Artificial Intelligence and entering an Independent Study because he felt that A.I.’s disproportionate amount of busywork was distracting him from narrowing down his research area, and would ultimately delay him completing the program. He did this after the add/drop date, paying for the class and taking a withdrawal; that’s how much of a timesink this class was. As the class went on, I began to realize just how wise a decision this was.

I actually liked the classroom environment quite a lot – the professor tried to run the class very socratically, and almost nothing was taught without having a student come to the board and work through a problem with the entire class helping. I thought this was a really great way to teach, and the professor clearly had a passion for the subject. Class was very lively and engaging, which I enjoyed. It was unfortunate that the intense workload distracted me so much from the passionate professor, strong lectures, and engaging material.

Ultimately, the workload is what dragged this class down to me, wasting its potential as a great class and transforming it into the only class I’ve taken that I didn’t like. It’s one thing if the work takes me a long time because I’m struggling to understand the material, but when I understand the material and it takes me 10 hours to write it all up anyway, something is amiss. I’d have preferred to have half the number of homeworks, and have them be more challenging than what we got. In fact, I’d have preferred to have some projects, given that I wound up writing a lot of code to generate solutions for me to save time.

There actually WAS a project for the class, but it was extra credit. This project was assigned halfway through the semester (to help students pull their grades up from the midterm), but the lectures that explained the concepts needed to do the project weren’t until the final week of class. Given how much I was drowning in work just keeping up with his class, I decided not to pursue the project at all and just focus on doing well on the final. After my final, my professor e-mailed me to let me know I had a B in the class, but I could pull it up to an A if I did this project, which was due in 2 days.

I’ve had straight-A’s for every other class, and I can’t imagine a course being more challenging than A.I. I realized that one day I’d look back at my transcript and see all A’s and one B, a B that I had an opportunity to pull up to an A but I didn’t bother because I was lazy and wanted to be done with the semester. I decided laziness wasn’t a good enough reason to accept the B, so with only two days to do the entire half-semester project, I decided to give it a shot. It actually wound up being incredibly fun, largely because I made it fun by doing it in Scala. You can check out the project here if you want.

In the end, I managed to complete the project by staying up until about 2am a few nights, and I wound up with the A in the class.

Computational Complexity

Textbooks: Automata, Computability, and Complexity and Computational Complexity

The existence of an entire course devoted to Computational Complexity was one of the main reasons I picked UCD over other schools. Taught by a professor I really enjoyed for Theory of Automata, I figured this class was likely to be my favorite class of all time. Unfortunately, it wound up being a bit of a disappointment.

As an experiment, the class was, for the first time, taught as a “hybrid” class. Rather than the traditional classroom setting it had always been, it was taught mostly online. Once my professor saw that only 3 people wanted to take the class at the 7000-level and everyone else was taking it at 5000-level, it was split further, and the format it wound up taking was that the three of us met in-person once per week and discussed various issues within Complexity.

Complexity Classes, from Math $$\cap$$ Programming

The main issue was that, by only meeting once a week, we simply we unable to cover a great breadth of material. Computational Complexity is a huge subject, there are 495 classes in the Complexity Zoo, and the infrequent meetings meant that only a tiny fraction of the topic wound up being covered. We walked through some of the more difficult, classic papers in theoretical computer science, which was a lot of fun, but fully dissecting a single paper would often take 2 classes, a huge fraction of the available classtime when only meeting once a week.

For my semester project, I did a literature review and covered 27 complexity classes from the Zoo that we didn’t have time to even mention in class. Due to the A.I. class, I had much less time to devote to this project than I would have liked, but I still wound up doing a lot of research. I absolutely loved this project, and discovered a whole bunch of complexity classes I had never heard of before as an undergraduate. I found the material just as exciting as I expected to, but the sad truth is that I was able to spend much, much less time on this fascinating subject than I wanted to.

There was also a wide disparity between the 3 students. One of the students had actually taken a different version of the same class in another semester, and another was an upper-level PhD student working on his dissertation that was taking the “class” as an Independent Study. Both of these students had a much greater grasp of this material than I did, so I often felt like the class moved too quickly for me, and I got lost frequently. I was reluctant to ask questions because I knew I was the only person in the room who didn’t understand things, so I had to do a lot of reading on my own time to keep up. Of course, I had almost no time to do this kind of reading, so I think there’s a lot of stuff that went over my head and stayed there.

Overall, I really enjoyed this class and both of the textbooks we used, but it was also one of my biggest disappointments because I felt like I was only getting half a class. I would have loved for us to have met twice a week (hell, I’d have loved thrice per week), but I’m glad I took the class and I learned more in the couple weeks of independent research than I have in any other class I’ve taken. I wound up ordering physical copies of a number of complexity textbooks because I found the topic so interesting, and I’m eyeing the sub-field closely for potential research topics.

The class was pretty informal, with the only graded components being a presentation we did halfway through the semester, another presentation at the end, and the final term paper. I wound up with an A in the class.

Grading: Fundamentals of Computing

I swore off grading last time I did it, with an overabundance of cheating ruining the experience for me. But after the same class I graded before saw a 100% increase in enrollment, the chair of the department personally asked me if I could help her out by grading it again, along with a second grader. As much as I didn’t want to, I couldn’t turn down the chair, so I reluctantly agreed.

I only graded the odd homeworks, with the other grader doing the evens. A grading session took much longer than it did last time I did it, but they were infrequent enough that it wasn’t too much of a problem. It certainly did feel like I never had the time to grade, but I managed to sneak in the time whenever I was too tired to do A.I. work.

Classes started off badly, with more students cheating on the first assignment I was grading. I once again caught them and called them out and then, to my great surprise, the cheating stopped (or they got much better at hiding it). Grading was much better this time, the only downside being that it cut into time I simply didn’t have.

One tip I got a while ago from a blog post or article about getting a PhD is to remember that your goal is to get the PhD, and that anything you spend your time doing that doesn’t bring you closer to that goal is inherently taking you further away from it, since your time is limited. Grading definitely falls into that category, and I particularly felt the drain on my time since I was barely surviving anyway.

I intend to avoid grading in the future as much as possible, though it’s hard to turn down a professor or department chair when personally asked by them.

Online Classes

Functional Programming Principles in Scala

I, along with something like 10,000 other students, took Functional Programming Principles in Scala taught by Martin Odersky online on Coursera.org. I had registered for Coursera courses before, but largely treated them as “bonus material.” I’d check out video lectures every so often, glance at assignments, and so forth. I thought taking a Functional Programming course would help me both academically as well as professionally, since we use Scala exclusively at work.

I took this course very seriously. I carved out time to watch every video lecture, and I treated the homework assignments like real assignments. I really enjoyed the format of the class, with an autograder running secret tests against my code. The code had a couple clever tricks to make “???” compile but not work, so you could leave functions unimplemented and submit what you had to see if you were on the right track. A co-worker would typically do the entire assignment and submit once, but I tended to write a little, submit, write a little, submit, over and over again. I typically wound up with 10-20 submissions per assignment.

I thought the course started out better than it finished. When the course first started, it really felt like a class on Functional Programming itself, which simply happened to use Scala as the language. Later in the course, it began to feel like a Scala course, with more of a focus on Scala’s idioms and syntax. I still enjoyed these sections, but definitely less so. Another thing that irked me was when Odersky dropped the hammer on posting and sharing code solutions to the homeworks. My co-workers and I would always share our solutions after the deadlines had passed, and I wound up learning a ton from seeing how others implemented the same things as me. I understand why they had to crack down on “cheating” but I think the restrictions were a bit overly strict.

Odersky teaches a followup to the course at EPFDL, and I’d love to see that course offered online as well. I’d like to see more focus on FP in general with less time devoted to the particulars of Scala, but I definitely got a lot of out the course as it was. In fact, I wound up using a very similar style to the course to implement the A.I. project described above, and it worked incredibly well.

I got 100% in the class, I was never willing to walk away from an assignment without getting full credit on it, even when I was pulling my hair out with suboptimal trees in the Huffman Codes assignment.

Writing in The Sciences

I also took Kristin Sainani’s Writing in the Sciences course on Coursera. This is the online version of a class Sainani teaches at Stanford University. Since I’m doing a PhD, I know I’ll be doing a lot of writing, and I wanted to improve my writing skills. I also recently read the very similarly-themed Writing for Computer Science by Justin Zobel, which I found enlightening.

I took this course pretty seriously, in that I actually watched all of the lectures and did all of the assignments, but I didn’t give it the level of attention I gave the Scala class or either of my University classes. The course simply wasn’t technical enough to require my full attention and it was always my bottom priority, so I often listened to the lectures in headphones while at work, turning my attention to the video only when something visual was being presented. One week, I played the lectures on my laptop while doing Scala homework on my desktop. Now that’s multitasking.

I struggled a bit with the grading of the class. Since it wasn’t code, no auto-grader could be used. Instead, students simply submitted writing assignments and had 3 other students grade them. Similarly, you had to grade the work of 3 other students. The peer reviewers were tasked with making suggestion to improve the overall clarity of the writing, but generally they focused on word choice and minor paragraph tweaks. Nobody ever turned a 4-paragraph rant into a sleek and slender 2-paragraphs, the tweaks were always much more minor. By the final assignment, I was putting about the same level of effort in.

I was also shocked at the level of plagiarism. One student submitted a paper that had a single sentence introducing a scientific peer, then a 4-paragraph quote by them, then another sentence thanking them for their contribution. What the hell is that supposed to be? I gave them a zero.

I got pretty good feedback on my writing, and I think I improved overall. I definitely know some things to watch for when writing, but I also think I got more out of Zobel’s book, possibly because it was more focused on Computer Science specifically than Sainani’s class.

I wound up with a 91.8% in the class, just barely above the 90% required to be considered passing. This was due almost entirely to my own lack of organization, getting due-dates of two assignments mixed up with all of my other due-dates and earning a couple zeroes as a result.

Conclusions

This semester was incredibly rough. On multiple occasions I asked myself just what the hell I was doing, and why I was subjecting myself to it. Lots of self-doubt, wondering if I was cut-out for the program. In the end, I pushed through it by thinking that if I can survive this semester, I can survive any of them.

Having finished the semester with my grades and sanity in tact and little more than a severely bruised social life and diminished level of happiness, I think I can probably survive the rest of the program, which is promising. When I started this program, a goal of mine was to not let it impact my life noticeably; time I normally would spend watching TV or playing video games would be spent doing schoolwork, and otherwise my time would be the same. While I succeeded in this goal every other semester, this semester I failed, being completely unavailable for anything during any weekend, including for simple duties around the house. Lots of plans had to be cancelled or postponed, and juggling everything in my life was exhausting.

Next semester should be less intense. I’m taking a class in the business school (it’s a requirement) about how to do research. I somewhat resent having to take a course that isn’t really Computer Science, but it’s the only non-CS requirement for the degree so I’m just going to have to do it. Now that I have straight A’s, I’m going to feel a lot of pressure in that class, I don’t want my only non-CS class to drag my GPA down.

Due to credits transferring from my Master’s program, that’s actually all I need to be done with classwork. But since I’ll be enrolled anyway, I’m taking Graph Theory as well. I don’t technically need this course, but I find the topic extremely interesting and I’ve been looking forward to it since the professor who teaches it introduced some of the material in my Algorithms class. This course is taught simultaneously at a Master’s AND Bachelor’s level, so I doubt it’d going to be a back-breaking workload, and I get along well with the professor.

I have one more preliminary exam to take in February before I’m truly considered a PhD candidate, so that’s my next big obstacle. After the prelim and these two more courses, my coursework is finished and all non-research requirements will have been met. Hopefully I’ll have narrowed things down and I’ll have a good idea of what I want my research area to be before the summer. Ideally at the end of next semester I’ll defend my proposal and be well on my way in research.

I’m still glad I’m in the program, and I’m looking forward to continuing, but after this semester I’m definitely ready for a nice long break.

For a final paper, we had to pick a topic of our own choosing in Complexity Theory and research it on our own. For my topic, I choose to explore a bunch of the other important classes in complexity theory. I had never had any exposure to any of these classes before, so I really enjoyed this project, though I was unable to cover as many classes as I’d have liked, and none of them in as much depth as I was hoping.

Complexity Classes, from Math ∩ Programming

Nonetheless, I’m pretty happy with my paper, which provides an undergraduate-level explanation of 26 other complexity classes, based off The Complexity Zoo, kept by MIT professor Scott Aaronson. I tried to boil these classes down to the bare essentials and explain them with examples in plain english as much as I could. The goal of the paper is to expose those new to Complexity Theory or early in their Computer Science careers to a handful of interesting classes and explain how they relate to each other, the more common classes, and of course the $$P =? NP$$ question.

You can download the paper here.

Please note, this paper has not been peer-reviewed in any fashion. It has not been (nor will it be) submitted to any academic journals, and it makes no novel contributions to the field. It’s purely an overview of other classes, a literature review at best. I post it here in case others might find it interesting or informative, but it is not to be cited under any circumstances. If you somehow find something valuable for your own research, I suggest you follow the citations in the paper and look up the references yourself, then use those as a source.

I also cannot stress enough how incomplete this paper is. It only covers 26 classes, leaving out over 450. There is a great deal of information about these classes as well as those not covered, which I do not touch upon at all. The paper is intended as an introduction to these complexity classes, so don’t be surprised if things are left out. I tried my best to avoid errors, and I had a few corrections issued by my professor where my language was misleading (for example, claiming a problem was not in $$NP$$ when in fact it was simply not known to be in $$NP$$), but if you find something confusing or surprising, I suggest using the references provided, as this paper may have some mistakes. If you find any, feel free to leave a comment and I’ll correct them.

Since that time, I’ve been using Scala almost exclusively, and I wish to revise my view: Scala is awesome.

While some of my initial thoughts still stand, particularly that Scala APIs often overuse operator overloading, much of my perception has shifted otherwise. Scala not only allows, but encourages solid functional programming principles that are difficult or impossible in Java.

Comfort and Training

A great deal of my perception shift has been due to familiarity and training. I realize that a lot of my earlier issues with Scala were due to my own lack of comfort with the language, and over the last year I’ve done a great deal to level up my Scala skills significantly, like:

• Read the entirety of Odersky et. al.’s Programming in Scala cover to cover
• Attended Dick Wall and Bill Venner’s excellent Stairway to Scala week-long workshop (this probably made the biggest contribution to me getting over the Scala hump).
• Read what was available of the MEAP Functional Programming in Scala, a book focused not on Scala but on Functional Programming principles
• Enrolled in Odersky’s Functional Programming Principles in Scala class on Coursera.
• Currently reading Josh Suereth’s Scala in Depth, which actually wound up being the Effective Scala book I wanted in the previous post.

All of these resources, combined with a continued daily use of Scala, led to me using Scala in a much meatier way than previously, enabling me to write some extremely expressive code.

Cool Stuff in Scala

Close your eyes during lectures, it sometimes it sounds like Schwarzenegger is teaching you programming.

I really like how strict Scala is in terms of the compiler. Many developers are embracing increasingly dynamic languages, but Scala bucks the trend. The ability to define generics, covariant types, contravariant types, as well as the existence of classes like Any, AnyRef, and Nothing, allow developers to rely on the compiler to check things that, in other languages, can only be checked at runtime. It’s possible to be this strict in Java most of the time, but somehow I feel like the way Scala handles this complexity is cleaner and more elegant. At work, we implemented our own Dependency Injection system that checks all injections at compile time, no XML required.

Scala makes it easy to implement good Functional Programming paradigms, like higher-order functions, function composition, and currying. Though possible to implement the Option pattern in other languages, Scala’s type hierarchy and rich generics support makes it much easier to cleanly avoid exceptions. Being able to perform flatMaps on collections of Options in a way that feels natural is excellent.

Pattern matching is simply awesome. Declaring extractors for types has allowed me to write some incredibly cool code. Pattern matching can have a tendency to lead to deeply nested matcher blocks, but I still like them overall. My biggest complaint is that, while they work so well at matching against Regular Expressions, Regexes not being a first-class type makes working with them a little clunky. You have to declare Regex variables by calling the r() method on a String (usually triple-quoted). It would be much easier to work with regular expressions /like this/.

As with all other languages I enjoy, I love being able to return multiple things from a method and perform multiple assignments in a single line. And being able to pass a type to a method which solely defines the type anonymously in terms of which method(s) it must have is a super cool feature that can be abused.

I initially complained about operator overloading, and I still feel like it can be overused, but I’ve always felt like Java should at least support limited operator overloading, at least on the basics like +, -, <, >, and so on. Scala supports totally arbitrary operator overloading, which gives me what I want at the expense of allowing other people to overuse it. Additionally, the rules that Scala has to follow to allow for normal order of operations with infix operator overloading are a bit ridiculous (check page 135 of the Odersky et. al. book), but that’s the price you pay to keep infix support, I suppose.

The Point of Scala

Scala is a great language because it’s to FP what C++ was to OO. It’s familiar to users of the more traditional programming paradigm, but capable of a different one. It allows people to gradually shift towards Functional Programming as they gain comfort with the ideas, and it allows programmers to use Object-Oriented Programming where it’s the best tool for the job. Scala lets you leverage the power of a functional language and the power of an OO language simultaneously, catering your code to the strengths of each paradigm where more appropriate. Code that would be henious in OO land might be very reasonable in FP style, and code that would be unweildy and complex in FP might be totally understandable in OO. Scala lets you choose whichever works best for what you’re doing.

I’m not aware of any other languages that embrace both FP and OO as thoroughly as Scala. Programmers are free to use it as an even stricter, more statically compiled Java (with less boilerplate and some handy convenience features like case classes and traits) if they wish, or they can go whole-hog into the Functional style and leverage lazy evaluation, tail recursive functions, currying, partial application, monads, and so on.

This allows me to use the power of Scala without losing my knowledge of the JVM, the huge library of open source code written in Java, or even JVM-based frameworks. I’m not totally on board with any of the web frameworks for Scala, so I’m using Groovy/Grails for a client-facing site, which connects to a bunch of backend services written in Scala. Being able to do this is great (though the switch can be a bit jarring at times).

Overall, Scala is exactly what it needs to be, and it’s an incredibly well-designed and clever language.

Still Some Woes

There are a few nags I have about Scala. It’s power comes with a price – even though I understand Scala pretty well now, it’s still common for me to encounter code that looks almost unreadable, sometimes resembling particularly bad Perl programs. I have to really sit and stare at this code to parse it, which can be time-consuming. This seems to be common even among seasoned Scala vets, which is disheartening.

There are also some nags I have about the language design itself. I hate that XML is treated as a first class type with lots of compiler support, but regular expressions are not. In 2012, it’s difficult for me to take an expressive language seriously if I can’t define a regex without first creating a String. It also annoys me that there is an annotation that makes the compiler check for tail recursion, but not one that provides automatic function memoization.

Interop between Java and Scala still seems to suck pretty bad, especially around Collections. You can do some things to make this problem less severe, but it’s still harder than it needs to be, and I’m not convinced there’s a good reason.

My biggest complaint is with the Scala ecosystem. IDE support is tolerable but not excellent, but more importantly the build tools are terrible. All of this power and all of the things the compiler does for you causes compilation to be extremely slow. A large Scala project can take ten minutes just to compile.

The only workaround for this seems to be to use SBT and leverage its built-in incremental compilation, but SBT happens to be extremely difficult to understand and use. Unfortunately, SBT seems to be the only game in town for Scala; we tried a Gradle build for our large Scala project and converted to SBT after spending a great deal of effort and still failing to make the full build in Gradle take fewer than 40 minutes.

Basically, you’re using either Maven or Gradle to build your project but it takes forever, or you’re using SBT and it builds quickly, but modifying your build takes forever instead. My understanding is that some work is going on in the Twitter/Foursquare land to create a new build system that perhaps leverages the incremental compiler, so I’m excited to see what comes out of that.

All in all, I’m very happy using Scala regularly now, and I often find myself missing it when I’m using another language. The community seems to have exploded in the last year or so, with excellent online courses based on Scala, and tons of fantastic functional programming books having been released or currently being written using Scala as the base language. I think it still has a ways to go in terms of good tooling support and compilation speed, but I’ve definitely come around to the Scala way of thinking this past year.

“The Career Programmer” is meant to be a dispensation of wisdom from a sage, a book that gives younger programmers keen insights from someone who has been in the industry for a long, long time. I tend to really enjoy books like this, so I picked up a copy. Unfortunately, it comes across as an anachronism, like the book time-traveled out of the mid-90′s. While reading it, I felt compelled to double-check the publication year, and was absolutely astonished that it was printed in 2006. The “wisdom” of the book is so hopelessly out of date with the current state of software development that I cannot recommend it to absolutely anyone.

Duncan’s view of software development is straight out of Dilbert. Managers are idiots that hold all the power, programmers are just lackeys that do what they are told. In his world, “shit rolls downhill” and programmers are at the bottom of the hill. Duncan has over a decade of experience in the industry, which is the basis for his advice. Well, I also have a decade of experience and I have never, ever worked in a place as dysfunctional as what he describes as typical. Perhaps I am extremely lucky or just extremely talented, but I doubt either of those are true. If I found myself at a company like those Duncan describes, I’d leave immediately and get a new job, I certainly wouldn’t build a 10-year career stringing those experiences together.

As an example of what I’m talking about, Duncan describes that programmers are expected to “do whatever it takes” to get the job done, which means:

“Now would be a great time to rent out your house because you’re not going to be seeing much of it until after the deadline. You will code, eat, and do everything but bathe in your cube for as many consecutive hours as you can manage to stay conscious.”

Duncan’s book is meant to contain tips for avoiding this scenario, but I’ve avoided this scenario my whole life without them. In my 10-year career, I have worked late on exactly 3 occasions, each lasting no longer than one week. On these occasions, I was home by 9pm. On 2 of those 3 occasions, my team and I worked late not because it was expected of us, but because we had messed up and supplied a commitment we shouldn’t have, and we felt honor-bound to meet it. Any other work outside of office hours has typically been a midnight deployment, and the expectation has always been that I’d be sleeping in and coming in late the following day.

Probably not his best work.

Pointy-haired bosses have never demanded I work late to meet a deadline. In my experience, programmers that habitually work late are the worst programmers, constantly digging themselves into spaghetti code nightmares that result in them making up for lost time. Working late is an admission that you suck too much to get your job done during business hours, and most managers know this. I don’t think my experiences are the exception, I think they are the rule. Most companies simply don’t operate this way anymore, and those that do tend not to have developers for long.

He goes on to talk about vague requirements with tight deadlines. He states:

“It’s almost completely unheard of in our business for management to ask us for a system without attaching a timetable of some sort.”

This is nonsense, and can come only from a programmer who has had absolutely no experience with agile development. This kind of death march was common in a time when people were all-Waterfall, but in the post-agile-manifesto world, this kind of thing is vanishingly rare. Almost every project I’ve worked on has either had a fixed delivery date with variable scope, or fixed scope with a variable delivery date; very rarely are both dimensions fixed.

Duncan confirms that his view of the world is based in Waterfall when he talks in Chapter 2 about how management often shortchanges the “Analysis and Design Phase” – terminology right out of Waterfall. Chapter 4 talks about gathering requirements in an official requirements gathering phase, and getting them “set in stone”. He argues that a formal requirements document gives you “ammunition further down the road when someone comes along and wants you to add additional features.” This kind of thing is dinosaur-talk, people who know what they are doing don’t develop software this way. They gather small numbers of isolated requirements in user stories, and get those stories finished and in the hands of users. In real life, software requirements are going to change – pretending you can get requirements set in stone to protect yourself later on is simply divorced from reality. It’s far better to embrace a process that allows for that kind of shift, as virtually any professional software developer I’ve met in the last ten years would attest.

The book constantly references the “maintenance programmer,” the concept of a programmer that takes over maintaining the system after the Serious Developers have built it. This type of development is such a glaring antipattern I can hardly have imagined someone mentioning it in any positive context in 2006. The programmers that write the system should maintain it, end of story. All programming is maintenance programming, developing a system and throwing it over the wall is a recipe for long-term disaster. Again, I haven’t heard anyone talk this way in a long, long time. Duncan’s notions of software are a blast from the past.

To be eaten, not compiled.

The real clincher for me was Duncan’s chapter on Effective Design Under Fire. Duncan acknowledges that there are many “excellent books on the software design process lining your shelves” but that he has “rarely been in a shop in which management gave the developers even a fraction of the time necessary to fully implement these methodologies.” First of all, writing well-crafted, maintainable, high-quality code is not management’s call, it’s yours as a professional. To shirk your professional responsibility because of deadlines is to be professionally negligent. Duncan confirms my worst suspicions when he states:

“I’m about to … destroy my reputation in the eyes of credible and respectable professionals everywhere. However, I’ve got deadlines to meet, and I’ve always been more interested in that than looking respectable.”

Combine this attitude with Duncan’s belief in the “maintenance programmer” and the fact that he spent most of his 10-year career as a contractor and a pretty clear portrait is painted: Christopher Duncan comes off as someone who writes crappy code and then bounces to another job before having to maintain it. Duncan seems like the worst type of programmer: the guy who doesn’t worry about writing quality code because there’s Just No Time and then believes it’s someone else’s job to clean up after his mess.

When Duncan is explaining some tactics for good design, he advocates Big Design Up Front (wrong) but suggets to basically rush it as much as possible (doubly wrong). He argues for prototyping systems before actually building them (often wrong) but describes prototypes that are fully-functional UIs (wrong) with nonfunctional implementations (wrong). If you’re going to build a prototype, you should build a steel-thread prototype with a garbage UI – there is literally no point to the kind of prototype Duncan describes except to mislead your stakeholders about the progress of the system. His view couldn’t be more wrong.

Duncan argues that accurate estimates are essential. He devotes a chapter to improving your estimation technique which boils down to this:

“just to be on the safe side and make sure we have a little cushion in case things go wrong, we multiply [our estimates] by two and give it to the project manager [who then will] multiply the numbers he was given by two and turn the estimate in”

Padding estimates

Duncan’s strategy for estimates is to pad all estimates by a factor of 4. Why 4? Why not 2, 3, or 8? What a completely unprofessional stab in the dark. How is possible to be this criminally unaware of scrum, sprints, story points, and velocity in 2006? For crying out loud, as our industry has matured and improved, even Scrum is out of date in favor of a more metrics-oriented planning within a Kanban framework – Duncan is two process methodologies behind the times.

The book is well-written and entertaining, so at a technical level it is good, but the advice is presents is the worst possible.

I really don’t mean to be too harsh on Christopher Duncan. He seems like a genuinely funny, nice guy, and my issue is not with him personally, but with the advice contained in this book. He was a Windows C++ programmer who spent most of his career developing software that shipped on CDs. Towards the end of his career, he saw a sudden shift toward the Web for delivery, and attempted to learn Web-related technologies, then soon after quit the industry and became a full-time speaker and author. Maybe if Duncan had stuck with it, he would have matured and grown along with the rest of us rather than stay stuck in his antiquated notions of professional software development. But the fact of the matter is, he didn’t, and the world has changed without his awareness. To publish a book full of outdated wisdom as though it had any applicability to today seems borderline careless. I shudder thinking of young programmers reading his book for career advice, taking it to heart, and then joining a team I’m on. Is it illegal to screen out any job applicants who like it? The attitudes in The Career Programmer are absolute poison for a good software engineering team.

Everything about this book is wrong. Every aspect of The Career Programmer is covered better, by people who know what they are talking about, in other books. Here’s my list of suggestions for similar books that are all vastly superior to this one:

• The Pragmatic Programmer – Full of general tips for programmers to improve their skills.
• Emergent Design – Describes the ACTUAL way to handle design under pressure: by organically growing and evolving the design of the code as needed.
• The Passionate Programmer – Covers how to handle your career development.
• Agile Estimating and Planning – Describes how to estimate work well within an agile framework.
• User Stories Applied – Talks about how to gather requirements properly. Another good one is Agile Software Requirements, which is quite a bit more in depth.
• The Clean Coder – All about how to conduct yourself professionally, how to interact with the business and handle “politics”.

The Clean Coder is the one that is most similar to The Career Programmer in terms of purpose, but in almost every way it is the polar opposite. I think every programmer should read The Clean Coder, but even moreso if one finds him or herself tempted to read The Career Programmer.

Do not, under any circumstances, read this book. It will bore and annoy you at best, and ruin you at worst.

How common is it? It’s so common that this post has been in my Drafts for about five years. What I mean is, I wrote it in reaction to someone irritating me at work, but decided not to post it because I was worried they would see it and know I was talking about them. And it’s been in Drafts since that day because I encounter it so often that any day I post it, it will be seen as a response to something that actually happened at work. There hasn’t been a break in the last five years where I could post it without at least one person thinking it was a reference to them. That’s how common it is.

In fact, I know posting even now, it’s going to look like it’s related to an occurrence this week. STFU co-workers, I wrote this shit ages ago.

Anyway, what I’m talking about is developers refusing to do things or complaining about doing things because they distract them from what they call “Real Work.”

Here are some examples:

• “Can you come back later? I have Real Work to do.”
• “Ugh, can we finish this meeting? I’ve got some Real Work to do.”
• “I didn’t have time to update that ticket, I was doing Real Work.”
• “Why are we even talking about this, don’t we all have Real Work to do?”

Fake Work?

The implication here is that the developer is resisting a particular thing in favor of doing Real Work, implying that the thing they are resisting is inherently not Real Work.

And what is Real Work? Real Work is writing code. I’ve never seen a developer ask to stop coding so he can do some Real Work in a meeting, Real Work only ever refers to sitting at a computer and typing code.

Over my career, I’ve seen the Real Work dichotomy used to avoid, resist, or complain about planning, designing, retrospecting, conversing, whiteboarding, testing, bug swarming, estimating, and even deploying.

What this phrase is really a euphemism for is “fun stuff”, but nobody would ever say “I don’t want to go to that meeting, I have fun stuff to do,” because it would make them sound like a whiny brat. As an aside, I wonder how these exact people would feel if their boss saw them on Reddit and asked them if they had any “Real Work” to do.

Here’s the deal, fellow developers. You’re not a professional Coder. Your title isn’t Lead Code Writer. It’s probably something like “Software Engineer” or “Software Developer”. Your job is not to write code. Your job is to write software, and that’s not exactly the same thing. Sometimes, successfully developing software means you need to plan what work will be done in a long boring planning meeting. Sometimes, developing software means estimating work so that business stakeholders can have a good idea of when stuff will be done. Sometimes it means grabbing a whiteboard and figuring out long-term architectural direction. Sometimes it means having long, drawn-out discussions or even arguments with other developers who feel differently than you. And yes, sometimes, it means writing code.

But I only want to do the stuff I want to do!

Writing code is just one part of developing software. The fact that it’s the part you like the most doesn’t mean you don’t have to do all the other stuff – doing that stuff helps ensure the success of the project. If you’re in a planning meeting, the meeting isn’t keeping you from doing your job, the meeting is your job.

When you’re at work, everything you do is real work by definition, at least as long as the company is willing to pay you for it (so playing Angry Birds on the shitter for 20 minutes while your legs fall asleep probably doesn’t count).

I’m not arguing for unnecessary distractions. A planning meeting for poorly defined work, a discussion that leads to no decision, or a bug triage meeting that fails to identify the source of bugs are all waste, but they’re not waste because they’re keeping you away from your keyboard, they’re waste because they’re keeping you from making forward progress on developing software. We should always strive to minimize meetings and reduce distractions, but that shouldn’t be used as an excuse to avoid being a professional.

Every time I hear someone complain about having to do something they don’t want to and how they have “Real Work” to do, all I can hear is a crybaby whining that real-life professional software development doesn’t consist of them sitting in front of a monitor with headphones in for 8 straight hours per day. Get over it, you’re not entitled to fail to communicate with your team or your business simply because it’s not fun for you.

Imagine if you ordered a hamburger at Burger World and the register-worker told you that he wasn’t putting in your order because the part of his job he likes is flipping the patties, and he really doesn’t like entering orders. That’s you every time you talk about “Real Work.”

This is part of the reason software developers have a reputation for being unprofessional. It’s not because we like wearing t-shirts with dumb nerd shit on them or curse a lot, it’s because we have a tendency to act like self-entitled, obstinate twerps.

The problem is, 99% of the time people discuss Traveling Salesperson being NP-Complete, they are wrong. The Traveling Salesperson Problem, as it is usually described, isn’t NP-Complete at all. In fact, it’s not even in NP.

The Traveling Salesperson Problem is typically described as “given a graph of cities various distances away from each other, find the shortest path for a salesperson to visit every city exactly once and return to the origin city.”

More formally, TSP is “Given a graph $$G$$ of vertices $$V$$ connected via nonzero cost edges $$E$$, find the lowest-cost Hamiltonian circuit”

Traveling Salesperson from Wolfram Mathworld

However, this particular version of the problem is the optimization problem (“find the lowest cost”). There is another version of the problem, the decision problem, which is “Given a graph $$G$$ and a cost $$k$$, decide if there is a Hamiltonian circuit whose cost $$\le k$$.”

The decision problem, the one which requires a cost to be given and simply decides if there is a cheaper (or equal) Hamiltonian circuit, is NP-Complete. But almost everyone who talks about “the Traveling Salesperson Problem” is talking about the optimization problem, which is not NP-Complete, it is NP-Hard.

What does it mean for a problem to be in NP? It’s actually simpler than it is often made out to be: A problem is in NP if, given a correct answer (a certificate) to that problem, you could verify that it is correct on a deterministic turing machine, in polynomial time.

That’s it. Some might object to this definition, wondering “doesn’t the algorithm that solves the problem have to run in $$O(2^n)$$ or some other terrible runtime?” In fact, no. Every problem in P is also in NP since P is a subset of NP. Every problem in P has a deterministic, polynomial-time verifier – they must, since they have polynomial time deciders! Having a polynomial-time verifier is necessary and sufficient for a problem to be in NP.

So what’s NP-Hard? A problem is NP-Hard if every problem in NP can be reduced to it, meaning it is at least as hard or harder than any problem in NP.

A problem is NP-Complete if and only if it is both in NP-Hard and NP.

Complexity Classes (assuming P != NP)

The traveling salesperson decision problem has a polynomial-time deterministic verifier. Given a connected graph $$G$$ and a cost $$k$$ and a candidate (a cycle that hits every vertex and costs less than or equal to $$k$$) $$C$$, we can quickly verify that $$C$$ has the same number of vertices as $$G$$ and that its cost is less than or equal to $$k$$. Therefore, the decision version of the problem, TSP-DECIDE, is in NP. And since it’s also in NP-Hard, TSP-DECIDE is NP-Complete.

But we do not have any known polynomial-time verifier for the optimization version of the problem, TSP-OPTIMIZE. If you were given a path, how would you verify that it truly is the lowest-possible cost without checking all other possible Hamiltonian cycles and making sure none of them cost less? Is it possible that TSP-OPTIMIZE is also NP, and therefore NP-Complete? Yes, it has not been proven that there cannot be a polynomial-time deterministic verifier for TSP-OPTIMIZE, though it certainly seems unlikely there would be one. But as it stands, TSP-OPTIMIZE is not in NP because it lacks the verifier, so it is in NP-Hard but not NP-Complete.

TL;DR: For now TSP-OPTIMIZE is in NP-Hard but not (necessarily) in NP, so its not in NP-Complete. TSP-DECIDE is both in NP-Hard as well as NP, and is therefore NP-Complete.

Mistakenly referring to the optimization version of Traveling Salesperson as NP-Complete is unbelievably common among computer science students, so common that I took it for granted that it was the case for years. I just saw this article in Communications of the ACM which refers to:

The NP-complete traveling salesperson problem asks for the smallest distance tour through a set of specified cities.

So next time a computer science person tells you that Traveling Salesperson is NP-Complete, ask them to define what they mean by “Traveling Salesperson”, you’ll be surprised how often they will say “lowest cost” and get it wrong. And hopefully, if you’ve been getting it wrong for years, you’ll now know better.

UPDATE: This post has been linked to by Hacker News and Reddit now, so lots of people with more knowledge than me have begun leaving enlightening comments. Please read them as well, they explain some things that I was not entirely clear about, and have issued some corrections where I may be mistaken.

Imagine you are writing some software that will have a number of interacting components. I’m going to suggest a toy example, one that will help illustrate what I’m talking about, but is not so complex to actually warrant it. Imagine you are going to write a Lottery game. Players will have lottery tickets, and they will listen for Callers to read out the winning lottery number (think Observer pattern). The Callers will use a Hopper with numbered balls, selecting the appropriate number of balls and then calling out the winning number at the end.

To follow the Single-Responsibility Principle, you think your game will probably have three classes:

1. The Hopper – this contains all of the numbered balls and, when asked, returns one to the caller (removing it).
2. The Caller – once the lottery has started, this will ask the Hopper for numbers and call out the final sequence of numbers to registered Players
3. The Player – this will observe the Caller, listening for numbers to be called and determine if he is a winner by comparing the numbers to his array of numbers (given at construction).

The Player is going to interact with the Caller, and the Caller is going to interact with the Hopper.

Traditional Bottom-Up Coding

The Hopper has no dependencies on anything else, so it’s the simplest to write. You can construct it with a set of numbers, provide a way to get one of the numbers at random (removing it from the set). It’s the easiest to test and the easiest to write because it doesn’t depend on any of the other classes. So some (most?) developers will start with the Hopper. Once the Hopper is done and it has a clearly defined interface, the developer will write the Caller. Then they will finally write the Player and be done.

One might reasonably refer to this as the bottom-up approach to this problem, starting at the bottom-most, dependency-less class and working upwards, building on each newly-created class to make the next one. This is a very abstraction-oriented approach to development, and it’s a natural fit for many developers. For example, a developer knows that his or her code will have to eventually hit a database, so they naturally want to write the database-accessing component first, then build on top of it once it’s done.

There are problems with this approach, of course. The primary issue is, you might write Hopper and think you’re done, then as you’re writing Caller you discover that you really wish Hopper worked in a slightly different way. Since the issue is a problem of the interface, you must modify the Hopper interface, breaking the tests written against it. So you have to halt your work on Caller, go back and modify the Hopper tests, modify the Hopper interface and implementation, and then even modify the mocked version of Hopper being used in the Caller tests, all before getting back to Caller. This kind of interruption kills any sense of momentum.

Because of this, you’re never really working on a class in isolation. You’re juggling between that class and its dependencies, keeping all of them up in the air and available for change at any time, potentially burrowing all the way into your bottommost dependency, far away from where you’re trying to focus.

Developing this way also means that nothing is presentable to a customer until it’s almost completely finished. The class closest to the customer is done last, which means an awful lot of work has been done before the customer has a chance to indicate that things aren’t quite as he or she would like.

Alternative: Need-Driven Development

Allow me to propose a different way of dealing with this problem: code top-down, start with the Player.

The Player is ultimately the client and the real point of entry for this system. The Player is the class closest to the user. Player will obviously need to reference Caller, so create an interface for Caller and mock it out in the test for Player. As you are writing Player, whenever you need Caller to do something, just assume it already does it and write the interface method for how you wish it to work, from the perspective of the Player. Mock it out so that, within the test, it DOES do that, and move on.

When you’re done with Player, since you already assumed Caller works, move on to implementing Caller. You have already defined its interface based on the needs of the code consuming it, and you already have a head-start on what tests you need to write based on the behavior you mocked out in the Player test. Write Caller, this time mocking out Hopper in a similar way. Then move onto Hopper.

At each stage, rather than simply guessing at how you will want to use the class you are writing, you’ve already defined exactly how you want it to be used. This client-oriented approach means that your classes are always designed with the client in mind, and therefore the code that uses them is always extremely clean and intent-revealing. As a bonus, you have a great outline for the tests you need to write at each level.

I’ve liked developing this way for a long time, but I never knew what to call it. Well, I recently found out this approach already has a name: Need-Driven Development¹.

Advantages

As mentioned, the main advantage here is that your code is always designed with the consumer in mind, which helps ensure code is clean and understandable.

Another advantage of this approach is that it will help with YAGNI²: bear in mind the example from Bob Martin’s Bowling Game, in which Martin and Bob Koss developed a Bowling scoring program bottom-up, only to discover they were needlessly creating more classes than really essential. Working top-down means you only split out into a new class when it’s truly essential. A good heuristic to follow is if you’re coding and think “I really shouldn’t do this in this class…” you can assume another class is doing it, create the interface for that class, write the methods as you wish they existed, mock them out, and continue on without letting it distract you for long.

It also lets work you quite a bit faster. Instead of getting hung up on the implementation detail of something unrelated, if you find yourself saying “I really don’t feel like figuring that out right now” you can refuse to. Instead, create a class whose job it is to figure that out, then keep working on the assumption that it’s already done. Delegate difficult work to a placeholder, then go back and fill it in later.

This even works extremely well when doing heavy front-end or client work. Build a stub that claims to do the work you wish was already done, then code to that stub. Once the component is completely finished, you can move on and flesh out the real implementation of the stub, all the while knowing that you can’t break the client.

Lastly, this approach makes your work demoable much earlier. No matter where you are in the process, the part closest to the user is the most complete, so your customer or product owner can interact with it and have a decent idea of how the final version will work³.

So next time you’re writing some new code, don’t start at the bottom, start at the top. Develop based on your need.

1. xUnit Test Patterns, p. 149
2. You Ain’t Gonna Need It
3. It’s a good idea to make it visually clear the work isn’t complete, however. Otherwise they may want to ship early.

• Access and edit wiki from browser
• Run in OS X (Laptop) and Linux (Workstation)
• Synchronized across all machines
• Can use offline

I tried using TiddlyWiki with DropBox as the cloud-based sync mechanism, but I use Google Chrome as my browser, which has a lot of trouble with the Java plugin that does the saving. There are command line arguments for Chrome that fix this, but that’s weirdly difficult to deal with on OS X.

So my final solution, subject to improvement, is to use Gollum. Gollum is a Ruby-based wiki server that runs completely self-contained (you don’t need to install PHP or a database) and is backed by Git. I use a Git repo cloned off a private GitHub repository for sync functionality.

There are a number of steps to getting this set up, so I’ve decided to document them here, both for the benefit of anyone else who wants to do this, as well as for myself if I have to set it up on another machine.

These instructions are geared toward OS X, largely because I found it more difficult to set up on OS X than Linux, simply because OS X’s support for scheduled and startup script running is clunky and stupid.

GitHub

The reason I like GitHub for backup/sync is that their web interface has a built-in editor that supports Markdown, the same Wiki syntax I’m using in Gollum (Gollum actually supports many different formats, but Markdown is one of the easiest to install). This means I can view, edit, and preview using the GitHub web interface alone, in case I need to access my wiki data from a machine that does not have Gollum set up, but does have a web browser. My smartphone, for example.

A private repository on GitHub will cost you $7 per month, which is a little pricey if all you’re going to do is have a personal wiki stored there. You could open source your wiki to get around this, or you could also use BitBucket, which offers free private git repos, but doesn’t have the slick web interface for viewing or hand-editing the markdown files Gollum uses.

In any case, get a Git repo set up on either GitHub or BitBucket. Since I think GitHub is better for this purpose, I’ll be using git@github.com:rodhilton/personalwiki.git as my repository URL.

Gollum

The easiest way to install Gollum in OS X is to run gem install gollum. This requires that you have Ruby and RubyGems set up correctly. OS X 10.5 and up have this already, so this shouldn’t require any work on your part.

Once Gollum is installed, you need to install support for a wiki syntax. I’m using Markdown, so I run gem install redcarpet. Instructions for how to use alternative formats can be found in the Gollum installation README.

Now, clone your personal wiki somewhere handy. I’m putting it in my home directory, so I merely run git clone git@github.com:rodhilton/personalwiki.git from Terminal in ~. This will check things out at ~/personalwiki. Change into that directory and run gollum. You should see something like:

== Sinatra/1.3.2 has taken the stage on 4567 for development with backup from Mongrel

Open a browser and load http://localhost:4567 to verify things are working correctly.

Pro-tip: Gollum allows you to create files called _Footer.ext and _Sidebar.ext in the root of your repo that will show on every wiki page, where .ext is the extension for the wiki format you’re using. In Markdown’s case, .md. The files must be added and committed by hand.

Alternative Installation

I often find that installing gems under rvm and then trying to run those gems outside of the shell (like, at login) gives me trouble. Another way to install Gollum, and the method I’m using on one of my machines, is to check it out from source and use bundler.

To do this, clone the Gollum repo to somewhere on disk, such as /usr/share/. Then in /usr/share/gollum, run sudo bundle install. This will install everything you need.

When I need to reference the absolute path of gollum, it’s now /usr/share/gollum/bin/gollum so I can work around rvm’s oddities.

Synchronization with GitHub

Gollum makes local commits only, it doesn’t push those commits to any remotes. This means that nothing is going up to GitHub yet, which prevents me from synchronizing across multiple computers.

To solve this, we’re going to periodically run git pull && git push from our repository. This will pull any outstanding changes and push any local changes up to GitHub for us automatically.

There is potential here to get merge conflicts. If I were to edit a wiki entry in Linux, then switch to my Mac and edit the same file, I’m going to get a merge conflict that prevents the sync from executing. This kind of conflict requires manual intervention, but since I’m running the sync commands non-interactively, I wouldn’t see this happen and know to fix it. To mitigate this problem, I’m going to have the sync command run every 60 seconds. This makes the window for getting a merge conflict very small, though having a machine disconnected from the internet for an extended period of time enlarges this window considerably.

Gollum stores each wiki page in a separate file and uses a very simple markdown syntax for them all. There are no database files being shared or single-file indexes, so a conflict can only arise by editing the same wiki page, in approximately the same place. Otherwise Git will be able to merge the files and handle things without intervention. So far, I have not actually gotten a merge conflict that needed to be dealt with manually, so the windows seem small enough.

In any case, I’ve added a script to my ~/personalwiki named .sync.sh which looks like this:

DIR="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
(cd $DIR && git pull && git push)

What this is doing is figuring out the directory of the .sync.sh script itself, changing to it, then running git pull (to pull any changes from GitHub) and then git push (to push any changes back up to GitHub). Make sure to set the script to executable by running chmod a+x .sync.sh. Also make sure to make a local commit of this file (otherwise, ironically, it won’t be able to run itself since your git working tree is dirty) by running git add .sync.sh && git commit -m "Sync script".

This script can be run from anywhere (this is important) and it will sync the wiki. Now it needs to be set to run periodically. On OS X, we’re going to use Apple’s incredibly stupid and terrible launchd, because crontab has been deprecated for reasons that are behind my comprehsion.

Add a file called com.personalwiki.sync.plist to ~/Library/LaunchAgents/ which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.personalwiki.sync</string>
  <key>RunAtLoad</key>
  <true/>
  <key>ProgramArguments</key>
  <array>
    <string>/Users/your_name/personalwiki/.sync.sh</string>
  </array>
  <key>StartInterval</key>
  <integer>60</integer>
</dict>
</plist>

You can have this run more often by decreasing the “60″, obviously, but per-minute seems fine for me.

Running Gollum on Startup

First, we’re going to make a script that runs Gollum for us. Place a script in ~/personalwiki named .gollum.sh:

DIR="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
/Users/your_name/.gem/ruby/1.8/bin/gollum $DIR

Again, the goal here is that the script can run from anywhere, so it has to first figure out where it is, then run Gollum on that path. It’s a good idea to provide an absolute path to the gollum executable, particularly if you are using rvm or something similar. To get this, just run which gollum to see where gollum is running from, then use that path.

If you want gollum to run on a different port, you can add –port [number] like so:

/Users/your_name/.gem/ruby/1.8/bin/gollum --port 7890 $DIR

Again, make sure you make this script executable (chmod a+x .gollum.sh) and commit it to your git repo (git add .gollum.sh && git commit -m "Gollum script").

Now we need to make this script run at startup. There are lots of ways to run things on startup in OS X. I think LoginHooks are dangerous because they are difficult to track down, so we’re going to stick with OS X’s abysmal launchd nonsense.

Place a file named com.personalwiki.gollum.plist in ~/Library/LaunchAgents/ which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.rodhilton.gollum</string>
  <key>ProgramArguments</key>
  <array>
    <string>/Users/your_name/personalwiki/.gollum.sh</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

God that’s hideous. /etc/init.d/ too good for you, Apple?

Anyway, you should now be able to log out and back in, and have everything work.

Testing and Troubleshooting

When you log back in, open up http://localhost:4567 and make a change. Within a minute, this change should show up in your GitHub account. If it doesn’t, launch “Console” from Spotlight, and type “personalwiki” in the filter to see if there were any problems running your scripts.

That should do it, now you’ve got a GitHub-synced personal wiki. I actually run two on my machine (that’s why I included the bit about the port) one for personal wiki stuff which backs to my GitHub account and one for work-related stuff which backs to my corporate GitHub Enterprise account. I make sure these always run on the same ports on every machine, so I’ve got bookmarks in my browser bar that always work across machines.

So far I’m pretty pleased with this solution. I wish it was easier to sync via Dropbox instead of Git but the benefit of Markdown support in GitHub almost turns this con into a pro.