Book read: The Productive Programmer

There was a long time since I read anything „classic” in software literature. Nowadays I entertain myself with more practical stuff and less methodology or best practices. So came the thought that it’d be nice to read something that wouldn’t become obsolete in five years.

I checked the recommended readings thread at stackoverflow but I already read a lot of them so I thought Amazon would be able to help me out. I wanted to read something like The Pragmatic Programmer so I checked which books were bought together with it. After some fiddling I found the book in the title, The Productive Programmer. I thought why not I’m in desperate need of productivity. I tend to set up The Ultimate Productivity Blog on every workstation I get to work with. As its name suggests, it’s one of the single best resources of productivity materials. Be sure to check it out.

Let’s talk about the book a little. It’s a short read, about two hundred pages. It is split into two parts, the first hundred pages is full with practical advices (called mechanics in the book), and the second half is more theoretical. I’d recommend quickly skimming trough the whole first part; since it’s full of tools pretty outdated by now (the book was published in 2008). The tools which stood the test of time are mostly for Java, so they weren’t very useful to me also, but if you’re a Java guy then they could come handy. The reason for not to skip it altogether is that there are some useful advices on how to eliminate distractions which are less specific to tools.

Cover art of The Productive ProgrammerThe second part is much more interesting and it contains new and fresh advice after a lot of books in the mentioned stackoverflow reading list. The topics include unit testing and test-driven development, best practices for designing classes and organizing code, and YAGNI has a whole chapter dedicated to it.

I particularly liked the chapter titled “Question Authority” there was a nice parallel on the behavior of monkeys and humans regarding authority. The gist of the experiment with monkeys was that the experimenters punished a certain natural behavior. Then they started replacing the conditioned monkeys with new ones, and watched the old ones punish the new ones to prevent the behavior in question. When all of the originally conditioned monkeys were replaced the monkeys still punished newcomers showing the bad behavior, although they themselves didn’t know the original cause. That’s a nice example of “that’s the way it’s done” attitude. And that’s an attitude which certainly prevents positive changes in any organization.

There’s a chapter about reading classic books on software which contains useful advices, and another which tries to introduce the concepts of the classical philosophers, although the examples weren’t that good there.

As a summary I’d definitely recommend the second half of this book. It’s an easy read and contains lots of useful advices. For the first part, I wouldn’t be so sure but it definitely won’t hurt to read that either.

Advertisements

Beginning Arduino

I was always fascinated by electronics. Both of my parents finished as electrical engineers, so the current flows in the family (pun intended). It’s certainly a wonder in itself that I ended up in social sciences but that’s another story.

My “freelance” contracts are about to end, and I grew tired working all days and nights, so pursuing new ones wasn’t an option. I decided that I need a new hobby. Of course it must be computer related, and it must involve building something physically. Creating mobile apps are certainly fun, but you get the hardware as given, can’t really stretch it (especially on the iOS platform). Long story short, I decided that tweaking microcontrollers and breadboards is the next thing I want to do in my spare time.

I checked the market and found some great tools. I was fascinated by Lego Mindstorms, especially by the sheer awesomeness of this Sudoku solver robot. But I didn’t want to spend that much money, so eventually I settled with Arduino. It seemed as a reasonable compromise: extensible beyond imagination, works with any standard electronic component (certainly avoiding vendor lock-in), free software and massive community support (not to mention it’s open source). And it is definitely cheaper than a Lego robot. I thought it would be nice for starting out. I ordered a starter kit and waited patiently. To ease the pain of waiting I got two books, Beginning Arduino and Electrical Engineering 101.

When the kit arrived I must confess that I was intimidated greatly.  Here’s a picture after identifying all parts:

Arduino Components
A bunch of electrical components crowded in a box intended to use with an Arduino microcontroller.

Plenty of stuff and completely incomprehensible for a total starter in electrical engineering like me. At this point comes the community support very handy. I googled all the components adding “arduino” in the beginning and started building what I saw in the results. It’s tremendously funny and you learn a lot about your gadgets (which ultimately use the same components only in a much more compact form).

Arduino certainly encourages experimenting. I have a great time sorting things out, how to connect them, and eventually make them work as I intended. Sure, you can’t be as careless as if you were sketching source code in a hobby project, where you just fix things up if it doesn’t compile. It’s pretty easy to fry circuits and equipment and this is a further entertaining factor (at least it is for me). You better understand what you are doing (and why you are doing it) in order to prevent damage which of course forces you to learn things.

