As a part of the last few classes I have to finish, I am taking a CPSC Seminar course which so far has consisted of talks from the Texas A&M Career Center. A lot of talk has been on managing your personal on line reputation. Besides the obvious “don’t post pictures of you on Facebook doing keg stands” or “don’t post embarrassing, topless photos of yourself”.

A lot of these tips are based on the idea that you don’t want potential employers that read your blog (Hi prospective employers!) and research your internet famousness to screen you based on what they gather from their research. From not hiring you because all of your Facebook pictures involve you being trashed at a party to an extreme scenario of a Baptist corporate recruiter seeing that post you did on how much you hate Baptists. The theme is the same: don’t let the company screen you unnecessarily. Usually the safe bet is to TIGHTLY titrate the amount of information you post on the internet.

However if one does a cursory Google search of my name, one will find that I have not shied away from associating my content with myself. Granted the first page of Google results is mayhaps even sexy to recruiters (hey look, a couple of my technical blog posts linked on PHPDeveloper.org, my LinkedIn account), if one can see or gets access to my Facebook profile or read the rest of my blog, one will notice that I do not hesitate in expressing myself.

Why would I put myself out there like that? Because while companies are out shopping for employees, I am out shopping for companies. And such shopping extends beyond basic research on a company and visiting their work environment.

How many of you found the above photo offensive? uncouth? unprofessional? ridiculous? How many people would put that person lower on a hiring list because of the information you’ve gathered so far in seeing that photo? If you were, I would bid you adieu (yes, that picture is of me) because a company that would penalize me without investigating as to why a picture is ridiculous. Would the backstory that this picture was taken of me performing a skit as a Fish Camp counselor in front of 150 freshmen, trying to provide a little humor as we spent a little over 3 days preparing them for their time at Texas A&M, change your opinions?

The way I see it is the company that would weigh so heavily on the superficial and not on the content (leeway given to the fact that not every company will have the time to do full background research on me) is not a company I wish to work for. If they do this while they’re in the process of hiring me, what do I have to look forward to in my future with that company? Apparently not much.

Maybe this is just an excuse to myself for having a lot of information about me out in the wild, however I feel like I have carefully filtered information about me onto the internet to aid in my job search, and to help potential recruiters understand my personality a bit better. Because as cantankerous as I sound above, the “not being hired by X firm” works both ways. I don’t want to work at a firm where I will not be a good fit. I’ll cause friction, drop morale, and generally be ineffective.

Plus this post has been a great chance to explain that picture.

I’ve been thinking a lot lately about a presentation given by whurley at a refreshBCS meeting a long time ago. He gave his presentation on Open Source Software, only SLIGHTLY an era of his expertise (just in case you can’t tell, that was sarcasm) and raise an interesting point.

He talked about how when BMC Software picked him up to head up their open source efforts, he battled a little bit the developers. They wanted to make sure the code was perfected, polished, and at its best whenever they started dumping it on the public. Of course they’d want to do this, releasing code as OSS is almost equivalent to deciding to present yourself to the work naked and without makeup. They wanted their friends who could see the code to be in awe, and their code base to be a shining example of a project done right.

Whurley wanted them just to release it. Not because he wanted it now, not because of impatience or deadlines or anything else. He wanted them to just release it because, and I’m paraphrasing him, releasing open source thats a little buggy will actually help grow and foster the project. Granted, you do not introduce bugs, you just open and display the code and start making releases even though there are still tickets in your bug tracking system.

He gave the hypothetical example of the stereotypical arrogant OSS developer finding a bug in BMC’s FooBar software, calling the BMC devs dumbasses, fixing it (because it was a small and easy bug), and now being invested in the software. You don’t really lose much reputation, but you gain an invested and loyal following.

While this sounds good and true, and it makes a lot of sense (if there’s nothing to do, OSS developers will never get involved), it never really clicked for me until I associated another story with whurley’s principle.

I meet Elizabeth Marie Smith (aka auroraeosrose) at ZendCon08 and had good times talking with her and many of the other #phpc members. At one point in the conference, at an opening for one of her talks (a brief overview of PECL extensions), she told the audience how she got into programming PHP and PHP C extensions. She wasn’t a computer science major, she only started in the early 2000′s (prior to that not much computer science experience).

What had happened was, to the best of my recollection and her seven things post, in the early days of 2001-ish she was really big into Anime and wanted to start a fan site. Her dad helped her install a forum (written in PHP) on a server he was running out of his house on a cable connection.

Well, as with many of the forum projects, there were bugs to be had in the software. Elizabeth was dedicated to the idea of her site and decided to break open the forum and dig around to fix the bugs. Fix them she did but everything kinda snowballed from there. In fact it was bugs in the PHP-GTK extension that caused her to learn C (not an easy feat) and become the maintainer of PHP-GTK as well as the Windows port of PHP maintainer.

It was bugs and problems in the software that caused her to be where she is now, it was bugs in the OSS world that caused her to latch on to PHP-GTK and the Windows PHP port and get them to where they are today. Though she told this story a long time ago, and whurley’s presentation was even further back yet, it only just now clicked that I had seen a real life example of whurley’s principle of “just publish it, flaws and all.”

