Great Books for Becoming a Better Developer

You want to become an even better developer? Then you must read these books. If you have already read them. Read them again.

Design Patterns. Elements of Reusable Object-Oriented Software: This is the standard book on patterns and patterns are an extremely important piece of vocabulary for every developer. Not to impress coworkers with your knowledge, but to be able to think about bigger concepts than loops and conditionals. It describes each pattern with its purpose, it’s applicability and an example. Make sure to read a couple of blog posts about each pattern, to make sure you avoid some of the more common mistakes when applying them.

Clean Code: A Handbook of Agile Software Craftsmanship: You want to be proud of your code? You want to be able to go back to your code in a year without swearing? This is the book for you. The author Robert C. Martin (also known as Uncle Bob) is extremely aggressive on what he is accepting as clean. This book really changed the way I look at code, and of course the way I write code. Make sure to really understand the lengthy examples. It is tedious, but it pays.

The Pragmatic Programmer. From Journeyman to Master: In Software Development the professionals often follow practices which the professionals them selfs aren’t aware of. This book lists and explains many of these practices as well as some obvious once. While this sounds trivial the resulting book is a great source of small and big practices to acquire as a habit.

For the German readers of my blog: Read the english originals. German translations of computer books are horrible on average.

Posted in: Softwaredevelopment by Jens Schauder 4 Comments

My Study Technique

A couple of days ago my wife asked me: “How do you learn.” She is really great at this kind of question, which doesn’t seem to have an answer. At least I had no idea how I actually was learning. But my impression is that I am learning reasonably well. On the other hand, learning is something I’d be glad to improve on. So I started up my browser and searched a little about Study Techniques. Disappointingly most stuff I found was about memorizing stuff. I don’t know about you, but I don’t do that. I write stuff down. Instead of filling my head with phone numbers and dates of birth, I try to understand concepts. You know what, I think this is my first study technique:

Don’t memorize, understand: Memorizing stuff is hard and mostly useless, when you actually want to apply your knowledge. Of course understanding stuff isn’t much easier, but it uses much less brain capacity once done, and you can apply your knowledge in new areas as well. So the question is: how do you achieve understanding? Here are my recommendations:

Modify: When you read or hear something, think about what might happen if you change it a little. Let’s say you are learning a programming language, e.g. Java. One of the first things you’ll get taught is how to write a hello world program. Take that program and apply small changes: Add a semicolon on various places; Remove a semicolon; Change names and literals; Change the order of lines and so on. Most of these changes will result in a compilation failure. That’s great, because now you experience, what kind of mistakes cause which kind of exception. For example you will see that a program needs a main method and you’ll see what the exception looks like, when there is no such method.

Compare: Compare the stuff you are learning with stuff you already know. This is extremely important. If you have nothing to compare with, all you can do is memorizing. This becomes extremely obvious, when kindergarten kids ask questions about quantum mechanics or software development. For example my son asked me what all these curly braces are for when programming. Trust me, that’s hard to explain to a five year old. On the other hand when I learned C, I already knew among others Pascal, so I immediately thought: ‘Ok, curly braces are like begin/end, just shorter’. Often it helps to compare to something, even though the comparison falls apart when looking close enough. Consider for example  the various analogies for software development. In the end they are all wrong, but still they are helpful, especially once you understand which parts of a comparison work and which don’t

Build a mental model: Chances are when learning something new, you won’t understand every detail. Still build a model about what is going on, and about the purpose of different pieces.

Verify (or falsify) your model: By experimentation, try to verify your model. This will force you to modify your model, until you will have a pretty decent one.

Teach your new knowledge: When preparing a training, a presentation or a blog post about something, it forces you to really think  through it, thus deepening your understanding.

Practice: All the stuff should happen during actual experimentation, not just in your head.

The last four steps are all about what you do with knowledge heading your way. So the obvious next question is: “How do you direct knowledge your way?”

Read Books for in Depth Information: I  love the Internet, and you’ll find almost any information somewhere. But lot’s of it are just little pieces of wisdom (or stupidity) . The author of a good  book will put much more thought into his writing then the average blog author.

Read Alternative Sources: Once you have a basic understanding of something read additional sources, for example blogs, Wikipedia articles (possibly in different languages), other books, scientific publications. This serves as repetition, but also as a source of various opinion.

