Aaron N. Tubbs bio photo

Aaron N. Tubbs

Dragon chaser.

Twitter Facebook Google+ LinkedIn Github

Have been really busy lately, and am building up a backlog of stuff to write about that I will likely never get to. I’ve been wondering why the Starbucks coffee sleeves are for one use only, but that’s a topic for another day (they’ve replaced our styrofoam coffee cups with starbucks cups, so I can pretend I have a habit). Here’s just one little nugget.

It has been interesting watching our development team change and grow. Currently, they have been discussing putting together an advanced .NET training course for the team. This is probably a good idea, since they are so Microsoft-centric, and because with a few exceptions, everything is written in C#.

But, as I’m looking through their training agenda, I see a lot of the following popping up:

  • File I/O performance
  • Network performance.
  • Mixing managed/unmanaged code
  • Interprocess communication
  • Queues
  • Distribution architecture
  • Versioning
  • Best practices
  • Encapsulation
  • Process control
  • Creating/managing threads
  • Access to resources from different threads (locking, waiting)
  • Interthread signals, thread lifecycle
  • Controlling CPU affinity

These are, without exception, elementary computer science topics. Their senior developer has proposed this list of topics for .NET training, even though it seems to be language-agnostic. That their senior developer recognizes that these are more important topics than assembly binding and deployment makes clear there is an endemic problem in this development group. A development group full of college computer science graduates should not need to cover these sorts of topics. Any university program producing computer scientists with little to no knowledge of these topics should have all of its issued degrees revoked. These are the topics you should have to teach ITT Tech grads, not undergrad computer scientists.

I know that is an extreme statement, but these are serious deficiencies, and things I have seen in supporting these applications. That no code profiling is done is silly. Very few developers I work with even known where their programs are performing slowly. Expensive data structures are naively used everywhere, consuming way too much space, and killing performance. That report-generation programs expand to use all of the physical memory until they run out of addressing space is unbelievable (and that the developer had no idea that their process could consume that much memory is inexcusable). That, for that matter, developers have no idea how their code will perform, be it faster or slower, is just plain silly. I just don’t get it. Is talent that hard to find? I know it is on the support side, but there are people that actually want to do development.

Oh well. Another work story and then I’ll stop bitching for the day (I promise). Actually, just a quick phone conversation:

  • Caller: I’ve got this list of servers with your name on it that need to be patched. It says they had to be done between 8 and 12 [currently 13:15] today. Can we patch them now?
  • Me: No, it’s not between 8 and 12.
  • Caller, irritated voice: Well, why don’t YOU check this spreadsheet and tell me when these can be rebooted.
  • Me: Ok.

So they now have a much more restrictive schedule to deal with (must begin at 5AM, may finish no later than 7AM), because I’m tired of screwing around with that sort of thing. I have four resources whose time was completely wasted because they were informed they could not test between 8 and 12, because the servers would be patched. If you cannot deliver when you say you are going to, do not come to me angry after the fact because I am not flexible.