It is an interesting phenomena to consider, our human ability to turn that which we find extraordinary into something mundane, or even undesirable through repetition.

For example, as far back as I can remember I remember that I would have given anything for a Job that let’s me deal with computers and/or programming all day long. I even promised myself I would never take it for granted.

For the last year that has been a reality- and that reality turned from a dreamy visage that I expected to be forced out of into a harsh reality where it did not exist, to something more like the constant cold feet you would get from not wearing socks during winter. It’s something that we might not notice without reflection but something that I think we all should be vigilant for to prevent stagnation.

I recently noticed that about myself. And it has a implicit duality that makes it both dumb and valid simultaneously. On the one hand, we have a case of comparing what we thought to reality- and what we think something entails seldom fully indicates what that something is in reality. After all even the best job will leave you frazzled and worn out at times.

At first I thought this was a result of it not being a fit. Perhaps, I reasoned, I simply cannot do this. However on further thought I think that is simply a good indication that one is working. It’s possible to both love doing something while at the same time not enjoying it. This also has an interesting mixin (no pun intended) when we look at the overall message of books like “Clean Code”. Many of the common frustrations of Programmers is the result of, well, programming. For example, if we are constantly bumping into some code limitation we built in a library; or we are frequently writing and adapting to new viewers and wrappers and filters and other programs that call other programs who’s syntax is frequently changing and so on and so forth. Just yesterday I (and a few others) spent the entire day trying to figure out a single problem that turned out to be a comparison method that was not transitive- and was used for completely redundant debugging code. I wasn’t able to appreciate the irony of something written to aid debugging causing problems with debugging later at the time but I can do that now.

It is an interesting contrast to compare the sort of solid, well-engineered, modern software you expect to see being used for businesses mission critical software with the software actually being used. As an example, at my previous job we clocked in and out using a touchscreen system. The software was reasonable on the surface but I was able to copy it and decompile it and see the guts and it features innumerable things that I found abhorrent; hard coded passwords and usernames, poor flow control, and all sorts of other oddities that seemed completely out of place for a software suite that had it’s intended level of usage.

Of course that perspective fails to take into account the possibility that the software had to remain compatible in some way with older software; or perhaps at some point it was moved from ISAM to another database until finally being moved to MySQL and accessed from C#. So it has a lot of legacy.

I have yet to finish the book “Clean Code”, or really even get started. But one message I think I found that seemed clear was the idea that software should be rewritten at intervals. This flies in the face of my more conventional understanding where rewriting an application or program is bad, especially considering we have so many examples of the latter. But the reasoning it presents seems quite sound, And certainly seems to fit with my own experience. The fundamental idea is to prevent too much legacy from carrying over from decades previous. For example, if we have a MySQL table called “RESVPOSX”, then we have a very clear smell. And in the long run it is always best to eliminate as many smells as possible. It just makes sense.

The problems appear when airing out the code in such a fashion by refactoring it, renaming things, and moving things around as well as adjusting them start to stack up in terms of man-hours as well as causing even more problems. It can seem almost counter-productive- one day it is agreed that the configuration names need to be standardized, the next you are dealing with the problem of moving the old systems using the non-standard names to the new system without breaking other systems at the same site that are running the old version and not breaking new versions when those old versions run. It’s a endless game of cat and mouse and fundamentally there is no end to it. Any piece of non-trivial code can always be made faster, cleaner, easier to read, or easier to use from other code. The real question is when you draw the line.

As a direct example I’ll take BASeBlock. For the moment we will ignore that I haven’t touched it in ages since that isn’t related to my point. It was effectively a rewrite of a game that was pretty much the same. I learned new things while writing that first one and applied them to BASeBlock; When I wrote BASeBlock I learned even more and applied them to “PreHender” which is a game who’s name had some clever backstory that I don’t remember at all but has at least succeeded in making a name that seems unique. This is important, I think- learning new things about the language and technologies of which you use. It’s even cooler when you get to use those technologies and programs in your work later on- There is something somewhat fulfilling about having Update code I wrote over 5 years ago in my spare time when I was making minimum wage be applied and reconstituted with a dose of liquid refactoring to a real live project used by real live people. At the same time, however, it can also be scary. to take another direct example of this, for this website early on I felt I could use an Updater. Or, rather, the creation of an Updater to meld with the PHP of the site seemed like an interesting challenge. And that is what I did- I created a web-based Update system that I found to be quite powerful. It existed in a few of my programs but to be honest nobody is going to be affected financially if their version of BASeBlock is out of date. There is something- uneasy- about having that code be placed in an environment where it working and working well is of the utmost importance. This I have done and if there is one thing I can say it’s that we have somehow moulded it into something that works great and presents a pretty cool looking sort of “front-end ” first experience of sorts.

My use of the word “we” rather than “I” is important above. If there is one thing that is important to realize is that in any development team there are islands of one. Without the ability to work with others you are going to fall on your face; and without the ability to interact with others without exposing yourself as a social retard you will also experience problems. The worst mistake any developer can make at any point is to ever think they are, for whatever reason, smarter than their co-workers. That is an incredibly stupid and perhaps ironically small-minded approach. I won’t get into that too far except to state that if at any point you think that, you are wrong. wrong wrong wrong. Additionally, it’s worth noting that if you are in such a state of mind where you are thinking such things about your other team members, they are almost certainly thinking the same thing about you. A team where every person thinks they are the smartest will end up being the dumbest- it’s anti-productive and trading in productivity as part of a team for some form of validation of your own hubris is one of the biggest mistakes you can make.

A much better approach seems to be that expressed By Scott Hanselman. Fundamentally, if you just assume you are the dumbest, the worst outcome is you learn. On the flipside, this does mean you can’t just let your team members blame shift everything onto you. One needs to strike a healthy balance, and it is almost certainly difficult depending on the size and makeup of the team in question.
and work towards a common goal- Too often you see development teams and IT teams turn into a game of office politics where individuals blame-shift to other members of their team in order to position themselves in some entirely imaginary “pecking order”; This is counter-productive because it doesn’t establish any form of teamwork, instead of drives wedges between members of the team and creates rivalries.

Another consideration I think is important is to keep your mind at work. Speaking personally the challenges I would face through my work are going to be wholly different in many ways from any I would face from my work on BASeBlock or Prehender, or many of my other projects- Still programming of course, but the problem sets will be entirely different. Where one focuses on legacy compatibility and data integrity, another focuses on what particde timeout and acceleration or alpha falloff makes the coolest explosion. There is something to be said about being able to write an Application or Program without having to care about whether it ever works- This is something that I did back with VB6; I had so many program ideas over time (it’s a shame I lost them) came up with entire MenuStrip-type frameworks that used hooks, wrote custom tab controls, and all sorts of things like that, but at no point did those things need to work- that is part of what might have made it most enjoyable. That is not to suggest that working on programs with goals that need to be met is much different- the difference is simply that the goalposts are more rigid, but they also won’t get smushed under the weight of not caring, because you need to care on a professional level.