Reread your Sources: Especially with books I use little post-it index markers to mark interesting pieces and some time after I finished a book, I’ll use these markers to go through the interesting pieces again.

Provide yourself with a constant stream of information about the topic of interest: A good way for doing this is to subscribe to newsletters, or relevant blogs, or following relevant people on twitter. Of course paper based magazines work just as well. It will cause you to rethink the topic over and over again, thus triggering repetition.

Keep a list of things you don’t understand yet and work on reducing that list: When I hear a term which I don’t know, but which might be interesting for me, I put down a note and look it up on google, wikipedia, or whatever seems appropriate asap. Just as the two points before it is a form of repetition, but it also builds a network of different but related terms, which helps in building comparisons.

Stop reading when it doesn’t add value: This is a thing which I had problems with. Once I started a book, I had the habit of finishing it. Same for articles. This is stupid and a wast of time. There are so many great books, articles and sources of information out there. You won’t be able to read them all. So I consider it a critical thing to identify stuff that doesn’t add value for you and skip it. If that means skipping the rest of a 600 pages book after reading the table of content, that’s great. By the way: you absolutely should go through the table of content and the text on a back side of a book, in order to get an impression what the book is all about.

And finally there is the aspect of your environment, which largely affects your capability of learning.

Motivate yourself: Why do little boys know so much about dinosaurs, often including all the difficult names? Yet grown ups have a hard time distinguishing a Brontosaurus from a Pteranodon. They find dinosaurs cool. They are big, they are strong, and the boys soon realize, they know more about them than their parents. That is pure motivation. So find out for yourself why you want to learn something. What will be better, easier or more fun in your life once you grappled that new knowledge? Promise yourself a little gift once you are done with a piece of your learning. For tiny steps the gift should be tiny. For me such a little gift often is a tweet, publishing my progress to the world.

Make yourself comfortable: Find a spot which you can easily access, and which offers everything you need for learning. This might include: Something to eat, to drink, music, a door to close, a comfy chair, a window with a nice view.

Use your knowledge: In my opinion nothing is so gratifying and motivating as applying new knowledge. And again, you’ll find the limits of your understanding, giving you a chance to push these limits outward.

Know your preferred time for learning: There are certain times in the day where I’m more able to do mentally challenging stuff. For me the best time is the early morning. Your mileage my vary, but I am pretty sure everybody has such a time and should know it.

So these are my study techniques. What are yours?

Posted in: The Rest by Jens Schauder 1 Comment ,

3 Books You Should Read When You Want to Go Agile

If you haven’t switched to an agile approach to software development yet, you probably should. But be warned. Agile is not about daily stand ups in the morning. It also isn’t about renaming your “work break down structure” into “backlog”. Going agile requires changes deep in the internals of your team and/or in your company, depending on the level on which you want to go agile. In my experience there is just no reasonable way to gain the required understanding of agile approaches from on-line resources alone. I recommend the following three books instead:

Agile Software Development with Scrum by Ken Schwaber: Obviously this book is about Scrum, which is just one of many agile processes. But even if you don’t want to go with Scrum, this book will teach you a lot about why Scrum is designed the way it is, and this will be very helpful, no matter what approach you choose. Be warned: the book is small, has crappy graphics and is rather expensive. But it is worth it’s money.

Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck: This book isn’t tied to any specific process or approach, instead it describes the underlying concepts, which are common to all agile approaches. And these are the ones that really count. Since the Poppendieck have a lot of experience in non software projects they provide lots of examples an cross references which might help convince a stubborn manager, who doesn’t realizes that doing waterfall software development might be 10years behind standards in software development, but is about 50 years behind when compared with other branches of industry.

Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo: Unfortunately you can’t buy the book yet. But I had the honor to review an early version of the book and provide Jurgen with my nit-picky comments. This book is very different from the other two, because it focuses completely on the management side of things. Agile doesn’t mean managers will go away, they don’t even become useless. Quite the different, they might actually put themselves to good use, and this books will tell you (or your boss) how. Even if you don’t go fully agile, this book will offer lots of advice and ideas, on how to improve you work as a manager.

Posted in: Softwaredevelopment by Jens Schauder 1 Comment ,