What's it all about, Alfie?

I really don't like the "shortcuts" a lot of people put into code. They don't really make it more readable, and they certainly make it a lot more brittle. Case in point, today I realized that the code in a rule was written:

  if days_since_assignment && days_since_activity
    # do something
  end

where these variables/methods are nil for those times when there is no respective date. This seems OK, but it's really not. In order to do a good, robust, check, we need to see if it's not nil and then check the value or include it in an inequality. There's no other way.

Now your typical Ruby Code Monkey will say "No! That's not the Ruby Way!" and they'd be right, and the Ruby Way is, in this instance, horrible for so many reasons.

I'm a fan of making things comparable wherever possible, and that means get rid of the nils. Make it simpler - use Float::INFINITY for the return value of a "days since" method if the date doesn't exist. At least that way, it makes sense in all comparisons, and it's at least no worse in some edge cases for testing values. Most often times, it's exactly what you want.

So I had to go in and change what appeared to be "working" code to something that actually worked as intended all because of this desire to minimize typing. Had the original author said:

  if !days_since_assignment.nil? && !days_since_activity.nil?
    # do something
  end

then at least it would be clear what was going on. Returning an INFINITY now makes it clear that we're never going to fail these checks as a nil is never a possible value.

It's all this maturity that I see missing: no comments… minimal typing… over the top refactoring… fascination with new and shiny things… I believe these guys could be great, but they limit themselves and they don't have to. They can see what they should be doing, and they even know they should be doing it. But they choose not to.

I wish they didn't make that choice.

This morning I come in to see that we're horribly behind in processing the UAT divisions! The new Salesforce sandbox is a joke! I've got to trim back what we're doing in UAT and get the Salesforce Team on this because we can't let this go on… it's simply unusable.

UPDATE: it took 16 hours to finish this run! That's up from about 3.5 hrs last night - all due to the new Salesforce sandbox. This can't stay this way… I'm moving UAT back to the Staging sandbox as it had decent performance.

This afternoon I had to move our development and UAT environments to a new Salesforce sandbox. This one is supposed to be the place we'll be doing our development and releasing code to the Salesforce Team's promotion process, so it made sense to get it right and just do it.

The process wasn't hard - I've got it all documented from the last time I had to do this, so it went pretty smoothly. Just needed to get it done.

I've been thinking a lot about a conversation I had with my manager about producing versus well thought-out design. He seemed to think that it was a trade-off, and the more I think about it, I think he's wrong. Oh sure, there are tons of trade-offs in engineering and software development, but there isn't a trade-off in putting out good code every day, and doing it "right". There can't be.

If I'm putting out a bunch of features in a day - every day, then they can't be hacks, or some day they are going to catch up with me and make it impossible to go forward. That's not sustainable. What is sustainable is to make sure that you're writing good code… well thought out code… but you're doing it like you mean it.

For example, today I had to go through a lot of code written by one of the Code Monkeys that was really slapped together and included no documentation at all. It was a rules system and it wasn't working cleanly because the methods were quite the rules, and they weren't quite the factors of the rules, so there were nasty dependencies, etc. that made it very hard to figure out what was happening and how to fix it.

I had to clean it all up, make the methods either condition checks or rules, and all rules simply were collections of condition checks, had to clean up some of the tests based on the logging strings, and in general, just make it a lot cleaner.

This didn't take me long, and it took me a lot less time - even under pressure of fixing bugs, then it did to create it by the original author. So it's not about the time required, it's the actions that are taken.

There's no trade-off here. You have to be good at what you're doing or you're going to make a mess. Period.

I can see when code has been lazily copy-n-pasted and not really incorporated properly. I can see when coders leave in hard-coded values when they thought they were changing things out. It's not all that hard. This morning I've been doing quite a bit of this kind of bug fixing. It's not all that hard - it's pretty easy stuff to spot, but it makes me sad for the guy that wrote it, because I'm not going to see him in the same light as I had.

Also, comments would be nice when I'm digging in a new web framework (Sinatra), and I really need to get up to speed on these Ruby web systems sooner rather than later as it's going to become more important to me that I'm able to write these - as opposed to just bug fixing them.

I suspect they just don't care, and aren't motivated in the least to care. So I really have to try very hard not to think it's who they are - just how they are responding to the job.

I know I've written about my lack of understanding with the apparent desire by Ruby devs to write no comments, but today I officially said out loud: "This is my grown-up Christmas wish: Comments in the code", and I really mean it. I was in the middle of trying to figure out a Sinatra app, and the entire file had one comment, and it was a TODO: as opposed to mentioning what the code was actually doing.

I think I have an idea why this is the case… face it, comments can "ruin" the look of code. It spoils the "line" and "flow" of the code. The only reason they are there is to save time for the developer trying to understand what's happening. But suppose you had a developer that didn't care about the time it took to understand the code?

Then you'd have a person that didn't like comments.

It's not about caring about the "next guy". It's about the beauty and ascetic of the code. And if you simply don't care that it takes you more time to figure things out, then there's no downside. I didn't understand - until now, that it wasn't that they were lazy… it was that they simply didn't care about getting things done.

Certainly not in comparison to the style and look of the code.

Which explains so much.

Why is it that there's so much ping-pong and pool played during regular hours? Well… if you're not concerned about delivering things, this is easy - you have friends here, and the table is right there. It makes perfect sense when you realize that they just don't care.

