My Ego is Bigger than your Ego

There’s no doubt that ego plays a part in software development.  We’re all in competition with each other.  Not just for work, but in terms of “geek points”.  I am unashamedly egotistical when it comes to software development.  I love to point out how clever I am and tell people about this crappy wonderful little class I just wrote, or how I found a bug in so-and-so’s code that made a really big issue go away.  I can say this safe in the knowledge that I probably cause as many problems as I fix.  I know that never a day goes by when one of my colleagues in either this or a past life comes across some code I wrote and sighs quietly to themselves before taking a sip of a caffeine-infused drink and “refactoring” it.

Much as I’d like to be, I’m not the world’s greatest software developer.

I am, however, a geek.  This is where the competition and virtual chest thumping really comes from.

There are loads of ways to earn geek points.  Having a blog is one way but a bit obvious.  Better is to use Twitter or FriendFeed.  How about an account on StackOverflow.com?  You might have an iPhone* or contribute to an open source project.  Hell, you might even have a “There’s no place like 127.0.0.1” t-shirt in a different colour for each day of the week.  You should also use the word grok a lot.

An ego in software development, like competition in any other area, is a good and healthy thing.  It’s what drives us to create something better, cooler, faster, more reliable than our peers.  Developers love nothing more than to write software for developers.  I believe this is both because we are writing it for ourselves, but also because we know that other developers are the only people who will really grok (+1 point) what we’ve done, and appreciate what it took to get there.  Other developers are the ones that will spot the bits where the mouse pointer didn’t turn to a wait cursor.  They’ll notice if your app becomes unresponsive and suggest clever things like multithreading and BackgroundWorkers.  You respond by saying “yeah, this is just the first version – that’s all part of the plan”.  We want our peers to say things like “Dude, that is so cool”.

This attitude isn’t necessarily what our employers are looking for, however.  There are those out there that can afford to let developers experiment, of course (Google is probably the best known for this), but most companies need to earn money.  They’re not interested in your implementation of Castle Windsor or ASP.NET MVC, and will struggle to be sympathetic with your reasoning.  “Because it’s so cool” doesn’t cut it.

Also, when you have multiple egos in a team, it can be mildly unproductive.  Software developers are intelligent people for the most part but that in itself can be the problem.  Put some together in a room and most will have their own variation on the solution.  At some point someone needs to step up and say “Okay, that’s all great stuff, and we’re going to do it like this…”.  Bear in mind that this doesn’t have to be the right solution.  Software and opinions can be changed.  You just need an agreed spokesperson or lead to make the decision so you can break the tie and each get back on with developing.  Of course, secretly knowing you had the best idea all along…

* And for bonus points you should have a 2G *and* a 3G version.

Too Hard == Broken?

I’ve spent a few hours over the last couple of days trying to get NHibernate to work. I failed. As soon as I call Configuration.Configure() I get an exception. I’ve tried various combinations of app.config and hibernate.cfg.xml files etc to no avail. I give up.

And this isn’t the first time I’ve had this. I’ve started to think, that if I can’t get something to work, its effectively a fault. A bug, no less. I’ve blogged about the risk of learning a new framework, and this proves my point perfectly.

I’ve taken to giving up on things like this.  I have better things to do with my time than work through problem after problem after problem trying to get something working.  I even recently uninstalled Resharper, because while it was very good, it stopped my solutions opening quickly. Sometimes entirely.  Again, broken.

So I’m going to look for an alternative to NHibernate that I can get running, and therefore “works”. It’s official – NHibernate is broken.

Unless you can help me out…

One Job to Do

My PC will confound me several times a day, every day. It’s not just me, either.

Today I had trouble installing .NET 3.0. Recently I’ve also had problems with Explorer freezing, the Outlook notify icon stays visible even when I have no unread email, and occasionally double-clicking a file only opens the application and not the file. Grrr.

These are all things that should just work (though I hear not even Apple are doing so well in this area recently…). These are tools, appliances, they have one job to do and I expect them to do it. SVN was recently a problem for me. The settings for Tortoise SVN to integrate with Araxis Merge didn’t seem to be giving the correct results, and only after many hours of poring over various files and reading various TSVN webpages did I find that it was just confusing filenames causing my problems, and that everything was working perfectly.

I’ve installed and almost as quickly uninstalled Resharper, too. I’m really disappointed about this, but the 20-minute performance hit opening one of my solutions (before I got bored and killed the process) was too much to bear for the additional refactoring tools. I was looking forward to catching up to where I was 4 years ago on Eclipse, too. Turns out I’m not the only one.

These often aren’t actually problems with the tools as much as the environment they’re in. Other people say it works on their machine.

So this has turned into a rant, and I’m not the only one who’s been through it I’m sure. I’m at a point where I’d like to re-install Windows, but seriously – that’s a lot of work. I get upset too easily.  The really worrying thing is that there are probably lots of people out there thinking the same thing about software I’ve written…

The Evil of Implicitness

I really dislike things that are implicit. Okay, it doesn’t help that I’m the most forgetful person I know, but still.

I’m a believer that if you want something done, you should do it. Use a framework if you like as a tool, but explicitly ask that tool to perform the task. Things shouldn’t be hidden away, doing as they please.

Examples:

Post build steps
I’ve mentioned it before, but I really do like my build process to explicitly do everything I need, in one place.

SQL
My boss gave me a tip yesterday. He says that for things like this:

insert into a_table (id, the_value) values (1, 11)

He sometimes cheats and does this:

insert into a_table select 1, 11

I think that’s dead clever (because I thought you had to specify the columns you want to insert into), although I’d personally never run it on a production database, and it would only be for quick and dirty test code on a database I control. The problem is (and to be fair he admitted this), if someone changes the schema of that table, things can get messy very quickly. I’m more anal so my first thought was that I just like to know what columns I’m editing without having to investigate that table schema before I run it.

Of course we all know the evils of:

select * from a_table_that_might_have_columns_added

Which speaks for itself, so let’s not dwell on that.

Attack of the Scheduled Job
I personally dislike any kind of scheduled task. It makes me nervous to think that there’s an unknown cloud of processes that I don’t know about that might be editing my data without me knowing.  Also, you lose a bit of the “realtimeness” of information with scheduled jobs. Of course sometimes this is necessary, as in the case of maintenance tasks.

So I like to do things by hand a lot of the time. I don’t like to write classes that do work in constructors, I prefer instead to use factory methods or create static methods called “Load” which create the object and populate it for me. Right or wrong is tough to decide, and is probably a religious issue as much as anything else. But “better safe than sorry” and “keep it simple, stupid” are principles that make applications easier to maintain, because you avoid more issues from happening, and make it easier to find and fix those that do appear.

Hidden in plain sight

What’s your opinion on pre and post build steps? Personally I prefer all my build operations to be performed by the build script itself, so that if there are any problems to be fixed or changes to be made, I only have one place to look and one thing to update. Post-build options are what you look at hours into a problem when you finally remember that you have them, so can make debugging your build process much more difficult.

Let me know what you think.