[7Figures2Commas]

I'm always surprised when a company is so quick to publicly comment on a sensitive personnel matter, but that said, it's interesting to note what this response doesn't contain.

The OP basically called into question the quality and stability of Unbabel's platform ("The code was a tangled mess of mindless duplication, half-implemented features and misleading comments. Of the few automated tests that existed, most didn't even run anymore") and the competence of the people behind it ("The team lead was the only one who knew anything about the system and he was either busy trying to patch things up by himself or working with the other person they had hired for my position before I got there"). The subtle implication of the post: the OP may have been terminated because he recognized these things.

Are the OP's claims true? Who knows, but the response here doesn't directly address them at all. Instead, there's ambiguous language like "terrible fit", corporate-speak like "we believe that the culture of the company is extremely important" and a poorly-timed "A position just opened up :)"

Frankly, if I was the founder of a tech company and I made the decision to respond publicly to a situation like this, the claims about my platform and the competence of my team would be my focus and I'd address them head on. After all, such claims could become very harmful when encountered by prospective employees, customers and partners. Given that, it's curious they were completely ignored.

[neilk]

> The code was a tangled mess of mindless duplication, half-implemented features and misleading comments.

In my experience, a lot of code is like this, and the majority of startup code is like this. I have found there's almost zero correlation between startup success and good coding practices. I have no data, but I suspect there's a negative correlation.

Before you protest, I know that your code is a shining example of clarity. But if you consider all the incentives for a startup, there's much more value in being experimental, and highly responsive to customer demands, than there is in charting a stable, long term course. People celebrate pivots like it's cool, but this is what it does to the code.

Just a forewarning for anyone who is going from a more corporate world into startupland.

[jacquesm]

I can't comment about any specific code bases for obvious reasons but I'm more often than not positively surprised by the quality of the code at the start-ups that I look at. Of course there are corners being cut, but usually that's for very good reasons marked with copious 'todo's. Start-ups definitely aren't equal when it comes to this and in my experience there is a definite correlation between those that ride that fine line between being in a hurry and making a good product and those that create a mess and those that try to be perfect out of the gate.

The idea here is that you do the best you can within the constraints, not that you use your start-uppishness as an excuse to be sloppy or to produce crap.

In fact, the majority of the real messes I see are not in start-ups but in more established companies where the original developers have long since moved on. Large codebases where very few people (if any!) have an idea of what is really going on.

[hawkice]

Seconded.

I have been at startups where it's a total mess that will never be cleaned, and I've been at startups where the code is always tip-top because everyone knows you get big B2B points for implementing their dream feature right after a regular "how are you liking our service" followup.

I haven't worked at mega-corps, but I've seen bits of code that is so much worse than imaginable that I expect there are places that scrape pretty far below the bottom of the barrel, but that might just be a volume issue (the worst 1% of code will be mostly mega-corp code because most of _all_ code is in mega-corps).

[pavlov]

I don't know if it's worth going on the defensive about that kind of stuff.

If the founder made an in-depth reply explaining that "No, we don't suck, we use language X, framework Y and methodology Z", then that just opens up a pointless side discussion about whether the X+Y+Z stack sucks, and how much exactly.

All that will remain in search engines, so in a few years' time the company will appear in public searches as a company that uses X+Y+Z even if they have moved on.

[7Figures2Commas]

You're missing the point: if you're going to respond to a matter like this publicly, you had better respond substantively. Anything less can have the effect of making the claims against you seem more credible.

Note that this wasn't a debate about languages, frameworks or methodologies. The OP flat out referred to the company's code as "tangled mess of mindless duplication, half-implemented features and misleading comments" and claimed that only one employee "knew anything about the system." The response here mentions surfing on Wednesday but doesn't dispute any of the OP's claims about the state of the company's technology and technology organization. That looks horrible.

[Tyrannosaurs]

I disagree, there really is little beyond a "he said, she said" type argument to be had here and that really doesn't benefit them (or indeed Andreas). Much of that is subjective and they're not going to publish code to prove it one way or the other so there will never really be agreement. Best case is they reply and he refutes it which puts them pretty much back where they are now.

As a company you want to shut this sort of discussion down as quickly as you can. A detailed rebuttal may appear to do that but doesn't - the more you say, the more you raise questions, invite rebuttals and encourage further debate.

Maybe this doesn't answer some claims and they suffer some very slight damage because of that, but far worse damage is often (possibly even usually) done by detailed replies which keep the story going and fuel the fire.

[vasco_]

The claims are most certainly not true. Regarding the code and team we have an mazing team and our code is pretty good, especially since going through YCombinator we have grown at a tremendous rate which sometimes forces us to cut some corners. Of course our code could be better, and it was precisely for this that we hired someone that we thought could be a valuable contributor to the code. Unfortunately we were wrong, as it is ow publicly obvious, but fortunately the rest of the team is truly excellent.

[korgis]

an amazing team of surfers? It's funny, if you go to their facebook page, on a lot of posts, they'r either praising their "engineering team" or making up excuses on downtime and bugs. And from the looks of the team it seems besides the elder ones (who must be the founders of course), the rest are recent grads whom they can sell their surf's up crap to then make work on weekends, and extra hours

[personZ]

the claims about my platform and the competence of my team would be my focus and I'd address them head on

Why? A former employee criticizes the company they were fired from -- that carries essentially zero weight to pretty much anyone, and you seem to be among very, very few who took it at face value. Heck, even if they weren't fired and didn't have the axe to grind, people complain about "spaghetti" code with such vigor and frequency in this industry that it has become essentially meaningless: It's the standard fall-back when someone is in over their head -- attack others, malign their code and technology, and try to pull up yourself by tearing down others.

Further, how in the world can you complain about them commenting on a "personal" matter, when they are responding to a guy who posted a highly-critical extortion rant. I call it an extortion rant because he even claims that if he warned them that they need to pay up or face his public flailing.

That's incredibly lame.

[k__]

"the OP may have been terminated because he recognized these things"

He wouldn't be the first one.

I had a bunch of jobs, where I had to work with crappy code and have seen many people getting "terminated" because they prefered to complain about it.

I complained too, but I worked with what was given, when it didn't change after a few years (most of these "the whole system is fucked up changes don't come easy) I just quit.

[true_religion]

> The subtle implication of the post: the OP may have been terminated because he recognized these things.

These things are self evident to any programmer who isn't in their first year of work. I can't see anyone being fired over recognizing what their experience allows, especially since you hired them for that experience.