Author Archives: Kevin Pang

About Kevin Pang

ASP.NET Developer. ALT.NET Supporter. Pragmatic Programmer. Published Writer.

My laptop died recently and because of this I've been doing some preliminary research to find myself a replacement.  It's been awhile since I've had to purchase a laptop, so I was a bit surprised when I couldn't immediately find one that I was satisfied with.  For some reason I thought that finding a suitable laptop for development that met my short list of criteria wouldn't be very difficult.  But the more research I did the more apparent it became that "software developer" wasn't a target demographic laptop manufacturers were trying to capture.  With that being said, here's my short plea to laptop makers:

Don't Mess With the Home/End/Page Up/Page Down/Insert/Delete Keys

Seriously.  We need those.  There's a reason why the QWERTY keyboard layout has remained stagnant throughout the years.  It's because people are used to it and they would riot in the streets if it suddenly changed.  Why then, are the home/end/page up/page down/insert/delete keys somehow considered free game to be mangled beyond recognition? I realize that there are space constraints with laptop keyboards, but it's not as though preserving their layout hasn't been done before. In fact, I seem to recall more laptops with the standard 2×3 layout in the past than I see now.

Honorable mention: As someone mentioned in the comments, another common keyboard change is switching the function and ctrl keys.  Most programmers — and computer users in general — use copy (ctrl-c + ctrl-v) and paste (ctrl-x + ctrl-v) so much that it's become a muscle reflex.  Swapping these two keys takes a *lot* of adjusting to get used to.

Test the Heat Under Heavy Load

Ok, so here's the thing: every single laptop I have ever owned turns into a scalding hot piece of plastic punishment after running Visual Studio for 1-2 hours.  I realize there are physical constraints that make cooling a laptop a significant challenge — and I know that I may also be in the minority here — but I'd be willing to put up with a bulkier (read: larger *gasp*) laptop if it meant that I could get proper cooling in return. 

For the most part I think laptop "portability" is vastly overrated.  The difference between carrying a 4 pound laptop and an 8 pound laptop isn't that big unless you're Steve Urkel (ok, so this may be a concern for the programmer demographic). I'm not playing shotput with my laptop.  I'm not doing curls with my laptop. I'm putting it on my lap, which can handle a little extra weight being put on it.  What it can't handle however is being scalded by a poorly ventilated brick of heat.

A 5400 RPM Hard Drive Is NOT Fast Enough

Scott Guthrie has a great blog post — written one and a half years ago — about how a 5400 RPM hard drive is often a bottleneck when developing on a laptop.  Nowadays it's easy to find standard cookie-cutter laptop configurations with 4 GB of RAM and 2+ GHZ dual core processors that are secretly tied down by a 5400 RPM hard drive.  Granted, this is less of a problem if you're willing to pay up the wazoo to upgrade to a solid state drive (and the advantages of these are even debatable in a development environment).  For the rest of us, we're lucky to have an option to upgrade to a 7200 RPM hard drive, let alone a 10,000 RPM one.

Glossy Screens Can't Be Read In Daylight

As great as a glossy screen can be for watching DVDs in the black of night, I can't read a single thing on them in the daylight.  Granted, this really isn't much of a problem since programmers are deathly allergic to natural light.  But on the off chance that I want to get some work done at a park or at the beach, there's absolutely no way of doing this with a glossy screen.

Not All of Us Want a Widescreen

As mentioned in the comments, a widescreen isn't always best for programming.  Vertical space is far more precious to a developer than horizontal space.  Most code is in the first 80 characters, so having the abililty to see 300 characters across usually just leads to a bunch of excessive whitespace.  Yes, if you're running multiple apps side-by-side, the widescreen monitor becomes very handy.  But for the typical Visual Studio developer, this usually isn't the case.

Well, that's my list.  I still haven't pulled the trigger on a purchase yet, but the comments have given me a lot to think about and research.  I don't claim to be a hardware expert so if I have grossly mistated anything here, let me know.  Have any other suggestions for this list?  Leave them in the comments below. 


Well, we all knew it had to happen eventually.  After years of great blog posts and insightful commentary on the programming world, Jeff Atwood has finally jumped the shark in his latest post which essentially says “programming is hard, let’s go shopping!”.

