-Chad Fowler in My Job Went To India, with the idea from Seth Godin (whose book is linked in the quote)

Moooooooo!

Chad illustrates the entire point in less than ten words:

Remarkable definitely doesn’t mean the same thing as good.

Said another way, I want to rock.

I've never believed I'm smart or gifted or otherwise especially endowed with intelligence. To me, working hard and putting in the effort has always been the key to success. Not until many years after I came to that conclusion did I read about how "eastern" educational philosophy outpaces that of the "west" in that way.

This is hard for me to say, given those beliefs, but it's something I've come to realize in the past few weeks: it's not hard to be remarkable. Let me explain how easily not sucking leads to remarkability, from stories I've personally experienced in the last two weeks.

A Tale of Two Types Of Customer Service

Ring... Ring

Hello?

Hi, I just bought a reel for my garden hose, and there's supposed to be a short 3 foot hose that connects the faucet to the reel which connects to the hose. The reel I picked up didn't have one on it, can I get one?

Sure, is there something I can "steal" and give you from another one?

...

Ring... Ring

Hello?

Hi, I just bought a ceiling fan and installed most of it until I realized one of the blades is scratched. Do I have to disassemble the fan and bring it all back in?

No, just bring the blade and the receipt...

...

Marsha, check out this 61 inch slim DLP TV. Isn't it awesome

Well, the viewing angle sucks. Can't we get a flat screen LCD?

Wow. You're right.

We don't have one. The nearest one in the computer is in Corpus Christie [3.5 hours drive time], but there's also one in the warehouse that will be here Friday.

That's not good enough, I need it by Monday.

[After making some calls to check around for TVs not in the system] I located one for you. It can be here tomorrow at 1 PM.

Great, I'll see you then.

...

Contrast those short stories with taking Wednesday off to get telephone service, calling AT&T and asking why a technician never showed up to get told they'll be there Thursday, to be taking off all day Thursday and then calling asking why a technician never showed up to get told they'll be there Friday, to be taking off all day Friday and calling to be told there was a problem with your order and no one ever bothered to call to tell you about it, to be taking off and calling ...

Also contrast those short stories with waiting a week for an appointment with Comcast on Monday, to be calling after the time frame ended, to being told to wait up as late as you can because they have flashlights, to being told they'll certainly be there Tuesday, to waiting until Wednesday, and again until Thursday.

Aside from the monopolistic consequences we observe, the difference in customer service is striking. Normal would have been acceptable, but the first three examples were remarkable, especially given the crap that came later.

The Point
There may be a lot of companies who aren't looking for great hackers, so perhaps being one isn't going to be in your best interests for finding just any job. It may be in your interest for finding an incredible job, however.

I used to think being lazy might be a quality of a good software developer. Instead, I learned that you should be proud, not lazy. It's not the negative side of pride we should strive for, mind you - it's the the limit of not sucking x_amount as not sucking x_amount approaches infinity.

I don't want to be around people who only want to succeed. I want to be around people who want to excel.

It's that easy to be remarkable to most people. It's the difference between being the one who blows the feather that ends up floating in the wind versus being the feather.

Being remarkable is the difference between being the one to flush the toilet as opposed to being the piece of shit that rides the wave down.



As always, comments, thoughts, and criticism are encouraged and appreciated.

Simply having participated in the project shows not only your passion for software development, but also that you're well versed in the technology you intend to use. You helped develop it, after all.

My own experience in this sphere has been limited, but it's something I hope to rectify. I have released a couple of projects, to little fanfare, but since then, I've been wanting to work on projects that someone else started, because being responsible for the life of the project is something I'm just not interested in at the moment.

In pursuit of that goal, at the beginning of the year, I resolved to get more involved in OSS (among other things), and for a couple of weeks I actually stuck to it. But once school started I quickly realized that there just wasn't enough time to do everything I wanted, and open source contributions were some of the first to go.

Another limitation was that while I wanted to work on JRuby, I wasn't using it for any major projects (just many small scripting tasks) - so I couldn't even help in the most obvious way of filing bug reports. However, now I'm working on a Ruby on Rails application that we expect to deploy on .NET using IronRuby, so I may get some good opportunities to help on that project, even if just by a little.

These are all baby steps. I expect to get more involved in the future, even if in small ways to various projects that never lead to "committer" status.

Aside from learning by being the worst and just saving your job by practicing it, you can also market yourself through your involvement in open source projects.

I know a lot of you already have your own projects and collaborate or participate in others. Perhaps you can help answer the concerns of everyone else.

For the rest of you, here are a few questions for discussion:

• What are you waiting for? Is there a way you can help your favorite project this weekend? It will make you a better developer than reading this blog will, that's for sure. =)
• Do you feel too intimidated to start, or just don't know how?
• If you don't participate, why not?

In the software industry, we've been chasing quality for years. The interesting thing is there are a number of things that work. Design by Contract works. Test Driven Development works. So do Clean Room, code inspections and the use of higher-level languages.

All of these techniques have been shown to increase quality. And, if we look closely we can see why: all of them force us to reflect on our code.

