Archive for the ‘Observational’ Category
I Heart Joel on Software
Wednesday, December 2nd, 2009
Let me make one thing perfectly clear before you embark on this journey with me: I very much love reading anything Joel Spolsky writes. I am a Joel on Software fan-boy. I am also aware that, due to his ubiquitously strong opinions, he is frequently cited/criticized on other tech blogs, and that doing so is derivative and shallow, even though that’s what I’m about to do here.
I acknowledge this, but it’s ok, because I Heart Joel on Software.
I have read most of Joel’s books, including the self-titled “Joel on Software”, the sequel “More Joel on Software”, the dubiously too-small-to-be-a-book “Smart and Gets Things Done”, and the edited-by-Joel “Best Software Writing I”.
After reading so much of his work, it’s very clear that if there’s one thing Joel cares about, based on reoccurring topic, it’s what separates the programmer wheat from the code-monkey chaff: that is, how do you identify a Good Programmer?
Indeed, “Smart and Gets Things Done” and its analogous sections in “JoS”, and “More JoS” is billed as a hiring guide for managers looking to hire the best possible programmer.
Herein lies the paradox though: the real audience of all of Joel’s books is his core readership, which are programmers, and since the thrust of “Smart and Gets Things Done” is that 99% of programmers are terrible at what they do and not worthy of jobs, Joel then, must have a latent disdain for his own readership.
Joel’s ideal programmer has graduated from an Ivy League Engineering School, and can construct a Full-Adder from memory without using XOR gates. Further, Joel asserts that these mythical engineers are never on the market since they get hooked up with extremely rewarding and fulfilling internships right out of school and never want for anything else. The 10 or 12 engineers that fit into this category won’t buy his books since they apparently know all these things a priori, which means that it’s all of us slack-jawed programmers that must be enabling Joel’s book royalties.
So it seems that Joel is stuck in a love/hate relationship with his audience. I assume he loves to sell books, yet he must be aware that the type of programmer he takes so much time to insult and the programmer reading the insults are in fact one in the same.
Why would we, the sub-par programmers of Joel’s universe continue to enable this? It’s possible that we are indeed so Neanderthalic that we simply don’t have the higher functioning thought processes to get the joke. Do we think he’s talking about someone else?
“Ha ha, it’s so true, Joel! Those boneheads have to submit their resumes to dice.com to get work. What morons! Ooh, what’s this? Another email from a recruiter? Yes, I am interested in a Hot Java Contract in New Jersey! A ‘must fill ASAP’? I’m sending my resume now!”
Or perhaps we are well aware that we are both the target and the audience. In this case it becomes more like an abusive relationship. Even though he hurts us, we know he doesn’t really mean it. We keep coming back for more, hoping to read that post someday that will heal all the hurt and make it all better.
We yearn for the post from him that admits that, indeed there is no correlation between what school you went to and what type of engineer you are. In fact, how fast you can regurgitate a quick sort algorithm on a white board has nothing to do with how you’ll fare in a team, and further, that raw algorithm analysis is both an unnecessarily reductionist and irrelevant way to assess someone’s skill.
We’d like to sit on our high horses and look down at the unwashed masses with disdain and stroke our egos by saying that what we do is High Art as opposed to all those Java Lightweights that would break down and cry if they ever saw a dangling pointer, but the fact is that it requires no more (and no less) innovation or brain cells to write bug tracking software (for example) as it does to develop budget reporting software. Any project is a fount of potential technical challenges, no more or less important than any other project’s, and solved by programmers of all mental shapes and sizes.
We, Joel’s Readership, would like to think we’re better than most of the programmers out there and may feel the need to distance ourselves from all the inept imbeciles since the field has such a low barrier to entry, as compared to say, being a doctor. But of course, we’re writing software, not saving people’s lives, and if we are talking about the category of software that does keep people alive, whether by moving the laser to the correct place over the cornea, or adjusting the yaw of an aircraft so it can safely land, then it was probably written by a contractor, that class of engineer which stands diametrically opposed to the “never on the market” rule and probably didn’t go to Yale.
In fact, I imagine that, as the aircraft descends into that last critical few hundred feet above the ground, the pilot is subconsciously hoping that the engineer who wrote that motion control code was more concerned with preventing gimbal lock than with being able to sort that array of numbers in “log n” time.
We, Joel’s readership, would love to see his acceptance of us in this form, but alas, we are unlikely to see such a concession from him. At least not while we, the JoS fan-boys, keep buying his books.
All I Really Need to Know About Programming I Learned in Kindergarten
Thursday, November 12th, 2009
On the days that I pick up my daughter from Kindergarten, she’s always bursting with excitement over what she has learned that day. It often makes me wistful for my own Kindergarten days, almost 30 years ago. As I listen to my daughter talk about her day, I reflect on my own time in kindergarten, and how, trite as it might seem, that year spent in school at age six, really gave me all the tools and life lessons I needed to be a professional programmer.
I often think back to what Miss Johnson used to say in that small classroom at Laird Elementary back in the early 80s, “now remember class, try to keep your initial load factor for your hashtables at 0.7″. At the time, I remember thinking, “now when am I ever going to use that?” But sure enough, my mid-thirties self now chuckles at my younger naivety.
After recess, we would all gather ’round and listen to her tell the story of the Traveling Salesman and how he could never find his optimal route in a deterministic amount of time. “Use a branch-and-bound algorithm!” we’d all shout at the climax of the story.
“Children”, she’d chide us, “can we do better than that?” Of course we couldn’t resist being baited like that, “use a Nearest-Neighbor Heuristic!” we’d exclaim with excitement, barely able to stay on our carpet squares.
She would often tell us that while learning to clean up after ourselves, and sharing with others were indeed important life skills, they were not relevant at that age, and we would likely learn about them in grad school.
Come to think of it, I do recall an extensive lecture on the importance of flushing and always washing your hands in Genetic Algorithms in my Masters program.
The Nonzero-Sumness of RIA Platforms
Tuesday, September 8th, 2009
In an industry that seems to thrive on competition, it’s natural to think that the three major RIA platforms are incompatible, directly competing technologies, and that an application that uses one, will preclude the use of the other two. After all, an application written in Silverlight is one less application that could potentially be written in JavaFX.
Right?
This would be true if application development were a Zero-Sum Game, which it sometimes is, but not in the case of RIA development.
RIA platforms are currently the underdogs of adoption when compared to general web application development. When it comes time to choose a technology stack for a new project, it is often assembled based on (among many other things) what is familiar, and what others are using — and these days the default stack is web-based.
On the occasion that the requirements demand something that current web technology can’t easily accommodate, a RIA solution may slip into the mix and cross-pollinate with an existing web app. When this happens, the general awareness, and acceptance of RIA technology rises a bit more, and with it, expectation that future applications will follow suit.
Every project that uses Flex, JavaFX, or Silverlight increases the user’s expectation of how applications should behave and what’s possible. Soon users may come to expect the ability to run an application offline, out of the browser, or on a mobile device, and the higher the user expectation, the higher the demand for this type of development.
Put another way, RIA platforms have the task of not only trying to increase adoption, but also of generating the demand and raising awareness for the technology itself. This is much easier done collectively then as individual platforms.
In other words, RIA Platforms are playing a Nonzero-sum game between each other: that which benefits one, benefits all.
For this reason it is good, from an adoption standpoint, that the three RIA platforms keep pace with each other’s feature set. For example, while Mobile support may be perceived as a differentiator for JavaFX, it’s actually a good thing (and I’m sure not completely non-coincidental) that Flex and Silverlight have Mobile support planned in the near future. The reason is simply that if more applications have mobile components, the expectation, and therefore demand for this style of application, will rise. So if a project ends up using JavaFX Mobile (for example), it is not a net-loss for Flex or Silverlight, as two more mobile RIA projects may appear that would not have otherwise been there based on the demand created by the initial project.
Neal Ford hinted toward a similar trend in dynamic languages in his talk “JRuby vs. Groovy”. Despite the antagonistic title, Neal warned that if developers don’t realize that the ecosystem is big enough for both languages, neither may thrive. In other words, two seemingly competitive technologies are dependent on each other for survival as long as both benefit from the other’s successes.
There may come a time when the RIA space is so saturated that the game may switch to zero-sum, much like the current state of web application development. There may come a time when the phrase “desktop-like experience” actually refers to technology that runs on the desktop.
For now though, the task of mass adoption is far too great a challenge for any one platform. They are better off acknowledging their potential win-win situation of co-adoption.
User or Usability? (or, The Psychology of Software Support)
Friday, June 26th, 2009
Before going into Software Engineering, I took a job in PC support at the university from which I graduated where it was my job to answer the support questions of the professors and administrative staff. I quickly realized that my job had very little to do with any sort of proficiency with technology as it did with simply being a sink for raw human emotion.
A veritable “who’s who” of the emotions involved in grief, I’ve seen a professor indignant and rage filled over the news that a crashed computer and unsaved document added up to hours of lost effort.
I’ve tried to console a staffer in tears over the embarrassment and despair of her 10th support call over Excel, whimpering, “I just don’t get it. I’m just no good at this!”
I’ve witnessed the bewilderment and denial of a PhD at the words of his document all running together: “I don’t understand, I’m pressing the “shift” key to shift the cursor over”.
My heart goes out to these people — technology is harsh and unforgiving (although in fairness, the “technology” of the space bar has been around at least since mechanical typewriters).
I would imagine that most users spend a not insignificant percentage of their time on a computer in some sort of troubleshooting mode. I actually enjoy working with computers, so my patience threshold for futzing around with something I don’t understand is probably higher than average — but woe to the user who actually doesn’t want to sink hours of time into learning how to use a new program.
It’s easy to point to the end user as the one at fault, but I think this is a mistake. I think more often than not, it’s a usability problem, not a user problem.
Usability is a fragile thing. We like to label programs as “intuitive”, but they are only that way because we’ve been trained on what to expect from previous programs. So when we say that a program is intuitive, we really mean that it conforms to our expectations — expectations that have been formed by the evolution of programs which have come before. But when a program behaves in an unexpected way, our confidence in its use is rattled, and we become adrift in its apparent arbitrariness. What was intuitive for its designers turned out to not be so for its users.
Usability Expert Jef Raskin warns against the flippant use of “intuitive” to describe interfaces:
“The impression that the phrase “this interface feature is intuitive” leaves is that the interface works the way the user does, that normal human “intuition” suffices to use it, that neither training nor rational thought is necessary, and that it will feel “natural.” We are said to “intuit” a concept when we seem to suddenly understand it without any apparent effort or previous exposure to the idea. In common parlance, intuition has the additional flavor of a nearly supernatural ability humans possess in varying degrees. Given these connotations, it is as uncomfortable a term in formal HCI studies as it is a common one in non-technical publications and in informal conversation about interfaces.”
He goes on to note that we should more accurately favor the word “familiar” over “intuitive”.
So really, when users are at the mercy of support it’s not because they lack intuition, a word that is connotatively linked to intelligence — it’s that they lack familiarity.
The person questioning her own self-worth over Excel may be in the wrong profession — or perhaps Excel is not all that intuitive. Excel in particular is an extremely powerful, and complicated program, one that, for some reason, is present on most machines in corporate America. Given its ubiquity and unusually broad user base, it needs to pay particularly close attention to usability.
One way a program can make up for being complex is by encouraging the user to explore and try out features knowing that they can always back them out with “undo”. In my experience Excel is particularly bad at this, not because it implements “undo/redo” poorly, but because it is such a complex and bloated program that it needs to go above and beyond conventional “undo” semantics.
I’m continually surprised, when after futzing with charts (or whatever), making changes and having “undo” disabled: “Can’t undo”. Can’t undo? Why not? I just modified the state of the document — back out my changes, Excel! Don’t make me Revert To Saved!
Now that I find myself on the other side of the curtain of application development, I try to be mindful of the user on the other end. When I watch people use an application I’ve written and they struggle with how to do something, my gut reaction is that it’s a training issue.
But it’s not. Ever. It’s a Usability Fail, and it means that I need to listen to the users, and try again.
UPDATE: So, in some sort of odd cosmic coincidence, Hamlet D’Arcy has written about almost the exact same topic a few days ago (although somewhat unbelievably I didn’t notice it until after I posted this). He even quotes Jef Raskin! So go read his post too.
Dumbing Down Our User Experience
Sunday, June 21st, 2009
If a genie offered to give you some incredible super power, say the gift of flight, or invisibility, but in return would chop your IQ in half, would you do it?
What if he said that, over time, you’ll recover most of your intelligence to a point, but you’ll never be quite as smart as you are right at this moment — would you do it now?
About 12 or so years ago it seems like we were approached by the Web Genie, who offered us the fantastic promise of being able to use an application from any computer connected to the internet — no installation necessary!
All we would have to give up in return is any sense of usability to which we had grown accustomed. Sure we would gain it back slowly, but even 10 years later, web apps would still be struggling to be as usable as the most modest Visual Basic applications of the late 90s.
The first web apps in this pre-AJAX world held the novelty of filling out forms and pressing buttons in our browsers, at the expense of redefining our expectations of usability. But who needs usability when we’re bidding on small household appliances? Just take my credit card number and give me my toaster!
Then AJAX came around and set us back another five years in usability. Sure AJAX made web apps somewhat more usable if used correctly, but it meant that instead of returning to rich application development, we were going to try and keep at this web thing a little longer yet.
Web advocates proudly strutted the improved usability of their applications which we only accepted because our expectations were so low from the first generation of web apps. Suddenly Gmail looked amazingly usable compared to HotMail. A full page refresh on every operation? A thing of the past! Meanwhile, rich clients like Thunderbird silently wept in the corner.
It was similar to, in the early 90s, when popular music abruptly shifted away from Bands with Skill to the Grunge movement. Guitarists everywhere simultaneously recoiled at the notion that “Smells Like Teen Spirit” was the new standard, and rejoiced that the bar was now set so low since being in tune was now optional. It wouldn’t be until Guitar Hero brought back into the cultural awareness the reminder that Kansas is a pretty kick-ass band, and that guitar solos in songs aren’t optional.
Web Apps tend to struggle with fulfilling some basic rules of usability — basic maxims that Jef Raskin championed, such as, applications must treat all user input as sacred and, always allow the user to undo an operation.
We take it for granted that we’re not supposed to hit the “back” button at the risk of double charging our credit card, to say nothing of navigating to a different page, or abruptly closing the browser. We’re annoyed, but not surprised, when a form that we’ve spent the last 15 minutes filling out mysteriously resets itself after we submit it. We commit an operation, but we have no expectations at all that we will be able to undo what we just did.
I don’t know how many email drafts I’ve lost to Gmail because it got stuck in an unrecoverable “auto-save”. While editing a web page on “Google Sites” I am not uncommonly confronted with the message: “Unable to save the page at this time, please try again later”. Please try again later? I want to save my work now, not later!
We would never let a desktop application get away with this, but we grant a free pass to web apps because we understand that they’re shackled by the browser and pesky security models that don’t allow access to local storage, so we grant them copious amounts of slack, even though I’m sitting here with gigabytes of empty storage space and a document that can’t be saved.
As an internet consumer, I, of course, make liberal use of web apps all of the time. At the risk of biting the hand that feeds me all of the convenience of paying my bills or buying movie tickets without having to mail a check or talk to a person at a ticket counter, I am grateful for it all. I gladly accept convenience over usability with only mild amounts of grumbling.
It’s not like I haven’t produced my own usability nightmares on the desktop, or that there aren’t stand-out paragons of usability on the web. The distinction lies within the intention of the toolset that us mere mortals are expected to work with.
When I’ve committed my usability atrocities on the desktop, I had to go out of my way to buck the toolset I was using (I don’t, know, maybe I thought I was being clever), and conversely, the web developers that created, say, Google maps (since I’m on such a Google theme here) must have moved Heaven and Earth to make that work. One can only imagine what they could have come up with using Desktop technologies (it probably looks something like Google Earth).
So having said that, I find it difficult to get around the sentiment that web applications dumb down our expectations of what we’ve come to expect from how an application should behave. That might sound like an incendiary statement, and you might be tempted to think of this as just a tirade against web applications.
In fairness though, User Experience certainly does not make up the entire enchilada of what makes a quality application, just as the Nintendo Wii is proof that High Definition visuals aren’t necessarily for a quality gaming experience.
“Convenience and Collaboration” are huge driving forces behind what can make a Web application great (and I am a big fan of many of them). However, while “The Legend of Zelda: Twilight Princess” is one of my favorite games, I can’t help but wonder how much better the experience would have been in 1080p.
One of the Java Posse, in a discussion about how to distinguish a web app from a rich internet app,etc. stated that the distinction is moot: “it’s just apps”.
Perhaps this is extremely forward thinking and will be true ten years from now, but for the present trying to erase the line between the two types is what leads us to “The Uncanny Valley of User Interface Design”, as outlined in Bill Higgins’ excellent post. In a nutshell: web apps should conform to a user’s expectations for how a web app should behave, and vice versa for desktop applications. When the two cross into each other’s paradigms, a jarring, off-putting experience is the result.
Indeed it seems to be the trend for web apps today: move as many desktop-isms into the browser as possible banking on the fact that the user will appreciate inconsistent “auto-save” over none at all.
I wonder though, if we aren’t pushing in the wrong direction. Surely this web technologies thing can be taken further…but maybe it shouldn’t. Maybe it’s time to stop squeezing more “features” out of AJAX and get back to our rich client development roots.
Maybe we can remember that there was a time when not every application ran out of a browser.
The George Thorogood of Software Development
Thursday, May 14th, 2009
Acting as the fiber of Software Construction’s diet, it would seem that good collaboration skills are necessary to produce anything useful.
Indeed, if you go to any tech conference chances are that interspersed between the sessions about actual technology will be sessions devoted to, in some way, collaboration with others. Whether its focusing on getting the most out of SCRUM, or new techniques for Pair Programming, “playing well with others” is a perpetual hot topic.
However, I’ve always regarded the “collaboration” side of software development with a bit of reluctant guilt.
This is largely due to the fact that I’ve actually spent the majority of my programming career as George Thorogood — I [code] alone. (I realize that reading the title of this post, without the introduction could infer another direction, such as "I drink while I code", which would be the subject of a much more rambling and incoherent post -- if that's possible).
It's not that I've never worked on teams, can't work on a team, or actively seek out solo projects. Indeed, I have great memories from projects long past of selfless collaboration, mentorship, and camaraderie.
I have always felt a little embarrassed by my solo status since, while I generally do enjoy working by myself, I tend to project a "solo stigma" onto my situation. Surely anyone who works by themselves will stagnate under the stifling professional isolation, right?
While that's no doubt a perpetual risk, I don't think it's unique to programmers on solo projects. Indeed, being on the "wrong" team or part of a voiceless mass can be severely demotivating and isolating.
Some of the greatest software out there has been authored by individuals working alone. John Carmack of id Software fame has managed to perpetually remain a pioneer of high performance 3D graphics engines -- and I imagine he could have only done it alone.
Clearly he is a genius though, and while it would be disingenuous to say that I didn't intend a comparison with myself in some way (although drawing a comparison any greater than say, that we both type on keyboards would be spurious since even my best achievement in software engineering would be a mere (unlit) candle to the burning sun that is even the original Castle Wolfenstein 3D), I can admit to the sense of unmitigated control and concentration on something that would be difficult to do in the same way (or at least in the same time frame) with more than one person.
Being able to completely scrap a design, or turn in a completely different direction three times in a morning may seem like sloppy, chaotic software construction, and in some sense it is, but what comes out of the other side tends to be, if nothing else, a unified vision of purpose that all but the most agile teams would have trouble matching.
At the risk of sounding completely solipsistic, I don't think I'm saying anything new here: pound for pound fewer developers are more productive than more developers, with one developer being theoretically "most productive". Indeed, the whole reason we have teams of developers at all is because one person can only do so much.
"Not true!", you protest. "Developers have different specialties. No one can simply "do it all". I don't want just anyone messing with my data layer -- I need a hibernate guru!"
This sentiment may make sense in theory: put 'gurus' in their respective slots, bake at 325 for 2 hours, and watch the quality ooze out. However, in my experience, generalists win out over those that carve out niches for themselves with the reason being simply that most projects don't require "guru" levels of knowledge.
Admitting that I enjoy, and perhaps even sometimes prefer, to work solo can be interpreted as a sort of professional suicide given that most job interviews eventually get around to asking how well you play with others (or depending on how misguided the interview is, how many people you've directly managed).
In fact, the title of the post may conjure up images of a "rebel coder", a lone wolf, or at the least, someone who's proud of "going it alone". So to be clear: I think working on a team can be great. There's no quicker way to sharpen your tool set if on the right team, and this is especially true early on in one's career. I merely think that there is no shame in working alone.
In other words, I think that this post is best interpreted as an internal running monologue of one person's thoughts on working by his lonesome and not a diatribe against working on teams -- scatological references in the first sentence notwithstanding.
I Want to be on the Front Page, Too!
Friday, February 6th, 2009
So my company, CityTech, has recently overhauled its web site, and I’m sure you’ll agree, it looks really nice. As you’ll note, the top few posts from our company’s blogroll are aggregated off to the left.
Since I first saw the new site go live last week, I couldn’t wait to write a post and take the place of honor just south of our corporate logo.
But it turns out that writing is actually very difficult…
I suppose I could have blogged about how Java Passion is running a free JavaFX course, but that’s old news at this point (although you can still sign up).
I could have mentioned that Josh Marinacci has just blogged about how developing for JavaFX Mobile will be no different than developing for JavaFX desktop (under the Common Profile, which, no, does not include Swing). That would be timely, but I didn’t really have any insight to add to it.
So I decided to crack under the pressure, and, attention starved, decided to write a post about nothing (sorry for bumping you, Bill, but you understand the allure of seeing the first few words of your post against that silky brown background).
For the next few hours at least I’ll be able to see my post here on this Sidebar of Wisdom until my eager colleagues feel compelled to write new posts bumping me off the front page and into obscurity.
When that happens though, be sure to be on the look out for my followup post: “You Can’t Bump Me From the Front Page That Easily!”
While My Schedule Gently Weeps
Wednesday, January 28th, 2009
It never fails, we can be in mid-Sprint, our task list decided on, our Product Backlog up to date, and out of the blue the client will hesitantly approach my desk. “I was wondering…how hard would it be to…”
At this point, any self-respecting programmer has disengaged her higher-order cognitive function and queued up the automatic “mid-Sprint” answer: “I’m not sure. We’ll add it to the backlog and estimate the effort in a future iteration”.
She does this not out of callousness, but out of respect for the greater good of the process. If she allows her flow to be interrupted and derailed by an “out of cycle” request, she’ll be doing the team, the schedule, and ultimately the client a disservice.
Not me. That phrase – “how hard would it be to…” — that budding client request — triggers in me the Pavlovian response of “Sten the Can-Do Problem Solver No Matter What I’m Currently Doing, At Your Service!”
Innocuous or not, this phrase is a trap by clients to wedge work into the Programmer Flow — an attempt to get “free work” without estimation. I don’t know of any Agile or eXtreme methodologies that advocate “drop everything and do whatever the client says”, but I fall for it every single time. I’m more than happy to circumvent any established process, no matter how Agile and flexible for the sake of People Pleasing and Immediate Problem Solving Gratification.
client:”Sten, how hard would it be to add some extra columns to that report we wrote four months ago? Remember that one? I just want to add a few, or so, or 10 extra columns.”
me:”Um…we should probably…add it..to the to-do list–”
(And then he brings out the bait)
client:”Oh of course, I figured it was too difficult to do right now. That’s a shame though…”
me: “Well it’s…not necessarily too difficult, I just–”
(And then the Mega-bait comes — the client’s attempt to solve the problem himself, usually by referencing random UI elements).
client: “No, you’re right, we should wait. I imagine it will involve adding some more checkboxes, and possibly a button or two”.
me: “No! No! No that’s not– Fine! OK! I’ll do it! Right now! I can do this, it’s not a problem”.
I don’t know why I’m such a sucker, but every time it– whoops, hang on, the client wants to talk to me–
I’m like a Hypochondriac, but with Programming
Tuesday, January 6th, 2009
I heard the following phrase no fewer than three times at a recent tech conference: “Bad Programmers will move heaven and earth to do the wrong thing”. The first time I heard it I thought that it was kind of catchy, maybe I even chuckled a bit with the others in the room.
The second time, a nervous smile crossed my face and I started looking around. By the third time, I was convinced that this quote was aimed directly at me: “Sten, you”, the presenter aimed his laser pointer right in my face, “will move Heaven and Earth to do the wrong thing”.
Other professions probably have their effective, less effective, and probably even negative producers, but for some reason, in software development this is a super heated topic. Look, we even have a Wikipedia entry for them: The NNPP, or so called Net Negative Producing Programmer.
In fact this very topic turns what by all other rights seem to be nice folks into vitriolic zealots. Many blogs I read, or talks that I’ve attended, will at some point digress into a commentary on their sub-par peers. Since these people seem to know the qualities of a Bad Programmer a priori, and I’m a little fuzzy on the subject, it leads me to believe that one (or both) of the following may be true:
- I have not yet had the pleasure (or misfortune) of working with a truly destitute programmer yet.
- I am actually one of the terrible programmers in question.
I don’t believe that the latter is true, however, even passing belief that it might be has led me on a never-ending crusade to determine if indeed, I suck.
It’s like Matt Damon said in Rounders: “if you can’t spot the sucker in the first half hour at the table, you’re the sucker”. If I look around and fail to see terrible programmers, does that mean I’m one of them? Am I blithely leaving a path of coding carnage that others are forced to clean up?
I don’t believe this is the case, but the frequency of hearing about NNPPs coupled with my anxious tendencies make me uncertain. So that is why whenever I stumble across yet another witch hunt for smoking out the bad seeds of programming, three way mixed metaphors notwithstanding, I break into a nervous sweat while I pour over the latest criteria of “You’re a Bad Programmer if…” with anxiety that should be reserved for waiting for thyroid test results from my doctor (re: thyroid, no worries, I’m fine).
This obsession has led me to do things like interview with Google, since they seem to have their share of smarties, so maybe some of their smarties could objectively evaluate me, even though I didn’t necessarily want to work there (retrospective note: should not have said during the interview, “I don’t necessarily want to work here”).
Joel Spolsky (and his ubuquitous book/blog “Joel on Software”) is in many ways the origin of this anxiety. Before I go any farther let me be perfectly clear: I adore Joel’s writing style, I eat it up as Software Gospel. Indeed, it was out of this adoration, that my quest for acceptance grew.
But Joel has no shortage of opinions about what makes a Great Programmer and what makes a steaming pile of programmer dung. Joel has written extensively on the subject in no fewer than three books including a guide to hiring the best programmers (which outlines exactly why you won’t be able to hire a great programmer. Answer: they are never on the market. Which, by the way, makes me wonder where consultants fit into his developer food chain since we’re on the market potentially several times a year, but that’s another topic).
In fact if you’re a Programmer Hypochondriac like me, you may be nervously scanning this post looking for assurance and validation from my own list of “Bad Seed Traits” so that you can breathe a sigh of relief when you see that “oh thank goodness, I write unit tests, I must not be One Of Them”.
I’m sorry to disappoint, but I have no insight into the Bad Programmer phenomena. Actually, at the moment, I’m more interested in looking at those who hunt them down.
Actually, it’s probably not much of a mystery. The realm of Software Engineering seems to have more than its share of Those with Strong Opinions.
If you doubt that programmers have strong opinions, be sure to check out the heated argument over at Coding Horror over a probability problem, as scanning through a couple thousand comments may convince you otherwise.
I don’t know if it’s that those with strong opinions naturally gravitate toward programming, or if arming someone with a bit of CS knowledge makes them this way (probably the former), but suffice it to say that I’ve seen friendships end over “inheritance vs. composition”.
When you couple strong opinions with a very low barrier to entry in the field, it’s only a matter of time before the the finger pointing and name calling start to emerge. (As a profession, doctors also have a high rate of Strong Opinions, but they have a much higher entry barrier including lots of expensive schooling, and emergency appendectomies at 3am. So one might say that they’ve “earned it”. Besides, it’s dangerous to compare us to doctors anyway).
But how much of this is legitimate criticism, and how much is just plain mean?
At one of the talks I attended recently the speaker encouraged us to figure out creative ways to shame programmers who did things like break the build. Really? We’re promoting shame now as a motivation tool? As in, we should take away someone’s dignity? The speaker told us that talk was intended as a venting session, but I walked away from it feeling spiteful and sad for our profession.
Don’t get me wrong; I’m by no means blameless. I compare myself to others all of the time, and it’s usually not satisfying enough to come to the conclusion that we’re all equal in our own special way. So I judge others’ competencies, in my own mind if nothing else.
It’s just that when I do, it always leaves me feeling dirty and antagonistic. It makes me protective over my own ideas and not a very good team player. So for me anyway, dwelling on trying to separate the Programming Wheat from the Chaff is unhealthy and leads to professional sadness.
“Dude, you don’t understand”, you say, “Bad Programmers are costing us millions of dollars a year and slowing down the Good Ones”. No, I get it, fine. I’m all for higher barriers of entry and accountability. I’m not denying the existence of NNPPs — in fact I would argue that we’ll all NNPPs some of the time. (Are we all positively productive on the first day of a new project?)
The problem is that there is a difference between a call to improve yourself and a call to quit and find other work, you’re hopeless.
JavaFX 1.0 to be Released Today (includes Bonus Op Ed)
Thursday, December 4th, 2008
The maiden voyage of JavaFX is scheduled to begin today. There have been, what seems to me, a lot of nay-saying and grumbling on the Internet — a place usually known for its welcoming of new ideas with open minds and hearts — regarding the projected success (or failure) of JavaFX.
So I’m going to do something a bit unconventional and share an opinion about something in the context of a blog post.
I don’t think JavaFX will win any “hearts and minds”. In the end, I think everybody goes with what they know. Dot Netters will go with Silverlight, and Adobe people will stick with Flex. All that’s changed is that finally Java people have an option now. That’s it. No more and no less.
Some predict that JavaFX is too late to the party. I agree that it would have been nice if it came out last year, but I ultimately think that this won’t matter. JavaFX’s primary differentiator, that it runs on the Java platform and interoperates seemlessly with existing Java code, deflates this claim. We shouldn’t forget that Java really started as an RIA technology back in the late 90s with applets. So in a way, JavaFX’s infrastructure has been here for years.
We’re in a transition point between the Age of Web Apps and the Age of RIAs (in the web space, that is). And if you doubt that we’re at this transition point, or if you think that RIAs include web apps, ask yourself, does AJAX really give you “all the rich you need”?
Can AJAX really, as Jef Raskin famously stated, treat all user input as sacred? Is AJAX really the end all and be all of a Compelling User Experience? Or do we remember that applications used to run outside of a browser?
There is plenty of room, and I would argue, even a need, in the RIA space for an Open Source solution that runs with Java.
So Java people, cast off your MXML and come back to the fold! Silverlight people, there’s nothing to see here; move along.
Recent Posts
Archives
I’m Literate!
'to-read':
Tags
Categories
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « May | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||