The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
How to adopt XP? Here’s how, from Extreme Programming Explained.
1. Pick your worst problem.2. Solve it the XP way.3. When it’s no longer your worst problem, repeat.
I think the above is not only for adopting XP, but a good way to solve any development process issue. It is a good way to improve your process.
Here’s how I think you can solve any process issue (a modified version of the above):
Where else can this be applicable? I think this is also a good way to work on your individual problems.
You are not going to fix anything right away, start making small, step-by-step changes and you will get there sooner than you think.
RelatedGood XP Practices, my recent entry
Don’t Make Me Think
by Steve Krug
ISBN 0321344758
Date Read 3/2006
My Rating
This is a required reading for UI designers, web developers, and very useful for web users. That covers almost anybody, right? Written in a style that is accessible to anybody, so why not? Anywhere you fit in that group, you will benefit.
Think about yourself as a web user. When you visit a new site, what happens? Do you spend a lot of time figuring out where everything is, or do you quickly scan it then if you find you’re looking for, you click on it. I certainly follow the latter. And I’ve gotten frustrated a lot of times when a site is making it hard for me to see where I am, what the site is all about. I give up a lot of times. But I know, now, because of the book, that the site is badly designed. On the other hand, I appreciate the sites that just seem right instantly.
This book is very valuable. I learned how users browse (they scan). I learned what users don’t like (they don’t like fancy stuff). I learned what users like (standard, intuitive interfaces). I became a better user because I see this when I browse. I became a better developer, because I know that users don’t think and I try to make it as easy as possible for them. I think about that when I design an interface.
This is an excellent book. It is a quick read (you can even read it in a bookstore in one or two sittings). I bought the second edition, but it doesn’t differer too much from the first. This is the best, most intutive, and the shortest book on UI I’ve read.
Surviving Object-Oriented Projects
by Alistair Cockburn
ISBN 0201498340
Date Read 2/2006
My Rating
It is a decent book, and the author has a good writing style, but I think this book is more geared towards project managers than software developers. I enjoyed it, it was a quick read, but never really “got into it.”
I am a software developer because that’s what I like to do, and because I think I’m decent at it. But I’m affected by the happenings in the software industry. Last couple of years, the news had been all negative. Recently, however, the tide has turned: I’ve been hearing a lot positive news. Companies are hiring again. It’s a joy to read an article like the following, Study says U.S. tech hiring grows.
the number of U.S.-based technology workers is higher today than it was at the peak of the Internet boom. Not only that, but also the U.S. tech sector is expected to post positive job gains for at least the next decade.
ReferenceStudy says U.S. tech hiring grows, CNN/Money article
Extreme Programming has been around for years now. From what I hear, it has been successful. I like the process, but I don’t think I could withstand all of the practices on a continual basis. Having to pair program on a continual basis is just a pain (bathroom, personal calls, taking breaks, etc). I think it could be done at times, for instance, fixing a critical issue, but on a day to day basis, I dont’ think I would be able to do it.
Here are the practices of XP, taken from Extreme Programming Explained book, which I’m currently reading.
Based on these practices, I think a good agile process should have the following practices (from the XP process).
All in all, XP brought a lot of good practices to the development world. It was, and still is, a disruptive force. And that’s a good thing. Whatever your process is, make sure it is agile, and exposes problems early.
|
[Programming] There is no such thing as straight and level. Even if things seem to be going perfectly, you don’t take your eyes off the road. Change is the only constant. Always be prepared to move a little this way, a little that way. Sometimes maybe you have to move in a completely different direction. That’s life as a programmer.
Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes.
–Kent Beck
in Extreme Programming Explained |
JUnit in Action
by Ted Husted, Vincent Massol
ISBN 1930110995
Date Read 2/2006
My Rating
This is a very good JUnit book, and a good programming book. There were a lot of things I liked, and some things I did not.
What I liked. This is the best JUnit book out there. It contains a lot of good advice. The author explains a lot of the best practices that every developer should be following. That’s good stuff. It is a very well written, easy to read. The examples in the book are very good as well.
What I think is missing. This is a comprehensive JUnit book. And it covers most of the topics that will be of interst to a tester. However, it does not cover HttpUnit (not that I would use it, but still). Plus, its coverage of Mock objects could be improved. This is a very important topic that should have its own chapter and be clearly explained. The book contains pieces of it, but not enough for me.
If you’re looking for a JUnit book, this is the book for you. (I want to get JUnit Recepies, but the book just looks and feels too big.)
Becoming a Technical Leader
by Gerald M. Weinberg
ISBN 0932633021
Date Read 1/2006
My Rating
Even though I’m not the prime target of this book, I really liked it. Weinberg explains the different leadership styles with good detail, and with a pragmatic style. I learned a lot of what a good leader should be. This book made me better, as well. I started writing a 5-minute a day journal. I’m enjoying doing it. It helps me to learn of who I am, and what I want to become.
But who is the prime target of this book? I would say that if you have been managing a group of people, this is a must read for you. I am not a manager, but I would like to become one eventually, and this was a good book for me (not required, though). You would benefit the most from this book if you have had some experience leading. I plan to re-read it down the road.
If you’re trying to learn CSS, or if you want a good reference, like me, CssBasics.com looks very good. It is a tutorial that is simple, well laid out, and has a very good rating on digg.com. Check it out.
I came across a list of Five books every Java developer must own by Rob Sanheim. I commented on the list. But the list got me thinking. What are the books that I consider the “must have” books? Today’s Javalobby newsletter just added to the fire. I had to create the list. So here it is.
1) Effective Java, Joshua Bloch
A lot of people just code in Java, without being aware of the implications. This book clears out those implications.
2) Code Complete 2, Steve McConnell
This book will make you a better programmer. Enough said. My favorite.
3) Refactoring, Martin Fowler
It is getting a little old, but it contains invaluable information on good design, code smells, and more.
4) Design Patterns, GoF
The best book on patterns, though not an easy one. Might want to get the Head First Design Patterns to help you.
5) Core J2EE Patterns, Deepak Alur, Dan Malks, John Crupi
You have to know GoF patterns if you call yourself a good programmer. You have to know Core J2EE patterns if you want to be a good Java programmer.
6) Agile Software Development: Principles, Patterns, and Practices, Robert Martin
Not an easy book, but a best book on Agile, good Object Oriented programming, and patterns.
7) Applying UML and Patterns, Craig Larman
Java is an Object Oriented language, but a lot of people still treat classes as data structures. Learn what an object, and OO programming is all about.
8) Pragmatic Programmer, Andrew Hunt, David Thomas
Contains sound practices, good advice. It will make you a better programmer.
9) Facts and Fallacies of Software Engineering, Bob Glass
See what works in software engineering, and what doesn’t. Bob Glass explains it best.
10) Don’t Make Me Think, Steve Krug
A great little book, great when you’re involved in UI.
Wait List
I have not read these, and that’s why I have not put them in my original list, but the books below should be on your must-read list.
Peopleware, Tom Demarco, Timothy Lister
Domain Driven Design, Eric Evans
The Timeless Way of Building, Christopher Alexander
Patterns of Enterprise Application Architecture, Martin Fowler
Reference
Five books every Java developer must own, Panasonic Youth blog
Javalobby discussion, my list on the bottomJavalobby Newsletter: archives (great newsletter, btw)
