Staying Still

A great question that everybody off-hand says is, "what if money wasn't an issue, what would you do?" And the obvious answer would be, "whatever I damn well please". Well what would that be? When I first started my career, getting out of university, I entered the work force during a downturn. Software jobs were few and far between especially for new grads, but I was luck, I found something interesting within the first month of graduating. In a year however the startup company which I was working for wasn't able to support itself and I found myself back at square one. I think the next 9 months was possibly one of the best times in my life. I was unemployed, I had a bit of money but I was still learning. Possibly learning more about life than I've ever done within the other two decades that I existed. And this is what made it so special. Going back to software development, there are people that are veterans in the field, working in software for 15-20 years. But you have to ask yourself did you do 5 years of work and just repeat those 5 years 3-4 times? or did you really work for 15-20 years? There is a difference between getting by and really thriving. My personality is if I stay still for too long I become indifferent, I lose my passion for the thing that I'm doing. And for most people that's OK. But I say no. Don't do that. Constantly always keep active, keep learning. Keep checking yourself, are you stagnating? Fight against staying still. You'll enjoy everything much much more, even if you had all the money in the world.

Alternative Realities

I always ‘believed’ in alternative realities, where every choice you make ripples into an infinite number of possibilities and each reality describes a possibility. Far fetched?…yes. But the beauty of the human mind is that we have the cognitive ability to partially predict what might happen based upon past and present events - so we can play out these scenarios within our own reality.

Today we’re exploring two stories, same players, same events leading up to the incident, and extremely different outcomes. In the first story, a team sets out on a new software project, call it project X, for a new client. They perform time estimates, get approval from all interested parties, do the design and start the implementation. Bam! A major roadblock hits the team. The manager asks the team to buckle down, absorb the roadblock. Due to the loyalty of the team, they oblige, put in significant overtime and solve what needs to be solved and continue on their merry way. The roadblock pushes there timelines down a month but being great dev. they push forward ‘hoping’ that everything will be OK. They deliver the software to the client a month late, boggled with failures. Ultimately they’re unhappy, unsatisfied with the work and it takes an additional 3 months to stabilize. The second reality, the manager identifies that there is a major roadblock, informs the client and together they formulate a plan on working it out. The team does as little overtime as possible, they get there best guys on the roadblock, they reduce scope by a few features and they deliver 2 months late. The client ultimately happy with the quality of the software and believes that it was a success aside from the late delivery. So what went wrong in the first reality? It’s really about setting expectation in everything that you do. Say you’ll finish a task in a week and it takes you a week and two day. Take the same scenario but you say it will take you a week and a half. You’ve just turned yourself from being the wiener to being the winner. And it’s the same thing in the two stories. Get your client involved, let them invest in the cause so there’s buy-in from both side of the coin. One of the great things my previous employer preached was that good news travels fast, bad news should travel faster.

Project Slider Bars

I’m not sure where I got this idea implanted into my brain, but I would like to give credit (if I could remember who it was) to the person that thought of this description of a software project. There are basically four sliders within a project, quality, time, money and scope. All four are inter-dependent. The sad truth of it is as a developer you only have control of one of those slider bars, quality. So what is a developer to do if a project is late? Naturally work harder, put in some overtime and get the job done. So what happens if a project is REALLY late? The only slider bar that you have in your control is quality and what happens? Quality suffers…

This is by far one of the worst mistakes a developer can make, because what’s going to happen is that the entire team (including management) is going to pay for it over and over and over again in the long run. I remember a study about cost and the later it takes to fix something in the project timeline the more costly it will be for the overall project. So what is a developer to do? Push back; tell someone, people have to change their perception that this is bad news… This is GOOD news! It’s even better news if it can be identified early that a project will be late. Tell people, tell people early, tell them so they can do something about the other 3 sliders, which are out of a developer’s control. It also adds value to the team that their managers are supporting them – that they don’t have to work on crappy code – that, quality from a manager’s standpoint, is important (I’ve seen sometimes it isn’t). For those managers out there, stop saying “just get it done”. You may not realize it but you’re going to pay for it in the end. As a developer you really don’t have a lot of control over anything other than quality, make that as one of your high priorities. There will be pushback of course from above if something is late. Be strong, set those expectations early, and tell someone that has control of the other sliders if something is going wrong; it really isn’t bad news…

Delivery Pains

Handoff of any kind within the software industry, and probably within every industry, is possibly one of the most important aspects that you have to take care of. It’s really about perception. I’ve never believed in throwing things over the wall and hoping for the best. If I do have the control, I will take extreme care when I write a bug report to developers and the testing team, or handing of a software drop to a client. There are just so many things that can go wrong. I’ve had the privilege of working on a lot of version 1 type software where a small little setting here or a specific hardware configuration there might be the perception changer of what works and what doesn’t work. I’ll have to say that letting the testing team or the client bang their heads over and over again trying to get your software to work properly is possibly the most frustrating thing imaginable. You then have to remotely debug their setup which takes days due to the process of pushing logs and instruction between the two, wasting your time and the client/tester.

If you’ve performed a fix for a QA bug report put as much information as you can into the unit testing that you’ve done, be available for them to bounce questions off of you. When you have a software drop be there for the client, maybe even drive or fly down to their offices and work remotely for a day or two so that the software transition is smooth. This really could be the deciding factor in the perception of the software working or not working. Truthfully, how much does it really cost for a short flight, a night stay and some senior developer time. It really adds value for you as a provider to the client that you care about delivery, you want to build a solid foundation with them with face time, and ultimately you make their lives easier just being around.

So the next time think about delivery, are you doing all that is necessary for a smooth transition of information passing? Is it very stressful during code drops? Do you have to put out fires right before and after every release?

Maybe it doesn’t have to be that way…

Maybe it’s your delivery…

So...What's Next?

I've been in the software industry for a short amount of time compared to some of the veterans out there that are going on 15-20-25 years, but I've come to a point in my career where I'm asking myself what's next? I know some of you can agree with me on this...

My vision of a software dev. is it's a stepping stone to being something more. I don't want to pigeon hole any career path or insult those gifted developers that have been in the business and will be in the business for most of their career, but I really think there are only three major avenues to follow after the software dev gig. Project Management where you're getting away from software, managing timelines, budgets, teams. A software architect/CTO - driving the technology of the company, designing some napkin scribbles and giving this down and saying "implement this... What you can't read my handwriting"? And the contractor/consultant route, which sort of ties into the software architect role, where companies hire you for time and material for your technical expertise. I don't want to get into mISV or building your own company, I think that's partially separated for working for 'the man'.

I question to myself, what if I don't want to follow these paths? All of the above, to be really good, needs an inherent personality trait (which can be partially learned), but one must have an affinity for it. So what if you don't fall in to any of those categories? What if none of those options really appeal to you?

So what's next...?

Personally I don't know - maybe in the next few years I'll figure that out and head down that path.

It's a Friday - maybe one of you have some thoughts on the subject?

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

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...