Showing posts with label work. Show all posts
Showing posts with label work. Show all posts

Thursday, March 22, 2012

Life As An Engineer

Today, I think I coined a new work-related term: "multi-blocking". It's sorta like multi-tasking, but different.

At any rate... "Multi-blocking" is the (necessary) habit of running multiple, concurrent projects, but letting "blockers" determine which project goals you're actively working towards at any given time. That is, you work on a project until some dependency stops you, then hop onto the next most pressing project that isn't blocked.

Other interruptions to multi-blocking can be "suddenly critical" things that aren't on your project plans being dumped into your lap. These either get added to the multi-blocking queue or supercede everything in it.

The big down-side of this working-model is when you reach a state where you're 100% blocked. Then, it's total frustration time. If this happens frequently enough, or you're given a superceding task that also blocks, it can cause a total freak-out of frustration and denial of satisfaction.

Wednesday, February 8, 2012

They Call It Security

As someone who's had a history of taking liberties with poorly-protected systems (eveyone's young, once), I recognize the value of locking down technology. Because I know there are bored people out there and because I know there are truly malicious people out there, I make efforts to protect things against them. I understand the value of "systems security".

That said, I have to deal with others interpretations of what it means to make a system "secure". In general, security is at odds with usability and functionality. The key to good security is finding "balance". Sadly, so much of systems security is left to people who've never broken a system and who've only ever read papers, articles and/or books on security. So, when someone writes a security recommendation, the typical security person takes that recommendation as gospel or comes to the wrong interpretation of that recommendation (or fails to consider the impacts of what following a recommendation is).

This type of blind approach security always leaves me scratching my head. Invariably, the people implementing these policies in a context of ignorance leave gaping holes in systems. They'll lock down an avenue to a given piece of information. But, because they don't really understand the systems they're securing, they don't realize that there's a dozen other ways to get the same data (or that some data are critical to overall system usability and maintenance). In the end, it leaves you, as a system user, wondering "what the hell were they thinking" or "what the hell was the point of doing X". Today, what I found myself wondering was, "who the fuck removes `whereis` from a standardized UNIX deployment??"

Sunday, October 23, 2011

Diminished Highs

There's good and bad to being goal-oriented (though, in truth, it more frequently seems to be bad than good).

The good is the sense of accomplishment you have when you finally reach that goal. To a lesser extent, there's also that sense of joyful anticipation when the achievement of the goal is imminent.

The bad: the impatience to achieve that goal; the frustration of things outside your control thwarting the accomplishment of that goal; people pestering you about when you're going to achieve that goal, especially when they are responsible, in no small part, with your inability to get it done; the "now what" feeling that immediately follows the sense of accomplishment of achieving a goal.

On balance, I just can't tell, any more, whether the high of reaching the goal is anywhere near enough to balance out all the other things. I guess what I loved about consulting was that the "high" I got from achieving goals came so much quicker and more frequently. And, before you could fall into the abyss of "what's next" and the frustration-cycle of the path up to the next achievement, you already had your marching-orders for what to do next.

Wednesday, August 31, 2011

Time Differences

I dunno whether to be impressed with myself or absofuckinglutely livid at the contractor who was "helping" me most of the summer. I'm pretty sure I'm livid.

In the space of about three hours, I was able to just run through building and linking three functional backup servers - inclusive of downloading and staging software and repeating two of the servers (because I forgot to capture the install session to a text file). The contractor who had been previously "helping" me, had taken over two and a half months and been unable to achieve the same feat.

Now, I get that I am fast at doing things, but a time differential of two months versus three hours??? I dunno how a person with anything resembling personal or professional integrity can bill that much time and accomplish so little. W.T.F.

Thursday, August 18, 2011

Delegation and Failure

Honestly, I didn't know whether to post this on this site or my "serious"/work site. Technically, it's about work and would be well-situated there. However, this is more a philosophical post than a technical post. Thus, I opted to put it here...

For the last several jobs I've worked at, I've frequently been in the position where I had to push the tasks I was once responsible for onto groups with less exeperience than I have. This is the nature of an engineering role: you figure the stuff out, then you turn it over to others to manage - usually after simplifying and documenting that "stuff", first. Then, you move on to other things and act as a technical resource for those charged with the day-to-day care and feeding of that "stuff".

