Mental Pandiculation

I’m a gardener. It’s in my blood I think, something that goes back to both my grandparents who had gardens. My mom has beautiful roses in her backyard. People in my family garden. Like most pursuits, gardening gives back what you put in, oftentimes in multiples as long as the input is over a certain threshold. If you put in the absolute minimum, you can still receive great paybacks as long as you choose plants and flowers that are OK with little help in surviving. If you’re like me, you can greatly increase what you get back out of your garden by constantly improving the process, finding new ways to increase efficiency or productivity, tinkering with results, etc. Regardless of what kind of gardener you are, as long as you don’t give up, your gardens will typically survive.

However, if you stop doing the bare minimum, you will no longer receive any results at all, at least as it relates to producing flowers or vegetables. If you give up or reduce your effort below a threshold necessary to achieve a standoff with nature, nature will quickly take over and your carefully cultivated gardens will return to their natural state, one of abandon and disarray. There may still be rare successes but they are random and always under attack from weeds, drought and pests. A rose left at a country house long abandoned may continue to bloom for many years but the plant will constantly be surrounded by weeds and pests.

Software projects are not unlike gardens in this regard. Different types of projects require different levels of attention but they all must have a leader of some sort. There is often talk of self-organizing teams that turn out solid results but these teams were typically either brought together by a leader who remains engaged in some way or are comprised of individuals who express leadership in different ways within the group. If a software project does not have a leader or the leader is distracted from the needs of the project and team, the project will begin to deteriorate. Almost immediately, the entropy of nature will set in. Weeds begin to sprout up. Edges begin to deteriorate. The structure of the project erodes and dirt seeps out of the cracks. Without leadership, no project can stand up to the force of natural entropy. Once that entropy takes over, it takes an inordinate amount of work just to get the project back to a functioning state.

This is an aspect of all methodologies, but specifically Agile (big A), that is often overlooked and undersold, that of strong leadership. The literature often talks about the team, self-organizing, Gestaltic, productive. But no team survives that way without leadership though the leadership can come from within the team instead of the typical all-knowing leader. Someone (singular seems preferable though I know of teams that have 4 leaders and 1 team member that work reasonably well) has to turn on the sprinklers, pull the weeds, mulch the ground, apply small dosages of fertilizer so that the team can become more than the sum of its parts. Without that strength of will and character, the team will almost always devolve over time into an incoherent mass of movement, undirected and inefficient.

Ah, TFS, you shouldn’t have. A gift? For me? I know I’m leaving but I really didn’t expect anything. Here, let me open it.

(sounds of paper being unwrapped, boxes opened, scotch tape sliced with an overly large kitchen knife)

The Present: “Note that you need to manually track the ID returned from your subscribe commands if you don’t plan on writing code. There’s no way to get a list of subscriptions from the command line. While you can poke around inside the SQL Server® 2005 databases, that is neither recommended nor supported.”

So, umm, TFS, if I created a subscription months ago, you’re telling me that I needed to manually track the ID so that I could unsubscribe from it months later when I was leaving? You suck TFS. You suck hard. I hope you kept the receipt because I want my damn money back.

I’m working on SSRS and reports as part of my current contract (you should pity me just a little) and we needed to order the result set of a report based on user input. I initially tried this

Select i.SkuNo, g.Reference from Item i
INNER JOIN GTable g on (g.ItemId = i.Id)
Where g.Category = @Category
ORDER BY CASE WHEN @OtherParameter = 'Some Value' THEN i.SkuNo ELSE g.Reference END

This worked fine as long as i.SkuNo and Reference were convertible to the same type, in this case a bigint. Unfortunately, Reference is a varchar and so if the table had some data in Reference that was not convertible to bigint, the report blew up. The fix ended up being pretty easy (they always are after they are fixed).

Select i.SkuNo, g.Reference from Item i
INNER JOIN GTable g on (g.ItemId = i.Id)
Where g.Category = @Category
ORDER BY CASE WHEN @OtherParameter = 'Some Value' THEN i.SkuNo END,
CASE WHEN @OtherParameter = 'Some Other Value' THEN g.Reference END

That worked like a champ. It didn’t make SSRS any more palatable but at least I can file another bug as fixed.

Ben Rady has a new metaphor for the MVC pattern, the command line. It’s interesting how as you become more familiar with a particular pattern or technology, you begin to see it in other places. Oftentimes, this is helpful in beginning to understand things more deeply. Occasionally, it gets you in trouble when you begin to see patterns in everything not unlike when I first learned the factory pattern and then thought everything was a factory.

In this case, I think he’s right that the command line can be thought of as an implementation of MVC. The part he doesn’t address is a persistent data storage layer and the model’s interaction with it. With Ruby on Rails, our interaction with the data goes through the model in the form of ActiveRecord. With the command line example, your interaction between the model and the data all depends on what model you’re using, an interesting twist. For example, with grep, your interaction becomes the search strings and regular expressions you feed it to determine what data you want to see. With wget, you determine your model-data interaction by specifying URLs or specific resources that you want your model to load.

Thinking of the command line as an implementation of MVC gets you thinking about other common applications or tools that might also be MVC in nature. Any come to mind?

