Entries from November 2005 ↓

Links for November 23, 2005

Paul Graham’s New Essay Explores the Meaning of Web 2.0

Joel Spolsky Publishes a Recommended Reading List
A bunch of the books he mentions are on my bookshelf, and I have plans to review them so stay tuned!

10 Cool Software Business Ideas
From TechCrunch.

Microsoft Announces Bi-directional RSS, or “SSE”
A more detailed spec is available here.

Amazon Launches Product Wikis
Every product listing now has a ProductWiki section where visitors can leave relevant information. I wonder how much oversight it will require to keep garbage from appearing?

20 Years of Microsoft Windows
Includes cool pics and trivia.

Free Open-Source Flight Simulator
The images look great!

Color Scheme Tool
A color-picker that aids the visually-challenged (like myself) by suggesting a complementary color scheme that goes with any color you choose.

A Block-based World Map Built by Visitors
A pixelated representation of the world where each pixel is chosen by website visitors. When you arrive at the site it highlights one pixel and asks you to make it land or water. There’s also a cool animation of the “world” forming through the last 118,000+ votes.

Which Search Engine is Best?
Here’s a “blind taste-test” of the top 3 search engines: Google, MSN and Yahoo!. Search for a familiar topic and select which of the three result sets you think are the best.

How Much is Your Blog Worth?

Weblogs Inc, a blog network, recently sold to AOL for $25M in cash.

Based on that information and crafty use of Technorati, Dane Carlson created a tool to determine how much your blog is worth based purely on the number of incoming links. Mine’s worth around $14,000, how about yours?

My blog is worth $14,678.04.
How much is your blog worth?

Hyperbole Rules

From An Illustrated Guide to Cryptographic Hashes “If the hash algorithm is properly designed and distributes the hashes uniformly over the output space, ‘finding a hash collision’ by random guessing is exceedingly unlikely (it’s more likely that a million people will correctly guess all the California Lottery numbers every day for a billion trillion years).”

Looks like a career as a hash guesser is only advisable if you get paid by the hour.

My Blog Now Listed on asp.netPRO

asp.netPRO magazine recently added my blog to their author listings; check it out at http://www.aspnetpro.com/Blog/.

I Took the Beta .NET 2.0 Web-based Client Certification Exam Last Week

I took the .NET 2.0 Web-based Client beta exam last Tuesday. I don’t want to spoil it, since I just wrote an article for asp.netPRO about the experience, but suffice to say the exam covered most of the material you’d expect with an emphasis on XML and custom controls. Approximately 50% of the questions were 2.0-specific.

I was a little disappointed to encounter only one question that used the cool new interface where I dragged and dropped pre-written code snippets to build a class definition. Hopefully we’ll see more of these types of exercises in the future, not only because it’s slightly closer to what we do on a day to day basis, but because it was a nice break from clicking radio buttons.

New Article: Software Training Sucks: Why We Need to Roll it Back 1,000 Years

From my new article Software Training Sucks: Why We Need to Roll it Back 1,000 Years:

“This article is about training, but not the typical ‘pay $1500 to sit in a stuffy hotel conference room for five days while some guy who hasn’t written software since Elvis reads his PowerPoint slides to you in an effort to keep you awake’ training.

We’re going to talk about in-your-face, do-as-I-do, on-the-job, get-them-writing-production-code-four-weeks-out-of-school training. It’s the type that makes people clamor to work at your company, and requires a whole heck of a lot more effort than the fifteen hundred bucks to send someone to a week in a hotel conference room.”

Read the complete article here.

[ Bookmark the article with del.icio.us (What is del.icio.us?) ]
[ Submit to Slashdot ]

Software Training Sucks: Why We Need to Roll it Back 1,000 Years

This article is about training, but not the typical “pay $1500 to sit in a stuffy hotel conference room for five days while some guy who hasn’t written software since Elvis reads his PowerPoint slides to you in an effort to keep you awake” training.

We’re going to talk about in-your-face, do-as-I-do, on-the-job, get-them-writing-production-code-four-weeks-out-of-school training. It’s the type that makes people clamor to work at your company, and requires a whole heck of a lot more effort than the fifteen hundred bucks to send someone to a week in a hotel conference room.