Now I’m not entirely sure why Jeff and Joel have decided to wage war against SOLID.  At first I thought it was just a bit of verbal diarrhea and I sympathized.  I am very aware of how easy it is to say something stupid when you’re just casually bantering with a friend or colleague.  However, from the tone of his post and the subsequent comments it received, it seems that lines are being drawn and the battle is on.

Honestly, I don’t really understand what all the commotion is about.  SOLID isn’t all that controversial in my opinion. Jeff’s main problem seems to be that by introducing so many best principles and practices, we run the risk of overwhelming programmers with too much guidance:

The bigger and more grandiose the set of rules you come up with, the
more severe the danger. A few broad guidelines on a paint can begets
thirty rules for painting, which begets a hundred detailed principles
of painting..

Pretty soon you’ll find yourself believing that every possible situation in software development can be prescribed, if only you could come up with a sufficiently detailed set of rules!
And, of course, a critical mass of programmers patient enough to read
Volumes I – XV of said rules. You’ll also want to set up a few
messageboards for these programmers to argue endlessly amongst
themselves about the meaning and interpretation of the rules.

He has a point, of course.  If we reached the point where programmers relied so heavily on rules that it hindered their ability to code, then yes, we would have a serious problem on our hands.  The problem is that this scenario is so laughably far from the reality of what average programmers are like that I wonder if Jeff and Joel are secretly just messing with us to see how much commotion they can stir up.

Dance puppets, dance!

The reality of the situation is this: the average programmer has probably never even heard of SOLID and couldn’t care less about it even after it was explained to them.  The idea that we are soon going to be swamped in bureaucratic rules that force us to think too much about the software we write is ludicrous when sites like TheDailyWTF still exist.  If anything, we should be in support of anything that will force programmers to think more about the code they write, not less.


In general I try to keep this blog as programming-centric as possible.  However, I will make an exception for this:

We're Pregnant!

7 weeks along so far for those interested.  All signs are normal right now *knock on wood*.  With any luck, we'll be welcoming our new child into the world sometime around 7/28/2009! :-) 


As many of you have undoubtedly have heard by now, Microsoft officially announced during PDC 2008 that Windows Live ID will become an Open ID provider.  From the Live Services blog:

"You will soon be able to use your Windows Live ID account to sign in to any OpenID Web site!"

That's right!  Soon you will be able to use your Windows Live ID account to log in to the 5 sites on the internet that suport Open ID!

All sarcasm aside, it does not appear that Microsoft will be joining those 5 sites and accepting Open ID logins.  Color me unimpressed.

The success of Open ID has always, and continues to, hinge on there being websites that accept Open IDs.  It's great and all that Microsoft has decided to join the Open ID party, but what they're doing doesn't really increase its utility.  The whole point of Open ID is to make it so that users do not have to memorize a bunch of usernames and passwords to log into their accounts.  Microsoft's latest move does little to further that cause since I still have to remember the same number of usernames and passwords as I did before.

At this point, the only sites that I use that accept Open ID are StackOverflow and … I can't even think of another one.  When you consider how many big names have now thrown their weight behind the Open ID movement — Yahoo, AOL, and now Microsoft — it should be shocking that when you mention Open ID to the average internet user all you get is a blank stare.  That tells me that there is something systematically wrong with the way it is being promoted.

Update 10/29/2009 3:05 PM

It appears that Google has joined the list of Open ID providers who don't accept Open ID as well.  Only they went one step further — in the wrong direction — by forking Open ID and implementing it in a way that isn't compatible with any other Open ID providers.  Are you kidding me?

I think this Slashdot comment summarizes it quite well:

OpenID's vision statement:

OpenID eliminates the need for multiple usernames across different websites, simplifying your online experience.

Everyone else's vision statement:

Fuck OpenID, I'm in control now.


Test driven development proponents often tend to push code coverage as a useful metric for gauging how well tested an application is.  100% code coverage has long been the ultimate goal of testing fanatics.  But is code coverage really all that useful?  If I told you that my application has 100% code coverage, should that mean anything to you?

What does code coverage tell us?

Code coverage tells us which lines in our application are executed by our unit tests.  For example, the code below has 50% code coverage if the unit tests only call Foo with condition = true:

string Foo(bool condition)
    if (condition)
        return "true";
        return "false";

What does code coverage not tell us?

Code coverage does not tell us what code is working and what code is not.  Again, code coverage only tells us what was executed by our unit tests, not what executed correctly.  This is an important distinction to make.  Just because a line of code is executed by a unit test, does not necessarily mean that that line of code is working as intended.  

