My new book idea – “Don’t do it again”
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?
Tags: book, development, improvement, inspiration
March 16th, 2009 at 12:29 pm
Excellent idea. You should do a fancy title though. Like e.g. “Workflow patterns” or “Hackers’ guide to laziness” or similar ;)
March 16th, 2009 at 12:35 pm
I’d love to see one version for developers and a similar version for their project-manager, decision-makers, boss(es), etc., that provides the same information, but delivers it in an appropriate context for them; remind them how important their developers are and how to get the most out of them.
March 16th, 2009 at 12:45 pm
I do agree with a lot of your statements, because it is also important for Designers too (my personal background is multimedia), would be great to read this coming book. Chris, I think you could also try a special format to keep the content of the chapters visually in tiny pieces (paper format). I think, this would catch the audience’s attention much more in comparision to the wanted follow-up feedback.
March 16th, 2009 at 12:50 pm
There is very much a need for this book! I’m struggling to think of any books that cover documentation, and coding for future developers and features.
In my experience documentation, QA and future-proofing are part of the culture of an organisation so it might be worth looking at how you can change instances of this not working, or at least explicitly outline the benefits. That way a developer with a manager who wants it done quickly and poorly can explain why things should change. I’ve seen it very many times where a manager doesn’t understand the value of doing things properly so it just doesn’t happen, leading to frustration all round in the long run.
Are you going to cover an Agile development process at all? I don’t think anyone has really covered this either!
March 16th, 2009 at 1:06 pm
Or, howabout the title ‘If I could do it all over again I’d do it all over you’ ;)
Reference: http://en.wikipedia.org/wiki/If_I_Could_Do_It_All_Over_Again,_I%27d_Do_It_All_Over_You
March 16th, 2009 at 1:27 pm
The title feels a bit odd (not really encouraging and a bit too inspired by Steve’s book maybe) but the outline looks great, really good. Also, the delivery options appear a bit author-centric but definitely sound interesting.
So fingers crossed I’d say! Meanwhile I’ll think about whether or not I should unsubscribe from this site to protect the work on my next book ;)
March 16th, 2009 at 1:31 pm
Sounds like a good one, Chris. You don’t specifically mention any particular language…would there be example code, and if so, should I assume it would be in JS? (I’m thinking of your article here: http://is.gd/nxc8 )
March 16th, 2009 at 2:55 pm
I especially like the idea of making the talks available for download w/ purchase of the book.
March 16th, 2009 at 3:02 pm
I love the concept.
I’d like to see a mention of limits too.
Not everything is worth making generic and reusable. I once worked for weeks on a car configurator, which had been badly designed simply so that it could one day configure kitchens too – which no-one had asked for.
A car does not have two engines. And not everything is a reusable component.
Chapter three seems to cover this and more. Look forward to reading it.
March 16th, 2009 at 3:52 pm
Sounds great. I don’t know about the title, but it may work. The concept is sound, though.
March 16th, 2009 at 4:17 pm
I love the idea! As for giving the chapters as a series of talks first, I think it’s a great idea. I’ve noticed more and more musicians refining their new songs at concerts before recording them; I don’t see why an author can’t use the same technique.
March 16th, 2009 at 5:09 pm
Hi Chris
Yes, yes and yes. Almost all of the pain that I and my team suffer is because of failures in the above. And all the pain I suffer with developers comes when they’re not able to step away from pure coding and understand a wider context.
One thing to note though in the user chapter: where you’re building applications for internal corporate users. Of course, high usability is important, but you’re largely describing the situation where the users are consumers, and can choose whether to use your system – in effect, your users are your sponsors. In a corporate environment (say when developing a contact centre application), how your sponsors want it to work is also important, and if that’s not aligned with your users, then you have an interesting problem.
March 16th, 2009 at 7:00 pm
I am a developer. I would buy this book.
March 17th, 2009 at 12:47 pm
I’m afraid most of these points have been repeated a lot before (e.g. see “The Pragmatic Programmer” – Hunt • Thomas). That book does contain a lot of technical points too, though.
March 18th, 2009 at 7:18 am
Sounds awesome. I’d buy that.
March 24th, 2009 at 2:42 pm
Very good concept, and the coverage looks good. I’d agree with other comments that “don’t do it again” might not work as a title with all audiences. Suggest something like “A good coder is a lazy coder” or “never code twice”.