i.depreciate()

It’s interesting to think about yourself in the job market. How did you emerge? I came out of school and couldn’t find anything. It seemed that the jobs I was looking for weren’t available. The thoughts and ideas that I had, “be the best in your class” and “go above and beyond” drove me to believe that I would inevitably land an incredible job for a Google or the next big tech company. I finally got a byte (yea I just went there) to my many casts into the stream and landed at a web development shop.

Why do I bring this up? I’m trying say that I had an incredibly inflated vision of my worth to a company. This isn’t to say that it was necessarily innaccurate, although it was it’s irrelevant. All that I am saying is that my personal valuation of what I could provide to a company was fairly high. But, what I didn’t realize how little I was actually bringing.

Think about it this way. A company spends a great deal of time, effort, and resources in both people and materials to hire you, bring you up to speed, and then keep you happy over your time with that company. This isn’t a simple equation, but keeping it basic it looks like this:

recruiting + resources + salary = x

‘x’ is the monetary value that you are supposed to be worth to the company. That’s right, asset value. As with most things in accounting that hold a value, they depreciate unless more money is put into them each year. This is not giving you a raise or doing a review. Instead, this appreciation only comes from you, as an employee, getting better. This could be conferences, books, feeds, or even sitting in on a code review. Otherwise, your value to the company goes down each year.

That is called depreciation. When you purchase/build a house, the value doesn’t stay the same. You need to invest more to get more. This means time and money. If you can keep yourself on top of what is going on in the world within your field and be able to handle many situations, you’re keeping yourself classified as an appreciating asset.

I say all of this because it has helped me over the years to realize my actual worth to a company rather than my inflated view. If I never evolved or got any better, then I would still be where I started, which is casting lines into the stream. In fact, I’d be worse than that, because I’d have depreciated.

The Myth of the Expert

Second semester of my junior year in high-school had started and I was fairly eager to return to classes and not do the homework that was assigned to me. My last class of the day was a math course, pre-calculus if I remember correctly. I sat next to my friends and we began talking when the teacher walked in and wrote this on the board, “mean what you say and say what you mean”. He then turned to the class, told us to take out a piece of paper and write about what this meant. I looked up and began questioning his sanity… What in the world did this have to do with math?!?

He told us that we would need to be able to express, clearly, the ideas and concepts that we had to in our lives. That understanding the meaning behind that phrase would help us to better ourselves. However, that he would help us to understand this through math. The remainder of the course turned out to be great and we didn’t talk much about this, but I would always attempt to tie what we learned back into it.

It struck a chord with me. Now, I can thank him for presenting the question. I’ve had to deal with a handful of very sticky situations that require the truth and brevity.

With this in mind, how does one manage being truthful and concise while doing something such as marketing or advertising? Both of these professions tend to lead to the twisting of words such that new and hidden meaning is applied. So, how can, in good conscience, people do these professions if they follow the rule of “mean what you say and say what you mean”?

Ultimately everything comes down to marketing and advertising does it not? If I have a task that I need done, I have to market the task to the person(s) doing it such that they feel an important role in the success of the task. If I have to mow the lawn, I can sell the idea to the neighborhood kid such that they can make a quick buck. But, how do I go about doing this? It’s easy enough to say, “Hey kid, you want to make a couple bucks”. However, I’ll likely have to make a second pass at some point because it has a higher chance of being done poorly.

If I now turn that into something like, “I’m looking for an expert grass cutter. Are you that someone”. The kid can take some pride in what s/he is now doing. Plus, they will make a buck and likely make more for doing a great job. But, does this really make them an expert landscaper? No. In fact, it would be absurd to say such a thing.

This being the case, I’m beginning to wonder why in the world we have so many “experts” in any field. Surely Einstein was an expert in his field, but what about the rest of us that are in the back 95% of the bell curve? Can we truly call ourselves experts? The obvious answer is no.

I remember when I graduated from college fully believing that I was a programmer extraordinaire. Man, I was good…I’m tellin’ you. In fact, I was one of those 5% in the world. Once I got into the “real world”, I realized that I’m probably at about 50%…and that is likely pushing it. But, I am expected to market myself in such a way that I portray an expert. I’ve always been confused by this.