Every company that writes software needs to make training a top priority. Say that with me: every company that writes software needs to make training a top priority. Why? If word gets around that your company has a killer training program you’ll be beating candidates away with sticks (at least until the first lawsuit), it boosts your bottom line by making programmers better equipped to do their jobs, and gives people a sense that the company cares about their long term success, making them less likely to leave. As a nice side effect, learning new skills makes people more satisfied with their jobs.

So to review, well-executed training attracts developers, retains developers, and makes them happy. Say it one more time: every company that writes software needs to make training a top priority.
Great Wall of China
Developer Traits
Before we delve into the structure of an effective training program, let’s talk about the specific areas we can hope to improve. The two fundamental traits of a developer are: knowledge of theory and experience.

Theory is what we learn in school: little-o and big-O notation, finite state machines, 3rd normal form, etc… Theory is easy to discuss, but difficult to experience since it’s like a wispy cloud floating around in someone’s mind.

Most developers learn theory in school on the road to obtaining their degree in Computer Science or a related field. Many learn it from books, magazines, and developer websites. Theory is things like object-oriented concepts, database design and normalization, and many aspects of software architecture.

Someone who knows a lot of theory and has a little experience tends to sound more knowledgeable than they are. Their mind is mature in the ways of software, but their code is juvenile by comparison. It tends to be over-designed, overly complex, brittle, and lacking in practical areas such as error handling.

Until you’ve debugged an application that lacks error handling it doesn’t occur to most people that storing this information might be helpful. That’s where experience comes in.

Experience is about making mistakes. When you study theory there are no mistakes: code is bug-free, APIs are perfect, and operating systems never, ever crash. That’s why there’s no “blue screen” shape in UML.

For a programmer, the more mistakes you make the better you are at writing code. I’ve made mistakes on every project I’ve ever developed, and each mistake added one more notch to my belt. Experience can only be gained through sitting down and writing code; there are no exceptions.

Someone with a lot of experience and a little theory tends to write code that runs well but is difficult to maintain and extend. Since the point of software design (which relies heavily on theory) is to organize a complicated system into something extensible and easily-understood, a solution lacking in design tends to want in these two areas. The larger the system, the worse the problem becomes.

It’s a sad day when I cringe at the word “apprentice.” Let me say this up front: I’m not referring to Donald Trump’s TV show. Before the show became popular, “apprentice” described someone who works under the oversight of a mentor. Apprenticeship is about learning while doing.
Costa Rican Volcano
Apprenticeship was born in the 14th century, and with it came a revolution. Suddenly young men and women could trade their most abundant asset, time, for a truly scarce resource, training. Skilled tradesman, including blacksmiths, cobblers and silk weavers, mentored young men and women with the promise that they might one day take over the business, while in exchange the tradesman lowered their labor costs by having low-cost apprentices on staff.

Apprentices were young men or women, typically 14 to 21. They didn’t make much money, but they learned their trades on the job. A blacksmith apprentice, for instance, learned about building super-hot fires, combining different metals to create mixtures with varying melting points, and how much work it takes to make a rake, a knife, or a plow. Most of it was not something they could learn from in school; they needed years of first-hand experience in order to master the trade.

Fast-forward 700 years and apprenticeship has disappeared. No, wait a minute…it hasn’t disappeared. This ancient tradition still appears everywhere you look, from construction to medical school to priesthood. So why is it that this model, which has certainly passed the test of time, is rarely present in the world of software development?

Is it because you learn software development better from books rather than from doing? Nope.

Is it because programming is a solitary trade, while running electrical wire requires a team of people? Wrong again.

How about the ol’ “physical trade versus thinking trade” argument? Not that one, either.

The only reason I can come up with is that computer programming is a new trade, only coming of age in the last 40 or 50 years, while the others: doctors, priests, construction workers, have all been around for thousands of years. And even though they’ve adapted over time, they remain steeped in the rich tradition of apprenticeship; a tradition that computer programming, a wee lad by comparison, has yet to accept.

Some would argue that apprenticeship is present in software development, and I have to agree to some point. I’ve learned a ton from the experienced developers and architects I’ve worked with (thanks Rick, Jeremy, and Calvin), but it’s always been on an informal basis, through osmosis, and only because they were willing to teach and I was willing to learn. From management’s perspective, my mentoring has typically consisted of: “You know .NET? Here’s a spec; build it.” That’s what needs to change.

