RSS 2.0
Journal / Blog
Sunday, July 13, 2008
Gross Generalizations: Software Evangelists, Rock Star Developers, Senior Developers, and Software Architects
Generalization like rumors usually have some truth to them – at some point, someone formed a thought around a frequently observed piece of truth and… Viola! A generalization was born (or maybe a rumor). Generalizations are incorrect for every single possible case (the exceptions), but there is truth to them.

That’s my disclaimer; now let’s have fun with generalizations.

The Software Evangelist

The epitome of an Evangelist can be observed on Sunday morning TV:
"SHEBBA-WABBA-MULLA-MONEY-POWER-BOOYACKA-POW-BOW!!!!"
A congregation frying like bacon on the floor (being moved by spirits), 800 numbers requesting money seared into your TV set, and an Evangelist at the helm orchestrating the show.

Evangelists are a great source of inspiration, excellent communicators, and great leaders. However, they often present a one sided biased opinion, a narrow focus, and can be driven by ulterior motives (money, power, viewership, readership, etc).  Listen to any Evangelists with a grain of salt.

Rock Star Developers

Rock Stars are on MTV, and featured in tabloids - they live hard and die young. 

The lyrics of Great Big White describe the life of a rock star:
Well I'm a wasted rock ranger
I live the life of danger
On the road to find a higher high
I don't need no one's affection
All I need is my injection
The music of wild rock will get me by
Some companies seek out "Rock Star Developers", here’s an excerpt from an email I received:
are you a Rock Star? I have an opportunity for a rock star … I am reaching out to you in the hopes that you might the star I and the client are looking for!

So, what is a Rock Star Developer? My perception is a: narcissistic, self-centered, prima donna – someone who doesn’t work well in a team, doesn’t listen, does whatever they want, and lacks dependability. Hiring a Rock Star Developer probably isn’t recommended - unless your organization has a liberal guitar smashing policy, doesn't mind drunken belligerency, and is run by a one man show.

Senior Developers

Everyone wants a Senior Developer, but occasionally these developers are more senior than developers, and certainly not senior developers – often the developer's age (not experience) determines their title. Studies have shown that a developer with 2 years experience can perform at the same level as a developer with decades of experience. Still some Senior Developers have an unexplainable need to let the world know of their seniority through email signatures, resumes, business cards, LinkedIn profiles, and so on.

If you work for 10 years, do you get 10 years of experience or do you get 1 year of experience 10 times? You have to reflect on your activities to get true experience. If you make learning a continuous commitment, you’ll get experience. If you don’t, you won’t, no matter how many years you have under your belt. - Steve McConnell, Code Complete 2nd Edition

Software Architects

Software Architects can be glorified Senior Developers - an architect might be a developer who is senior (like a curmudgeon with a walker) that needed a new title.

Thoughts on generalizations:

There are two sides to these generalizations, the people who claim to be, and the people who are. The people who claim that they’re a Senior Developer are usually impostors, whereas the person who is a Senior Developer is collectively regarded as one by their peers.

Generalizations (like metaphors) are communication mechanisms, sure, there are edge cases and exceptions. Occasionally I encounter aversions to generalizations. Responses like: "Hey that’s not completely true, X,Y,Z disproves that", or "Naw... that’s just incorrect" seem to be made when we forget that we’re just using generalizations.

What generalizations stick out in your mind?

Tuesday, July 01, 2008
2008 Summer Reading List: What Are You Reading?
Summer is finally here! Well... "here" as in, "here in Canada" where we have 8 months of winter, fall, and spring...

This summer I hope to finish up the following books:
Books and reading are essential for personal and professional development. The more you read, the more you understand and the more resources you have to fall back on.

What books are you reading this summer? Do you have any recommendations?
Monday, June 23, 2008
Joining The Dual Monitor Club: Getting a New Computer: The Ultimate Developer Rig