I joined Twitter in August of this year without a great deal of thought and after long decrying the effect I was sure it had on attention. I did it mostly because there are usually 5-10 times a day when I have a thought or see a link that don’t warrant a full blog post but that I find interesting enough to want to share it with people. I tried Facebook originally but that didn’t really feel like what Facebook is about. Twitter on the other hand seemed to be perfectly designed for that sort of activity. So I joined up and started updating pretty regularly.

For my purposes, Twitter was excellent. A majority of my updates were links to something that seemed interesting enough to share. Other times, I’d have a thought that seemed Twitter worthy and based on the responses I got from people who followed me, about 25% of them actually were. Over the course of my time on Twitter, I updated 373 times or about 4 times a day. I got 159 replies to my updates. I was following 37 people and being followed by 47. I was happy with Twitter and Twitter seemed happy with me.

Unfortunately, there was a darker side. I already have issues with attention and focus. I LOVE anything that gives me a dopamine fix. Twitter was rapidly becoming a dopamine fix. My real writing completely dropped off the map. I wrote 9 posts total in 2 months on my tech blog and this one. Several of the posts on my tech blog were almost Twitter-like in their brevity. I was doing no fiction writing and no journal writing. I began to notice that I was checking Twitter 5-10 times a day, even on days when I left TweetDeck turned off. When I updated and didn’t get a response, there was a distinct mental reaction in that I didn’t get any feedback. This caused me to update more.

My focus at home on projects was nil and I had trouble getting into anything. Whenever I got stuck on something, off I went to check Twitter updates. Twitter taught me that I don’t have the discipline necessary to turn off Twitter when I needed to be working on something else.

On top of all that, I started thinking about what the result was of all this *effort* I was putting into Twitter. There was nothing meaningful going on. In 2 months, I had 1 conversation that could be considered interesting and productive. I produced nothing that I’d want anyone to remember me by, nothing useful to the greater good. The irony of my reasoning for joining Twitter is that even though I was posting things that I found interesting, none of them led to greater, more in-depth conversation or learning. They were just informational junk, no different from the junk mail that I get every day. Things that I thought were interesting were really just information junk mail, even if people voluntarily signed up to get it from me.

None of this is a judgment on Twitter. I actually think it is quite useful as a mini-RSS reader in a way, a tool that someone might use to successfully market or promote a business or a blog. I wish I could use it for that. Twitter did drive my viewing stats up on my tech blog from 1 a day to 9 a day on those days I mentioned a post on Twitter. I just don’t have the ability to compartmentalize Twitter the tool from Twitter the dopamine provider. I don’t want to look back on 12 months of Twitter and wonder why in the hell I didn’t write more in that time period. I want to produce things and that takes focus and attention, something Twitter increasingly was stealing away from me. I have a limited store of attention and the more I divided it hoping to hear that stupid little TweetDeck notification sound, the less I had to pour into something that actually mattered. I really do want more than the pale facsimile of fulfillment.

David O’Hara, one of my colleagues at Improving Enterprises, posted the following to Twitter today:

Folks, if you’re not willing to buy tools to get your job done faster/better – please do us all a favor…

He and I had the related Twitter discussion which you can follow, as well as a chat offline to further clarify what we meant. However, I thought it was a subject rich enough to deserve more than 140 characters in explanation. It’s my stance that the quote above at first read is essentially saying if you aren’t willing to buy productivity tools, then we’d be better off without you. David has since explained that he was really targeting people who complained about built in tool support or the lack thereof and that if you weren’t willing to buy the tools, stop complaining and just do your job. However, several other people agreed with Dave’s quote as written and I fairly strongly disagree so let’s look at the quote as it is.

My stance is that this is a purely economic decision at its most core, one that if taken at face value, expects developers to take a financial risk, e.g. pay for a yearly subscription to Code Rush or Resharper, and accept in return a non-financial reward, e.g. greater productivity which we’ll assume leads to greater happiness. Additionally, an employer who can convince all his employees to buy their own subscription reaps almost immediate rewards while taking on none of the risk. This is a bad economic decision for an employee to take. There is an edge case which nearly everyone brought up in their agreement with David and that is a craftsman. We’ll discuss that in a minute.

One point that’s critical here is that we’re talking about salaried employees and not independent contractors of any kind. When I first objected to Dave’s remark, I questioned what other profession expects the employees to buy their own productivity tools. I don’t think there are any outside of independent contractors. This is an important distinction because contractors can pass the cost of their increased productivity on to the consumer through either higher prices or longer engagements if they choose not to use the productivity tools. Salaried employees do not have that option. Several people argued that employees who were more productive would be rewarded in the long run but again, this is not a good economic bargain since future returns on my economic risk today are inherently, well, risky. Maybe the employer lays me off or pays me less than my productivity cost me.

Looking at it from another angle, by convincing me either implicitly or explicitly to pay for tools to increase my productivity, my employer has also lowered his salary costs while gaining in output. Again, in an economic agreement, this is a big loss for me. Of course, David didn’t mention the employer in all this but the assumption is that if I have to pay for my productivity tools, it’s because my employer refuses to do so for whatever reason.