The lesson from all this can even be applied outside of OSS development. It’s a lesson on perfectionism and can be applied towards my personal development practices. I know that agile teaches to publish early and publish often, fixing bugs and adding features on the way, but perfectionism still plagues me. I have maybe 10 drafts on this blog on small little PHP and Python topics I could publish that I never do because I feel it’s not good enough, or too simple. I have had code at work that I could have released a week ago but instead I obsess over making sure its “perfect” when a simple staging deployment will keep everyone happy, keep my moral up, and show me where the REAL bugs are.

So I see a link on reddit today to an article entitled No, your code is not so great that it doesn’t need comments. The article site was down so I started reading the comments and was very disheartened to see an actual debate over whether pro developers put comments in or left them out.

For example, we have this from “ckwop”:

I find that the number of comments a developer puts in to their code is inversely proportional to the amount of experience they have.

I believe the reason for this is two fold.

Firstly, as you become more experienced you become fluent in reading code. You’re not expending mental energy trying to grok the syntax and the flow of the program. It just comes naturally.

Secondly, as you become more experienced, you learn how to layout you code in a more readable way. You name classes and variables such that the code is, for the most part, self-documenting.

I don’t quite know how to describe the absolute FAIL in this particular statement. While he does go on to say:

The only comments left in programs written by experienced programmers are comments which document decisions. Why one approach was taken over another, for example.

It still doesn’t redeem himself. Comments like his betray a staggering amount of arrogance that poisons the mind of developers and turn otherwise good programmers into spaghetti-spewing monsters that take on government jobs so it’ll take longer for them to get fired.

This person (and sadly many others) assert that well written code is intuitive. These people are the same people that try and tell me Python is perfect for everything and I shouldn’t work in any other language unless I’m working in the embedded space, in which case I should write myself a Python-To-Assembly script prefixed with the cute little “py”.

Comments are meant to provide a quick overview of code flow and reasoning behind particular decisions. Comments should be clear and concise and allow a developer to spend 5 minutes figuring out where in the code base they need to be to fix the rounding issue rather than spending 40 minutes tracing program flow.

Comments are meant to help developers who either have limited experience in a language, who are new to a language, or who haven’t used a particular language in quite some time. Your Haskell code may be clear and simple to you, but I can’t read a single damned line of it: comment it!

Comments are meant for the developer who puts down a project to focus on something else for a few months only to pick the original code back up. The sign of a mature developer is one who accepts the fact that when he puts down code for a few days, he forgets the “why”. No developer is immune to this, and anyone that tries to tell you they are different is not worth the time you wasted listening to them.

So, to “ckwop” and all the other developers out there that think code should speak for itself I have a few things to say:

• If code could speak for itself, it wouldn’t be called code
• You will not remember your design decisions, and in some cases even code flow, after a month
• Comments make it much easier for me to debug when your company hires me to fix your failures both as a programmer and as a human being.

In closing: The debate has long been over, comment your fucking code.

One of the guiding principles I have lived by the came from my middle school swimming coach. He told us:

Don’t do more work than you have to.

On first glance, it doesn’t seem to be very good advice. However when you realize that what he was getting at was we shouldn’t waste energy on a poor stroke, the quote takes on a much deeper and more profound meaning. It is this principle that takes a good developer and makes him great.

Profile of a Good Developer

Good developers are almost a dime a dozen. Walk in to any computer science course or web development shop and you’ll find that the majority, if not all, are good developers.

These “good” developers can sit down and work through an object oriented architecture, they can construct their SQL queries, and can write an application that just works.

A “good” developer checks in his source code at the proper times, he comments his code as well as could be expected, and you can usually be guaranteed his code will compile and execute with very little fuss.

Profile of a GREAT Developer

What separates the great developers from the good developers is LAZINESS! You will find that the good developers, while producing clean, working code, operate much slower than great developers, and for the reason that separates the good from the great.

Good developers are set in their ways of just manually working with everything. A good developer handles deployment with FTP, and updates database structure by hand. In the end, the good developer ends up wasting time doing menial tasks. FTP alone can kill up to 30 minutes of your day. Good developers are very set in their ways and do not like new things introduced.

Meanwhile GREAT developers HATE menial tasks. They abhor having to drop into the console every time they wish to test or deploy, and loath dropping into the database to manually update structure. So these GREAT developers begin to write scripts and integrate all their tools to reduce their menial overhead as much as possible.

The GREAT developer is lazy because they do not want to do things themselves, so they spend 20 minutes automating their tasks so they’ll never deal with it again. And when you think about it, when you could spend 20 minutes once writing automated deploy scripts but instead spend 20 minutes every deploy in FTP, you are doing more work than you have to.

What Does This Mean For Me?

All of us developers should strive to be as lazy as possible. Do you have a task you have to do more than 3 times total? Write a script or a build task for it. Do you spend a lot of time testing features? Automate your testing. And if possible, integrate the systems so you never even have to run those scripts manually, reducing user intervention to one step.

I know I try to be as lazy as possible, do you?

Edit 6/10/2008:

I feel I should make sure everyone knows that I am to an extent being facetious with the word “laziness” but I’m being completely serious on the “don’t do more work than you have to.” While a good developer can handle long, arduous tasks that are prone to human error, a great developer avoids them in the first place.