In this picture: My Charles Babbage mug, books: Domain Driven Design, the Ruby Programming Language, the Definitive Guide to JavaScript, my Evoluent VerticalMouse, and lots of Red Rain empties.
One of my biggest pet peeves is trying to efficiently complete development work on a slow machine. In my mind, trying to work quickly on a slow computer is like asking a marathon runner to wear snowshoes then demanding they WIN the marathon. What ensues, is painful for the runner, painful for all who watch, and reaching the end goal feels impossible - bottom line good equipment matters. However, many client's overlook the relationship between getting stuff done and a slow machine, or they don't care, or they can't do anything about it.

Maybe they find it thrilling (in some sick way) to watch your soul fizzle away as you spend 300 minutes a day compiling your application (or running your tests). :)


In great organizations slow machines aren't an issue. According to the The Programmer's Bill of Rights: "Every programmer shall have a fast PC", and from the Joel Test: "[Organizations should] use the best tools money can buy?" But reality is often a different beast, and in my experience you have to make the changes you want (or "be the change you want to see..." - Gandhi).

I'm sure in Silicon Valley, good computers would be mandatory for most organization, but I live in Canada - we suffer through black flies, mosquitoes, 8 months of winter, and organizations with poor resources. :) Did you know that Canada's population is roughly equivalent to the population of the state of California alone!?

Anyhow, I started working from home full-time this year - up to this point most of my work has been done onsite using whatever machine the client provided (some with outdated hardware). My home desktop was a six year old PC that would make Frankenstein look sexy - it was a collection of old and new parts. Since, I do most of my work in Virtual Machines (I typically have three VMs running) performance is absolutely critical. After spending a month working on my dinosaur of a machine, it was clear I needed a new computer.

Leave me a comment requesting the details, and I'll happily bore you with the technical specs of my old machine including a story of where I acquired each component. :)


I based my specs on Jeff Atwood's and Scott Hanselman's specs for the Ultimate Developer Rig. The machine turned out to be economical, the prices have come down significantly since the initial post was published, and to top it all off, I was able to chop shop my old machine and sell every single part through eBay and Kijiji - for a surprisingly decent price too (who would have thought a 6 year old Sound blaster Audigy would sell for $50?).

Contrasting my setups:

ThenNow
ProcessorsTwo 32bit AMD MP 1.2GHz  Quad Core 64bit 2.4GHz
RAM3.5 GB8 GB
Monitor(s)A single 17"Two 22" Samsung SyncMaster 226BWs
Personal Pain Points  Excruciatingly painfulOccasionally painful (only Vista induced)
Working on my new machine is enjoyable. I find myself more productive without being distracted by the frustration of a slow machine, and having dual monitors also contributes to my productivity (Does More Than One Monitor Improve Productivity?). My favourite parts of the new setup are the monitors, the Ergotron stand, the speed, and the Case. You really get what you pay for with LCD monitors, the SyncMasters are easy on the eyes when compared to my old economic Acer, and the case is dead silent.

In the future, if I'm provided with a substandard PC, you can expect to see me hauling my new machine into the office. :)

Take a look at my old desktop setup in my older post: Something About the Cobbler's Children Having No Shoes

Have you ever had to use an outdated machine as a developer? How does working on a slow machine effect your work? What are your thoughts on taking matters into your own hand (like purchasing your own computer to replace the slow one at work)? Have you ever installed additional resources in the computer you use at work?

Wednesday, June 18, 2008
Strange Interview Questions === No Job
I was asked a series of questions during an interview that I'll never forget.

The interview was at a successful company in the process of growing from a start-up. They offered a fantastic work environment, the developers had dual 22" LCD monitors, state of the art machines, fooze ball, and to top it all off, they had a cafeteria with two gourmet chefs  - I even had lunch there, it really was good food! It could have been a great place to work, but... the interview left me running for the door.

Some of the unnerving questions:
"Do you smoke? Does anyone in your family smoke?"

It turns out that they had a strict no smoking policy written into their contract. Yup... You had to sign, that you and your family will remain smoke free (including second-hand smoke) for the duration of your employment.  While I don't think smoking is smart, and can see some benefits of having an explicit no smoking policy - still... this question took me off guard.

