Tag Archives: Programming

Sign of an Immature Programmer

This is a bit of a sticky subject, akin to the endless debates on what makes a “real” programmer (not to be confused with a Real Programmer). I don’t use the term professional because that simply denotes something that you do for pay, with the assumption that if you’re being paid for it, you have a certain level of competence.

However, there are stages of development that people seem to go through as a programmer. Just because one is at a certain stage doesn’t imply goodness or badness, it’s simply where one is at.

I’ve been working with a remote team in a not-to-be-disclosed location, and have been struggling with their work because while they can code, their practices have a lot to be desired. At first I attributed it to incompetence (of which there is a degree), but for my current struggle, I’ve settled on the explanation that they’re still immature in their development practices.

The thing I’m struggling with right now is revision control. In past discussions, I’ve been told that there’s not enough time, the schedule will be hurt, it’s too much trouble. Now that I’ve been forced to cut off direct access to the servers and have said, only through revision control, the truth has come out. The e-mail said, in essence, “Uhm… what’s revision control and can you tell us how it works?”

These people are technically professionals with degrees in computer science, but in my book this is a sign of underdeveloped maturity as a programmer. Revision control is an extremely liberating tool that allows one to work with reckless abandon, knowing that the next “I don’t believe I did that” moment falls from being a devastating heart-stopping mistake to an annoyance. It’s used to varying degrees by individuals, but at least in my circles, I don’t know of a single competent programmer that doesn’t have some form of personal revision control system in place.

In professional situations, a lack of revision control is in my book inexcusable. Client assets need protection, the software process needs the flexibility and surety, and developers don’t need the headaches.

Now it’s a interpersonal and management problem that I have. The inner annoyed part of me wants to say, “RTFM.” But we have work to do, so I’ll need to do a little hand-holding to not interrupt the flow.


/tmp on OS X

Under Linux and most other Un*x systems, you can rely on the directory /tmp being the system scratch space. As such, you can pretty much use /tmp without fear.

On OS X, each user has its own scratch space. Use the NSTemporaryDirectory() function to retrieve the directory name.

Here is a small bit of Objective C example code.


int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

// print the current user's scratch directory.

[pool drain];
return 0;

Update 2009-07-27:
On the command line, the TMPDIR environment variable holds the same value that NSTemporaryDirectory() returns.

Removing Sticky Packages from Delphi Projects

In the Delphi IDE, when working on a project, you open a package (.dpk), then close the package. However, when you open the project at a later date the package “sticks” to the project. In other words, the package is listed in the Project Manager window. Sometimes the package becomes the default active project, so when you compile your project, the package is compiled rather than your project. This forces you to go to the Project Manager window and activate your project before you can compile. It’s annoying.

The cause of this is that when you close a project, the IDE remembers which windows you had open, breakpoints, and other IDE state information for that project. It does this by storing the layout in the desktop (.dsk) file. For some reason, even when you completely close the package file, the Delphi IDE remembers the package in the same way that it remembers the files you have open in the IDE. This does make sense on one hand. Packages are more than a source file, but less than a full-fledged project. However, packages have side effects that normal source files don’t. This is why the package seems to be “sticky”, showing up every time you reopen the project, and possibly interfering with your work on the project.

To get rid of the pesky “sticky” package there are two options. For both of these, do not have the project open in the Delphi IDE. If you do, you’ll end up overwriting your fix when you close the project and the IDE rewrites the desktop file.

Method #1

If you don’t care about which windows you had open, breakpoints, etc. you can just delete the whole .dsk file. Bam!

Method #2

On the other hand, if you want to preserve the IDE state without the “sticky” package, deleting the entire desktop file is too draconian. You’ll have to edit it. This is pretty simple. The desktop file is in Windows INI format. Open it up in your favorite text editor. (As an old Un*x head, I like vim.) Search for the name of the package’s file name, and delete the offending INI sections. Save the desktop. When you reopen the project, the IDE will not see any references to the package. Thus the pesky package will not show up anymore.