Invariably, part of the push-down process is figuring out which things are suitable for push-down and to whom. Part of "to whom" is knowing who's available to do the work and their skills set or prescribing the type of person that should be capable of doing the work and allowing the folks in charge of staffing to find people that meet your prescribed skills set. At the end of the day, it's a process that, if executed correctly by all parties involved, allows the "stuff" to be more widely used and kept healthy, and allows the engineer to mostly divorce himself from that "stuff".

The push-down process is one fraught with challenges and fear. While you, as an engineer, can decide what things can and should be pushed down and who it should be able to be pushed down to, there's always the fear that you won't be able to push it down. You have fear that the people you're pushing to won't be up to the challenge. You fear that the people you're pushing to won't do things the way you had envisioned, ultimately resulting in more work for you (first, by having to fix any breakage that results; and, second, having to undo all the stuff that resulted in the breakage or, worse, having found the unanticipated deviance so pathologically and intractably ingrained that you have to leave it in place and work around it). Further, if your a conscientious sort, you always have the worry that you're setting people up to fail.

It's this last that I hear over and over when it comes time for the push-down: "we might be setting them up to fail."

This is a hard one to argue against. Any time you pass a resposibility on to others, you pass on the possibility of failure. It's the nature of the beast. If you're giving anyone the ability to do anything meaningful, you're also giving them the ability to screw important things up. That said, if you've properly described the expected skills set for the task(s) and/or provided good procedural documentation, you've not only given them the ability to fail, you've also ensured that they have the tools to succeed. The only time you're "setting someone up to fail" is if you give them a tasking that they can't reasonably be expected to handle. If the people responsible for staffing ignore your staffing prescriptions, that's not your fault. If the people handling the passed-down responsibilities ignore the procedures you've tested, documented and passed-down, that's not your fault. The best you can do is to act in good faith and be there to clean up the mess when your efforts weren't enough (oh: and document why the failure occurred so that it might not happen again for the same reasons).

Wednesday, January 19, 2011

Just Shoot Me

I know I'm not the only person to ever think or utter the words, "just shoot me." I mean, there even used to be a crappy sitcom by that name.

The past couple weeks, I've been working on a project at work that has been an exercise in nearly endless frustration. Today, when it finally looked like things might be turning a corner, what was around the corner turned out to be a yawning, spike-filled chasm.

For better or worse, where I work comes with very formidably-armed guards. Thus, if I ever really wanted to seek permanent relief from my frustrations, I could probably figure out a way to get myself fatally lit-up. I'd just need to figure out who the most trigger-happy guard was and work on him/her.

Hmm... Probably an exclusion in my various insurance policies for that, somehow.

Thursday, January 13, 2011

A Perspective on Consulting

When I first got in the consulting game, back in 2004, I wondered why it was consultants had such a bad rap. After spending five years working with a really good group of peers, I still had no real clue why consultants had a bad rap. I mean, I knew our group was an elite group, but I didn't think that others could have been that mediocre. I mean, if our group was as elite (as it's become evident), one really wonders why: A) partners kept trying to reduce our rates; B) customers balked at our prices; or, C) how it was the person that took over our group managed to drive our group into the ground in under two years.

I mean, I get that people always want things cheaper. If they didn't, how would Walmart exist. But, at the end of the day, if you're paying good money, one would think you'd want good results. As with many things, in consulting, you get no more than you pay for. If you go cheap, you get crappy consultants and worse results. As a group, we always performed. We came in and executed. We knew our shit cold. So, we did it quick and we did it right. Usually, we did it quickly enough that we could be done with the work early enough to do knowledge transfer and other supplemental tasks.

As a group, we rocked. Many times we got brought in, it was to clean up the messes left behind by prior, less competent consultants.