Potential benefits of a strict non-smoking policy:
More productivity (no cigarette breaks for employees), an odour neutral working environment, fewer employee sick days, cheaper corporate health insurance, and it could filter out potential drug users.
Draw backs:
Rapport with the interview team was immediately shattered, it's probably illegal to ask this question in the first place. It was an invasion of privacy (If you're demanding this, what's next?). It felt very Orwellian (Would they have Big Brother monitoring us too?), confusing (How can I control second-hand smoke?), and just weird (Would I be fired if someone planted a pack of cigarettes in my desk?).
"Do you play video games?"

There was another sigh of relief when I answered "No". I don't play video game - well... aside from playing Tony Hawk on my classic Play Station every 6 months or Pong on my cell phone. I have better things to do than play video games, even if it's doing nothing - like watching the paint peel off my wall (clearing my mind). Besides, isn't having a computer monitor (or monitors) larger than your CRT TV a requirement for entering true Geekdom? Seriously though, I've watched family members and friends drain their lives into video games, as a result I'm not crazy about video games (but the Wii is fun). This question, like the previous was another negative hit for my employment prospect.

Potential benefits of having non-gamers as developers:
Better rested and more productive employees (they wouldn't be staying up all night playing World of Warcraft), fewer sick days, and more focused employees (web surfing for game tips would not be an issue).
Draw backs:
Being a gaming doesn't say anything about your skills as a developer. I started to get the impression that productivity really matters to this organization. I felt confused (Why is this so important? Is there something they're not telling me?), and it was another blow to privacy (Who really cares if your employees play games?), and a blow to trust (Will I have to answer questions like this everyday? I'd like to maintain some freedom, what if I decide take up gaming?).
"Do you have a problem with being at work at 8:30 sharp every morning?"

Now scenes from A Clockwork Orange are flashing through my mind - I'm being strapped in a chair, eyes pried open, hands chained to a keyboard, I'm being interrogated on the events of last evening, followed by a nicotine breathalyzer. OK... they didn't embrace flextime. This organization was not a good cultural fit, too many weird questions, interview was officially over in my mind.

Potential benefits of a regimented routine:
Uhmm... I guess, you know when your employees should be at work.
Draw backs:
Going to work could feel like tree planting / boot camp / the army, demanding rigid hours could imply a lack of trust in your employees, demands like this would certainly engender turnover, and companies with high turnover are bad places to work (there's a cost for turnover).
Some smaller companies might like to know their candidate at this level, and if that's the case then take them out for a couple drinks or dinner - try to learn these questions, don't outright ask them. Questions like these might hurt the reputation of your organization, after this interview I was resisting the urge to run for the door, and since then they've asked me to recommend potential candidates.

What kind of interesting interview questions have you been asked in the past?

Sunday, June 15, 2008
Living The High-tech Illusion: Software Development is Not Rocket Surgery
#CalgaryBarCamp was swell. It was refreshing to meet such a diverse group of like minded people that all essentially do the same thing (create software), but do it in different ways using different tools, platforms, and languages. The ad-hoc discussions both in the bar and between sessions were my highlight. A reoccurring theme in our conversations was that technology, tools, and platforms don't matter that much. What really matters is: people, communication, ideas, taking risks, and motivation.

The topic of our discussions reminded me of something David Heinemeier Hansson said when talking about software development:
"You don't need to be a f***ing genius to make any of this stuff work, it's not rocket surgery!" - David Heinemeier Hansson at Startup School 08
DeMarco and Lister also echoed this outlook back in the 80's, and publicized: the High-Tech Illusion:
the High-Tech Illusion: [is] the widely held conviction among people who deal with any aspect of new technology ... that they are in ... high-tech business. [These people] are indulging in this illusion whenever they find themselves explaining at a ... party, say, that that they are "in computers" ... The implication is that they are part of the high-tech world. [These people] usually aren't. The researchers who made the fundamental breakthroughs in those areas are in the high-tech business. The rest of us are appliers of their work. - Peopleware : Productive Projects and Teams
If we were in the High-Tech business, then we'd be the bottom feeders (the parasites, the grunts), because our daily activities revolve around consuming other peoples research and work (programming languages, platforms, frameworks and the like). We are consumers, we're not on the cutting edge nor are we in the high-tech world.

Perhaps building software could be much like outfitting yourself for a day in the snow. You head off to the local shopping mall, you acquire the functional items to keep yourself warm, but brands and store choice don't really matter. Whether we're buying winter boots or choosing a programming language, technology doesn't really matter. There are an infinite number of ways to solve any problem, as well as an infinite number of technical permutations to form a solution. If we can solve the problem within the constraints of our problem domain then we've succeeded.

The High-Tech Illusion often permeates my world - I work as a Web Developer in the Microsoft realm. I continually see the High-Tech Illusion manifests itself in these situations:
  • Colleagues talking in vague opaque high-level metaphors that patronizingly shield you from the inter working of what they assume is beyond your comprehension
  • Fixations on specific tools, hardware, platforms, and methodologies while the problem that needs to be solved is diluted and any combination of these items could solve the problem
  • Colleagues that assume superiority and can't acknowledge that knowledge is acquired through research and a continual efforts to improve
Pretentiousness in the software realm (in teams, organization, and so on) is usually the byproduct of someone that's living the High-Tech Illusion.

I've been guilty of subscribing to the High-Tech Illusion. How does the High-Tech Illusion permeate your world? How can we get back to reality?

Saturday, June 14, 2008
How I Got Started In Software Development: Confessions of a Script Kiddie


Ahh yes, the bowl cut. Simple to maintain, keeps the cold off the brain.

Me around age 12, and not much has changed. :)

Maggie Longshore (tweet: MaggiePlusPlus) posted her response to Michael Eaton's (tweet: mjeaton) initial post on: How did you get started in software development? I had fun reading the other contributions so here mine...

How old were you when you started programming?

Somewhere around the age of 8 or 9.

How did you get started in programming? What was your first language?

My dad went to College for robotics when I was around 8 years old, so he was really into programming (programming robots) and we worked through a book on the BASIC programming language. After that I continued to mess around with BASIC and wrote scripts so I could get at my favourite games. Later I was frequenting BBS's, and surfing the internet through a text based browser. I eventually became a Script kiddie - in retrospect, being a Script kiddie was what really turned me on to programming. My friends and I would write our own IRC war scripts take over local channels, we'd play MUDs late into the nights, and try to figure out how Trumpet Winsock, networks, mIRC, and HTML worked - those were the days of Netscape 1 (the version with the big glowing 'N'). Later we tried writing our own version of NetBus with the help of C / C++ programmers on IRC channels - the fragments of the C language these programmers shared with us were magical, they really sparked an interest in programming. In addition to all this my dad kept a constant supply of computer parts funneling into our house, my brothers and I would build computers from the parts - today my closest brother is a Linux guru, evidently all this sparked his interest too.

I've digressed, short story, programming has always been a part of my life, BASIC was my first language.

What was the first real program you wrote?

I followed a couple game tutorials in my BASIC books, but my first real program would have been Pacman in Turing - in my final year of high school I enrolled in a computer course, where the instructor let us choose our own adventure I chose to write a game.

What languages have you used since you started programming?

BASIC, Turing, Pascal, Assembly, COBOL, C, C++, LISP, Java, JavaScript, PHP, VBScript, most of the .NET Languages, and so on...

I've spent the most time in C, C++, C#, JavaScript, SQL, and the mark-up languages. I primarily program for the web or at least for the network.

While using multiple languages are great, I really believe that we you should completely understand the fundamentals of at least two languages (like say a static language and a dynamic language), because:
"Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity." - Steve McConnell, Code Complete 2nd Edition.
What was your first professional programming gig?

If by professional you mean worked at least 20 hrs a week and was paid, then I would have been 18. It was my first year of College, I needed a part-time job in order to live (In Honour of the Student Loan), I worked on an assembly line. I would occasionally help the office workers troubleshoot their IT issues and soon found myself working as their network admin / computer gopher. I went on to develop their cataloging system and a website. At the time I was going to school for Electronic Engineering, but decided to switch to a Computer specific program. Pervious to this, I had freelanced a couple websites for local businesses.

If you knew then what you know now, would you have started programming?

Absolutely! The industry continues to instill a sense of wonder in me. I can't imagine doing anything else.

If there is one thing you learned along the way that you would tell new developers, what would it be?
  • Read! You'd be surprised how little progress has been made in the software industry over the past 30 years. By reading we can learn from the mistakes others have made.
  • Don't be intimidated by code or frameworks handed down by large organizations, their code isn't any different than yours.
  • Hard work always pays off, or as Thomas Edison said: "Success is 10 percent inspiration and 90 percent perspiration."
What's the most fun you've ever had ... programming?

Collaborative programming is always fun whether it be paired programming or working together on a project. It's hard to pinpoint the most fun I've "ever" had, because it's all fun. :)

Now it's your turn to answer: How did you get started in software development?

Saturday, May 31, 2008
The Good Parts of The ASP.NET Framework and Visual Studio
Douglas Crockford opens his latest book with these words:
Most programming languages contain good parts and bad parts. ... [the language designers or architects] are usually powerless to do anything except heap more features on top of the existing pile of imperfections. And the new features do not always interact harmoniously, thus producing more bad parts. - JavaScript: The Good Parts by Douglas Crockford
His words can apply to all programming languages and frameworks. Especially the ASP.NET Framework and Visual Studio.

Bad parts in the ASP.NET Framework and Visual Studio:
  • ASP.NET Themes and Skins
  • The ASP.NET AJAX Framework
  • ASP.NET / Visual Studio Inline Style Properties
  • Visual Studio Design View
  • ASP.NET and Visual Studio's over dependency on XML configuration files
It would be great if someone wrote a book outlining the good parts of ASP.NET and Visual Studio. :)

