Books I read (2009, 2008)

Recently I was thinking about which book to read next and came up with idea to make a list of books I've read over the last two years to understand where I'm now, where I'm heading to and may be read some of them again.

I hope you can find something interesting in this list. (Books I considered not related to software development are excluded.)

2009

• [!!] Made to stick - why nobody remember company mission statement right after they hear it, but everyone know urban legends? It's a very practical book telling why it happens and how to make you ideas spread. The book of the year.
• [!] Refactor your wetware - great collection of ideas about how to improve and rewire your mind. Contains a lot of interesting references to other books. Can be a life-changing book!
• Don't make me think - web usability 101. Awesome reading. Nice pictures. I wish I had read this book years ago.
• Presentation Zen - make presentations like Steve Jobs :) It's real.
• Domain Driven Design - software design as it should be.
• Refactoring to patterns - the name says everything. Refactoring + patterns.
• Real World Haskell - hands-on book about Haskell. I haven't finished it though :(
• User stories applied - a guide how to use user stories in XP and Scrum.
• Manage it! - practical agile project management.
• The Humane Interface - interesting and sometimes surprising view on human interaction with computer interfaces.
• Developing Multi-agent Systems with JADE - makes sense to read only if you like multi-agents or use JADE.

2008

• [!!] My job went to India (was renamed to The Passionate Programmer) - very honest and realistic view on programming. Nothing about coding, only real-life pieces of advice. This is like The Pragmatic Programmer 2nd no-technology-edition. The book of the year.
• [!] Getting real - concise and opinionated book about web development and software development in general. It's awesome. It's free and available online in HTML format.
• Ruby Way - my favorite ruby cook-book. I still read it every now and then.
• Effective Java 2nd edition - a must-to-read book for every java developer. (Even if you've read 1st edition.)
• Implementation patterns - for me it's a bit unusual, but very interesting view on programming. Kent Beck can always take ordinary things and turn them around. This is Small Talk Best Practices rewritten for java.
• Analysis patterns - code is not the only thing you can reuse. Conceptual models might be more appropriate. Martin Fowler's first book. I'm a fan.
• Clean code - you should really care about your code. Agile Principles, Patterns, Practices was better, though.
• Release it! - real-life description how to create web applications which don't fail after going into production. (This book is focused on java.)
• Pragmatic SVN - concise and pragmatic guide to SVN.
• How to become a highly paid corporate programmer - controversial book. I didn't agree with a lot of things. That's why I kept reading.
• Scrum and XP from the trenches - real-life view on Scrum. Concise and easy to read. It's free to download from infoq.com.
• A Guide to the PMBOK - "old-school" ideas about management. Boring to read but very useful.
• Black swan - accept that there are unknowns you don't know about. Models we use to predict future will never really work. This is pragmatic nihilism.

Win + key shortcuts in IntelliJ

I always thought it’s not possible to assign Win + key shortcuts in IntelliJ. The reason was that if you press Win + key in shortcut editor, you see something like this:

It looks very much like IntelliJ cannot use this kind of shortcuts. Turns out it can!

The trick is to use Win button as a first key-stroke and key as a second one. Surprisingly enough it works when Win + key are pressed simultaneously.

(In the above picture I assign Win + S shortcut to split editor. I love left-handed shortcuts which easy to use :))

I’ve only tried in Windows XP. Would be nice if it also works in Vista and Windows 7.

Design Limits

"A lot" doesn't mean "good" even there is a lot of something good. You should know when to stop.

One of the worst thing I've ever done as a developer is over-designing. I've overdone many other things too, but over-designing is probably the number one. Like many other words the word "design" is overloaded. In software development world it usually means a structure of classes or the process of creating this structure. For example, Design Payoff (from Martin Fowler's Design Stamina Hypothesis) has always meant for me that "if you have a good structure, you will be able implement a lot of stuff; if you have no structure, you're out of luck". I can't say for sure whether this diagram implies "design" not only as structure but also as activity. Probably, the main point of it is just "payoff line". If you redraw this diagram in terms of "features per iteration", you will get something like this. From this diagram it's easy to see that the amount of features you can implement with "good design" is limited. This is kind of obvious thing which, probably, every developer knows very well from he's own experience. "Design" as the process of creating "design structure" comes to play every time you want to implement something which turns out to be cumbersome or very hard to do with current design. This is what I blame myself most of all. First off, it's the amount of time spent redesigning. I do not claim it to be true, but thinking about last several months for me the following dependency seems to close to reality. After a certain point the harder you try to "improve" design, the worst result you get. In other words, there is also a limit of much effort it's worth spending on design. The worst part of it is that determining how close you're to "masturbation point" is always a judgment call. Basically you don't know where you are on the curve. Even when you feel you've crossed the point, there is always temptation instead of Killing Your Darlings to continue in hope of getting some insight and turning things right. Spending more time redesigning something doesn't necessarily mean that design becomes more complicated. It can become simpler but less appropriate. It's also true that the time you spend designing is the time you could've spent adding new feature. The only good way I found to avoid this is to add feature with minimal changes and then consciously experiment with design ideas. Or just wait.

Going meta, this can be applied to other areas like code conventions, static code analysis or static dependencies rules.