My Last Two Weeks At Nike

Nike is an awesome company in many ways.  They spend a lot of money and effort on a pleasant workplace.  It's a fascinating campus, the restaurants are good, the pay is quite good and it's an easy work week.  So people (recruiters) are baffled why I left and it's hard

Nike is an awesome company in many ways.  They spend a lot of money and effort on a pleasant workplace.  It's a fascinating campus, the restaurants are good, the pay is quite good and it's an easy work week.  So people (recruiters) are baffled why I left and it's hard to easily explain.  Here is a description of my last two weeks:

1) A bug is logging passwords which should be filtered out.  I trace it down and the fix is  three simple string operations.  I don't know the scope of this fix so I subclass the Logger class as SecureLogger, add my three operations and extend the original class from SecureLogger.  It's safest because the original code is unchanged and SecureLogger is available if the bug is in other places.  

2) The team reviews it.  It's unacceptable because of performance problems.  What performance issue?  Perhaps a microsecond from an additional method signature?  But fine.  They say the bug is only in one class and one method.   So I move my three operations into the original class.

3) The team reviews it.  It's unacceptable, the code should be in a utility class.  What?  A utility class implies REUSE and you just told me the bug is only in one place. I originally wrote the SecureLogger exactly to address reuse.  But fine, I make a utility class and add my three operations.

4) The team reviews it.  It's unacceptable, I should have used a regex function for, yes, you guessed it, performance reasons.  Okay, now I'm pissed off.  The regex library requires time to load hundreds of functions which never get used and will still execute the same three operations.   They disagree.  I write a small  program and prove I'm right.

5) The team reviews it.  It's unacceptable because when I reformatted the code using THEIR format, it converted specific package paths into wildcards.  I ask what's wrong with wildcards.  They say it's a performance issue again.  No, it's not.  The compiler creates the same byte code regardless of wildcards or specified paths.   They disagree.   I write a small program and prove that I'm right again.

6)  Now I'm the bad guy making them look ignorant.  It's not that they don't know, it's that they are SURE of something that is NOT TRUE.  

7) After a week, I finally have my three operations checked in but now they fail code validation because there's no class constructor.   There's no point in having a constructor in a utility class but I add one.  

8) It fails again because it's a public constructor.   So I change it to a private constructor.

9) It fails again because it's a private constructor.  No constructor fails, public constructor fails, private constructor fails.   It's impossible to pass the validation step.  

10) I'm assured that I'm the only one with this problem.  I spend a week guessing and trying to figure out what's happening.  After a week, somebody finally admits that the code validation is screwed and nobody uses it, they disable it but pretend to use it to satisfy "quality control".

11) So now I'm the bad guy again, exposing their deception by being blindsided by it.

And that's when I went to lunch, had a drink, went home and never went back.

Two weeks to write three string operations.   And this two weeks was not atypical, just the last straw for me.  It's not that any single item here is important, it's the cumulative mentality which is probably creating a more convoluted, less maintainable and more unstable system.

Recent Posts

Flickr Stream

Text Widget

Aliquam eget arcu nec nisl imperdiet semper mollis sit amet tortor. Ut ultrices pharetra urna id cursus. Aenean ligula dolor, mollis id eros id, hendrerit malesuada nisi. Suspendisse et pellentesque est. In lobortis velit nec diam sodales, vel gravida nibh porta. Curabitur faucibus lacus ac tellus faucibus posuere. Nam lobortis