What bad parts do you steer clear of?

Saturday, May 10, 2008
Education is a Great Investment: In Honour of the Student Loan
As a student I was a pathological penny pincher, but as much as I've complained about student loans, I'm also grateful for them. Sure, it would be great if Canada could adopt an approach like Finland and other European countries where education is free, but that's not in our cards.

Why are student loans good?
I grew up in a small village in Northern Ontario, in a huge family - in total there are 11 of us. YES! I have 8 siblings and we all have the same parents. :) Most Canadians are familiar with the rural community setting (maybe not the huge family scene). A railway runs through town, the town has 2 gas stations, a single postal code is associated to the entire area (including all the outlying hamlets, and farms), the local high school is 30 minutes from home, the high school kids are bussed from a 100km radius (and there's still only about 700 students in total). Most of your childhood is spent: crawling across beaver dams, building tree forts, playing Lego, banging away at BASIC on rainy days, swinging from ropes in barns, chasing sheep, skateboarding, and shooting guns. Most of the residents in these towns live modest lives, and have chosen the rural community because it's cheaper than living in the neighbouring city, or they have just always lived there. The residents are employed in the dwindling lumber industry, the agricultural industry, the local businesses, they are seasonal workers, or unemployed.

In short, living in these remote communities can be economically challenging, supporting a massive family in these areas can be difficult, and receiving educational assistance from your family is even more difficult. So... If it wasn't for government funded student loans I probably wouldn't have gone to College/University, and if it wasn't for an education I probably wouldn't have been able to develop the skills necessary to be where I am today - yesterday I paid the last of my Student Loans. :)

