All posts filed under “books

No more computing books

One of my bad habits is constantly buying computing books. This wouldn’t be so bad if I read them, but I have amassed a huge backlog of books that will most probably never be read and which ends up being a waste of money.

A couple of posts I read recently have led me to the decision that I should stop, or at least drastically cut down on, buying computing books. The first post talked about “learning voyerism” where you are really more interested in the idea of learning new things instead of learning the thing itself and the second talked about spending time going deeper into topics instead of boucing lightly through many different ones.

It is very difficult to stay focused on one thing when there are so many things happening in the world of computing all the time. There are a tonne of new and exciting languages and frameworks being released all the time. And while it would be great to try them all, that can only mean that you’ll never actually become good at one of them.

I have always been a bit of a generalist and while knowing a bit about everything isn’t a bad thing, there is a fine line between knowing a bit of everything while being proficient at some things and knowing not quite enough of everything to be unable to do anything at all.

Ikigai

A shot in the dark is definitely better than walking away from the chance altogether. Trying can create a percentage chance above zero, whereas walking away guarantees that it is zero.

I always enjoy reading Sebastian Marshall’s blog. Primarily because I feel like I can relate to a lot of the things he talks about and his general attitude towards life and business. His book is a great culmination of those things. I thoroughly recommended checking out his book and blog.

The Lean Startup

I finally finished reading The Lean Startup. The main gist is that we need to be creating fast feedback loops for products/changes we make, so that we can quickly see what is and isn’t working. It’s a good extension of what to do once you have you minimum-viable product up and running, as it’s easy to fall into the trap of just adding features, without actually adding any value. I especially liked the parts on doing a cohort study of your users. Instead of measuring figures like engagement as a total for a specific time, you would track engagement for people who signed up in January only, then sign ups in February, then March, etc. This gives you a better picture of whether you’re actually improving your service or only appearing to improve because of growing figures.

Overall the book wasn’t too bad. I felt that perhaps the first half was a lot more “actionable” and my interest fell off once past the half way point, so I ended up just steaming through after that. Definitely worth reading if you’re in the startup arena though.

I’ll be getting another copy soon anyways as I’ll be seeing Eric talk when he comes to London in January.

How to Get Control of Your Time and Your Life

Former U.S. President Bill Clinton, who started his autobiography, My Life, with a reference to the book: When I was a young man just out of law school and eager to get on with my life, on a whim I briefly put aside my reading preference for fiction and history and bought one of those how-to books: How to Get Control of Your Time and Your Life, by Alan Lakein. The book’s main point was the necessity of listing short-, medium-, and long-term life goals, then categorizing them in order of their importance, with the A group being the most important, the B group next, and the C the last, then listing under each goal specific activities designed to achieve them.

The message is simple. List what you need to do and prioritise it. While that is the core message of the book, it also covers what to do in various situations. What to do when you perhaps feel like you don’t have enough time to complete an A task, or find yourself procrastinating but always doing B or C tasks instead of the more important A ones. The main thing I took away from the book though was to always ask yourself, “What is the most important thing I could be doing right now?”. It’s surprising how asking such a simple question of yourself can have such a huge impact on what it is you actually spend your time doing.

Prioritizing Web Usability Notes

Here are my most important extracts from Jakob Nielsen’s “Prioritizing Web Usability”. I have all my notes typed up. Just drop me a line if you want them all.

Users spend 25-35s on a homepage. Even with an avarage reading speed of 200-300 WPM, this only leaves enough time for about twenty words to be read.

Five biggest causes of user failure:
1. Searching
2. Information Architecture
3. Content
4. Production Information
5. Workflow.

Page design is more of an annoyance then a direct cause of failure for sites.

Don’t defend your interface, fix it!

Before adding design elements, ask yourself:
1. Does this element simplify the user’s task?
2. Does this element add value to the user?

Design for your users. Not for what you or your manager likes. The key to creating a good experience for your user is creating something with them in mind.

It’s an Improvement Adventure

