Austen.Ito.Blog

If you haven't noticed yet, I am very big on self-improvement. I am currently reading a book called Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp, who also writes the blog Rands in Repose. While reading this interesting and witty book, I came across a section called Skill vs. Will. It explains four states of developers:

• High skill, low will: Boredom is imminent-needs a change of scenery and responsibility stat.
• High will, low skill: Needs training, needs mentorship. Needs management. The good news is they really, really want it. Savor this because as soon as the skill kicks in, they're going to starting your job. This rules.
• Low will, low skill: Boy, did you screw up. It takes a fairly concerted effort to ignore the needs of your employee so long that (a) they no longer have the skills necessary to do their job, and (b) they don't want to do it. Roll those sleeves up, pal. You've got work to do.
• High skill, high will: Great job, ummmm, guess what? No one stays here long.

There are several things that came to mind when I read this section.

1. Why does management screw up if you have low will or low skill? Isn't it the responsibility of the developer to ensure that they keep up on the latest development styles, techniques, and processes?
   
2. Having a great motivation to learn is a great state of mind to have. You may not be the best at what you do or know everything, but being motivated gets you half way there. Improving everyday can only help your chances at becoming awesome.
3. He seems to side-step the problem of having low will by saying that by increasing a person's skill, they will also see an increase in their will. Somehow I don't really buy that. If you already have low will, what will make you want to increase your skills? And the larger problem is that if you have low will, what is going to stop you from going back to that state once someone isn't prodding you into improving?
   

On a side note: Aaron starred a blog from Coding Horror about achieving blogging success. That article has inspired me to stick to a blogging plan. I'm committing myself to blog twice a week, Sundays and Thursdays. Let's see if I can stick to it for a year.

I have read numerous articles in Muscle and Fitness that explain why body building is so tough. Body builders often talk about difficulties in being meticulous in what they eat, how they train, and their supplement cycles. The most important point they bring up is that body building isn't a job, it's a lifestyle.

In my opinion, hacking should be the same way. Hacking isn't just something you do at work to pay the bills. You need to always be improving your "Hacking Fitness". I believe that in order to become an awesome hacker, you need to change the way you live. You need to constantly train your mind to think in code, refine your hacking skills, and keep improving. English (or your native tongue) should be your second language.

Another thing to improve your Hacking Fitness is to find the right motivation. You have to _want_ to improve. If hacking is your hobby, then you'll be hacking at home. If you are hacking at home you are already have a leg up on a lot of developers. You have effectively turned "work" into "play", which to me is the real key of improving your Hacking Fitness.

Some other miscellaneous items that I am doing to try improve my Hacking Fitness:

1. Read books. You must read. There is no way that you can learn effectively without bombarding your brain with the stuff found in all of the reading material out there. There is absolutely no excuse not to read blogs, books, magazines. If you are awesome and not reading, let me know how you do it.
   
   
2. Read other peoples code. You can learn bunches of things when you read another developer's code. Improving your code reading skills will increase the speed at which you figure out things. Just imagine what it would be like writing a book report when you had trouble reading the book. It's hard to make connections when there is a language barrier. The same applies to reading code.
   
   
3. Pair program and Pair review. I have found that learning how other people think about code and their code tracing process is very useful. While pair programming is not useful all the time (although some people swear by pair programming), I find that after you experience it with another developer, you start to think like them when you are coding. I noticed this a while back when I started to trace through code like my coworker. You start wrapping the code around your head in different ways. You see the little things that you would not have seen before. Totally useful.
   
   
4. Try new things. I try not to get stuck using the same tools all the time. I try to move over to something new to see what is out there. For example, I was using the Netbeans IDE for a bit. You can't find anything better if you aren't looking.
   

A lot of these things have been said before. You need to keep learning, you need to get motivated, blah blah blah. If you take anything away from this blog, it should be that:

Hacking isn't a job, it's a lifestyle.

I came across a nice article on Liskov Substitution that clearly explained what it means to follow the principle. For those you who don't wish to read up on Liskov's Substitution Principle, the basic idea is that any sub-class should work, without any code change, for any interface that accepts a parent type. This got me thinking about the way I'm currently implementing the Simple Factory Pattern. The factory pattern provides you the ability of, "Insulating the creation of objects from their usage. This allows for new derived types to be introduced with no change to the code that uses the base class." So the implementation in Java would be:

public class SimpleFactory {
/** Prevents direct instantation. */
private SimpleFactory(){
}

public static FooObject getInstance(BaseParameter baseParameter) {
if(baseObject instanceof FirstChildParameter){
// return FirstFooObject sub-class instance using first child parameters.
}
else if(baseObject instanceof SecondChildParameter){
// return SecondFooObject sub-class instance using second child parameters.
}
// etc, etc.
}
}

This implementation violates the Liskov Subsitution Principle, which is found in reputable books such as The Elements of Java Style, because each new sub-type of BaseParameter that is created would require a code change to the simple factory. Perhaps this is one those cases where there is a trade off between code brittleness and encapsulation. While I agree that it is nice to encapsulate how objects are created using a factory because the method calling code does not have to worry about what type of object to create, I find the code smell behind my factory implementation to be disturbing. First, large numbers of subclasses would have to rely on type-specific code that constructs and returns the appropriate instances. Second, if a library with the SimpleFactory is in use by other developers, they are hosed if they create their own BaseParameter subclass. The code will not be able to be changed because Factory methods are static, therefore unable to be sub-classed.

The Liskov Substitution Principle is something I'm going to have to think about when designing new code. It is nice to finally get a solid grasp on what it means to violate this well-known principle. Perhaps my implementation of the Simple Factory is incorrect and there is an implementation that does not violate the principle. I should read more code.