That's the magic, and it's why unit testing works also. When you write unit tests, TDD-style or after your development, you scrutinize, you think, and often you prevent problems without even encountering a test failure.

Perhaps I've made it seem like I'm on the side of the pirates. Just to make it clear that I'm not sailing under the jolly roger: In my own view, piracy is wrong. It's wrong even when the people making and selling the game are senseless, self-destructive fools. It's wrong even if the game sucks. It's wrong if you're broke. It's wrong even if "you weren't going to buy it anyway." It's wrong and I don't do it, ever.

It is not my intention to preach at pirates and get them to change their habits. I'm not anyone's mum, and it's not my place to tell people how to act. I actually think that having lots of people repent of piracy right now would be horrible. The managers would conclude their monstrous policies were working, and we'd get a double helping of the same, forever after, in every game they put out.

Regardless of the approach taken, I definitely no longer believe that sprocs should play any significant role in any application. The current mandate in the software industry is to strive to lower costs by increasing developer productivity and ORM's clearly help to do this by eliminating the need to write and maintain countless simple CRUD sprocs.

It's definitely time for all of us .NET developers to abandon our convention sproc wisdom and start playing catch-up with the rest of the industry when it comes to using ORM's.

I am not at the mercy of some big up-front UML diagrams or "non-agile" models grounded in getting something wrong in its entirety and very thoroughly before you take measures to fix it (or even begin to detect it).

On the other hand, you could also be like Minor Threat are to Blink 182, or the Ramones are to the Backstreet Boys - as Chad puts it about Charlie Wood, relatively "no recognition and lots of respect."

Ideally, you'd have lots of recognition and respect.

You can start by making sure you don't have a negative image. Don't be a jerk, especially online. The search engines won't easily forget, which means prospective employers (and dates!) will be able to find out how often you've been an asshole. If you're near the top of those search results, you could soon be singing with Cher.

<a href="http://www.youtube.com/watch?v=5G4O5AMSevc">If I Could Turn Back Time</a>

But you can go further than not being a jerk. You can show that you're taking an interst in self-improvement, that you're passionate about what you do to the point of discussing, learning, or doing it outside of work, and that while you don't know everything, you're actively filling the gaps as you encounter them.

You can gain respect.

It's easier to gain recognition by being negative or catering to the lowest common denominator than by earning the respect of your peers. That's called selling out. If you can do both, with just a modicum of success ... can you imagine the potential you have?

Stand up and tell the class, "what do you want to do with your life?"

<a href="http://www.youtube.com/watch?v=S6e8aOdPxhI">Twisted Sister - I Want To Rock</a>

I want to rock.

• The code is not readable without comments. Or, when someone (possibly myself) revisits the code, the comments will make it clear as to what the code does. The code makes it clear what the code does. In almost all cases, you can choose better variable names and keep all code in a method at the same level of abstraction to make is easy to read without comments.
  
  
• We want to keep track of who changed what and when it was changed. Version control does this quite well (along with a ton of other benefits), and it only takes a few minutes to set up. Besides, does this ever work? (And how would you know?)
  
  
• I wanted to keep a commented-out section of code there in case I need it again. Again, version control systems will keep the code in a prior revision for you - just go back and find it if you ever need it again. Unless you're commenting out the code temporarily to verify some behavior (or debug), I don't buy into this either. If it stays commented out, just remove it.
  
  
• The code too complex to understand without comments. I used to think this case was a lot more common than it really is. But truthfully, it is extremely rare. Your code is probably just bad, and hard to understand. Re-write it so that's no longer the case.
  
  
• Markers to easily find sections of code. I'll admit that sometimes I still do this. But I'm not proud of it. What's keeping us from making our files, classes, and functions more cohesive (and thus, likely to be smaller)? IDEs normally provide easy navigation to classes and methods, so there's really no need to scan for comments to identify an area you want to work in. Just keep the logical sections of your code small and cohesive, and you won't need these clutterful comments.
  
  
• Natural language is easier to read than code. But it's not as precise. Besides, you're a programmer, you ought not have trouble reading programs. If you do, it's likely you haven't made it simple enough, and what you really think is that the code is too complex to understand without comments.
  
  

There are only four situations I can think of at the moment where I need to comment code:

1. In the styles of Javadoc, RubyDoc, et cetera for documenting APIs others will use.
2. In the off chance it really is that complex: For example, on a bioinformatics DNA search function that took 5 weeks to formulate and write out. That's how rare it is to have something complex enough to warrant comments.
3. TODOs, which should be the exception, not the rule
4. Explaining why the most obvious code wasn't written. (Design decisions)

In what other ways can you reduce clutter comments in your code? Or, if you prefer, feel free to tell me how I'm wrong. I often am, and I have a feeling this is one of those situations. What are some other reasons you comment your code?

