Showing posts with label developer. Show all posts
Showing posts with label developer. Show all posts

Thursday, October 21, 2010

Being the Hero

Even as a little child I've always wanted to be the hero in the story, now who wouldn't. Slay the bad guy, get the girl, praise and grandeur bleeding from every where... It's surreal... This unfortunately applied to software development early on in my career. Push through to get that software release, solve problems that people have been scratching their heads on for days. Be the 'go-to' guy. This was fuelled by a mix of challenging yourself to the brink, wanting the praise and gratitude from other co-workers and ultimately just a longing to be special. So, did I get the girl? Slay the bad guy? Sad truth is... no. I want to say flat out that it's OK to be the hero, but there's this fine line that one should never cross.

So.. what happened?

I burned out... I was serving up every morning a shot of indifference mixed with a side of impatience and really nobody could do anything about it. Nasty - I know. Nobody wants to be in that pocket and no vacation or time off could remedy this (when you get back from vacation, it's still going to be there).

What I realized was that being the overboard hero wasn't helping the team but actually hurting my co-workers. Long stretches of overtime is not something any dev should take, this just means that the project was poorly planned from above (push back). Being the go-to guy for everything under the sun depleted others on the team from being autonomous. Sometimes people have to grind it out themselves (with a little guidance that is), it will be better for them in the long run. Developing an organic symbiotic relationship with the other members on the team where you share ideas and techniques is a better solution than being the point man on everything.

Rule of thumb these days, pre-plan your projects and hash them out, design and timeline wise (there's actually a statistical formula per project type). Don't push your devs for too much they'll hate you in the end for it. Intrinsically show the value of their work and how they grew within the project they were on. Follow the "Don't Live with Broken Windows" mentality. Expect knowledge to always flow equally between each team member. And most importantly go with your gut and don't be afraid to be vocal about it.

It took me a year to get out of that burned state... Will I ever get there again? A resounding 'Hell No' - there's more important things to life

Wednesday, October 20, 2010

What's my job description?

I had a revelation the other day - maybe it's my old age getting the best of me - but I slept better afterwards. A part of our job as a software dev. is yes, creating elegant solutions that work seamlessly. And yet how many of you out there have worked with terrible, unimaginable code, and you cursed the sun and the moon while reading it (and maintaining it). That's right folks the sad truth is that close to 90% of the code out there (that's an arbitrary number) is filled with holes, bugs, crash scenarios, memory leaks, deadlock situations and whatever else is under the sun.

So what is your job description you may say...?
Being a great software developer is-NOT making elegant solutions that work seamlessly - well not in it's entirety - you're never going to be in that bubble! you will always have to interact with other 'stuff'. So to be a great dev., you have to elegantly fix other people's stuff!. And that's the bottom line. Someone had dragged a piece of code through the trenches and it's a big stinking pile of garbage, it works some times, other times... not so much.

Options? rewrite - that would be the easy and yet hard way around things. A great dev elegantly tucks hear and there, snips this and that and ulimately makes it something that might actually be presentable. Wow, now that's a great dev. Solving other peoples problems.
Strange how that sounds but sadly that's the truth. So think twice about cursing - that piece of code that I have to integrate with, or that gobbly mess I have to maintain and bug fix, and really think about your craft. Blaming other people's code is the easy way out, a great dev will dig deep and transform what might be a mess into something manageable. Now there's the true artistry in your job...