There is a better way.
Ghana Cannon
Training Done Right
You can probably guess where this is headed by now, so let me cut to the chase: the better way to train is through software apprenticeship. All you need are a senior and a junior developer. Ask if they’d like to participate in an apprenticeship relationship. The junior gets training, the senior gets to pass along his knowledge (most people are flattered if you ask them to be a mentor). The key here is to make a deliberate choice to pair two developers together and get their buy-in. No buy-in, no apprenticeship.

What should their interaction consist of?

Use the time-tested approach of trades that have been doing it for years. Let’s take an electrical apprenticeship as an example: in the United States today, the International Brotherhood of Electrical Workers (I.B.E.W.) trains thousands of electricians every year. They learn through two distinct experiences:

  1. Attending night school during the week to learn the theory of electricity.
  2. Working days on a construction site where they’re able to gain experience applying the theory to the hands-on construction of a building

His first day on the job an apprentice is paired up with a journeyman (an experienced electrician), who shows him the ropes. The journeyman typically talks the apprentice through a task, demonstrates the task, has the apprentice perform the task, then gives feedback. Listen, watch, do, review.

With software it looks like this: the mentor evaluates the task at hand, be it writing data access code or building a web-based user interface, and holds a white-board discussion with the apprentice (listen). Next, the mentor might write sample code demonstrating a particularly difficult or confusing concept (watch). At this point the mentor sends the mentee off to gain their own experience writing code (do). And finally, the mentor should review the code, providing positive and negative feedback and suggesting improvements (review). Listen, watch, do, review.

A final note: the key to any type of apprenticeship is the “do” step. Most software training gives you the listen and watch, but the “do and review” is what inspires growth and advances skills. The beauty of apprenticeship is that it tackles theory and experience in one fell swoop. And it’s easier than you think.

The Bottom Line
Training is critical to any company that writes software, and apprenticeship is the best way to bring new developers on board, make them feel at home, improve their skills, and keep them happy and growing. You’ll keep experienced developers in touch with new approaches, compliment them by asking them to share their wealth of knowledge, and hopefully create a few friendships along the way.

Photos by Sherry


I was recently contacted by a company in the UK offering a real software apprenticeship program. Details are below:

e-skills UK (an industry body for IT skills) is piloting a Software & Web Developer Apprenticeship in the UK, working with Microsoft and QA (a training company). Ten IT companies of all different shapes and sizes will be recruiting 20 apprentices, who will receive a 12 month structured apprenticeship programme. This starts with a 4 week programming boot camp, with 5 further weeks of technical training, on topics such as Data Modelling and Software Testing and, dotted throughout the year.

The key is that the apprentices will be working for the rest of the time, learning their trade as developers from the technical mentors in their companies, but also being productive employees. The pilot will be focusing on C# and the.NET framework, and the apprentices will be aged between 16 and 20, using this as an alternative route to going straight to college/university.

To get in touch, email ben.sweetman@e-skills.com or follow him on twitter @bensweetman.

Top 10 Free Tools for .NET Developers

Richard Slade recently put together a compelling list of the Top 10 Free .NET Development Tools.

Top Five Red Flags of Software Development

37Signals is a small software firm based in Chicago with over 100,000 users of their four web-based applications. With their mantra of simplicity and downright infectious design, they’ve become an example for small software companies on how to set yourself apart from your competition.

Their blog, Signal vs. Noise, is read daily by over 10,000 readers (I’m one of them), and they recently put together a somewhat insightful list of the Top 5 Red Flags of Software Development.

Although I wouldn’t necessarily agree these are the top 5, they are certainly common and dangerous.

Volunteer Call for IT Workers

An international development charity is looking for computer-literate teachers to volunteer their skills (link). From the article:

“Usually those who can teach skills such as reading and writing are in demand by the Voluntary Services Overseas (VSO)…’We would like them to be able to share their skills and train other teachers…Instead of sending people out to Africa willy nilly, we are responding to a request from the minister of education out in Tanzania.'”

If you’re interested in offering your expertise you can contact them here.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Submit to Slashdot ]