I don’t really know if I’d publish some sample projects I did because I’m such a starter that I might do things terribly wrong, and I don’t want to be blamed for dead Arduinos. But should I build something awesome, I’d post it here for sure.

Book read: The Design of Everyday Things

Nowadays I’ve checked out the archives of Jeff Atwood’s Coding Horror blog, and found this highly recommended title. I remember a few years ago I read Don’t Make Me Think, and intended to read The Design of Everyday Things that time as well, but somehow forgot it.

I must confess that I had to force myself to read the book. It’s not a long read, probably 300 pages (I do my readings on Safari Books Online, with my Kindle, so page numbers don’t come into play anymore), and there is vast knowledge and practical advices but they are more like isles, separated with oceans of text.

Anyway this book made me realize just how awful designs I used to make (and of course, still make every now and then). By designs I mean my class-hierarchies and APIs that my “users” (who happen to be my co-workers) have to use. This revelation came when reading the book’s most important statement: when people can’t operate “everyday things” then it’s not they who are at fault, rather than the design of the device in question. Well, in software development code is pretty much an “everyday thing” and I’m certainly through some frustrating conversations about how exactly some of my classes should be used. And sadly, common sense didn’t make me realize that if I need to explain something then the issue doesn’t necessarily lie in the other party’s incompetence.

One might argue that source code is definitely not an artifact that’s for everyone, and whoever writes it must be educated and competent enough to be able to make sense from it, and he would be definitely right. The point is, which is well emphasized in the book, that anybody can operate a door, use a word processor, or perform other similar tasks, but mostly people are inclined with what they want to do, not the how, so you should make it as easy as possible. This is also holds true in my case as a software developer. Consider the following code, first stage of yesterday:

I bet you spot the obvious problem, how on earth do we know what 1000 represents? Well, you can just hit F12 in Visual Studio and try to figure out how I treat that value, can’t you? OK, let’s take it a step further, and document our work:

Much better, isn’t it? Well, not really that comment is destined to get out of sync with the code. I could improve the documentation of the attribute class, adding code comments for the constructor of the attribute taking that parameter, but I think we can agree that there is a better way. I’ve come up with this in the end:

I think you can’t really do more to prevent others screw up with the usage of this attribute. I must mention that documentation is in place in the class, so Visual Studio IntelliSense will grab and presents it. The point is that now the code tells what it does about itself, so you don’t have to read the documentation. Sure, there was some extra work, like creating an enum for storing time values, thinking on a more expressive name, etc. But I only have to write this class once, and it will be used thorough the application.

This is the philosophy I learned from The Design of Everyday Things.

Book read: Data Structures and Algorithms using Java

Recently I had a reminder that my algorithmic knowledge is less than stellar. This inspired me to read some books on the subject. I started with Data Structures and Algorithms using Java (note the “using” word, there’s a very similar book called Data Structures and Algorithms in Java). I thought a post would be nice on it, so here it comes.

Basically it’s a university textbook, so it’s very accessible but has some quirks. I’d note that referring to all practices, results and evolution of the software industry (the part of it which isn’t considered as academia) as good penmanship is a little bit pejorative at least. One more thing and I’ll finish my rant. I don’t like religious wars on where to put your starting braces, when I program in C# I consistently put them on a new line. When I use Java or Objective-C I always put them on the end of the line. But I didn’t even possibly think of putting them on a new line, then continue writing code on that very same line. So if you easily get frustrated by this:

public class MyJavaClassWithHorribleConventions

{  private int myField; //look at how I’m commenting

}

you’ll have a very rough time reading this book.

As I promised, this is the end of the rant, let’s look at the good things. The book is very accessible, with just enough theory to be able to read it after a long workday. There is very little mathematics involved, only basic algebra. There are lots of pictures showing each step of an algorithm, so you’ll get a pretty clear visual representation of what’s going on. Also, code samples as the title shows are in Java, (of course, on this level of complexity, they could be in almost any reasonable language) so it’s readable for a C# developer as well.

The books covers the big O notation, algorithm time and space analysis, basic data structures, such as arrays, linked lists, stacks, queues. A whole chapter is dedicated to hashing and hashed data structures. There is a chapter on recursion and on different types of trees (binary, AVL, red-black). There’s some coverage on sorting algorithms, but I’d expected more on the subject. The last chapter deals with graphs, and that’s all.

As a summary, as someone who doesn’t have a formal CS background and didn’t really looked up the subject of data structures, I found this book very useful. Although I’m sure I won’t stop here, but it provides a good foundation studying algorithms.