Wednesday, January 13, 2010

Making the improvments - leaky abstractions

A while back I was reading a post by Jeff Atwood about abstractions in code. Jeff was in turn was picking on something that Joel Spolsky had written, but the gist of the post was pertaining to abstractions in code.

The gist of Jeff's post is I think summed up in the following:

It's our job as modern programmers not to abandon abstractions due to these deficiencies, but to embrace the useful elements of them, to adapt the working parts and construct ever so slightly less leaky and broken abstractions over time. Like desperate citizens manning a dike in a category 5 storm, we programmers keep piling up these leaky abstractions, shoring up as best we can, desperately attempting to stay ahead of the endlessly rising waters of complexity.

Leaky although abstractions may be, they do improve the code - readability, maintainability (other ilities) over time. As Jeff mentions - the question is:

Does this abstraction make our code at least a little easier to write? To understand? To troubleshoot? Are we better off with this abstraction than we were without it?

I think in a large majority of the cases that the answer is yes - the abstraction helps to improve the code in ways that allow it to be better understood by others, easier to maintain in some ways and sometimes hard to maintain in other ways. The abstractions can allow new code features to be easier to write and get into production. In essences code abstractions can help programmers to work to make things better all the time for the next person coming along.

Abstractions can also allow you to get to market quicker and then work to fix issues down the road. This is essentially how I think Microsoft works, get version one out the door and then work to plug the holes in the dike - fix the leaky abstractions that have caused issues. Overtime Microsoft builds better abstractions and better code until something solid that people will like or like better then version one comes out. Personal opinion here is that Windows did/does this, and so does c#/cli. (On a completely side note it is also interesting to note that this build, deploy - revise is something that java does not do very well at all. For all the touting that people make of the JCP, the whole thing seems to be lagging behind what the cli and C# have to offer programmers in terms of ease and simplicity.)

Abstractions are an important part of programming and of how people deal with the world around them... trying to fit ideas and thoughts into buckets of how things are and how they work. People use abstractions because it helps them think about things in ways that are comprehendable/understandable/manageable - this is no different... programming abstractions help us to understand the systems better and make it easier to do certain types of things. Are abstractions leaky? Yes - I think they all are, not a single one of them hits every nail like it was a hammer but they improve things enough to allow progress towards a goal.

Monday, January 11, 2010

Another arrow for the quiver

I have been meaning to post on this topic for a while, but have just now found a little bit of time to squeeze it in.

In the recent past (say about a quarter) I was reading a post by Joel Spolsky about looking for programmers to hire. He made some statements in this post and a post that followed it - some of those statements I agree with and a few I do not and I wanted to take a minute to see if I could spell out both in this post.

In the agree category:

1) It is hard to FIND good programmers.

Interviewing them is not a problem... a fair number of bloggers have pointed to how to hire or interview candidates in an attempt to make sure that you get the best of the people that come through the door. However getting the programmers to the door tends to be an issue. There are two sides to the issue of getting programmers to the door.

* Side one, how does a person looking for a job find my opening @ BigCo.

Lets be honest, there are literally hundreds if not thousands of people looking for jobs in the technical fields, programming included. Of those looking for jobs - not all of them know about the opening I may have @ BigCo. The hiree has plenty of places to go and plenty of places to look for these job openings - Monster, Yahoo Jobs, Joel's Job Board, Dice dot com and of course they can also do the non-electronic thing and search their local paper. Lets call this a well covered area.

* The other side of that coin, how do I find someone who is looking for a job to fill the position that I have @ BigCo.

Above we noted that there are plenty of people looking for jobs, how do I find the candidates that are the cream of the crop... especially if I am looking for the programmers who are the hyper-performers? You know those folk who do 10x more work in the same amount of time as the avg. programmers? Where is the tool that does this type of 'person' finding or person searching?

2) The lack of a good search engine for employers looking for developers hurts

One of the other things that Joel mentioned in his second post is that it is important to be able to ask a programmer search engine just about anything. The fun example he had was students looking for Ocaml internships in Houston. Having a flexible way to look for good programmers who might meet BigCo's needs is important.

In the disagree category:

In the first post by Joel he noted that in an impromptu survey done amongst developers that attended DevDays (a one Day Development Conference) that about three quarters of the audience (75%) were either actively looking for a new job (25%) or at least keeping their eye out for something 'better' then what they had (50%). He posited that the people that attended DevDays are the cream of the developer crop. That the only attendees are the people that love programming and that the attendees are the types who are the 10x developers, the [only] types who participate in Stack Overflow. I would argue that the statement is not entirely true.

It may be the case that the people who attended the conference are the folk who are the most interested in bettering themselves and improving their abilities, but these same people may not actually be the people who are the most productive of their programming brethren. There is no way to really know if any of the attendees are the types of programmers that we might want to hire - the hyper-productive kind.

Joel used the impromptu survey as a lightning rod to say that having that many 'good' programmers displeased with their jobs was something that needed fixing - enter Stack Overflow Careers. This new site allows you to enter your CV and provides all the neat searching and management information to allow employers looking for specific people to find YOU. This site is linked to your information on Stack Overflow, including your ranking and other information for being part of the Stack Overflow ecosystem. This is an excellent idea... however it does not equate to providing an employer a "Guaranteed" winner in terms of hiring a programmer for an open position as Joel seems to imply.

It does the things that Joel mentions, it allows the careers site to be linked to Stack Overflow reputation marks which helps you to "...demonstrate your reputation in the community and show us all how smart you really are." The cross link between careers.stackoverflow.com and the normal Stack Overflow site allows you to essentially prove that you are knowledgeable and can demonstrate a mastery of a particular subject. I would argue however that this alone doesn't provide a full picture of the person that I may want to hire but rather provides just one more piece of information to help me decide if i should hire them.

in the end...

Look, lets be honest - I think of myself as being a decent programmer... modestly I don't think that I fall into the 10x type of programmer, better then most but certainly not like some of the smartest people that I have met in my career. I care alot about my learning and my experience... I attend conferences where I can - and I try to put time into bootstrapping and improving the coders around me, just as I hope that they care the same for me when there is a gap in my learning.

I do not however, participate in Stack Overflow. I don't participate not because I don't think that I could help people but rather because there is limited time for me to pay attention to the other things around me from day to day. My kids, their school and activities, this blog (which admittedly needs more attention but I keep putting it off) and things like my current job and career. There is alot of stuff in my list and limited time to do all of them... Stack Overflow would suck me in to the point of being an addiction and given my other time needs it makes it hard for me to see my way clear to participating. My lack of participation doesn't mean however that I am not a person worth hiring which is what I got out of reading the posts from Joel.

Participation in Stack Overflow may provide an extra insight into my ability to communicate via writing (which admittedly has never been a HUGE strength of mine), but it most certainly does not provide any guarantee that a responder who is also looking for a job is the "cream of the programmer" crop. I for one have run into people who can provide reasonable answers to questions when posed to them... on paper, when they attempt to put those answers into practice however it is a complete disaster and their code SUCKS. Take the Stack Overflow Careers site as just one more bit of information that I might use to 'help' me find and decide if I should hire you - but certainly don't assume that just because the site is where you might find a person to hire that they are the cream of the programming crop, you may be disappointed.