Don’t get me wrong, I love coding. I love diving into a problem and coming out on top. But, that sure does not prove me to be an expert. I’m not sure whether it is a fad. that people have attached themselves to or whether it is just something that H.R. people eat up, but it seems to happen far too often. As a hint, when interviewing, don’t tell me you are an expert unless you are ready to prove it.

Be honest and upfront with what you know how to do, and be modest with what you do not. The vast majority of us are not experts by any stretch of the imagination and while you may fool someone into hiring you, there is a high likelihood that you’ll be asked to do something out of your ability. Modesty would have served you well in that case.

In addition to people needing to understand that overstating their abilities is taboo, people making judgment calls need to stop jaw-dropping over the ultimate. There are very few around and you are unlikely to see that resume. Provide a more granular view of the information they are providing to you so that you can assess the true validity of said “expert”.

What are your thoughts? Are experts overrated? Is there a myth? Am I just part of the inept 5% way to the left of the bell curve? Throw it at me. I’m curious to know what you think.

Hire the Meta Thinker

In the past few months I’ve seen suggestions such as fire the workaholics all the way to fire the underachievers. Then you’ll see suggestions about how to hire and what to hire. What I don’t understand is that everyone is looking for specific traits, “has xx years working with J2EE, has handled a project from start to finish, has lead a team of 5+ people, has a 4 year CS degree”. What is the point? None of the above is going to really help when it comes down to producing something good. I say skip the crap and focus on thoughts and thought process. Hire the meta thinker.

I find that the quality produced from meta thinkers is far superior to the contrary. The reason I say this is because the person writing the code cares about asking what and why. Simply asking “What is this method supposed to accomplish?” and “Why am I writing this method?” starts the thought process into what will inevitably be a much more powerful set of tools.

Not only will those tools, functions, libraries, etc. be more powerful, they will be reusable. The reason I say this is because a meta thinker will think about the practicality of the functions or libraries. Meta thinkers aren’t concerned with the number of lines being produced, in fact, it tends to be the reverse. A meta thinker strives to drive the number of lines required down to the optimal level. The optimal level being the most efficient level. This ties into the “what”; the reason I am writing this function is because it allows me to create an object within the database. A meta thinker asks, how can I make this universal. How can I make this work outside of my specific scenario.

The other reason a meta thinker will produce better code is because of the “why”. A meta thinker understands that not everything requires separation, but attempts to see whether it makes sense to do so. To develop great software you will want some people who ask “why am I writing this?” One thing that will come out of that question is the finding of libraries or other tools. Also, you’ll find that the task at hand may be too complex for the purpose and realize and architectural fault in the system…Why am I really required to write ASM for this web app? Is the speed increase necessary? Maybe it’s time for a new framework. A meta thinker will find flaws less obvious than this one.

Beyond this, a meta thinker is someone you want around because you can bounce ideas off of them. A meta thinker will be able to help you flesh out ideas. These people will be able to expose issues or bless your concept. You are nearly always guarenteed to have a good idea of the more difficult parts of the operation once you’ve talked with these people.

Another reason you want to hire meta thinkers is because they are interesting to talk with. Not only do you build your level of understanding, you start to think differently. You learn and adapt your thought patterns similarly such that you’ll find yourself asking why a lot more. You’ll find that, after a period of time, you are the meta thinker.

This process is enlightening. You find that you try to solve a problem before solving the problem. Instead of diving into an issue you will think about it before and then attempt to solve the problem. This produces cleaner code and better performance, both in code efficiency and in the rate at which you write your code. By meta thinking, you find that you are solving the problem of how to solve problems. You are finding out how to write reusable methods by thinking about how to write methods. Your thoughts begin to change and your notion of just getting it done changes because you know that there is a better way.
Now think about it, would you rather work with someone that comes into the office and just does what is necessary for the day and then heads home, or would you rather work with someone that meta thinks about problems and come up with a crazy solution to a problem? I prefer the latter, it is just more interesting to me but, bottom line, I would prefer to gain more value for my buck.