Update: I forgot to mention that discussions on relatively recent blog posts by Brian Kotek (Don't Comment Your Code) and Ben Nadel (Not Commenting and The Tipping Point of Poor Programming) got the creative juices flowing in my brain for this post. Thanks for bringing it up, gentlemen.

Outlook not so good.

Does that mean we shouldn't teach them? Of course not. Does it mean we shouldn't look for better methods of teaching them? Emphatically I say again, "of course not!"

And what of the learner? Should beginners seek to increase their level of skill?

Only if they want to become a level 20 Spaghetti Code Slingmancer (can you imagine the mess?). Or, that's how some make it seem.


Photo from Ken Stein found via Spaghetti cables @ Geek2Live

All it means to me is that we shouldn't let our paranoia about the wrong ways of learning stop us from doing so. For instance, take this passage about the pitfalls of reading source code:

Source code is devoid of context. It's simply a miscellaneous block of instructions, often riddled with a fair bit of implicit assumptions about preconditions, postconditions, and where that code will fit in to the grand scheme of the original author's project. Lacking that information, one can't be sure that the code even does what the author wanted it to do! An experienced developer may be able to apply his insight and knowledge to the code and divine some utility from it ("code scavenging" is waxing in popularity and legitimacy, after all), but a beginner can't do that.

Josh also mentions that source code often lacks rationale behind bad code or what might be considered stupid decisions, and that copy and paste is no way to learn.

They're all valid points, but the conclusion is wrong.

Which one of us learned the craft without having read source code as a beginner? Even the author admits that he was taught that way:

Self-learning is what drives the desire to turn to source code as an educational conduit. I have no particular problem with self-learning -- I was entirely self-taught for almost three quarters of what would have been my high school career. But there are well-known dangers to that path, most notably the challenge of selecting appropriate sources of knowledge for a discipline when you are rather ill-informed about that selfsame discipline. The process must be undertaken with care. Pure source code offers no advantages and so many pitfalls that it is simply never a good choice.

This is a common method of teaching - "do as I say, not as I do." It's how we teach beginners anything, because their simple minds cannot grasp all the possible combinations of choices which lead to the actual Right Way to do something. It's a fine way to teach.

But I'd wager that for all X in S = {good programmers}, X started out as a beginner reading source code from other people. And X probably stumbled through the same growing pains we all stumble through, and wrote the same crapcode we all do.

Of course, there are many more bad programmers than good, so lets not make another wrong conclusion - that any method of learning will invariably produce good programmers.

Instead, let's acknowledge that programming is difficult as compared to many other pursuits, and that there's not going to be a perfect way to learn. Let's acknowledge that those who will become good programmers will do so with encouragement and constant learning. Instead of telling them how they should learn, let them learn in the ways that interest them, and let's guide them with the more beneficial ways when they are open to it.

Let's remember that learning is good, encourage it, and direct it when we can. But let people make mistakes. Learning in the wrong manner will produce good programmers, bad programmers, and mediocre ones. Independent, orthogonal, and irrelevant are all words that come to mind. The worst it will do is temporarily delay someone from reaching their desired level of skill.

I would be knowledgeable having read programming books with no practical experience. But I wouldn't have any understanding. Making mistakes is fundamental to understanding. Without doing so, we create a bunch of angry monkeys, all of whom "know" that taking the banana is "wrong," but none of whom know why.

What do you think?

So to combat the effects of increasing intelligence due to reading books like The Mythical Man Month and Code Complete, I'm careful about maintaining a subscription to digg/programming in my feed reader. Incidentally, this tactic is also useful in preemptive head explosion. However, this second type of explosion is usually caused by asininity, as opposed to the combinatorial explosion due to choices you gain from reading something useful.



Reading digg/programming is how I came across Ohloh.

As Matt Marshall writes in VentureBeat,

Ohloh, a company that ranks the nation's top open source coders, is opening its service to let other developers to track and rank their own teams. [Strong emphasis is mine.]

It's the latest move by Ohloh, a Bellevue, WA company that already distributes its coder profiles and related data to about 5,000 open source sites. The Ohloh profiles can serve as advertising for these sites, because the profiles show how active their open source development projects are.

Here's how it works. Ohloh ranks individual coders by tracking their activity. Ohloh can do this because open source projects publish their code, along with a record of updates each coder makes. Ohloh exploits this publicly available information and analyzes which coders are the most active in making key contributions to the most important open source projects. It assigns them a "KudoRank" to each coder between 1 (poor) through 10 (best).

Teams now have access to Ohcount - "a source code line counter" that "identifies source code files in most common programming languages, and prepares total counts of code and comments."

Unfortunately, since Ohcount helps power the normal Ohloh website, I'd bet it can track commits and lines of code by committer.

As is well known to many people, if you want something done, measure it. In this case, presumably you want more lines of code.

O RLY? Are you sure about that?

The trouble is that lines of code is not a relevant indicator of productivity, so tracking it per developer may not tell you what you think it's going to tell you.

And what makes measuring lines of code per developer (and saying more == better) completely stupid is that program size is code's worst enemy. You'll end up doing the opposite of what you intended.

Still, Ohloh has some interesting stats for you to look at. And you know you want to be ranked #1.

Thoughts?