Bad jobs make for good blog posts. I guess good jobs do too. I should write more about the previous employer. But right now, in the middle of job hunting, I'm remembering a former employer/client.
They weren't serious. They compensated by making lots of airs of being serious. I was flown out last minute and put in a nice hotel. I was subjected to a battery of interviews and interviewers, more than one of whom subjected me to a battery of puzzles and riddles. Numbers -- of hits, megabytes, dollars, and employees -- were thrown around in attempt to impress me with their seriousness.
On the job was a little different. The VPN client software for Linux was supported on very few versions of few distributions. It took days with systrace to figure out what it was trying to do and where it was trying to find its various undocumented deps. The company waffled and then had internal battles about whether I would be loaned a company Mac to get around this. I'm not one to covet work hardware, so besides inconvenient, this was insulting.
That's anecdotal for much of the rest that would follow. Really, it was a warm up anecdote, as I really wanted to launch off of another one: internal security, specifically passwords.
Failed password attempts burned. Too many bad tries and the central Microsoft Windows Domain Controller would lock your account. But the account naming system was inconsistent and prone to collisions. Two users with similar names would burn each others passwords. Authentication was needed for everything -- Bugtraq, logging into the development server, access to the staging databases, email, yadda yadda yadda. Your username on one system though would be someone else's, and software that automatically did things on your behalf wasn't keen to this subtlety. IT support happily reset your password all day long as many times as you needed it, and you had to sign a paper documenting that you had it done. Perhaps to them, it made them look good and productive, but it left me wondering to myself, "are you guys serious?".
Thinking back, I'm sure lots of techs and managers had lots of meetings and this is what was settled on. Going about things grotesquely inefficiently was a happy, welcome alternative to starting another round of meetings -- if they could be started, which would surely require lots of coordinated, organized, carefully phrased making noise to the right people. This is not hypothetical -- I sat in on similar meetings.
Any effort to reduce Technical Debt was done on the sly. When the programmers started to organize themselves to improve the release process of versions, make plans for dealing technical debt in the long term, and to form an internal consensus on what the technical requirements (as opposed to marketing requirements) of the next generation platform might be, new managers were sent in to get programmers to stop wasting so much time. Literally, people's time was to be better tracked. They were to be assigned projects, quote them, and be held to task. The worst trouble makers were fired or monopolized by management. Many left.
Management wanted "yes" answers, or perhaps "not just yet" answers. They did not want to take time to understand the complex implications various potions had on technical capabilities and the resources of the technical staff. They did not want to know what tech needed from the business units in the way of policy changes or technology business decisions. Communication was strictly one way -- mandates from on high.
Not being serious about technical matters started in upper management, but the effects trickled down until even the programmers left were only working in a theatrical sense. To do otherwise and actually try to get things done would cause trouble for every other person complacent in management's decision to just not care.
Like the IT support staff who was happy to change your password over and over again, it was easier to pretend that nothing was broken and never getting anywhere was fine. Kenyan customs officials smile broadly with their hands out waiting for their bribe.
When management did want to know why the programmers weren't more productive, rather than launching an open minded investigation through every level of the company, they hired a tough guy and phrased the question closer to "isn't there something you can do to get the programmers to be more productive?". In psychological terms, I suppose this is a case of Fundamental Attribution Error. The higher-ups get paid megabucks not because they don't make mistakes but because they're able to convincingly paint a portrait of the talents because they legitimately believe that their dung smells like roses.
This is my long winded way of saying that among the hundreds of little red flags I've learned to look for over the years for working for countless failed companies is this little gem: beware management that's "busy". That's retarded. Management too busy to be concerned with the most dire circumstances surrounding their programmers is akin to a race car driver who really can't be bothered to be concerned with his camshaft, or an astronaut who just can't give a flying fuck about portal laminates. These managers will do a bad job. Besides sucking at what they do, they're reinforcing their own festering case of Fundamental Attribution Error.
-scott