But Why? That's the biggie, right?

I have a theory, and it's based on a conversation I had with someone here. The focus is on sustainability. If you want to keep people at a position, you pay them well, staff the projects well, and expect a moderate amount of work from them. This allows them time to learn, grow, and rest - while getting a little work done. Consequently, they don't see "management" sweating about a few lines of code… or a few hours to re-learn what it's doing. So no big deal.

This might be the wave of the future, I have no idea. But it seems to me that in comparison to the other places I've worked - including my own company, this is only sustainable as long as they have money to burn. When money gets tight, they will expect more for less, and then things will have to change. At that point, there may be such an entrenched culture, it's impossible. No way to know.

I just know what I want for Christmas, and have a feeling I'm not going to get it...

I had no idea that the decompression I'd feel from leaving Finance and entering a pseudo-startup. I really didn't. In the beginning, I was thinking it'd be really nice. Sleep in… have lots of vacation… take your time learning new things - what's not to like about that? But that's not the whole picture, is it? It's never as easy as one quick look might suggest.

Today is another great example of some of the problems I'm facing in moving from where I was to where I am - and it's not about jerks, or mean people… it's about being in a Team, and having a Team member decide that he knows better than you - even though he's got far less experience than you.

I'm currently in a team that has lost three people - one to leaving the company, and two to other positions in the company. Unfortunately, two of those were really good guys, and I'm going to miss their approach to software development. As I told my manager yesterday in a 1:1, every project has "grunt work" to do - things that have to get done to move the project forward, and get deliverables out the door. It's called production for a reason.

Now I'm good at delivering code. Really good. Primarily because in Finance, you have to be, or you have to find another job. So I got good at it. That's not to say that's what I prefer to do, but I know that if the team doesn't deliver, it's not going to be long before they look to "lighten the load" of the team. I've no intention of that happening to me.

So I pick up the work if it's sitting there.

In a good team, others do this as well, so any one individual does a little, and the load is not dependent on one guy doing it all. But if you're in a group of people where they don't see that as "necessary", or they feel it's "beneath them", then you end up with a group that's very dysfunctional. In my case, that's where I am - doing about 90% of the code that's delivering.

This by itself, wouldn't be so bad. After all, I know what I'm doing, I trust that management sees the effort I'm putting in, and I'll get compensated for it. Not bad. But for the last several days, one of the guys in the group has been working on integrating the log files with an automated scraper - splunk, and while it was possible to build all the queries he needed with the tools at hand, and the log lines as they were, he decided that it was really time to make the logs less human readable, and more easily used by splunk.

This, I argued, wasn't a good idea. Log files are for people, not machines, and this was making them less readable, and that was bad. I tried to convince him that this was a bad direction, and he'd have none of it. No way I was going to convince him.

All this work - three days worth, because he wanted to gather a series of numbers in one query - not two.

Really!?

Two queries is "Bad"?

I had to walk away. I tried to talk him out of it. Just like I told my manager I'd try to do. But he was insistent. Totally unwilling to compromise. Yet I caught several errors he'd made because he wasn't paying attention to what he was doing.

I really hate this. I'd rather he just take time off and not be a problem as opposed to making things worse for me. And that's all he's really done. He's made the logs worse, and for no good reason whatsoever. None. The data was there, it's now there, but in a non-human-readable form, and he thinks that's "even"?

These kids, and that's all I can think it is… these kids have no respect for experience. None. But hey… why should they? They have done it all, right? They have built it, and it only took three days. Total crock.

Every now and then I find that CouchDB on my laptop really needs to be restarted. Because it was installed with Homebrew, it's for an entry in my ~/Library/LaunchAgents/ directory - so it's best to do it nicely. Meaning don't just kill it. The simplest way to do this is just:

  $ cd ~/Library/LaunchAgents
  $ ls
  org.apache.couchdb.plist
  $ launchctl unload -w org.apache.couchdb.plist
  $ launchctl load -w org.apache.couchdb.plist

The unload stops it, and the load starts it again. Very neat and clean.

We have been trying to move to JRuby 1.7.0, and running into a fair share of issues along the way. But still, we press on. Today we tried again, and failed, being stuck by another Dir.glob issue that has been a persistent little problem for us.

There are a lot of reasons we want to be on JRuby 1.7.0 - better socket implementation, better handling of exceptions up the stack, and better ruby 1.9 compatibility. All good things. But not being able to deploy in a jar has been a real pain. We need to be able to do this, and without it, we really can't move.

So we have been digging into the issues. Thankfully, for the latest one we have a work-around. It seems that JRuby 1.7.0 can handle Dir.glob, but only if the "path" does not start with jar:. Very interesting.

The work-around, then, is very simple:

  def project_root
    @project_root ||= File.dirname(File.dirname(__FILE__)).gsub(/^jar:/, '')
  end

will get the root of the project in the filesystem or jar, and then if it starts with jar:, it'll strip it off. We use this for all file pathing, and we're good to go!

This morning I noticed that Google Chrome dev 24.0.1305.3 was released with some really nice updates including the V8 javascript engine 3.14.5.0 and a significant update to how bookmarks are handled in the omnibus. From the comments, it's pretty clear that the omnibus is used by a lot of people for much more than a place to type a URL or a google query - which is nice, but it's certainly not behavior I'm looking for, so I never really "missed" it.

But as always, it's great to see the progress - even if it's something I don't really use.