Practical uses for FizzBuzz Part 1

In the Army, there were generally questions about soldiering that personnel looking for promotion would be asked. They would spend a day going before a promotion board in their crisp uniform and be asked questions about being a soldier.  Questions like: What are the different MOPP Levels? What is the process for clearing a weapon jam in an M16?  What is the effective range of a M16? What is “Danger close” for an MLRS? 

In case you were wondering, “Danger Close” for an MLRS is a whopping 1km x 1km.

Sadly, software development doesn’t let me ask such cool questions. I have to stick with things like “What is inheritance and what is composition, and when would I use either?”

However, much like the questions the Army promotion boards ask, these questions we ask developers are just as useless.  A great soldier may not know the effective range of an M16, but he can hit what he can see — and that’s even better.

A software developer may not know the word ‘composition’, but they recognize bad design when they see it; and they recognize good design when they see it.

This makes a change of tactics necessary, as it were.

Don’t ask questions about Object Oriented design — have the candidate design something for you.  Don’t ask questions about code — have the developer write code for you.

 

The easiest way to do the first is to use something like Monopoly to conduct the interview. To do the second? Something like Fizzbuzz would do just as well.

 

The great thing about Fizzbuzz (even though it’s shockingly simple) is that it can serve to show a few things:

1. Does the candidate know the language? (If someone is using ‘Mod’ in C#, that’s a good sign they don’t really work in that language much (which is doubly disconcerting if the word ‘Expert’ is next to ‘C#’ on their resume)

2. How do they structure their code? Do they go for the elegant solution? The Simple solution?

3. It provides a basis for refactoring. This shows you if they can think about the potential problems in their code.

 

    for (int i = 1; i <= 100; i++)
{
string result = String.Empty;
if (i % 3 == 0)
result += "fizz";
if (i % 5 == 0)
result += "buzz";
if (result == String.Empty)
result = i.ToString();
Console.WriteLine(result);
}

In our next wonderful adventure, I’ll go into how to use a simple programming exercise to determine a candidate’s ability.

How I became a programmer

You know those kids who learn to program in assembly at age 12?

I wasn’t one of those.

I grew up around PCs, I was even the first kid on my block with a Local Area Network, but I didn’t program for a long time. I didn’t even know it was possible.  My journalist father was on the cusp of the Computer User revolution; but he didn’t know enough to know how computers were programmed.

Ergo, he didn’t tell me.

In 1993, my school’s computer lab received 386 and 486 PCs. I found the BASIC interpreter and did stupid things like:

10 PRINT "HI THERE"
20 GOTO 10

I was sure I could do more with it; but didn’t have the vision to know what the ‘more’ part was. It was a novelty, but not a terribly interesting one without context.  Later on that year I opened up the GORILLA.BAS file; but I just didn’t have the vision to play around with it. The game worked the way I wanted it to; why muck with it?

Gorilla.Bas - An oldie and a goodie

 

Then I was introduced to the TI-93+; a programmable calculator with its own assembly language. Cool, now this has potential, I thought. I had no idea what to do with it; but I at least knew it was there.

I gamed through High school; but never took Mathmatics past Algebra III — I had a high school teacher who was more interested in her Yearbook duties than she was in teaching math.  That was a bummer because up until that point, I thought I was pretty good at math.

I attempted to get into a public university for Computer Science, but was told quite pointedly that I didn’t have the math pre-requisites to do so. I ended up winning a four year full Leadership scholarship for a local Catholic college — and they had Computer Information Systems. Huzzah.

I took Java the first semester along with Introduction to Computer Architecture and Systems; but again the vision thing blocked my path. The Architeture class took me through the physical bit flipping and memory address allocation and whatnot that happens at the very core of the microprocessor, but the Java course was so far removed from that that it didn’t make sense to me how they connected. I needed to go lower level. So I took C++. At the time the public view of Java centered around rotating cubes, and while I dig rotating cubes, I didn’t see how a rotating cube mapped to a memory address instruction.

While taking C++, I had a healthy dose of Data Structures and Algorithms and Database Design. Now this had potential. Finally, something that made sense. The courses were a lot of fun, and although I momentarily bombed on Pointers, I figured those out and was well on my way to doing fun things… Except for the fact that these classes were for the lowest common denominator, in a school that was defined as a Liberal Arts school.

Once again: bummer.

To pass the time, and because someone told me that it was the basis for all web development at that time, I learned Perl (this was right around the time PHP 4 was released, back when it was called Personal Home Page (yikes!)). and proceeded to use it for every day scripting.

Junior year I rounded out the rest of the undergrad CS curriculum (save the senior project courses that closely mirror what software developers actually do on a day-to-day basis), and started drawing up ideas for websites. My first idea was a website that users could log on to to rate and share their experiences at private retailers, a la Kudzu.com (which came 2 years later). I never got very far because I was called up, but I always wonder what would have happened if I had launched that site.

Right as I began my senior year, the government decided that it needed me to fulfill my reserve obligation. My Army National Guard Unit was called up and off I went to Iraq.

After I got back from Iraq, I wrote VBA code in for the Army unit I was assigned to. They used an Access Database to track everything that happened in their unit. My job was to make it generate pretty reports and create whizbang features that allowed them to track the disposition of members of the unit daily, and then generate pretty reports for multiple government agencies.  Before I got there, it took an entire day and coordinating with 5 people to do. After I finished, it took 10 minutes and no coordination.

Not bad, huh?

After that ended, and three years after I was called up, I took off the uniform for the last time and went to finish college.  My senior year consisted of a senior project that required us to pick from a stack of problems and fix one of them.  Typically, the local non-profits would ask the College’s CIS chair if he could spare a few students to write a program for them; we were those few students.

I led a group to design, implement, and deploy a Winforms based client-tracking system for a local non-profit charity. The code wasn’t tiered very well, it had an ugly 1-form-tabbed interface, and it crashed a lot. But it worked. This was my second real taste of success.

Due to domestic constraints at the time, I lived in an area that had very little programming prospects for me; and ended up taking a job as a Perl Web Application Developer about 60 miles away.  The work wasn’t much fun, but that was because I was the lone contractor on that particular project.  Thinking that this was how programming was, I opted to leave the job when the contract was up and go into Systems Administration.

How different these two worlds are!  As a programmer I rarely spoke with others, but as a System Administrator, I was in a new environment almost daily, doing something new and different. The job was as varied as the day is long; and there were always improvements to be made.  I promptly used Perl to automate system administration tasks (like waking up the PCs for disk defrags, keeping an active display of which computers were up, etc). Once I finished there, I used C# and the SendKeys API to automate the startup of the Point of Sale computers.

I was good at System administration, but I was in a place where there wasn’t much of a future.  How many SysAdmins do you know that start their own company?

So I went back to programming, and have been for the past few years.

Did I mention that I love every minute of it?

The 5 types of Programmer companies

I recently had a chat with a recruiter about why I wasn’t interested in a prospect. This is the answer I gave him:

In answering your question, it’s necessary to list the categories we (Software developers) put companies into.  Depending on where a developer is at in his career, different types of companies may occupy a different order.  The ordering of the list changes depending on the developer. This is by no means canonical.

Software development jobs generally fall into one of a few categories:

1. Startup – ‘Fun’ atmosphere, chaotic, making new things, generally at the cutting edge; fails easily, pay isn’t as good, but the other benefits (working from home, relaxed dress code, casual work atmosphere) make up for it. Long hours at times. Developers care about the company and their work. Selling environment may dictate ‘ship now, fix later’ mentality (that normally leads to project failure down the road)

2. Private Company that sells software as its primary business function – Developers treated well, first class citizens; pay is very competitive and benefits are outstanding. Normally right around 40 hour work weeks (there’ve been numerous studies that show as knowledge workers work longer hours, they perform more poorly mentally); dress code varies, but normally Jeans and button down or something along those lines. Well defined process; Developers care about product and company, vested interest to see it do well.

3. Private firm that sells something else and makes software as a ‘supporting’ function – Developers more often than not are second class citizens; restrictions on what developers can do; working with new technology or making changes ‘for the better’ is hard. Pay is great, but it’s a mixed bag as to whether the other developers really care or if they’re just collecting a paycheck. Dress code is conservative.

4. Private Firm support government entity – Somewhere between 2 and 3, depending on the company.

5. Public (government) entity – Not cutting edge at all (in most cases); heavy restrictions on what a developer can do; watched like a hawk; change is unheard of.

Explain the Path Not Taken

In my travels around the blogosphere, there is a common refrain in technical advice. For any given problem, there are n number of ways of doing it, but there is one most right way.  When writers write, they have a limited amount of time, so they tell you the ‘right’ way.  They may tell you not to solve your problem a certain way; but often times they don’t tell you *why*.

Why the hell not?

The answer you didn’t choose is as important as the answer you chose.  The reasons behind it are just as important, if not more so.

Recently, I was tasked with improving the performance of an advanced search query.  The query was taking about 5 minutes to execute.  No, that’s not a typo.  After diagnosing and benchmarking the query with the resident Oracle DBA, we started brainstorming fixes; and the idea was to get the low hanging fruit out of the way.  Here are the list of possible ways to fix this issue:

1. Force the user to use more than scant criteria for an advanced search (in this case, by requiring the user to enter more information into other indexed fields)
2. Improve the query performance through adding the appropriate indexes
3. Parallelizing the query since parts of it used a full-table scan.

Pros and Cons:
Approach 1:
Pro: Allows us to defer the actual query performance issue
Con: Makes user unhappy; alters existing functionality

Approach 2:
Pro: Low hanging fruit. Easy fixes; easy to benchmark
Con: May not get us ‘all the way there’; may have un-intended side effects.

Approach 3:
Pro: Divvies up the Query into multiple threads
Con: Possible to slow the query down since those threads have to share information

We tried the latter two approaches.  I documented the first one; but did not implement it. The second approach netted a 78% performance increase when we added two indexes.
 The third approach ended up actually reducing the original query by a miniscule amount but it was three times slower than approach #2. Ultimately we added the indexes and reduced the query time by 78%; a non-trivial amount; and sufficient since the feature is used very rarely.   To put more man-hours into a fix for a feature that is so rarely used would be folly.

My point is, it’s important for the developer that comes after me to know all of this.  If the client says, “78% isn’t good enough” then the next developer will need to know what I already tried; otherwise he’ll simply waste time re-duplicating effort.

The next time you see a blog post on the internet detailing a fix, ask them what didn’t work — you may be surprised at the answer.

Windows 7 Install – Painless

I’ve got a few blog posts nearing various states of completion (that’s blogspeak for “not done yet”); and in the meantime I wanted to hand off a public service anouncement about Windows 7.

I’ve been running Windows XP since the Release Candidate in 2001. I’m not the first to claim this but it felt like Microsoft’s first ‘real’ operating system. It’s like they joined the rest of the world.

Today I installed Windows 7.  Since there is no upgrade path from XP to 7, I simply bought  a new harddrive, installed 7 on it; and keep my secondary drive with my XP Files; so that I can still get to them if anything happens.  I’ll slowly recreate my Subversion repositories and whatnot on this machine, as well as Visual Studio.

Installing Windows 7 was painless.

I’m still in shock.

 

My Experience With Amazon at DevDays

Prologue

I was at DevDays yesterday; and during my time there I frequented the Amazon booth.  The same Amazon that Steve Yegge worked at.  The same Amazon that has essentially revolutionized online shopping. The same Amazon that… Ok, I’ll stop drooling now.  Amazon == programmer mecca. It ranks right up there with Google, Microsoft, and Fog Creek Software.  If you’re a programmer you want to work at one of those places.  It’s the Ivy league of programming careers, and about as tough to get into.  I had a ‘conversation’ with Joel Spolsky via twitter recently, and if I remember correctly an interviewee had no less than 6 interviews to determine whether or not he was ‘good enough’ to work at Fog Creek software.  I imagine the distribution of failure would scare most people away.

Act I: Epic Failure

So I went up to the Amazon booth and checked out their trivia questions.  The first one had to do with a variation of the fizz-buzz problem, and I recognized it for what it was.  But I was nervous, and the big Amazon (not a pun) guy with a goatee (BAGWG) was staring at me, so I stammered out something like: Well the ++i would evaluate to one higher the first time through. I botched it because I was studying the trees and didn’t pay attention to the fact that the forest would burn to the ground.  The answer was that while the problem accounted for either fizz (4) or buzz (5), it logically did not account for what would happen if there was a multiple that happened to have both fizz and buzz as factors (like 20). 

One of the PHD students that was hanging out with Rick Schott and I solved it (both Rick and I concentrated on the trees); and the exchange itself was somewhat funny:

BAGWG (to me): So you think you know the answer?

Me: Well the ++i would cause it not to iterate through…

BAGWG (interrupting): Doesn’t matter; any other ideas?

PhD Student: It won’t print anything anytime a number is a factor of both 4 and 5.

BAGWG (Turns so his back is towards me and separating us from the PhD Student): Have you ever thought about working for Amazon?

Rick and I looked at each other and walked away, dejected.

Act II: Victory Strikes Back

A little later, still smarting from missing the obvious, I walked back to the table and saw they had listed a new problem.  Essentially it was a problem where you had x,y coordinates defined, and you had to figure out based on the code shown whether or not the rabbit would get the carrot.  The answer is that no, the Rabbit would not because the carrot was hidden beyond the bounds checked by the code. I explained as much to the PhD student and Rick (who were coming to the same conclusion), and they told me I was wrong. 

I was, because I had used the word bounds to describe ‘out of bounds‘ instead of physically located outside of the array, which it was not.  Knowing that I had the answer correct this time, and remembering to use the correct terminology lest I get interrupted, I went up to the Amazon booth and chatted with another gentleman from Amazon (trying feverishly to avoid BAGWG, he was intimidating), and he gave me a Ninja for getting the problem right and asked me if I ever considered working for Amazon.I swear the Ninja is Laughing at me

Have I ever considered working for Amazon?

OMGWTFBBQ PONIES!!!111!!!.

Of course I have. Who hasn’t?!?!?!

I didn’t say this to him, though — I just nodded and he proceeded to ask me if I knew anything about EC2. I was still high from hearing the first question, so I stammered a question out that made it sound like I’d never even heard of Amazon and then proceeded to bolt from the table out of horror for my brain shutting down right when I could have had a networking session with the hiring manager for Amazon EC2

I swear the recently-won ninja in Rick’s shirt pocket laughed at me.

Act III: The Return of Defeat

The final question of the day (I’m recalling from memory) was about biased coin flips.  Specifically, let’s say you had a boolean method that acted like a coin flip and returned true or false and did so so that it was evenly distributed.  How would you construct a replacement method so that it would generate true only 31.416% of the time.  My thoughts were that I could get close with the following hacky code that I wrote just to test it out quickly:

 

       static void Main(string[] args)
        {
            Dictionary<int, bool> Flips = new Dictionary<int, bool>();
            Flips = flipCoin();
            int TrueCount = 0;
            int FalseCount = 0;
            foreach (var item in Flips)
            {
                if (item.Value)
                {
                    TrueCount++;
                }
                else { FalseCount++; }
            }
            Console.WriteLine(“True : ” + TrueCount);
            Console.WriteLine(“False : ” + FalseCount);
            Console.Read();
        }

        private static Dictionary<int, bool> flipCoin()
        {
            Dictionary<int, bool> _Flips = new Dictionary<int, bool>();
            bool result;
            Random rand = new Random();

            for (int i = 0; i < 1000; i++)
            {
                result = rand.Next(2) == 0 ? true : false;
                if (result)
                {
                    result = rand.Next(2) == 0 ? true : false;
                    if (!(result))
                    {
                        result = rand.Next(2) == 0 ? true : false;
                    }
                }
                _Flips.Add(i, result);
            }
            return _Flips;
        }

But that returns True about 33% of the time, give or take, so I knew this solution wasn’t correct.  I kept thinking about the Monty Hall problem and thought maybe that was related somehow, but I couldn’t figure out how.  I figured I could try a naive implementation of Rand() by keeping a ratio of true/false so that over a series of rolls, the probability would end up being 31.416%; but I also knew instinctively that that was wrong. What’s funny is that when it comes to matters of probability, lots of people get it wrong, including Blaise Pascal.

Something the BAGWG said to another passer by is still bouncing around in my head: It’s an easy one-line change.

I have no idea what that one-line change is; but I will figure it out.  It’s probably something really easy; something that once someone tells you you realize the piece you were missing.  It is driving me nuts because I know I should be smart enough to know the answer, and I don’t — and that bugs me.

Epilogue

But there is a chance!

I’ve been staring at the Amazon business card they gave me; both because I want to go download a barcode library and decode the barcode on it, and also because I really really want to submit my resume.

There are lots of reasons why I shouldn’t:

  • I can’t even figure out a simple probability problem
  • I’m just now learning Emacs
  • I’ve never even written a compiler
  • I’ve never used pointers in a production application

Reasons I should:

  • Not trying is much worse than trying and failing
  • Between ‘slim’ and ‘none’, I’ll take slim any day
  • Because that’s what I’d tell other people to do

To Be Continued…

 


Note to any employer (present or future): If I work for you, it’s because:

  • I like the work.
  • I like what I do.
  • I like where I work.
  • I like the people.
  • I like bullet points.

However, if Amazon or Google or Fog Creek Software or any other company that was universally recognized as a great place to work as a programmer contacted me and subsequently offered me a job, I’d probably put in my notice and leave.

It’s nothing personal.

Why would I leave? It’d probably have to do with the Joel test.  It’s the Ladder Theory for programming: we’re always going to go to the place that scores the highest on that test. One way to  keep good programmers is to score very highly on the Joel Test, the other is to hand out Porsches. I think the former is less costly for you.

Review: Stack Overflow DevDays – Washington DC

The Venue

DevDays at DC was held in the State Theatre, and it (as a venue) was suited for the information portion of the show, but wasn’t well suited for the ‘networking’ sessions that were held during breaks and during lunch time. The seats were set up in rows and there just wasn’t a lot of space for individuals to congregate in numbers greater than 5.

Pre-Conference

The Venue didn’t have beverages set up for us pre-show; which was expected due to the tweets the other venues’ attendees had made. There was music pre-show, as well a twitter feed with Stack Overflows DevDays countdown. The sound was high quality and the presentation of the venue prior to the keynote was of very high quality (considering).

Joel Spolsky – Opening Keynote

Once the opening video played (which, by the way, was perfectly cued to start with the closing of Drive In, Drive Out by Dave Matthews Band), it was apparent how much quality was put into the production of this show. The Video was high quality (though the part where it paused was a glitch) and the production quality of the video was apparent. They put some serious dough into making this look and sound good.

Once Joel came out he spoke with his usual wit; and it put the conference in the right ‘mood’. I won’t add too much other than to say that he is well versed in presenting and it was worth the price of admission to hear the subject matter. Other attendees had a problem with him touting FogBugz and having conspicious advertisements, but I don’t see a problem with that. If he were advertising for Microsoft, I’d be surprised; but he’s advertising for his own companyThat’s his Job.

Dan Pilone – iPhone

Production Note: Dan’s opening onto the stage was ‘rushed’, and it took a minute for the mic to catch up with him. I realize it was only a day conference and the price was cheap, but they probably should have worked on the ‘handoff’ better between speakers. This happened throughout the day, and while it wasn’t anything more than a ‘glitch’, it otherwise marred a perfect production (how it flowed, etc).

Dan’s talk on the IPhone hit the the true side of the ‘marketing’-speak. To paraphrase him: You’ll get rich if you make a great app, or if you’re a rapper. I would have liked a more technical presentation; but he didn’t have time for that. Given the time he had, he used it well, and it did whet my appetite for more. I may pick up his book on the subject to see what’s next.

He skipped the parts on Objective-C (presumably because they would have bored the hell out of half the room); but it would have been interesting to know how it diverges from other C-Based languages (other than the syntax is completely different).

I commend him for his presentation skills; he knew his subject matter and he was skilled enough in his environment to work around any glitches that came up. That’s hard to do when there are 200 geeks waiting for your next breath.

K Scott Allen – ASP.NET MVC

Hearing K. Scott Allen speak on ASP.NET MVC was a treat in of itself. He went through little more than the basics, but even for someone who’s worked on ASP.NET MVC for multiple projects, I still learned some stuff (notably the T4 Templates, which seek to make the “Magic Strings” strongly typed); and he even threw in some of the goodies from ASP.NET MVC 2 Preview that I hadn’t had a chance to play with yet.

Production-wise; it’s tough to give a talk without upsetting some geek somewhere. I’m sure there were quite a few Ruby on Rails guys that were just jeering at the ASP.NET MVC talk. That’s ok; we jeer at you when you’re not looking too (I kid, I kid). He probably couldn’t have changed much on it other than to have a fully ready-to-go expansive site that worked out MVCs muscle. I wouldn’t expect that for an hour talk, though.

FogBugz

Even if the rest of the show was a veiled advertisement for FogBugz, I still would buy FogBugz for my development team. Just looking at what that software can do is a testament to the developers at Fog Creek Software. I don’t care if you’re open-source or a Microsoft guy, that software is good. I’m talking yummy.

Lunch – Networking Session

The only ‘fail’ of the day. Not lunch, but the networking session that accompanied it. The Venue just wasn’t set up to house more than 5 people standing around; and the most interesting section (the one I wanted to hang out in – Startups) had 8 developers crammed into the opening for that section; with 15 more trying to hang out around it. It wasn’t happening.

Lunch was yummy and precisely what you’d expect for a $99 dollar conference.

Bruce Eckel — Not On Python

I loved Bruce Eckel’s talk. Didn’t learn a damn thing about Python (Because he didn’t teach anything on Python proper) but I learned the evolution of languages; which is quite important. You have to know why something is the way it is to be any more than a simple user of a tool; and his talk helped reinforce that point. Unfortunately people were offput because he didn’t just talk about Python, so there were grumblings from the masses.

He did make one point that I disagree with; and that was the reason Google was going to Python was because of the advantages it holds over Java (he spent a lot of time railing against Java. It’s ok, he wrote a book, he can do that); but I wanted to point out that while Google does use Python, they use Java too.

Jonathan Blocksom — Google App Engine

Informative; but light. He couldn’t do the walkthrough of his GAE site for whatever reason. Still enjoyed the talk; but don’t know enough about the subject matter to know whether or not it could have been better.

Richard D Worth – JQuery

Some people left during this part of the presentation, for whatever reason. Maybe they thought they knew JQuery, maybe they had to beat traffic (no way, not at 4:40 in the NoVA area); but they missed out on a truly awesome presentation. He introduced and went through JQuery and the various ways to ‘correctly’ use it, and in the process we got to play with JSBin.com and a site that tests JQuery Selectors. Fricking amazing.

Bottom Line

Well worth the price of admission; the topics were interesting. I would pay more if they would host it in a larger venue, or if they’d host it in the same size venue but actually make the area conducive to networking.


I also posted this review here, on http://meta.stackoverflow.com.

What are your Daily Hits?

In the book My Job Went to India (And All I Got was this Lousy Book), Chad Fowler writes about what developers can do to improve their craft.  There are 52 tips, and they range from positive gems like Be the Worst (#8) to other positive gems, like: You’ve already Lost Your Job (#43). 

All kidding aside; this book is chock full of tips meant to help us improve our craft, and it’s even gotten a facelift as The Passionate Programmer.

One such tip is The Daily Hit (#20):

As with most tasks that are worth doing, becoming a standout performer is more likely with some specific and intentional work.  When was the last time you went above and beyond the call of duty? Did your manager know about it?  How can you increase the visible instances of this behavior?

James McMurry, a co-worker who’s also a good friend, told me very early in both our careers about a system he had worked up to make sure he was doing a good job. It struck me as being remarkably insightful given his level of experience (maybe it’s a hint he got from his parents), and I use it to this day.  Without warning his manager, he started tracking daily hitsHis goal was to, each day, have some kind of outstanding accomplishment to report to his manager — some idea he had thought of or implemented that would make his department better.

Simply setting a goal (daily, weekly, or whatever you’re capable of) and tracking this type of accomplishment can radically change your behavior.  When you start to search for outstanding accomplishments, you naturally go through the process of evaluating and prioritizing your activities based on the business value of what you might work on.

Why daily?

Tracking hits at a reasonably high frequency will ensure that you don’t get stuck: If you’re supposed to produce a high per day, you can’t spend two weeks crafting the perfect task.

I’m guilty of trying to be perfect. When I sit down to implement code; I (very often) try to get the code working perfectly. I spend a lot of time fully implementing when I should be prototyping.  the daily hit is a way of prototyping instead of fully implementing a feature, and sometimes I wish this book came with a rubber mallet to beat me with when I forget its lessons. Do you keep track of your daily hits?

If you don’t know what your daily hits are, neither do your manager.

 

Bad Actors in your Code

During my time in the Army, I used to get rankled when I’d see Television or Movies portray soldiers.  Generally, they’d get something wrong; and usually, it wasn’t just something minor.  It didn’t usually bug me when it was clear they weren’t trying to get it right. It bothered the hell out of me when it looked like they tried to get it right, but failed in some way that could have been prevented if they would have spent $1000 and hired a military consultant for a day.

The same thing bothers me about naming in source code.  Well, not the military part, but the ‘bad acting’ part. Names that don’t do what they say they do, or names that don’t even mean what you think they mean.  These ‘gems’ can slow down development time and reduce the level of understanding from all team members. For every new person you bring on to the team, that’s another person that has to make the mental leap from what a word means to what it is used for in your application.

 

Here are a few bad names I’ve seen in source code recently, and they are all from commercial applications.

timeout  – Describes how old a file should be before it’s deleted

narrative – Refers to the ‘help’ field for a form or page.

nounset – where noun can be anything, like ‘bird’ or ‘category’ or ’email’ or ‘password’. The suffix ‘set’ is added to it to denote a ‘set’ of that noun. In some cases, it refers to a ‘template’.

That’s just a few; and there are more out there, probably in the application you work on.

What’s so wrong with bad naming?

Let’s say you have a new developer come onto your team. it doesn’t matter if this developer is just out of college or if he’s a 10 year veteran. He now has to learn what those words mean.  He then has to apply those names to the intent behind them, and daily has to remind himself of what they mean, since they aren’t used in their normal context.

Here are some possible solutions for the ‘naming problem’.

timeout  – fileAgeInMinutes

narrative – instructions

nounset – nouns, or nounTemplate (This can also rely on the fact that in databases, a table is considered a collection of things; adding ‘set’ is redundant).

It’s easy to change the name of something before it’s in use; but what happens when it’s in use?

Great question — one I don’t have a definitive answer to.

If you’re king of your particular hill, then you decree that the name is changed.

If you aren’t, then all you can do is raise awareness and push to having it changed in all parts of the application in the main branch, and make it an architecutural change for the next relief. It’s important to keep documentation up to date (preferably in source code) so that new developers know that in the ‘old’ version, it was called something different.

What are your thoughts? How do you deal with ‘bad names’ in Source Code?

 

Refactor Your Wetware: Review

Pragmatic thinking and learning coverI’m addicted to books. I like to read them, I like to collect them, I like to immerse myself and bathe in them.

Ok, strike that last part.

Generally I buy programming books, and since this book was sitting in the programming section, I figured I was safe.

 

Refactor Your Wetware: Pragmatic Thinking and Learning is a book that teaches you something within the first few pages and doesn’t stop until the book is closed.  It goes in depth into our methods and modes of learning and expounds upon them not only with well written ancedotes, but with research and practical examples.  From topics such as the Dreyfus Model to how our Right brain can solve problems when we’re not thinking about them, Refactor Your Wetware covers it.

Perhaps the biggest thing I learned from this book was the effect that our Right brain has on our problem solving ability.  When he couldn’t solve a particular problem, Benjamin Franklin would take a nap with ball bearings in his hand; and once he fell into a deep sleep the ball bearings would  fall and wake him up.  It was this moment when his Right brain was at its most active, and it would help visualize the answer.  This ancedote and more attest to the virtues of the right brain.

But Refactor Your Wetware doesn’t stop there. In true programming fashion, it deals with how to debug your brain and methods to remove bias from your every day thought.  It effectively covers methods of learning and retaining information with proven processes.  If you’re a knowledge worker of any sort, this book belongs on your bookshelf.