I am a massive fan of Steve Krug’s “a common sense to web usability” book called “Don’t make me think” and want to write a book that fills the same gap for developers.

Right now the books available for developers are very technology centric and make you learn a lot about a certain job but nothing about how your delivery meshes with the rest of the team. This makes developers a needed asset but nothing that people listen to a lot when it comes to architecture or future progression. Those books sell well and make us feel good as we have improved our technical skills. However as human beings and professional employees we need to break out and get access to calling the shots where our expertise is needed. Our own navel-gazing and non-interest in matters outside our remit prevents that.

Over my career as a developer I found that most improvements of products don’t happen because of top-down decisions but because of geeks on the ground putting things in that will make their lives easier in the future changes that will inevitably come. Our work environment changes constantly and the only way to really build products that are good for us and the people we want to reach is by doing things right the first time and not un-do what we’ve done beforehand or tack extras on in a second step.

I want this book to be a helper to read through in a short period of time before starting a new job or project. I don’t want to give truths or examples that are outdated by the time the book is out but instead want to make developers aware of the power that they have if they work smart instead of delivering only what is needed.

Proposed book outline

1) One of your best assets is your laziness

This chapter will talk about being cleverly lazy – working in the right way upfront to make sure your workload will become less and less the longer the product will be under way. It will cover using the right tools, finding the right resources and organizing your time the way you feel most comfortable and become the most effective.

2) Don’t build for yourself but for those taking over from you

This chapter is all about clever developers aiming for making themselves redundant to the process over time. As a clever developer you want to improve and deliver demanding products and not get stuck in doing the same work over and over again and get stuck in maintenance of products you don’t feel enthusiastic about any longer.

3) Clever recycling is the key

One of the biggest obstacles you find as a developer is to fight your urge to deliver everything yourself. This keeps us from improving as a professional group. All of us have a clever idea to contribute but instead of merging them and finding consensus we all take our small idea and blow it up and stick some feathers on it to make it appear as the best thing since sliced bread. This chapter will talk about how using and building on top of existing solutions will make you a better developer and profit your profession as a whole making it easier to earn more money in the future.

4) Build what is needed and keep it modular

As developers we tend to think in finished products, not in smaller, re-usable components. When we develop something we are very much inclined to put in feature after feature and considering edge cases instead of delivering a solid foundation and add edge-case extensions when and if they are needed. The danger with this is that we deliver products over and over again that over-deliver on the feature front but lack the one single feature an implementer needs – the basics are not covered. This chapter will explain how to avoid this.

5) Aim for excellence

One thing that makes us stop progressing is that over time people are so disillusioned about what they can achieve in a professional environment that “making things work” is the main goal. This is terrible and the only way out is to challenge ourselves to deliver the best product out there and aim for excellence. Only if we challenge both ourselves and the people we work with we’ll be able to deliver products that change people’s lives. This includes planning bigger from the beginning. A product that is built with bad accessibility and no internationalization options might as well not be built.

6) Your product is defined by your users

This is a very important chapter for me and overlaps a bit with the feature-fetish of the previous chapter. The main ingredient of a successful product is how it fares with the audience it is intended for. Our users – regardless of ability, location or sophistication are what make and break our products. We need to know who uses our product and how they want it to work. A great example is Twitter. The use of Twitter has changed massively since its conception and its success is largely based in looking at its users and enabling them to do things they want to do.

7) Your biggest challenge is communication

This chapter will deal with how you communicate best with others, how you get seen, heard and listened to in a world as disconnected as IT is right now. Developers are considered the doers, implementers, not the ones with the overall plan. As developers however we feel exactly the other way around and many a time find ourselves saying that if we had had the chance to stop a decision before it happened the product we build would be much better. There is truth to that, but also a lot of prejudice. The right communication is built on consensus and knowing the deliveries of each of the people involved in the product.

8) Your biggest weapon is enthusiasm

The main point about being a good developer is being enthusiastic about what you do. If you build something you have no connection to you won’t be delivering an excellent job – no matter what you do. Enthusiasm is one of the most contagious things on the planet – if you do it right. This chapter gives you ideas and explains ways how I got myself enthusiastic about products even when on first glance they looked like a drag to do.

