The Right Glue
Some kind of dev blog
By Dean
I've been using Google Wave for about a week now, thanks to an invite from everyone's favourite Linux monster qedi (who still hasn't updated his website to work properly in Chrome, by the way). From this week of use I have come to my conclusion about Wave: it's weird.
Wave is designed to be a replacement for a lot of communication technologies: e-mail, chat, forums, wikis and blogs. To that end, Google has come up with its own protocols and whatnot to deliver the basis for other companies and nerds to create their own Wave-based applications and websites. But Google hasn't released this yet, and what we're given (for now), is a web application that demonstrates all of the different functions that other apps can take advantage of later.
So we're given a web application, which itself almost resembles an e-mail client, with a list of saved searches (which are effectively directories), a list of contacts, a listing of active "waves" (the Google Wave word for "thread") and a big area to actually view the waves. The listing of waves is a lot like an inbox in an e-mail client, and indeed one of the views is called an inbox. When waves are created, the creator can attach participants to the wave. Those participants will see that wave appear in their inboxes, very much like e-mail.
Latest comments:
By Dean
A lot of my job is e-mail. Administrative e-mails from my boss, assertive e-mails to my boss, informative e-mails from my team, donut-centric e-mails to my team, questioning e-mails from other teams, advisory e-mails to other teams, sales e-mails from vendors, bug-report e-mails to vendors, furious and confused e-mails from users, reassuring e-mails to users, garbled e-mails from some other country, clarification-request e-mails to some other country, automated e-mails from software. Lots and lots of e-mails.
I just get too many damned e-mails, and so does everyone else. I get so many e-mails that I can't turn on my e-mail client's notification features, since I would be swamped otherwise. Likewise, I have to route automated status e-mails originating from some of our software to special directories and have them automatically marked as read so that I don't have them clogging up my inbox (which, ideally, should just contain real e-mails that I need to address). I only answer e-mails if I am not in the zone, so that I don't lose massive amounts of time dealing with something synchronously that is designed to be handled asynchronously.
I've seen other people's e-mail clients at the office and they too are swamped with e-mails. They all have various methods of organizing things, some of which work well for them and some of which don't. What's important is that they all recognize that there is a problem with the quantity of messages and they're trying to figure out how to best deal with it.
Latest comment:
By Dean
How many of you users have software that you simply put up with because you already have it? Or maybe because someone you know uses it?
How many of you programmers write software using a language or style because it's what you've always used? Or maybe because your boss told you to?
For an overthinker like me, it boggles my mind when I see people who just accept mediocre things because they think it will take too much effort to switch to something better. Even if it's little things like the position of the taskbar, or what music software you prefer to use. Just how bad does an application have to be for you to not use it?
Latest comments:
By Dean
On the 256th day of the year, the timid programmer (Homo sapiens analyticus) emerges from his technology-covered desk to eat delicious cake and discusses Markov chains with fellow members of his subspecies. He does this because programmers like nice, round numbers like 256, 65536 and 2147483647.
Similar to the chlorophyll in green plants, the thin, pale skin of a programmer is capable of converting light into simple sugars used to power their analytic brains. However, unlike chlorophyll, a programmer's skin can only work properly in the presence of a computer monitor refreshing at 60Hz. (A fluorescent light source at 60Hz produces a similar, albeit weaker, effect.) The process works through biochemical induction, and is finely tuned to the technology produced by engineers (Homo sapiens constructor) due to their long-lasting symbiotic relationship. Because of this, programmers are not able to leave their monitors for prolonged periods of time.
While programmers are powered primarily through the skin, they can also consume the flesh of animals such as donuts and cakes to provide them with limited autonomous power supply. It is imperfect, but when the programmer has to move from one monitor to a superior, distant one it is the only way to avoid the slow death of starvation.
Latest comments:
By Dean
Last night, Youtube raised its cocky little head and said, "Hey, Dean! I have a new TED talk for you to watch!" TED talks, being my only subscription on Youtube, have shown me hours of insightful ideas. If you haven't heard about them, you should check a few of them out. They're definitely the best thing on Youtube.
But most importantly is Daniel Pink's talk regarding the nature of motivation and how performance incentives affect performance. If you don't have the 20 minutes or so to watch the video, allow me to paraphrase:
When people are given tasks that can be accomplished largely by rote, performance incentives will increase productivity. In other words, if I have a task I need done, and that task doesn't require anything other than an uncreative, mechanical approach, I can get people to do it faster by offering to pay more to the people who get done first.

So far, that's just basic economics: people are motivated by payoffs.

But when the tasks require creativity, such as solving a puzzle whose solution isn't immediately obvious, performance incentives actually decrease productivity. The idea is that incentives help to narrow focus onto the task, preventing people from seeing creative solutions as quickly as they would without the incentives.
Daniel gives many examples of studies from different cultures that all show this effect. Incentives statistically stifle creativity and slow productivity. This is in contrast to how most businesses operate, a point Daniel makes many times in his talk.
Latest comments:
By Dean
Note that the following post has nothing to do with fishing, fish, tackles, lures, "catching the big one" or any other euphemisms. It is brought on by the fact that it's been too long since the last post and that it's too hot to turn on my gaming desktop. Why is it so hot? I choose to blame NASA arbitrarily for this heat. It's Hubble space telescope's fault. (Also, this laptop I'm using has a very non-standard keyboard so if you see a lot of out-of-place slashes you may join me in cursing HP for putting slashes in places slashes just should not be.)
Today I wanted to write about teaching and learning. While these things don't have anything specifically to do with software development I'm going to write about them anyway because I find them interesting. And it's not like the off-topic police are going to come shoot me with tasers or lasers or radars if I post something slightly tangential to my site's primary topic. Like a lot of things I've written about recently, this one is driven by behaviour I have observed on Stack Overflow.
I believe very strongly and fundamentally in helping people who help themselves. This is at the very core of how I approach learning and teaching. To bastardize an old proverb, I don't believe in giving a man a fish, I believe in teaching him to fish, provided that he is capable of learning how to fish. In other words, I need to be able to guarantee that he'll be able to help himself once I've helped him. If he's going to forget how to fish before the end of the week, there's no point in teaching him to fish because that's just a waste of time and effort.
Latest comments:
By Dean
The programmer of the night is at it again. This time he's claiming that software engineering is dead. I think he's got the wrong idea. But enough about that pale-skinned apparition; his post is merely the muse of today's post.
The thing I found most interesting was in the comments of his post. In particular, the article Coding is less science and more craft by someone named Joe Stump, written earlier this year. I think that article stumbles around a concept I've written about before, namely the difference between those with the engineering knack who are passionate about programming and Gehn programmers who see software development as just a job. Obviously there are more than two types of programmers, but those are the only two groups Joe's article touches on.
But a more subtle point that both Jeff and Joe mention is the standards and practices that are associated with the term "software engineering": things like project estimates, measuring deliverables, formalization of coding standards used at organizations, etc. They are concerned with treating software design and development as a manufacturing process. This is definitely true, but engineering isn't a manufacturing process either. It's unfair to claim that software can't be engineered simply because it resembles craftsmanship. One does not preclude the other.
Latest comments:
This is some kind of footnote. This webpage is awesome and can be viewed in any browser. Even ones that suck ass like Safari and Firefox. Isn't that awesome? This site is best viewed with browsers that aren't maximized on large-resolution displays (> 1024 pixels in width). But then again, if you are running a large resolution and browsing maximized, then you're a terrible person so you don't really deserve to see this site at its finest. Jerk. I mean, seriously. I spend all this time making a nice site and your silly browsing habits ruin its look. That's really cold, man. If you're using IE6, then in order to see the cool avatar effects you need to enable JavaScript. No rights reserved by Dean Whelton (who is awesome) of any of the content, images, design, backend or electrons used in this site. Steal at your convenience. None of it is worth stealing anyway, so there. I have even made an RSS feed for more efficient theft of my intellectual property: CLICK IT NOW!!! Now, don't say I'm not generous. I guess if you want to know more about me, you can visit the about page. It's not really an about page, though. It's just one of the first posts. I don't feel like making a real about page. You can contact me, too. If you feel like it. Are you really wasting time reading this? Go outside or something.