Thank-you Government of Canada for the student loans!


For all the students out there, keep your chin up, keep your eyes on the goal, don't let finances get you down, focus on your studies, and keep pushing forward. Education is a sound investment in your future - provided you're not going to school for underwater basket weaving, or attending an atrociously expensive private college, and not going to school forever (everything in moderation, right?). As the old adage goes: "you've got to spend money to make money", and education is a sound investment.

Griping About Users: What's Wrong With Forums?
Forums or Newsgroups are a great way to expand your community, contribute to the greater development community, hone your communication skills, and stay grounded. However, forums can have a frustrating dark side. From what I can tell, the dark side of forums stem from the wide diversity of users.

On Forums we have:
As a forum contributor, I like to think that I'm giving something to the community, but some days I feel like I'm wasting my time and here's why.

Frustrating forum threads:

When contributors pass your words off as their own:
Amanda from Microsoft offers this bit of advice on 08-28-2007:


Which seems vaguely similar to something I might have said back on 12-07-2006:

When users are belligerent:

"Adam has so little time he can't even read your question ..." - Brian
When users want a quick fix or want you to do their work:



"please verify and do for me some work." - dagamishiva
It makes it all worth while when users are genuinely grateful for your advice and suggestions. In the end, forums (and helping people in general) is rewarding, and some forums that explicitly cover more advanced topics omit the frustrating chatter and facilitate professional level discussions.