For example, the following code could have 100% code coverage and pass all unit tests if it is never called with b = 0.  However, once this code is introduced into the wild it could very well crash with a div by zero exception:

double Foo(double a, double b)
    return a / b;

So what is code coverage good for then?

To borrow an analogy from Scott Hanselman's interview with Quetzal Bradley, imagine you are a civil engineer responsible for testing a newly constructed series of roads.  To test the roads, your first thought might be to drive over them in your car, making sure that there are no potholes, missing bridges, etc.  After driving over all of the roads a few times, you might conclude that they have been tested and are ready for public use.  But once you open the roads to the public, you discover that the bridge overhangs are too low for big rigs, the turns are too sharp for sports cars, and that certain areas of the roads flood when it rains. 

In the above scenario, you had the equivalent of 100% code coverage since you had driven over all the roads, but you only superficially tested their behavior.  Specifically, you didn't test the roads in different vehicles and under different weather conditions.  So although you went through each possible execution path, you failed to accomodate for different states while doing so.

In light of this, the only solid conclusion you can draw from code coverage seems to be what lines of your code have definitely not been tested.  The lines that have been tested are still up for grabs it seems unless you are willing to go through each and every possible state the application can be in when executing them.  This makes code coverage far less useful as a metric as it only tells you what still needs testing but offers you no help in determining when you are done testing.

What *is* a good metric then?

Unfortunately, there doesn't seem to be a good metric for determining whether a line of code has been thoroughly tested or when a developer is done testing.  Perhaps this is a good thing as it keeps us from falling into a false sense of complacency.  It simply isn't feasible in even a moderately complex application to test each and every line of code under every possible circumstance.  The best case scenario seems to be to test the most common scenarios and reasonable edge cases, then add additional tests as functionality inevitably breaks on those scenarios that you didn't account for.  It's an admitedly clumsy system, but it's a realistic one compared to depending on 100% code coverage to weed out all possible bugs.  That's not to say that there isn't use in achieving 100% code coverage.  Executing the code in one particular state still has value, just not as much as developers seem to give it.

As always, I'm very interested to hear your thoughts and observations on this.  Please leave them in the comments below.


Proverbs are used to express universal truths or life lessons in a short and memorable fashion.  I find that they are a great way to keep things in perspective, both in life and in work.  Because of this, I have assembled 10 programming proverbs that every developer needs in their arsenal.

1. There is no smoke without fire

Relax. It's probably just another fire drill

Poorly designed code tends to manifest itself through some common tell-tale signs.  Some examples of these are:

  • Giant classes and/or functions
  • Large blocks of commented out code
  • Duplicated logic
  • Deeply nested if/else blocks

Developers often refer to these as code smells, but personally, I think the term "code smoke" or "code fumes" is more appropriate as it implies a higher sense of urgency.  If you don't address the underlying problem it will come back to burn you later on.

2. An ounce of prevention is worth a pound of cure

Ok, I'm convinced

Toyota's assembly line of the 1980s was famously efficient due to its revolutionary approach towards defect prevention.  Each member of the assembly line was given the ability to halt production when they noticed a problem in their sector.  The idea was that it was better to halt production and fix the problem as early on as possible than to continue producing faulty units that would be tougher and more costly to fix/replace/recall later on.

Developers often make the faulty assumption that productivity = cranking out code quickly.  Many programmers dive straight into coding without a second thought towards design.  Unfortunately, this Leeroy Jenkins approach towards software development tends to lead to sloppy, fragile code that will need to be constantly monitored and patched — perhaps even replaced altogether down the line.  Ultimately, productivity must be measured not only in how much time is spent writing it, but also by how much time is spent debugging it.  A short term gain may prove to be a long term loss if one isn't careful.

3. Don't put all your eggs in one basket

A software team's bus factor is defined as "the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed".

In other words, what happens if you suddenly lost a key member of your team?  Would business continue as usual or would it grind to a halt?

Unfortunately, most software teams fall into the latter category.  These are the teams that turn their programmers into "domain experts" who only deal with requests that fall into their area of expertise..  At first, this appears to be a fairly reasonable approach.  It works for the automaking assembly lines, why not for software development teams?  After all, it's unreasonable to expect each member of the team to be intimately familiar with each and every nuance in the application, right? 