At any rate, I left that world behind. It wasn't really by choice (see prior notation about the group being managed into the ground), but that's beside the point. Now, I work for an organization that brings in vendor consultants to do the types of things I used to do for a living. As a customer, I'm now able to see, in practice, just how above-the-norm our consulting group was. I mean, every guy in our group, in addition to being experts at the things we were officially "experts" on, was also clued and flexible enough to help integrate our technologies with other operating systems, applications, platforms, networks, etc. What I see from these other consultants is people who barely know just the things they're "experts" on. If things go wrong with that software, they don't really know how to fix or recover from it. If the environment isn't exactly like they're used to, they have a hard time coping with it. If they need to do tasks that aren't strictly part of their expertness (i.e., anything not strictly the software they're managing), they're at a loss.

Ugh. SOOOoooo frustrating.

Hooray for Pay-day?

In the era of electronic banking, pay-day is less a joyful occasion than an exercise in financial whiplash. You wake up in the morning to find the joyful message that you're suddenly flush with fundage. And then, you log into your bank's website and start paying bills. If it's the mortgage pay-cycle, you're pretty much wiped-out by the time you're done.

Hooray.

Monday, December 27, 2010

Work Mis-Direction

It seems like most people (other than me) see the lunch at desk thing as the person implying "I'm eating my lunch here so I can be available" rather than "I'm eating lunch here because I'm so busy I couldn't afford the time to eat someplace else" or "I'm eating lunch here because I didn't want to be disturbed in the cafeteria". Whatever. I've simply come to the conclusion that I'll never understand "normal" people.

That said, I've noticed that most "normal" people don't like to interrupt if they think you're listening to something. Whether that something is a phone call, your MP3 player, or whatever. Even if listening to nothing, ear-buds are great at the office for keeping people from bugging you. It's even more effective if you're using a phone head-set as your listening device because they tend to assume you're using it for the phone call purpose rather than just listening to music.

Yeah: I hate people.

Wednesday, November 10, 2010

*SO* Not Reassuring

Why is it that every time a manager tells me "all your jobs are safe" I think "time to start looking for a new gig"? Even if a manager is trying to allay anxieties that are stemming from something that is well and truly innocuous, it just tingles your spidey-senses all the more. I mean, historically, such "assurances" invariably act as precursors to negative employment actions. Personally, if there's nothing to fear, said managers should just keep quiet. Offering such reassurances just makes the more career-experienced individuals start looking for new work in earnest.

Faux Pas?

When I walk into the restroom at work and someones in the middle of a (really loud) ass-splosion, I find it hard not to laugh. Usually, what prevents the laughter is that, by the time I can no longer hold the giggles in, the smell hits. Then, I'm too busy trying not to audibly retch.

Sunday, November 7, 2010

Illiterati

It strikes me that, since I've stopped traveling, I've pretty much stopped reading books.

Weekend Go "Poof!"

Awesome is: trying to do some work over the weekend only to find that the server you need has failed.

Saturday, November 6, 2010

Smile!

Today, while having after-work pizza and beers, my coworkers noted that I don't smile much. I noted, "I smile when I'm happy." I figure they're capable of "doing the math" on that one.

Friday, November 5, 2010

Work Complaints

In general, when it comes to being asked to do things at work, I keep my complaining (to the requestors) to a minimum. However, when I've previously done something and fully and completely executed that task, I do get vocally cranky when asked to REDO those efforts. This is especially so if there's no reasonable justification for the redo-request.

Argh.

Tuesday, November 2, 2010

Good In Theory; Practice, Not So Much

First, let me start by saying, I don't have a problem with the underlying concept of equal pay for equal work. It's truly a noble concept. However, it's also very simplistic. It ignores a number of realities so that it can foster the idea of victimhood.

For starters, how does one define "equal"? I mean, outside of assembly-line-style work, how does one objectively define and measure equal work. Most jobs I'm familiar with are inherently subjective in their value.

It's really not a question of gender, race or whatever criteria you want to use. It's a question of how do you determine your basis for equality.

Even if you can, somehow, determine that two workers are producing equal work and have equal qualifications, other factors complicate it. Say that I, as an employer, have two positions that I absolutely have to fill. Say that I find two objectively equal candidates two fill those two positions. Say I offer a $60,000/yr pay rate for the position. Now, let's say that job-candidate "A" thinks, "well, $60,000 is more than fine for my needs: I'll take it!". Now, let's say that job-candidate "B" thinks, "I ain't doing that job for anything less than $70,000/year." As established before, I, as employer, absolutely have to fill both positions. So, if I want candidate "B", I have to offer him $70,000/year. Candidate "A" has already accepted $60,000/year. Am I now obligated to offer candidate "A" a $10,000/year bump to match the offer I've made to candidate "B"? Personally, I don't think an employer should be required to make such an offer (and it has nothing to do with the gender, race, religion, sexual-orientation, etc. of candidate "A").

But, whatever. I'm not some talking-head on TV. I'm not some politician trying to score points/votes with certain sectors of the population. I'm just some guy who's trying to ensure that I am always able to demand a given compensation rate without having to worry that a potential employer will need to say "no" because making a given offer-size to me would require them to extend the same offer to others who'd previously not required or requested it.

At the end of the day, I tend to think that, chances are, if you're crying about equal pay for equal work, you're the one who's unwilling to assert your value. Your unwillingness to demand your worth shouldn't impact on my ability to get what I think my worth is.

Configurational Oops

So, at work, they're setting up a database that needs to be replicated from one part of the country to another. No big deal, there's dozens of methods for doing so.

Unfortunately, it's so infrequent that one sets up such configurations, that, some small things aren't at the top of your head when you do. In this case, the flag that says to the software "both sites are already identical, just declare them synced and only sync what changes at the source site from this point forward."

In and of itself, forgetting this flag isn't inherently horrible. Instead of being instantaneously synced, you have to wait for the devices to do a zero sync. Where it becomes problematic is if you have a LOT of zeros and NOT a lot of bandwidth to ship them.

An initial replication sync of 17TB takes a LOOOONG time if you've got a 5MB/s session limit on the WAN. Specifically, at the rates we were seeing, it was going to take 45.862 days to do that initial sync. The WAN bandwidth was several Gigabits, but, those session limits were a motherfucker.

Oh well. Nothing to be lost by burning-down and redoing. Certainly, it would take sufficiently less time than to do that zero-sync that it's worth re-doing.

Bleah.

Wednesday, October 27, 2010

Egads!

An old boss is being quoted for a news article. I think I just died, a little, inside. At the risk of burning bridges, this is a person that I most definitely did not respect. I don't know anyone working under him that did. I mean, there was just a lot about his behaviors (at least during that time period) that were illustrative of how not to be a good boss.

Monday, October 25, 2010

I Think I'm Going to Be Ill

On the best days, working in an office is a trial. Then, you add in things like Mondays. Toss in horrible personal hygiene of co-workers. Throw in the noise associated with open office plans (i.e., "cube farms"). Take it all together and add in other annoyances and it's really a wonder that "going postal" isn't a daily occurrence.


Now, I like to think I'm fairly tolerant. I may bitch about things (a lot), but, I mostly put up with it. Then again, as a wage-slave, "what are ya gonna do". I also like to think that I'm fairly hard to shock or even surprise. Still, the personal habits of co-workers is always a source of amazement and, all-to-frequently, disgust.


Today is a perfect case in point. After my morning caffeine-infusion, I had to go use the bathroom. Mtn. Dew is great for waking you up, but it runs through you faster than an equivalent volume of beer does. My first trip to the bathroom, I was met with what would (mildly) be called and "unpleasant aroma". However, I was able to at least get in, get my business done, wash up and get out. Unfortunately, the quantity of this morning's Mtn. Dew was such that I needed to hit up the facilities again around an hour later.


This time, the lone urinal was in use. So, I had to resort to the sit-down stalls. I saw feet under the door of the first stall. I figured that accounted for the increase in the lovely aroma. That is, until I got to the other available stall. As I approached and was about to work my fly, I noticed a fecal stalactite hanging from the bowl of the toilet.


Disgusted, I thought to myself, "I'll hit one of the other bathrooms". So, I went upstairs to use that one. Unfortunately, I got there and the smell was even worse than the bathroom on my cube's floor. Again, feet visible under the door of one of the stalls, lone urinal in use. So, again, I sought out the remaining sit-down stall.


Whut-the-fuck: "Shit soup". Whoever'd made that mess couldn't be bothered to flush. Either that, they were in such a panic from what had just come out of them that they'd simply bolted and left it to brew.


So, I headed to the basement to find urinary refuge, there. Fortunately, that was clean. I can only guess that the authors of the prior fecal-crimes had yet to find that particular outlet on their rounds.


Note that I say "authors". As I said on Twitter, "I refuse to believe this morning's restroom atrocities were the work of a single, prolific author. Must have been a foreign foods fest in DC." However, in retrospect, I don't know which prospect is worse: that there's one person responsible for the multiple, heinous acts (and probably still skulking about, readying another "gift") or that more than one person could be that foul. Ugh.

Monday, August 23, 2010

Could You Be More Vague, Please?

I love security audits. You get back a lovely report of all the problems with your system. Unfortunately, the lovely report isn't always that clear. For instance:

Security Auditor: "installed version of Java out of date."

Me: "Ok, which Java is out of date?"

Security Auditor: "???"

Me: Ok, if I do a quick audit of my system, I find like six versions of Java installed. One is at the revision level you're telling me to update to; one is above that revision level and the other four is below.

Securtiy Auditor: "???"

Me: (stalks off in a mixture of bemusement and disgust)