Archive for December, 2013

Management

Thursday, December 12th, 2013

There are two types of management, managing for a field you’re familiar with, and managing for a field you’re not.

In the case of managing for a field you’re familiar with, you’re going to leverage a lot of your experience and expertise to make decisions.

In the case of managing for a field you’re not familiar with, you are going to rely on your people assessment skill, your surveying skill, and intuition. Do note, that if you’re going to hire someone to be an expert in the field, and constantly doubting his work, then you need to one, either hire a new person, get some training in the field so you can ascertain whether or not doing his job properly (but then you’ll be micromanaging; doing your job and their job), and finally you can keep your ears open to see if there are disagreements with the approach.

It’s important to realize what type of management the organization hired you for, so you know if you’re managing the way they expect you to. In a way, we’re all cogs in a larger machine, if we’re fulfilling our purpose, things will run smoothly, if we’re not, there are going to be hiccups.

Posted in Uncategorized | No Comments »

Harsh on self, Harsh on others

Friday, December 6th, 2013

I realize that in my world, there is working or broken, completed or incomplete, one or zero. A delivery is not complete until it is delivered and proven working, until then, it’s incomplete.

I don’t like making promises until I’m relatively certain that it can be delivered, and this certainty can only be obtained through testing. Just like a test, either the assertion is met, or the assertion failed.

I don’t like building systems that are prone to breakage, and not doing a thing about attempting to avoid them. It makes me feel negligent. Fixing a bug that I incidentally introduce doesn’t feel like an accomplishment, it feels like a failure.

Every single system I touch, every single line of code I contribute, I have a sense of fondness for it. To me, computer systems are like children. You groom and shape them into exactly what they’ll be. Sometimes, they’ll take on a life much bigger than the life you anticipated, and when they’re able to withstand the battery that’s the real-world, you feel a sense of pride that it was YOU who brought it into this world.

I ponder if I’m being harsh, or am I just following best-practices.

If I’m the person in charge of handling a project, or a delivery, and it doesn’t meet my criteria of code and system integrity, then it’s like asking me to violate my own principles. Not only am I violating my principles, it’s likely that the violations will result in much more headaches and time expenditures than originally allocated. Such requests are inconsiderate and insulting, especially if you acknowledge that you know the consequences of such violations. Perhaps the reason why I find it so irritating is that I expect them to understand the principles I live by, and for the most part, everyone should. You’re either alive or your dead (medical), you’re either in the black or the red (finance), you either got paid or you didn’t (human resources), your system entire works entirely or it doesn’t (code); It’s not so abstract of a concept really.

So am I being harsh on myself and others, or am I just being normal, and others are being extra lax? It’s something to think about, but I say I’m being normal.

Posted in Programming, Work | No Comments »

Testing, Delivery, and Confidence

Wednesday, December 4th, 2013

I’m often asked regarding how likely a code deployment will deliver the expected results. It’s actually a very simplistic formula, the answer is a neutral answer, but people often think of it as either over positive, or over negative, more frequently the later.

Chance of delivering on time is a function of: testing, how recent the tests are, how close the test matches the production system, and the points of failure.

Obviously, by on time, we’re assuming we’re delivering the functionality the client expected to have by a certain date.

A delivery that has no testing, server systems are widely different, and there are many points of failure, have little chance of being a successful one, doesn’t mean it can’t happen. A delivery that has testing, matching server configurations, and little to no points of failure, has a huge chance of being a successful one, but doesn’t it’s guaranteed.

I know I speak for a few, possibly not for all, but developers wouldn’t feel comfortable with the deploy until it’s been released onto production, stress tested by the public, performed as expected, and then, their hearts are finally at ease. This, is also a form of testing, the final one. Even then, in the back of their minds, they’re thinking that the code could’ve been better, there are edge cases it didn’t cover, and so on. We are forever doomed by a feeling of insecurity, the only thing we can say is that we’ve rigorously tested the crap out of it because, fact of the matter, bugs are a fact of life.

Posted in Programming | No Comments »