The problem is that developers cannot be easily substituted and replaced.  And while the pidgeon-hole approach works fairly well when everybody is available and accounted for, it quickly falls apart when "domain experts" suddenly become unavailable due to turnover, sickness, or even freak bus accidents. It is imperative that software teams have some sort of redundancy built in.  Code reviews, pair programming, and communal code go a long way to foster an environment where each developer is at least superficially familiar with parts of the system outside their comfort zone.

4. As you sow, so shall you reap

The Pragmatic Programmer has this to say about the Broken Window theory:

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

In short, good code begets good code and bad code begets bad code.  Do not underestimate the power of inertia.  No one wants to be the one who has to clean up sloppy code, but neither does anyone want to be the one that makes a mess out of beautiful code.  Write it right and your code will have a far better chance at standing the test of time.

5. Great haste makes great waste

Managers, clients, and programmers are getting more impatient by the day.  Everything needs to be done and it needs to be done now.  Because of this, the temptation to throw together hacks and quick-fixes becomes very tough to resist.

No time to properly unit test a new feature?  Oh well, it works for the one test run you put it through.  You can always come back to it later!

Mysterious object referencing error when you try to access property Y?  Whatever, just throw a try/catch block around the code.  We've got bigger fish to fry!

Sound familiar?  It's because we've all done it at some point in time.  And in certain instances, it is justifiable.  After all, we have deadlines to meet and clients/managers to satisfy.  But do it too often and you'll soon find yourself with a very unstable code base full of hotfixes, duplicated logic, untested solutions, and porous error handling.  In the end, you have to strike a balance between getting things done and getting things done right.

6. Look before you leap

The term "Agile Development" is used and abused frequently these days, often as a way for programmers to justify ignoring the dreaded planning/designing phase of software development.  We are creators, and as such we derive pleasure from seeing actual progress made towards a finished product.  Surprisingly, UML diagrams and use case analysis just don't seem to satisfy that desire.  So, we developers often start off coding without any idea of what we are doing or where we are going.  It's like heading out for dinner when you haven't yet decided where you want to go.  You're hungry so you don't want to waste time finding a restaurant and booking a table.  Instead, you just hop in your car and figure you'll think of something along the way.  Only, it ends up taking you longer because you have to make a bunch of U-turns and stops at restaurants that end up having too long of a wait.  True, you'll probably find your way to food eventually, but you probably didn't end up with the meal you wanted and it probably took a lot more time and hassle than it would have had you just called and booked a reservation at a restaurant you wanted to go to.

7. When the only tool you have is a hammer, everything looks like a nail

See?  I *told* you Active Record would work for this project!

Programmers have a tendency to get tunnel vision when it comes to their tools.  Once something "just works" for us on one project, we tend to insist on using it for every project therafter.  It can be a pain to learn something new and, at times, highly unsettling.  The entire time we're thinking "it would have been easier had I just done it the old way!".  Enough of these moments and we will simply go with what we know, even if it isn't a perfect fit for the task.

It's easy to stick with what you know, but in the long run it's much easier to pick the right tools for the job.  Otherwise you will be fitting square pegs into round holes for the rest of your career.

8. Silence is construed as approval


I see nothing! Nuh-thing!

This ties in with the theory on broken windows and programming inertia, only on a larger scale.  
The programming community is just that, a community.  Each programmer is a reflection on the craft.  The more bad code that is released into the wild, the more it becomes the status quo.  If you don't make an effort to write good, clean, SOLID code, you will find yourself having to work with it on a day-to-day basis.

Likewise, if you see poorly designed code written by someone else, you should make the effort to bring it up with the creator. I should note, however, that tact ought to be employed in such a situation. In general, programmers are willing to admit that they do not know everything there is to know about software development and will appreciate the gesture.  We all benefit when we help each other out.  Turning a blind eye to problems only perpetuates them.

9. A bird in the hand is worth two in the bush

There is a time and place to discuss system architecture and refactoring opportunities, and a time to just get things done.  It is important to weigh the pros and cons of revamping something that already works just to make it cleaner.  It's an admirable goal, of course, but there will always be code that you want to restructure.  The programming world simply changes too frequently for code to not get outdated.  But at some point you have to provide value to your customers.  The simple fact remains: you can't do two things at once.  The more time you spend refactoring old code, the less time you spend creating new code.  Striking a balance is critical to enhancing as well as maintaining your application in a timely manner.  

