maintenance support coding

andrew moore has an interesting piece that i found on reddit tonight and it points to why supporting code that someone wrote is the best place to be a 'hero'.

citation one:

If you outperform stagnant, you're a hero

ok - let's be honest here: only egomaniacs are into being a 'hero'. while you, as the coder might think that when you refactor someone else's code you're being a 'hero' - the fact of the matter is that you are very close to being an arse.

what mr. moore should have provided is the caveat: make sure you understand the code that you're about to refactor.

at one point in time i was working with a development team and the new coder decided that he was going to be a 'hero' and refactored some code that:

• wasn't in the functional design
• he didn't understand
• related to a business function that was rarely used

so he 'refactored' the code and broke functionality at a third stage approval process when the application was in the final stages of being approved. i, as the testing co-ordinator had to take the results of the tests and show where the previous beta compiles passed a particular function and why the 'final' version did not.

the project manager took this to the developer and suddenly there was found a 'bug' that was 'dormant' in the code and was 'only found when the final tweaks' were made.

it was pretty obvious to one and all where the source of that 'dormant' bug had been and it was the last time that developer handed in a product that had any 'features' that were not explicitly called for inside the functional design.

so, for all you rockstar developers who are bone certain that you know what you're doing, i have a simple suggestion for you: don't be a hero.

all too many times, the 'hero' ends up being a 'zero' in the eyes of everyone else around them because their either look down their nose at the other coders who are doing their very best - or they are setting themselves up for one of those career destroying errors.

heros are an epic fail in a team work situation. if you want to be a 'hero' you can't be a team member.

citation two: Sometimes when I look at an installed base of code, I find places where there is useful information that is not being exposed. The database knows some statistics about the business that are not being given to decision makers. Sometimes this wasn't done before because it's not obvious when something is being built what kinds of statistical information it will collect. Sometimes it's not done because it's just not the lowest hanging fruit (yet).

ok - this is boderline stupidity clear and simple.

developers are not paid, nor are they often wanted to 'optimise' the decision making process. leave that to those that wear the ties, have the blackberries, and are on the giving side of the layoffs.

a developer's job is to write the code that they are given. the business analyst is the one that is to decide what and how the code should be written.

all a devleoper that writes 'heroic, groundbreaking code' is showing is that they have way too much time on their hands. their manager won't really like it - and all the managers that had been making decisions based on the previous iteration of the code won't like it either.

it goes like this: the sad truth is that ninety percent of the time when your boss asks you what your opinion is, if you're like me: you have to keep your mouth shut and just give him back what he or she is looking for. i've seen too much heartbreak because i answered honestly what my opinion is about a situation or to provide a solution.

if your solution is radical enough then they'll file you as a nutcase.

if you give them the same brain dead options that they came up with while they were on their power lunch with their friends - then you'll probably be able to keep your job during the next wave of layoffs.

heros are zeros in the business context because they alienate their coworkers.

'innovative' solutions are only looked for from coders inside start ups.

Company Fishing

one of the aspects of the web that has impacted the job market is that if you are seeking a job, then you should be aware of what you have put up online.

today's marketwatch.com has an article about why companies should be careful about trawling for data on prospective employees:

Various studies suggest that upwards of 40% of employers have trolled Facebook and other social networking sites for information on potential hires -- and that when they find negative information on these sites, more than 80% of the employers factor that information into their hiring decisions.

now they go to list four aspects that u.s. companies need to be aware of but there are a couple of really salient points:

one: finding out information such as gender or ethnic background which could negatively impact the perception of the applicant to the seeking company.

well, at the end of the day - from a prospective employee's position, i am not sure i would want to work for a company that took things like that into consideration in the first place. it's illegal in both canada and in the u.s as well.

but, the sad truth is that there are still a lot of racists in powerful positions so from a blogger/job seeker - that fact is not all too relevant to me. if the company doesn't want to hire me because of my gender or ethnic background or political views - then i wouldn't want to work for them in the first place.

two: trawling facebook is, at best, a grey area in terms of legitimate background checking.

from my perspective - that's not such a big deal. i don't blog about anything other than my takes on how technology impacts my life, i blog sometimes about machinima (a hobby) and i have been blogging fairly regularly over at ibankcoin.com about my take on the stock markets.

now that last bit, is where i actually would prefer a prospective employer would pay very close attention to what i blog because here is my position:

• i like taking on challenges and solving hard problems.
  
• i also try to be as cognizant of the "big picture" as it relates to business as i can be.
  
• finally, i am willing to entertain "out of the box solutions" to the hard problems out there. case in point, would be my use of genetic algorithms and ID3 to find tradeable edges in the u.s. stock market.
  

i use an unorthodox style for my blog here - personally, in my private correspondance - i think that capitalization of letters is, well redundant. however, on my ibankcoin.com posts - i use upper and lower case lettering and ensure that my sentences and paragraphs follow a logical order.

that's because, really - if you are are a prospective employer and you found this blog because it was at the tail end of my signature, then i would hope that you find me to be a relestlessly creative type who enjoys solving problems and does not have any interest in being a drone that shows up and 9 and punches out at 5.

case in point, look how much time i spent on my ibankcoin.com posts - i was "King of the Peanuts" and blogged every day just about in december 2008 where i not only commented on the state of the markets but, i also presented ideas for trading solutions discovered using machine learning techniques.

if that's the kind of person you want - then you know how to reach me.

if it's not - rest assured, i probably don't want to work for you.

cheers.