A Day in the Life of an Open Source Project

Open source projects can be a challenge to manage. Why? Imagine this, you have a product you hold near and dear to your heart. You’ve poured blood, sweat, and tears into this thing and you have finally hit something you think is worthy. You ship it out to the world and say, “Here is my code: feed, digest, and enjoy.” Twp hours later you are bombarded with 40 emails telling you how horrible an idea using algorithm X, Y, Z was and how you should see that obviously W, X, Y is the preferred method. Then you see others that make note of your lacking skills in coding and that you should quit your day job. Next you see about 5 patches that need to be reviewed to fix bugs in your system. And lastly, you have requests to help enhance your product. This makes you want to pull your hair out- assuming you have any left at this point.
The picture I’ve tried to paint, I’m not an artist so forgive me, is not a very shiny or happy one. In fact, that is one of the things that turns people off from open sourcing products. Sure there are other reasons, but managing open source projects is very hard work. So, how do you make it easier. You should note that the community is not going to letup at all on the product providers. Everyone has an opinion and thinks it needs to be heard/read. So, without getting into the why’s or the benefits of open source, lets discuss how.

What things can be done to better control the flow of an open source project.

1. Patch Management- Bug fixes are going to come in, but to control those you could set up a bug management system. There are a number of bug management tools available; you just need to find them and use one. This will allow you to continue working on the things you need so that you can schedule 30 minutes at the end of a day or every other day to review any patches that came in and either include them or send them back. Not only will a bug system allow you to manage patches, it will provide a clear roadmap for your users and other developers. Thus, people wont step on each others toes. Two bug management systems that come to mind are Jira and Trac. Atlassian has a deal for open source projects as well, so take a look.
2. Enhancement Management- Branches. Branches. Branches. I’m not talking about the crap-tastic ones that SVN provides. I’m talking about real branches; DVCS branches. Go out and experiment a bit with Git, Bazaar-NG, and Mercurial. See which one tickles your fancy and pick it. You will have a far better time running your project with one of those rather than the alternative. And, if you don’t want to deal with hosting one of those you can use services such as Launchpad. What having one of these allows for you to do is create a branch that only the ehancers can push changes into, This effectively keeps the sources separate. But, when time comes to review the enhancements and push them back into the main branch, you can do this with a decent amount of ease.
3. Peer Review- You will never be able to break the flood of “you suck” commentary. However, you may be able to channel this behavior into positive, constructive criticism. Peer code reviews are great methods to keep you on your toes and make sure that you are always learning. My thoughts are that there is always someone more intelligent than you are out there. So listen. You can use some tools that provide a great way for people to write back on the code you are producing such that the comments go from “Why in the world would you use X?” to “Algorithm X is inefficient here because you loop over the data set twice. Use Y instead.” The commentary will become productive and useful. Tools do exist to aid in review; take a look at Crucible.
4. Ease of Contribution- Remember open source is about the community. You can’t half ass this. People have to be able to contribute in one way or another. And, they will know if you are just giving them the run-around. Therefore you need to allow for people to easily contribute. Many times people will be able to squeak 30 minutes in here or 2 hours there. And, if they have decided to spend that time on your project, you should be grateful. They could be doing something else. Thus, if you make it easy for them to help you, you’re likely to see better results from your open source-ness.

If you keep these tools in your toolbox for helping you to run an open source project then you are more likely to succeed with your project. Keeping the right attitude will also help. Be sure to take all criticism as good criticism. It can be hard since your code is generally close to your heart, but nobody is perfect and having a good attitude towards criticism will always be a benefit to yourself, whether in an open source project or not.

What approaches do you take when working on open source projects? How do you contribute? What are the steps you use to push your project to success?

Undertaking Projects

So I read a post from a friends blog, “Working Small”, and after I read the quote from Linus Torvalds in it I decided it was time to argue points.
Well, the next day at work we talked about the quote because I was curious about perspective on it and it seemed that we both agreed. What we both took the quote to mean was that looking at a project can be a very daunting task. Taking it from start to finish while meeting requirements, fixing bugs, working with new technologies, etc. is quite complicated. However, what we concluded is that the quote really depicts a view on how to go about working on these kinds of projects.