What are your experiences with forums?

Sunday, May 04, 2008
Necessary Skepticism: Skepticism is not Pessimism
In the software realm our opinions are often polarized (perceived in extremes) with no middle ground - you're a pragmatist or an idealist, you're a Windows or *nix person, "you're either with us or against us". This train of thought is referred to as Black-and-White Thinking, or All or Nothing Thinking. This thought process continually manifests itself in the software realm for good reason - we're under pressure to produce, but have limited time, and can't exhaust all permutations or combinations of technological possibilities. So we develop coping skills, and make quick decisions (even if they are wrong). As IT professional we're constantly in The Fight or Flight mentality:
"All or Nothing thinking ... is part of the most primitive of human responses: The Fight or Flight Response. When faced with a life-threatening situation, we must make a snap decision and act on it. There is no time for 'maybe this', or 'maybe that'." -All or Nothing Thinking
Some Polarized Views

Views or labels that seem to be commonly applied to people, organizations, and people:
  • A Pessimist or an Optimist
  • A Cynic or an Proponent
  • A Skeptic or a Dreamer
  • A Pragmatist or an Idealist
  • A Tigger or an Eeyore
These labels are generally mutually exclusive - you're usually labeled a Pessimist or an Optimist, but not both. Then there's this general acceptance that Skeptics are Pessimists and these are Curmudgeons, and Eeyores (but everything in moderation). Switching between views is healthy and advisable (be a Skeptic and an Optimist), because inherently "[a]ll programmers are optimists" (1) and too much Enthusiasm, and Optimism often results in Hype, and "Hype is the plague on the house of software" (2).

Why not embrace all these views? Take on the role of a Skeptical Dreamer, then an Optimistic Cynic, or a Pragmatic Idealist. Let's throw off these polarized thinking models and fill in the gray areas. As Fred Brooks once said: "Skepticism is not Pessimism", and critical thinking is also not Skepticism.

(1) Fred Brooks, The Mythical Man-Month (2) Robert Glass, Facts and Fallacies of Software Engineering

Wednesday, April 23, 2008
Turning the Page on Another Virtual Chapter: Time For a Website Revamp
Life is like a book of infinite chapters with everyone reading at their own pace - we're not who we were yesterday and won't be on the same chapter next week, we're all on the same journey, we progress.

Time for a change. This site and blog was initially directed at hiring managers, it worked great, the human resource teams thought the website was great.  It successfully demonstrated creative potential, communication skills, dedication, and so on, but that was 3 years ago. Today my audience has changed (has become more developer centric), but the growing pains of yesterday linger.

So over the next couple months I plan to revamp this site to better represent my current state and anticipated professional direction.

Site update road map:
  • Transition from a showcase / superficial / professional type site to a more personal / how-to / community based / professional site
  • Keep it simple
  • Replace all the ASP.NET AJAX (ATLAS) widgets with hand coded JQuery or Scriptacolous JavaScript components
  • Drop the Home landing page, replacing it with my Journal / Blog
  • Drop the Professional Development, Resources menu item
  • Drop the Professional Development Landing page, redirect to Reviews
  • On the Contact page:
    • Remove the lengthy explanation on why I'm using a Captcha
  • General Site Design
    • Replace all HTML images with CSS images
    • Design a new logo
    • Design a new color scheme
    • Switch the CSS design from a fixed width layout to a liquid layout
