This poses an interesting question: if you find yourself in such a position, working at a company that is doing so many things wrong, what do you do? I can think of several different things, but which is right?

1. Easy way out - go with the flow and add your own WTFery to the mix, and try not to let it destroy your soul.

2. Fight for what's right at every turn, and stand up to the status quo.

3. Pay lip service to the status quo, but subtly and sneakily introduce best practices one at a time. It would be an uphill battle, and hard to fight backsliding without blowing the undercover nature of your cleanup operation. In order to do this, you'd have to find the coworkers who still have a bit of a soul that hasn't been crushed, and get them on your side to help you.

"This poses an interesting question: if you find yourself in such a position, working at a company that is doing so many things wrong, what do you do?"

Leave.

I was in a similar situation and in my case I also had the fourth option:

4. Try not to touch any old projects. Instead try to "own" a new one where you can do things the right way.

There are, however, a few problems with this approach: your will probably be implementing the whole thing alone and will quickly become unpopular with the others.

In my case I ended up implementing a compiler frontend alone from scratch while everybody else were thinking it was a waste of time and we should have based our work on the old code (which, agreed by everybody, was hell of a mess). When time came to implement the backend, I had to bring one of the "old-timers" on board which caused a lot of tension (he preferred to do things the "old way", for example, to indent the generated C++ code manually instead of using the automatic indenter that I wrote).

One other thing that I tried with mixed results was to "recruit" new hires with some sense of design to work with me on the project before they got exposed to the "dark side".

In the end I left that place not the least because of the "us vs you" attitude which was, on the most part, the result of my own actions. I couldn't stand the attitude most people working there had towards software design (most of them were grad students so they weren't there for the long haul). I am now running my own development tools company and find it a much better way to spend my time.

In the end I suggest that anyone stuck in a situation like this get out of it as soon as possible. The extra effort required to make it work is just a waste of your life.

The same thing can happen at good companies which make bad decisions with tech staffing and development for whatever reason. You have to try and build non-confrontational coalitions that want what you want and don't stress out other people.

Sometimes you have to take stands on major architectural decisions. But if you're creating battles on day three as an incoming programmer you deserve to be fired.

I've tried all three. #2 is a good way of becoming unpopular very quickly. #3 is a lot of effort. You need to be very committed to the mission to make it work.

Look for another job right from day two. In such a situation quit is the correct answer.

Back in the day, we used to call this the [JustQuit Pattern](http://www.c2.com/cgi/wiki?QuitSuddenly)

If you aren't in a high position, you really won't be able to swing the ship directly.

All you can do at lower levels is drop strong hints. This can be done whether or not you quit (e.g. at an exit interview, assuming there even is one).

The best (yet flawed) analogy I ever heard for a large company. People in a company are like gears in a complex gearworking. Some gears have more influence/leverage such that if a big gear (GM) moves a little a lot of smaller gears may start moving faster. And to cap off the analogy, sometimes a movement causes some other gears to go backwards. It was from a VP too.

Why was he fired? Because he didn't stay overnight?

No, because he didn't fit into the team. It might've been the suckiest team on Earth, but the bottom line is that they were not comfortable working with him.

He should've quit on a third day. Since he was not comfortable working there either, I don't really understand what he was hoping to achieve by staying. Improve the code and demonstrate that everyone else there is an imbecile ? That would've never worked, and that's exactly where he was doing.

I suspect that he just didn't have any experience with this sort of a situation, which is not that uncommon. The good thing is that now he does have this experience :)

I'd blame the direct manager, Jola (and not just because something like that happened to me once). The guy from Germany made the big mistake of not hiring the right people in the first place, so he's completely responsible for the mess, but as far as the firing goes, it's her decision. His job was to bring experience, fresh air and make waves - and he was brought in for this purpose by Johann. At the very least Jola should have held a big long exit interview with him, since she knew already that the company was in trouble.

And another comment: I'm from Romania, and I saw several startups just like this one, funded by somebody abroad and managed by a local not in IT. They all were pretty much like the one in the article. I always wondered why they were such big failures. Obviously, the incompetent local manager, but they failed too spectacularly for this to be the only reason. Now I start to think this kind of culture actively rejects competent people. Even if they stay with the company for a while, they're never promoted to a position where they can use their skill.

More likely: He questioned everybody's practices within a few hours of starting. Right or wrong, it's bad politics.

No, it's an excellent way of filtering out bad companies early.

Never attribute to logic that which can be adequately explained by entropy.

I wouldn't want to work there either.

I am interested in this "It was really easy, though, because this class stored the data internally in a dictionary but the lookups on it were done by sequentially iterating through all the keys to find matching one. All I did was replacing the iteration with normal dictionary lookup."

can someone explain how to do a normal dictionary lookup?

what is that? and is there something similar in PHP?

A Python dictionary is a hashtable structure. It's kind of perverse to iterate over the keys to find the value when you can just do the hash lookup directly.

A PHP array() is also a hashtable structure. The PHP equivalent of the described code would be to do a foreach() over the array rather than doing an array[key] lookup.

Probably by storing the keys in a hash table structure instead of an array.