Posted on July 2nd, 2008%
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.
. . . → Read More: What’s your Programmer Competency?
Posted on April 25th, 2008%
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.
. . .
→ Read More: Bad programming examples (part 1 of x)
Posted on May 16th, 2007%
Here’s a few tips for those people who provide raw data in text files (think CSV files and the like).
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).
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.
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.
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.
Provide delimiters for all . . .
→ Read More: Five simple rules for creating delimited text files
Posted on May 9th, 2007%
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), . . .
→ Read More: Three tips for grief-free project estimates
Posted on April 30th, 2007%
As part of the overhaul of the WilsonORWrapper, I’m adding a cache service. To do this right, I need to implement an ICacheClient interface. This interface will define the methods and properties which any cache client will need to implement.
Sounds simple on the surface, but I quickly ran into a problem. What do you call your methods? Consider the following possibilities for naming four core methods.
Retrieving an item from the cache: Get, Retrieve, Load, Fetch, Read, Select.
Placing an item in the cache: Put, Set, Add, Insert, Save, Update.
Determining if an item exists in the cache: Contains, Exists, Has.
Remove an item from the cache: Remove, Delete, Clear.
Clear all items from the cache: Flush, Clear, ClearAll, DeleteAll, RemoveAll.
The worst part of determining a naming convention is that you are generally stuck with it once you choose it, unless you want to implement breaking changes into your application.
Most of the names above were found in some cache API currently in existence today. (I . . .
→ Read More: Choosing method names for a cache interface
|
|