This is the main idea for the outline. I am planning to write a small book that can be handed over to new developers, heads of department and consulted at the beginning of a new project.

Delivery considerations

I have a few publishers interested and I am thinking about the format right now. One crazy idea I am having – and considering my very full agenda this year is a very good idea is to deliver the chapters as a series of talks and write the chapters as a follow-up after feedback from the audience. These talks could become part of a download package with the book.

What do you think?

Lately a lot of bloggers have started venting their frustration on IE6 - Robert Nyman got the ball rollling, Roger Johannson enforced the argument and now Ara Pehlivanian chimes in. The general consensus is that people should stop making things work pixel-perfect for IE6 at the cost of delaying projects or adding cruft to the code. This brings on fond memories of Jeffrey Zeldman’s To Hell With Bad Browsers and WaSP’s browser upgrade campaign which was great (although I always considered the javelin thrower a bit creepy) but like then it makes you wonder who we are talking to with these campaigns.

As I pointed out in my comment on Ara’s post I thoroughly support the sentiment but consider it misguided:

As much as I would love to see IE6 being taken out into the garden and beaten by kids with sticks before being set on fire, I’d say there is a lot of fallacy in the argument that we as web developers have much say in the matter. Of course users have the choice to use any other browser, but the sad fact is that IE6 prevails in environments where users don’t have the option to upgrade their browser as IT defines what software is on the computer. These are the same companies that block Facebook and Flickr as it distracts people from “doing real work”.

The “good enough” syndrome

Actually this to me is a symptom of a bigger cause, one that I call the “good enough” syndrome. That’s the thing that keeps us from improving a lot of working environments: people are happy to use a half-baked solution that doesn’t require any additional work instead of keeping their setup up-to-date.

Not everybody is as enthusiastic about IT as we are and in most cases computers are a tool to reach a goal. That is the same for us but in a lot of cases the users simply don’t want to be bored with details. Instead they just want to use the damn thing.

It doesn’t matter how convoluted and braindead a process to get where they need to get is – once learned, this is the way to go and it is easy to repeat this every time it has to be done. Learning an easier way or trying out a different technology is extra work and seems superfluous – the time for the braindead task is already allocated and there is no point in shifting the interaction with that computer thing around.

Paper trail conditioning

You get the same happenings in companies and when it comes to paperwork. A lot of steps in internal processes or in ordering forms are completely redundant – ludicrous even. But as they are the way that things have to be done and questioning them means more work and “rocking the boat” we stick to them. There must be a reason for them, after all, right? We don’t work with idiots, there must be some good reason for all these redundant steps. We could ask for those reasons but that is too much work – after all we need this time to follow all these steps that have to be done, right?

Keeping the saw blunt – computers don’t evolve, right?

As computers are magical and too hard to understand there is also not much sense in questioning the status quo: whatever they use at work must be the best thing there is as we work with professionals. As geeks we like to push the boundaries of our toys and use them for all kind of cool things. Most of all we like to tinker with the toy itself which gets us far too close to the subject matter. A lot of of other users out there however see it as a tool to either get work done or to be entertained.

My favourite example is my brother: he wanted a computer to do some graphical work, to write reports for his job and to play games. Having these three tasks of course he needed a Windows machine as all his colleagues had one and can lend him games to try out. He also spends most of his time trying out new virus scanning tools and firewalls as all his colleagues tell him about all the evil viruses out there. Last time I checked his machine there were 3 virus scanners and 2 firewalls running and he wondered why the computer is so slow and why he needed yet another video card to run a new game. I bought him a Wii and introduced him to Macs and Linux, but that’s not on as the latter two don’t run games and there is no Word for it.

All in all the setup is “good enough” as he is not a professional and it allows him to do what he wants to do. That there are easier and better ways out there is neither here nor there, it took long enough to get the hang of it and other things will be harder to learn, after all everybody uses this setup and is protected by Virus scanners – it has to be the right one. That many people cannot be wrong.

The good enough syndrome manifests itself in a milder form of Stockholm Syndrome where people start defending the terrible solutions and complex processes with claws and teeth instead of keeping an open mind and trying out something new. Want an example in our world? Table layouts vs. CSS layouts :)