Showing posts with label Base. Show all posts
Showing posts with label Base. Show all posts

Tuesday, November 20, 2012

What else could it mean?

When your manager says we need to protect our base, it does not mean adding All Your Base Are Belong to Us into his profile photo.
Whoa...old school meme, eh?  If you're not familiar with the reference, the meme reference that is, not the management reference, you can find the short version at Wikipedia, and the long version of All Your Base Are Belong to Us at Know Your Meme.  Neither has anything to do with Castle Defense.

So what does it mean in management speak?  It means regardless of what else happens, ensure that your team is solid and you can get your work done.  It's a two edged sword in my opinion.  If you don't protect your team and put them first, things could definitely fall apart, and you might fall apart despite knowing that you could have been the sole island of sanity in the midst of an ocean of chaos.  On the flip side, maybe you contributed to the ocean of chaos by not considering that an inconvenience to your team, some pain for the team at the benefit of the organization, might allow everything else to function more smoothly.  In my experience, there's no good answer.

For example, there was a point at which we were in the midst of a mini reorganization.  Just three months.  We didn't know it would only be three months at the time.  But during that time, the larger organization was somewhat directionless, struggling to understand how to break apart old teams, slot new work into teams that were less likely to break apart and reform, and how to get platform-level work done despite trying to create agile, product-focused teams.  I sat in a meeting one day, between 40-50 managers and project managers and leads and upper management in a room, where there was an attempt to level work across all those teams collaboratively.  The question would go out, can anyone spare someone to work on this feature for this team?  I'd volunteer someone on my team to fill a couple of hours.  The question would be repeated.  I'd volunteer someone on my team.  At the end of the meeting my team had half a dozen members on 2-3 projects each.  No cohesion as a team whatsoever.  Incredibly painful for us and a management nightmare for my lead to try and slot everyone into a capacity chart.  Everyone else had protected their base.  But I like to think because I'd volunteered us as experts and, more importantly, willing to help wherever it was necessary in the short term to keep things functioning while we got back on track, that over the next few months the people I saw coming to engage our team for mentoring and help did so because they knew we were the only group not aggressively protecting our base.  We were a safety valve, even for other teams that weren't willing to match our willingness to bend.

The flip side was I aggressively protected my base beyond that volunteer to help.  I made sure my team members were happy and engaged and that if someone was wasting their time, a stop was put to it and the specific details of what they needed were negotiated so we could streamline.  If they had concerns about how to bill their time with all those projects, we provided very specific allocations so that as little time as possible was wasted pondering over the details.  If a resource was in danger, we did everything we could to lock things down and understand why and how to resolve it.  In short, every ounce of the unknown that could be shaved away was so that we traded one form of protecting the base for another.  In the end, when a team starts to be run well, despite the confusion, and is recognized as one of the few teams willing to step up, but is still productively engaged and despite the craziness of the work is having more fun than other teams, well then, All Your Base Are Belong to Us.

Snrky: When your manager says we need to protect our base, it does not mean adding All Your Base Are Belong to Us into his profile photo.
Title: What else could it mean?

Wednesday, July 11, 2012

Is this what you've been working on for the last eight days?

I've got it! public GenericBaseObject<T>:AbstractBaseGeneric<T>, IGenericObject.  We can finally get rid of all those pesky 'object' references in our code.

Rather than try to be funny, I'm just going to ship you off to Stack Overflow's entry on why base abstract generic classes are bad things (or not) and an article on immutability and inheritance.  While not funny, you can sit in your cube by yourself pondering a "meaningful ancestor" until it starts to seem ridiculous.

It reminds me of the time, early in my C# career, when I used an interface, then based half a dozen classes of it in a provider model designed to eliminate all possibilities of recoding anything not specifically third party datasource related.  If it could be put into the classes, even as an example for overriding later, I put it in there.  By the time I was done, there were two dozen classes I had to extend, implement, or override to add a new provider/data source.  It was beautiful in my head.  The reality was I could just create a few methods and be running a new datasource.  It was idiotic to anyone who had to deal with it and support my mess.  Fortunately I flipped jobs before I could inflict it upon a junior developer.

Unrelated - this was my favorite tweet I came across today, where a friend referenced a Stack Overflow post about Why does parseInt(1/0, 19) return 18?  Hint, think infinity and base 19.

Title: Is this what you've been working on for the last eight days?
Snarky: I've got it! public GenericBaseObject<T>:AbstractBaseGeneric<T>, IGenericObject.  We can finally get rid of all those pesky "object" references in our code.