What’s my Programmer Competency (take 2)

I stumbled across an old blog post of mine, What’s your Programmer Competency?, where I outlined my self-analysis results using Sijin Joseph‘s Programmer Competency Matrix. I figured it was worth revisiting this and see how much things have changed in the eight years since that original blog post.

The Programmer Competency Matrix is measured on a scale from 0 to 3, with 3 being highest.

  • Computer Science: 1.3. Back in 2008, I was a 1. The reasons for the low number today is the same as eight years ago: my computer skills were not learned in the classroom, but in the real world. I’m not a computer scientist (as per the academic definition of computer science). But that’s not a bad thing, because most of the business world doesn’t need computer scientists!
  • Software Engineering: 2.7. Now we’re cooking. The only reason this isn’t a 3 is because I don’t have much experience in automated functional testing and UI testing. This is one area where I’ve continually developed my skills over the years, and the past 8 years have been no exception to that.
  • Programming: 2.9. This is a huge category so I won’t give myself a 3.0, but I’ve got most things in this category nailed. Reusable code? Check. Published frameworks? Check. Ridiculously well-organized code? Absolutely!
  • Experience: 2.3. I’ve got a lot of experience in the technologies that I work with, and I have light experience in a lot of other technologies. Not having experience in things like Erlang and Prolog drags down my score here, but I’m not selling myself as an Erlang or Prolog expert, so I’m happy with my score.
  • Knowledge: 2.4. If my career track was 100% development (and not more of a development/management split) this score would have been higher, but I’ve long ago accepted that part of my value is not just my programming knowledge, but my ability to interact with and communicate with people, not just machines — which is why I’m not spending my entire days sitting behind a computer writing code.

Not bad for a guy who started off as an infrastructure engineer, became a programmer out of necessity and curiosity, and ultimately made a career out of it all. Who would have thought this would happen when I was 12 years old hacking an Atari 800?

What’s your Programmer Competency?

Via Gadgetopia, I stumbled across the Programmer Competency Matrix by IndianGeek.

What is my programmer competency, you ask? Let’s find out…

  • Computer Science: Level 1. This is not surprising to me, as the only formal computer science training I have is an Introduction to Programming class I took in college. I got an “A” in the class and spent half the time telling my classmates that the teacher was wrong. The class taught Pascal, a language I learned to use in 1984, because I was a 14-year old geek who wanted to learn programming beyond BASIC.
  • Software Engineering: Level 2/3. Before becoming a programmer, I was a systems engineer who scripted just about everything you can imagine (which is programming, too, but traditionally not looked at as such). In fact, me and a coworker scripted all Year 2000 compliance testing and updates for 2,500 users in a Fortune 500 company. We used to challenge each other to see who could do more work in one day without leaving our desks. We weren’t lazy; we just preferred to move around during lunch and for the 3:00 half-price cookies in the cafeteria.
  • Programming: Level 2/3. This is a huge category, so it’s hard to say anyone would be a solid “3,” but I feel I’ve mastered a good chunk of the items in here. The one I think I’m best at: “communication.” (Ask anyone who worked with me — peer, subordinate, or manager — and I think they’d concur.)
  • Experience: Level 2. I’m a programmer by evolution, not by initial choice. I’ve spent as much of my career as a programmer as I did as a systems engineer, so I lose points here.
  • Knowledge: Level 2. If I had time to read everything I want to, I’d be better in all categories above.

Continue reading

Bad programming examples (part 1 of x)

There’s no end to the number of bad programming examples we’ve seen in the past or will see in the future. Recently, I saw this one. (This was actual code seen in an actual project.)

try { createDate = Request.Params["createDate"]; }
catch (Exception) { createDate = "-1"; }

Nice and ugly. Aside from a horrible way to implement a try/catch block, it screams of performance issues and unreadable code.

A more proper alternative follows.

createDate = Request.Params["createDate"] ?? "-1";

The same project also had this use of integer parsing.

try { myInt = Int32.Parse(textBox.Text); }
catch (Exception) { myInt = -1; }

In this case, you would use the TryParse method instead:

if (Int32.TryParse(textBox.Text, out myInt))
    myInt = -1;

Exception handling is for exceptions, not for null checking or validations.

Five simple rules for creating delimited text files

Here’s a few tips for those people who provide raw data in text files (think CSV files and the like).

  1. Surround all text fields in single quotes, even if a comma does not exist in a specific instance. By failing to do this, you lose field delimiter consistency on a row-by-row basis, forcing the contents of the field to be parsed separately (i.e. stripping the “optional” quotes).
  2. Use consistent line endings. Pick one and stick with it for all your files. Use either (CR/LF), (LF), or (CR) — and use the same in all your files.
  3. Put column headings in the first row only. This is more a convenience than a necessity. If you make your first row column headings, make sure it is only the first row.
  4. Every row past the first should have an identical schema. Don’t try to be fancy and have different row types in one file. Each file should have the same number and sequence of columns.
  5. Provide delimiters for all columns, even when a row does not have data for them. For example, in a comma-delimited file with five columns, if a row has data in only the first two columns, make sure the row ends with three commas. Failure to do so implies missing or incomplete data.

When text files following these guidelines, I can write a script to import them into a SQL table (using BCP and a simple batch file) in a few minutes. Each guideline that is broken requires additional cleanup steps and more complex data import steps, and adds significant development (and debugging) time that shouldn’t be necessary.

Three tips for grief-free project estimates

Having spent six of the past ten years as a consultant, I’m all to familiar with the practice of estimating. Every client wants an estimate, and every client wants your estimate to be accurate. Of course, clients also don’t want to give you concrete requirements that are needed to give an accurate estimate, either, which compounds the problem.

Scott Hanselman has a nice post about estimating, where he mentions two lessons I learned over the years:

  • Make your estimate, then double it. I actually took this a step further. If an estimate had to be given based on very sketchy requirements, I’d double it twice (effectively quadrupling it). This practice leads to…
  • Under-promise and over-perform. Always make sure your estimate gives you sufficient cushion to come in ahead.

A third lesson he doesn’t mention is to be willing to walk away from a client if your estimate is too high. If a client balks at your estimate (even if you double, or quadruple, it), you can either reduce the scope of your proposed work (and thus reduce the estimate) or walk away. I’ve taken projects that I’ve regretted taking after all was said and done, and most of them can be attributed to me skimping on my estimate because the client was scared off by my original (and, usually, more accurate) estimate.

These lessons go not just for programming projects, but for nearly everything in life. Over-estimate, under-promise, over-perform, and don’t shortchange yourself. Words to live by.