10. With great power comes great responsibility

Software has undoubtedly become an integral and vital part of our lives.  Because of this, practicing good software development is more crucial than ever.  It's one thing to have a bug in a game of Pong, it's another to have one in the guidance system of a space shuttle or air traffic control system.  Slashdot recently posted an article describing how a minor glitch in Google News singlehandedly evaporated $1.14 billion in shareholder wealth.  Events such as these demonstrate how much power we wield.  It's a little frightening to think that the code you write today, whether you intend it to or not, may one day be recycled and depended upon for mission-critical applications.  Write accordingly.

Do you have any proverbs you feel should be added to this list?  Feel free to let me know in the comments!


I recently stumbled across a blog post demonstrating how to convert enums to strings using the Description attribute.  I thought it might be useful to expand on that example by providing a function that reverses the process (e.g. takes in the resulting string and converts it back to the enum).  This would allow you to do things like store off the description into a database and load it back into an enum or populate a dropdown list with the descriptions and save the user's selection back into your domain as an enum.

Rather than diving straight into code, let's just take a quick look at what the finished product lets you do.  Say you have the following enumeration:

The code from the original blog post will allow you to retrieve any of the Description attributes by calling the ToDescription extension method:

And with the code I wrote, you will be able to perform the opposite conversion by calling the ToEnum extension method:

Ok, now let's look at how it all works:

Here is the slightly modified version of the extension method from the original blog post.  It's pretty straightforward.  It's an extension method on the Enum class that uses reflection to grab the Description attribute and output it.  If no Description attribute is found, it returns the result of the ToString() function: 

And here is my extension method that reverses the process.  This extension method on the string class iterates over all enum values for the given enumeration, trying to find the one that has a Description attribute that matches the string that called it.  If the extension method can't find this enum, it returns the default enum passed in the parameters.

I'm sure there are probably cleaner ways of doing this, but for mypurposes this works great and is easy to implement and manage.  I'd be interested in hearing how others are handling this scenario in their own apps and whether this implementation would be useful at all.  Let me know in the comments!


My latest article, Debugging and the Five Stages of Grief, has been published on Datamation! Here's a short excerpt from the intro:

As a programmer, you learn to accept bugs as a part of life. No matter
how hard you try, there is no simple way to avoid them. What separates
good programmers from bad programmers is not only their ability to
avoid bugs, but also their ability to deal with them when they arise.

When programmers are confronted with bugs in their applications, they
typically progress through what psychologists call the five stages of
grief. These stages are a series of emotional states people experience
when dealing with tragedy or loss in their lives.

It may seem a bit odd that something as common and benign as a bug
could trigger this type of emotional reaction, but, in a way, it makes
sense. Our applications are like our babies. We create them. We raise
them. We watch them grow, all in the hopes that, someday, they will be
able to set out on their own (and make some money to support us in our
old age).

Click here to read the rest of the article, and don't forget to leave your comments!


Datamation just posted their list of the Top 200 Tech Blogs and my blog came in at #165

I'm honored.  There are a lot of great sites in that list (#147 Joel on Software, #149 Coding Horror) and it's humbling to be included, especially given the short amount of time that I've been blogging.

On a side note, I'm currently wrapping up my next article and it should be posted shortly.  Stay tuned!  :-)


10. Comments explaining “what”, but not “why”

Introductory-level programming courses teach students to comment early and often. And while this may be a useful practice during programming infancy (when even the simplest line of code can be incomprehensible), many programmers never bother to shake the habit.

Do you have any idea what the code above does?

Me neither.

The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it. Now consider the same code with a different set of comments.

Much better! Even if we still don’t fully understand what’s going on, at least we have some much needed contextual information to go off of.

Write comments to help readers understand the code, not the syntax. It’s fair to assume that anyone reading your code has a basic understanding of how a for loop works. What they may not be aware of is why your code works or why you chose to implement it the way you did.

9. Interruptions

In general, programmers tend to be more akin to locomotives than ferraris; it may take us awhile to get started, but once we hit our stride we can get an impressive amount of work done. Unfortunately, it’s very difficult to hit your stride (also referred to as “being in the zone”) when your train of thought is being constantly derailed by clients and colleagues.

8. Scope creep