It’s amazing how easy it is to be a programmer/developer/code monkey without having to do it properly. I got my first programming job when I was 17, a whole ten years ago, and now after recently reading Clean Code and Refactoring to Patterns, I can’t help but wonder what the hell I’ve been doing all this time. I’ve been writing code, but I sure as hell haven’t been programming. Looking at the code I’ve written as recently as only a few weeks ago now makes me cringe. “Why am I calling this method here?”, “What the hell is this comment?”, “Is this a joke?!?”.

I took a job as a developer for a mobile phone voicemail to email provider four years ago. I was only there for a few months but I still feel like I learnt more about programming while there then I had previously and ever have done since. I’m a firm believer in the notion that you’re only ever as good as the people around you. If you come in at a lower level you’ll soon pick up the pace, and if you come in over those around you, you’ll soon slow down to match your co-workers. As always there are exceptional circumstances. Sometimes if you’re too low, you’ll never be able to perform to the same standard, and if you’re too high, you probably won’t stick around long enough to get bogged down. I’m in a bit of a unique situation in my present role, because I work in pretty much complete isolation from other developers. Which means I have to set my own benchmark. I remember when I started, I was still so full of energy from my previous job (the one mentioned above) that I wrote some pretty cool code, which even impresses me when I look at it four years on. But as time went by I became more and more rusty and the quality of my code decreased dramatically. I stopped reading computing books altogether and took more of an interest in general business subjects. I took an interest again when Rails came on the scene, but none of the coolness or wow factor of doing Ruby could be applied to my day job doing Java, so that area of my life still continued to dwindle. The discovery of Grails changed that to a large degree, but by then I had lost the sparkle for Rails and my code became the same mess, just in a different language. I constantly think to myself that there has to be a better way. Rails and Grails felt like an answer to a certain degree, but the same underlying issues of design and brittleness remained. While features were quick to implement, changes were slow and painful to make. Simple requests became complicated hacks built upon other hacks to fill in holes left by other feature requests. Rails and Grails, while eye openers and moral boosters, didn’t solve my problems.

I was naive and blamed the language, the framework or the previous developer for my issues. I felt that my designs were sound and the code of a high standard. It “felt” tidy and the functionality all there, neatly sectioned off into different places. But Clean Code and Refactoring to Patterns showed me how wrong I had been. Regardless of the language or the framework, without well designed, robust and agile coding practices, you eventually hit a very hard brick wall. To say they were an eye opener is an understatement. It felt more like a programming re-birth. In hindsight, all the signs of bad code were there, I had just become totally blind to it.

Not very long after reading both books, I tasked with making some changes to an old legacy Java system. In the past I had absolutely detested working on it. Everything felt like a mess and that the slightest change would bring the whole system to its knees. But I felt confident this time. I started writing tests, which I had never done before, and started using the absolutely brilliant refactoring capabilities of IntelliJ. I spent a lot of time refactoring code so that the new functionality existed, wrapped up, in a state that it should, rather then in a shoehorned/hacked state. No doubt it too me longer then if I’d just shoved it in, but the system became better as a whole for it. The long reach of the masses of refactorings I performed have left parts in a greatly improved state. Perhaps in some cases, with added complexity – a small price to pay for better testability, design and extensibility. I would rather have an added degree of complexity over a brittle design any time

Anyone can knock out code, anyone can cut-and-paste a system together if they tried hard enough, but writing code alone is a solution to a small fraction of the overall problem. Anyone can churn out new features for a v1 release, but what about v1.1 or v2 or v3. As developers we dig our own graves. Clients don’t understand why things used to happen so fast, but now it’s sometimes weeks before anything new is ever shown. Fast – Slow – Slower.

This is where good, clean code starts to come into it’s own. Code that’s light on it’s feet. Code that’s easy to move in and out. Code that isn’t a brick wall and requires you to code around. Good design and good coding practices are at the heart of delivering a robust solution. If you are a developer you need to read the books I mentioned above, or at least just Clean Code. Heck, as a developer you need to read books. FULL STOP. I know many developers who don’t read at all, which to me is just unthinkable. You maybe one of the few that shrugs their shoulders after reading something like Clean Code and says “Yeah, I know all this already.”, and if so, good for you, but even you will probably know someone who could do with reading it, probably more then once ;)