First you must understand that projects for clients are going to need to be thought out, put into a timeline, and then worked on until completion. However, what concerns me is the working on until completion part…thats the portion I do. If you start out by taking some project and work on it’s entire architecture and _then_ begin to develop it, you may have problems.

One of the problems, and possibly the worst, IMO, is the lack of agility. You will have a much more complicated time restructuring a system if you go through the architecture in advance of any of the development. Instead, if you focus on smaller tasks you will have a better idea of the start and end points and be able to develop with a clear vision in mind. Also, you have more ability the change an API or develop new ones as you are developing it due to certain needs. You are less likely to be able to change due to clients needs. Many projects go for some period of time and due to this, requirements may change. The client may decide over that period of time that the functionality of requirement ‘x’ actually needs to do ‘y’. In a hard fast architecture you have 0 agility. Instead, you need to add more to the application which creates bloat and functionality that may not be used. This leads to the inability to refactor your code effectively without leaving broken windows.

Now, these ideas are not new. The guys over at the Pragmatic Programmer have been talking about it for some time, however, I thought that the quote was the common link between what those guys are saying. It really embodies the view most developers should have when undertaking a project. While some architecture is important, it should not be the entire focus of the initial stages of development. There is something to be said about building prototypes and hashing ideas out before really designing the architecture of the final product.

You must have some idea of where you want to go, but that does not mean you should throw agility and prototypes out of the window.

“That Shouldn’t Be too Hard” and Norman’s Law

A phrase that I have too often said and heard is the single phrase “that shouldn’t be too hard”. As soon as those words are uttered you can estimate that the task being discussed will take two to three times as long. This is something I’ve noticed. Well the thing that makes this even more concrete is Norman’s Law. This law, derived from Hofstader’s Law, basically states that your project will always take longer than anticipated…even when you take into account Hofstader’s Law.

So, if we consider this, our opinions to justify and give comfort to the person attempting to complete the task tend to make this task infinitely more complex. I never understood why we do this to ourselves. And to top it off, I cannot reason why I continually make the statement.

This came up the other day when I asked someone to complete a task, but in the last couple days of developing the solution myself, I’ve gone through a series of rewrites and architectural changes already and it will still probably take a couple hours to flesh out the last issues.

I suppose that we think it’s easier on ourselves if we think the task can be done easily. Thus we make the statements and disregard anything about Hofstader estimating that the task will be small and provide us with an easy win. Either that or it’s the daze that we are in from the last task like that that provides a haze over the complexity of what we want to accomplish…I’m going to vote on the latter.

Daydreaming

I was sitting at my desk and trying to figure out a few things. I assume that these things are common for people leading teams and managing projects. However, does anyone really have a _good_ answer or does it depend on the individual or individuals making up the team? I would say that it’s a mix of both; using a foundation you can find a base understanding, but you then have to take the plunge learning to swim on your own, without the arm-floaties. So one of the questions I found myself asking was: What makes a great team?

To be entirely honest I’m uncertain as to what makes great individuals, but I do know the fundamentals of a great team. I’ve been on multiple “winning” teams in the past. You can see great teams all the time. Usually these teams are highly functional with seemingly independent parts. However, those parts are usually very much related to each other. Often the members of that team will collaborate and have a base knowledge about the other members tasks. This makes almost all of them useful to each other. Here are some characteristics of a great team:

• Understanding of their part in the team
• Accountability
• Willingness to help others
• Open Collaboration
• Open Communication
• Ability to have fun in the team

The successful teams that I’ve been a part of have had most or all of these traits. Surely there is difficulty in trying to pinpoint who, in the team, possesses these characteristics. Even more difficult would be trying to find people to bring into the team where you have no previous knowledge to base your perception on. That being the case, how can you accurately judge someone to find their true abilities. More interestingly, how do you gauge that persons ability to sink or swim when put into a team?