Since my last name is hard to remember I'm considering www.adamdotcom.com as my primary domain name, what do you think?

Any recommendations are welcome!

Wednesday, April 16, 2008
How To Choose a Good Technical Book
The quality of technical books have wide variations between publishers and authors. While choosing a book based on the author is reliable, depending on a publisher or brand name is not reliable, and choosing a book based on advertisements is even less reliable. It makes sense to choose your books wisely since most technical books live a short life (the duration of a single project), cost money, and require precious time to be read.

When choosing a book I follow this heuristic approach:
  • Ask experts in the field (friends, forums, newsgroups) for recommendations
  • Ask these experts to differentiate between the high level books and the books that take a technical deep dive.
  • Filter out (discard) the high level recommendations.
  • Filter out (discard) all recommendations that contain the following keywords in their title:
    • Cookbook
    • Problem - Design - Solution
    • Hacks
    • Tips
    • Learn X in 24 hours
  • Look for recognizable authors.
  • Cross reference these recommendations through Amazon's Reviews:
    • Books with over 100 excellent ratings on Amazon are instant winners - the Amazon community is rarely misleading.
    • Books that haven't received more than 50 ratings should be considered with skepticism - visit a local book store and skim through the text in question before making the purchase.

Wednesday, April 02, 2008
Founders aren't Employees, but neither are Consultants
In You Weren't Meant to Have a Boss, Paul Graham makes some clear distinctions between Founders and Employees. A similar Founder Vs Employee thread was presented in Joel Spolsky's recent article How Hard Could It Be?: Lessons I Learned in the Army. Spolsky goes on to make the point that Employees do not have the same ambitions as Founders, and that Founders need to realize this dichotomy - that Employees are interested in today (short term) whereas Founders are focused on the long term.
The great employees will be devoted, sure, and it's completely reasonable to expect them to work their butts off. But unlike founders, employees are concerned about what their jobs are like today. They're not as excited about making sacrifices for the long run.

I can always tell the founders who haven't figured this out yet, because they're disappointed in all their employees, firing good people left and right and constantly asking, "Why hasn't Joe (or Jane) gotten this work done yet? I could have finished it in one weekend!"
- Joel Spolsky: How Hard Could It Be?: Lessons I Learned in the Army
Both these articles highlight the differences between Employees and Founders, but what about Consultants?

Consultants can often fall under the full-time Employee umbrella, but probably have an even shorter term interest in their client. Part of a consultant's job is to maintain objectivity, to distance themselves from becoming financially, emotionally, and personally invested in their client - objectivity is lost when an attachment or investment is made.

According to Janet Ruhl a couple of the biggest Gotchas in consultancy work can be:
  • Investing in your client - purchasing shares in your client or agreeing to software royalties rather than a pay cheque.
  • Being manipulated into working for free.
Consultants are kind of like Employees, but different. Consultants probably have an even shorter term interest in the company they work for then Employees do. I think it's important to highlight these differences.

Saturday, March 08, 2008
Something About the Cobbler's Children Having No Shoes
As knowledge workers, software developers and the like, we often find ourselves heads down in the trenches (micro focused, working towards deadlines), while throwing self-improvements and work environment improvements to the sidelines.

As the old phrase goes: "The Cobbler's Children Have No Shoes" - the Cobbler was so busy with other peoples shoes, that he couldn't make shoes for his children. Like the Cobbler I often find myself burried in work, and neglecting the things that could improve my situation.