Granted, I may have a choice in the matter. I may choose not to work with the tools. I may choose to get another job. But all of these come with associated costs, costs that must be weighed when making a decision.

In the end, the best employers ought to provide the best tools for their developers in an attempt to get the very best employees. The best employers do this because they know it’s in their best interest to focus on the long term return of having the very best employees while the worst employers focus on the near term return of the cutting costs. This is true across many fields, not just software development.

What about that edge case? Here’s where my thinking converges with David’s sentiment. Craftsmen always work with the best tools because their work is qualitatively different than that of the average software developer. They want to operate at the highest level of efficiency in order to achieve the quality of work that their internal motivation demands. Of course, the irony in this is that typically craftsmen refuse to work for employers who expect them to buy their own tools because that is a sign of the type of work or environment they can expect.

Overall, I don’t think it should be the employee’s obligation to provide themselves with productivity tools. They agree to do a job to the best of their abilities when they join a company. If there are tools that enhance their abilities, the employer should provide them as an investment in the long term gain of more productive and ultimately happier employees.

Of course, all this said, I choose to buy my own tools. I do this in part because I want to have them after I leave a given company but also so that I can use them in my own personal development as a software developer. I’m light years away from being a craftsman but I suppose striving to be one is the next best thing.

A rather ambitious title but apropos of what I’ve been playing around with this morning. At this month’s Dallas Hack Club, several of us got together and essentially toyed around with problem #1 on Project Euler, learning new things as we went. I ripped through it in Python pretty quickly mostly because I had done it before but partially because Python makes things so easy. After that, I started trying to do it in Clojure, a language I’m interested in but can’t seem to find the time to truly concentrate on.

My initial solution in Clojure was both ugly and uncompilable making it reasonably useless. I’ve been struggling with getting my head truly around functional programming and I finally figured that the solution to that was to do more of it. This summer, in another fit of ADHD and boredom, I bought the electronic version of Chris Smith’s Programming F#. Like most of my projects, little came of it until last night when I decided to work really hard on it for 30 minutes. I figured out Euler’s problem 1 in about 20 minutes and that made me think I should be able to handle Clojure as well.

It took a lot longer than 30 minutes but I finally figured it out in a way that didn’t require 85 lines of Clojure. I think the functional style is starting to sink in. Doing both F# and Clojure seems to hammer home the concepts because I can develop a solution in F# in a medium I’m comfortable in (.Net and Visual Studio) and then move to Clojure with a little more background to build from. The solutions are provided below as a reference.

def main():
  sum = 0
  for x in range(1, 1000):
    if x%3==0 or x%5==0: sum+= x
  print sum

This was the original solution in Python. After doing the F# and Clojure work, I came up with something shorter if slightly more obtuse:

reduce(lambda x, y: x+y, filter(lambda x: x%3==0 or x%5==0, range(1, 1000)))

Those two lambdas are not good for long term maintenance and aren’t that readable. A list comprehension in place of the filter would be a good deal clearer.

reduce(lambda x, y: x+y, [num for num in range(1, 1000) if x%3==0 or x%5==0])

So we’re down from 5 lines to 1 while retaining a good deal of readability. Maybe there really is something to this “Functional programming makes you a better programmer” stuff.

In unimproved F# (I’m open to suggestions):

let result (acc : int) x =
    if x % 3 = 0 || x % 5 = 0 then
        acc + x
    else
        acc
List.reduce result [0..999];;

And finally, in what I think is decent Clojure:

(defn isdiv [x] (or (= (rem x 3) 0) (= (rem x 5) 0)))
(reduce + (filter isdiv (range 1 1000)))

Sorry for not having syntax highlighting for the Clojure or F# code, they would both be a great deal more readable. However, it’s interesting to see in Clojure how all functions are first class, e.g. I can pass the + operator to the reduce function instead of having to define a lambda as I did in Python.

I have a feeling the Clojure code could be more succinct but for a first working cut, I’m pretty pleased with it. It’s clean and easy to read, even for someone like me with little exposure to the prefix notation and all the parens.

Overall, I feel less dumb than I did when I woke up this morning. I’m guessing the beer I drink at tonight’s Halloween party will fix that though.

Google has apparently advised Jon Skeet, C# guru extraordinare, that renewing his MVP status wouldn’t be a good idea. This strikes me as silly for Google to do assuming there is no underlying legal reason for the move. As Google continues to get bigger, its cute little slogans and supposedly fantastic place to work will become less and less interesting. Advising someone with the stature of Jon Skeet that he shouldn’t be an MVP doesn’t exactly jibe with that whole Don’t Be Evil thing.

I’m in the market for Resharper and Latish pointed me to David Ridgway’s blog. David has a offer for an extended trial period and 10% off the purchase of Resharper. I emailed David this morning and 13 minutes later, I had an email with the details. If you’re looking to evaluate or buy Resharper, drop by David’s place and give him a buzz.

When using the MSBuildHelper in the MSBuild Extension Pack to access particular items in a collection, the Position is zero based just like arrays are. I have no idea if this is intuitive or counter-intuitive but it’s definitely not VB6tuitive.