Hacker News Reader

agree completely. I'd have a frank discussion with him and attempt to determine if this is political. If it is, fire him immediately even if there's short-term pain because the politics will fk the company anyway.

If it's not political, and you agree with his assessment of your production code, then there's an R&D role that probably needs filling and that you've already proven you can do - finding profitable market niches and creating prototype products/services to address them.

Don't sweat being a "bad coder". Every coder (yes, even the awesome ones) feels a little worried that their code is bad, and he's just playing on this insecurity that we all have. Part of the 'your code is crap' syndrome we see in tech is just defensive projection.

You managed to build a production system that is gaining traction, which is amazing. Go do more of that :)

I'd second your words about "bad coder" arguments. This argument is ridiculous, particularly if he had managed to to build a production system that is gaining traction. And did it single-handed (or in a team of two).

I would disagree however about the advice to 'fire him immediately because the politics will fk the company'. The problem is, the moment there is some money on the table politics and power play starts. Unavoidable.

You can be a terrible coder and build an MVP in PHP or something. Doesn't mean you can scale it, both in terms of adding new features, or in terms of increased traffic.

Um. That kind of thinking is pretty close to my own from some years back. Not any more, but who knows, I may change my way of thinking again ;) In the moment I'm just reserving my judgement regarding skills of other developers. And only make judgements regarding particular pieces of code, mostly trying to find positive things in it, rather than negative ones.

Out of curiosity, a personal question. In terms of years of active software development, what's your level of experience? Is it say, 20 years of building code for moneys? Two times less than than? Two times more? You don't have to answer.

About 20 years, yes.

There's nothing bad about being a terrible coder who manages to put together a basic product. There are plenty of terrible musicians who still release albums for example. But it takes wisdom and maturity to understand ones own limitations.

If I owned 50% of a company, and a guy who had measurably increased my wealth by improving the product and hence the value of the company, gave me some advice like this I would listen very carefully. I would not "cut off my own nose to spite my face" or "throw the baby out with the bathwater".

Interesting. Well, my current way of thinking is that there are no terrible coders, it is just that mature and experienced engineers are slightly less prone to making terrible and difficult to correct mistakes. Like using an obscure language or something, just because they feel that way and without considering the implications ;)

I disagree, somewhat :-) There are people whose contribution is horrible but it's rarely confined to the quality of their code. It's more about being able to lead the company in directions that are ultimately wasteful in some way or other and not being able to change direction when the time is right. That leadership may be expressed in code, but the code is as much or more a symptom than the root cause.

With basic QA practices in place (peer review, coding standards, designs grokked by teams not individuals etc.) a single person usually can't muck up the codebase very badly. He or she can still poison a whole project or company.

Well, my understanding is that developer's experience changes the shape of the probability distribution of excellent/horrible contributions. But it is always a distribution. And that it is difficult to accurately distinguish between excellent/horrible contributions without hindsight.

I find that as I get more experienced, I'm more aware of how much of this huge discipline I don't know, and how many mistakes I've made in the past, and I'm much less likely to call myself a "good coder".

When I was younger and slapping shit together any old how, I thought I knew it all.

There are, apparently, those who cannot implement FizzBuzz. Perhaps it's incorrect to call them "coders". But beyond that, you have a spectrum of skill. Do they become competent before they become coders in your books?

I take it you've never had to work with bad code. It's ruinous to the company's prospects since it slows everyone down and makes' developers lives miserable until they quit. It starts to take an entire afternoon to make a simple change, and your business is paralyzed.

+1 on all pointers. That's what his co-founder is supposed to say. Unfortunately, failing to support each-other in such ugly cases, says much about the future (or the lack of one) of this partnership. :(

> If you think the second option is what he is really trying to communicate, then I would look for other opportunities to contribute to the company.

This was my thought. It would be worth looking into roles like developer evangelist, if it makes sense for your company: you're clearly technical enough to make things happen, and you have the domain knowledge to be very useful.

I agree with you. Of course, I don't know the full story but given what I have seen in the past I would guess it's the second option.

Some of the coders simply can't deal (or, more accurately, their egos) when someone less skilled is above them in the hierarchy.

If this is the case, I'd say just fire him. It sucks now, but will save from a lot of pain later on. For instance, when you hire someone else who might happen to be less skilled than the CTO.

Good software developers know that there are less skilled people, they used to be like them, and deal with that appropriately (i.e. with respect and without offending). And then there are prima donnas who can't deal with working with another human being for whatever the reason is.

At the end of the day, being a good software developer is not all about writing code. Far from it.

I was under the impression that "co-founder" carried a lot more weight than CTO; is this not the case? My gut feeling was that, if I were in the co-founder's shoes, I'd fire the CTO immediately.

This would be dumb though, because it would tank your company.

You are assuming that the CTO is the only CTO in the world.

Leaving the situation as-is would tank that company.

In a small team, infighting is a much bigger threat to survival than losing skills/results of any single individual.

Hmm, I'm sure infighting is bad, but often enough individuals do have skills and in particular experience with the setup and/or code and/or business contacts that the startup has made that you're not going to find a replacement nor train one without losing lots of time and money. Certainly that's an avoidable risk with effort, but I'm pretty sure that some level of infighting may be less risky than losing certain individuals.

A CTO with polarized vision would tank the company faster.

So, if that would tank the company noone gets nothing. If he doesn't fire the CTO, he gets nothing and company may or may not get anything. To me, pretty clear situation what would I do. I would risk the company to save myself from certain loose.

> I was under the impression that "co-founder" carried a lot more weight than CTO

Depends on the circumstances. If one founder controls a majority share, they can fire anyone they wish.

In this current situation, if the CEO controls more than 50% of the shares and the CTO reports directly to the CTO, the CTO can fire the OP.

I agree completely.