Wikipedia defines scope creep as “uncontrolled changes in a project’s scope”. Scope creep can turn a relatively simple request into a horribly complex and time consuming task. All it takes is a few seemingly innocuous keystrokes for scope creep to destroy a project’s timeline:

  1. Version 1: Show a map of the location
  2. Version 2: Show a 3D map of the location
  3. Version 3: Show a 3D map of the location that the user can fly through

7. Management that doesn’t understand programming

Ok, so maybe there are some perks.

Management is not an easy job. People suck; we’re fickle and fragile and we’re all out for #1. Keeping a large group of us content and cohesive is a mountain of a task. However, that doesn’t mean that managers should be able to get away without having some basic understanding of what their subordinates are doing. When management cannot grasp the basic concepts of our jobs, we end up with scope creep, unrealistic deadlines, and general frustration on both sides of the table. This is a pretty common complaint amongst programmers and the source of a lot of angst (as well as one hilarious cartoon).

6. Documenting our applications

Let me preface this by saying that yes, I know that there are a lot of documentation-generating applications out there, but in my experience those are usually only good for generating API documentation for other programmers to read. If you are working with an application that normal everyday people are using, you’re going to have to write some documentation that the average layman can understand (e.g. how your application works, troubleshooting guides, etc.).

It’s not hard to see that this is something programmers dread doing. Take a quick look at all the open-source projects out there. What’s the one thing that all of them are constantly asking for help with? Documentation.

I think I can safely speak on behalf of all programmers everywhere when I say, “can’t someone else do it?“.

5. Applications without documentation

I never said that we weren’t hypocrites. Programmers are constantly asked to incorporate 3rd party libraries and applications into their work. In order to do that, we need documentation. Unfortunately, as mentioned in item 6, programmers hate writing documentation. No, the irony is not lost on us.

There is nothing more frustrating than trying to utilize a 3rd party library while having absolutely no fricken idea what half the functions in the API do. What’s the difference between poorlyNamedFunctionA() and poorlyButSimilarlyNamedFunctionB()? Do I need to perform a null check before accessing PropertyX? I guess I’ll just have to find out through trial and error! Ugh.

4. Hardware

Any programmer who has ever been called upon to debug a strange crash on the database server or why the RAID drives aren’t working properly knows that hardware problems are a pain. There seems to be a common misconception that since programmers work with computers, we must know how to fix them. Granted, this may be true for some programmers, but I reckon the vast majority of us don’t know or really care about what’s going on after the code gets translated into assembly. We just want the stuff to work like it’s supposed to so we can focus on higher level tasks.

3. Vagueness

“The website is broken”. “Feature X isn’t working properly”. Vague requests are a pain to deal with. It’s always surprising to me how exasperated non-programmers tend to get when they are asked to reproduce a problem for a programmer. They don’t seem to understand that “it’s broken, fix it!” is not enough information for us to work off of.

Software is (for the most part) deterministic. We like it that way. Humor us by letting us figure out which step of the process is broken instead of asking us to simply “fix it”.

2. Other programmers

Programmers don’t always get along with other programmers. Shocking, but true. This could easily be its own top 10 list, so I’m just going to list some of the common traits programmers have that annoy their fellow programmers and save going into detail for a separate post:

  • Being grumpy to the point of being hostile.
  • Failing to understand that there is a time to debate system architecture and a time to get things done.
  • Inability to communicate effectively and confusing terminology.
  • Failure to pull ones own weight.
  • Being apathetic towards the code base and project

And last, but not least, the number 1 thing that annoys programmers…

1. Their own code, 6 months later

Don’t sneeze, I think I see a bug.

Ever look back at some of your old code and grimace in pain? How stupid you were! How could you, who know so much now, have written that? Burn it! Burn it with fire!

Well, good news. You’re not alone.

The truth is, the programming world is one that is constantly changing. What we regard as a best practice today can be obsolete tomorrow. It’s simply not possible to write perfect code because the standards upon which our code is judged is evolving every day. It’s tough to cope with the fact that your work, as beautiful as it may be now, is probably going to be ridiculed later. It’s frustrating because no matter how much research we do into the latest and greatest tools, designs, frameworks, and best practices, there’s always the sense that what we’re truly after is slightly out of reach. For me, this is the most annoying thing about being a programmer. The fragility of what we do is necessary to facilitate improvement, but I can’t help feeling like I’m one of those sand-painting monks.

« older posts newer posts »