A couple personal examples: this website (the design has remained unchanged for the past couple years), my desk setup (the mountain of books for a monitor stands and a single 17" monitor) demonstrate this.

I've since purchases an Ergotron LX Dual Desk Mount Arm, and will soon be upgrading to these Samsung SyncMaster 226BW 22" monitors, which I plan on running in portrait mode.

How can you improve? What does your desktop look like?

 
Saturday, March 01, 2008
The summer of '99: Junior-Style / n00b Programming
Steve Yegge discusses junior-style programming in his post: Portrait of a n00b. After reading Steve' post I decided to dig up some of my own n00b code - this code is from the summer of '99.
I got my first real C++ book
Bought it at the local book store
read it 'til my eyes turned red
it was the summer of '99
I found this code amusing... To keep things short, I included one method, but the entire class implementation is similar - my comments describe almost every facet of what I now regard as relatively simple logic and I've completely removed all whitespace.

As Steve puts it:
[I was] making up a temporal narrative in an attempt to carve out a mental picture of the computation for myself. These stories I told myself were a critical part of my mental development as a programmer. I was a child trying to make sense of a big, scary new world. - Steve Yegge: Portrait of a n00b
The code:

//***************************_Command.cpp_*********************************
//__Creator:_____________Adam Kahtava
//__Date:________________June 14, 1999
//*************************************************************************

//-----Implements the init method defined in the command.h header file
//-----Keywords and Modifiers are initialized into keyword[], and modifier[1-5].
//-----(Keywords and modifiers are all separated by semi-colons).
void command::init(char data[]){
  int j
=0;
  int len=strlen(data);
    for(int i=0;i<6;i++){
    //this for loop is run 6 times, 1st for the keyword,
    // and 5 times for the modifiers, and increments i.
    int k=0;
 
  char temp[20]={""}; //sets temp to "" (the default)
    //goes through "data" copying string into "temp",
    // until delimiter ";", '\0' is encountered or until len >= j
    while((data[j]!=';'&&data[j]!='\0')&&len>=j){
  
    temp[k]=data[j]; //copies useful data from "data" to "temp"
   
  i++; //increments i
      k++; //increments k
 
  }
    if(i==0){ //is initiated on first "for loop".
  
    strcpy(keyword,temp); //copies temp to keyword/
    }
 
  else if(i>0){ //else if "for loop" has been run more than once.
   
  strcpy(modifier[i-1],temp); //copies temp to modifier[1-5].
    }
 
  j++; //increments j
  }
}
Notable difference from then and now:

Back in '99 I thought everything I wrote was awesome, I thought I was a Code Poet, or a Programming Ninja (with Real Ultimate Power). I thought my descriptive comments were awesome, and probably thought that by removing all whitespace I would be increasing the program's efficiency. I thought I could learn more by just programming than reading about programming - I recall discarding books and often hacking my way to comprehension. I was clearly disillusioned.

Today
I agree with Jeff Atwood that everything I write sucks, I have an obsession with white space, and prefer to thoroughly understand a programming language before verbalizing my proficiency in it. Now I occasionally get complaints that I'm not including enough comments, and I'm still improving and learning. :)

Sunday, February 17, 2008
Software Ethnocentrism: Staving Off Tunnel Vision
Loosely typed / weakly languages are amazing! But... for myself, coming to this conclusion was like an acquired taste.

Many people appreciate loosely typed languages for the how expressive, elegant, simple, and Zen like they are - and I agree, but I haven't always thought this way. You see; strictly typed (statically typed) programming languages have always been the mainstay of my programming vocabulary, C++, Java, and C# were the meat and potatoes of my programming language diet. I used these languages (strictly typed) because they were familiar, I understood how their compilers, IDEs, and comfortable class-based inheritance model worked. If someone asked me whether I liked C# (insert strict typed language) or JavaScript (insert weakly typed language) I would immediately have given preference to the strictly typed language. Why? Because that's where I felt safe, and that's what I understood - besides who wants to admit they prefer the "weak" language? My preference wasn't based on knowledge or experience it was based on my familiarity with the strictly typed culture.

I was suffering from Software Ethnocentrism.
Software Ethnocentrism often entails the belief that one's programming language or development environment is the most important and/or ... are superior to those of other software developers. Within this ideology, software developers will judge other groups in relation to their own particular development environment or culture, especially with concern to programming language, methodologies, behaviour, customs, and religion.
 - the derived definition (above) is based on Wikipedia's article on Ethnocentrism.
I had the tell tale signs of Software Ethnocentrism:
  • I thought strictly typed language were "the bomb"  - the only viable solution :)
  • I thought