Handle criticism over early code at startup

Question

A year ago I started working in a very agile startup. I was the first non-intern developer to join and I worked closely with the CTO to put together a beta version of a pipeline and a product. Due to the the speed required and the domain being previously unexplored we built something patchy but working. Many things have been skipped including tests and some documentation (there was no time really).

Now it has been some months since a couple of other developers have joined. They are not full stack developers therefore each one of them has responsibilities over some bits of my code. But their areas do not overlap. This makes them ideal coworkers since each one cannot really criticise the other person's work.

What I am instead facing now is constant criticism over everything that I have developed. With no regards to the speed that was required nor the lack of knowledge in the domain.

I have tried talking to the CTO but he is just saying that they are learning and getting better, however, what I think is that he simply doesn't want to deal with these matters.

Does anyone have any idea on how to cope with these situation without living each day in fear and anxiety?

Answer 1

You made a tactical decision to accept some technical debt in order to deliver a finished product which was functional. You worked from a blank sheet of paper, and made something which is good enough that clients and investors want to use it. Take pride in that - it should be one of the first lines on your resume.

Now the system is growing in maturity. You have other developers coming in who can take an objective look at what was developed, and have (maybe valid) ideas on how to improve it.

Your role now is not to be a code-monkey. Your position is to rise above, and manage your coders. You have domain knowledge that they don't - you know why certain decisions were made. They should feel free to discuss ideas with you on how to make the product better - faster, more functionality, more secure, more scalable. If a developer isn't giving you these suggestions, then maybe they aren't the right developer for the position.

It's hard to take criticism when it's 'your baby', but if you look at it from the viewpoint that if the system is good, everyone then has a job and makes money, then you'll see that the developers are all pushing in the same direction (if not, make sure it's the exit door that they're pushing against). Even if your entire codebase ends up rewritten, you'll still be the person that wrote the first version.

Answer 2

I doubt the climate would improve if you told you take these criticism personally and you would like them to stop, nor if you did escalate the matter. You could gain that they stop criticizing openly, but that will not change what they may think and will be detrimental to your relationship as colleagues.

Criticizing the other developer's work is being entirely part of the developer's culture, and you have to cope with the fact it's not always done constructively or with the most tact. If they lack the understanding, you could educate them with reasons you made such sacrifices. By reminding them high mortality rates of startups, you could help them realize there are things above code quality, such as money pressure, that are very real.

As a practical advice, try to dissociate with your work and take remarks lightly as long as nothing is implied about your professionalism. If you feel they derail toward being negative, you could try to lead them toward positivity, by answering remarks "xxx code smells" with "we/you will have a chance to improve that at yyy date".

Answer 3

They can get over it. That code they’re criticizing is the same code that opened up the opportunity that required additional developers to be hired (aka them). Without it, there’s no reason for them to be there.

Short story is that developers are there to improve the code (same story everywhere else). If it’s not doing something that it should be, to make code to do it. If it’s broken, to fix it. If they wait long enough, they will put code in there for others to criticize.

Answer 4

Agree with the answer by @PeteCon.

You might be going into a defensive mode, because it is your code and somewhat a reflection of your skill. You say, there is no regard to the constraints you were facing at the time of writing, but that does not really matter. Bad code is bad code. If you created something functional, but not maintainable, then there is refactoring to do. This does not mean that putting out something that works in a short period of time wasn't an achievement.

As mentioned in the other answer, you need to stop doing full time coding and transition into managing resources. Also I strongly disagree with you thinking that your devs working on strictly separated pieces of your codebase is a good thing - it is not! If you want to effectively adopt things like code reviews, where devs can start reviewing each other's merge requests, then they should be familiar with the codebase they are reviewing. In addition you are creating islands of knowlegde and when one of your devs eventually leaves, there will be no one understanding how their implementations work, because no one worked with their part of the codebase and no one ensured quality, readability and documentation of their code via review.

I would like to share an exprience, because it sounds very similar to your story.

The Tale of Technical Debt

Back in the day i joined a tech startup. It was my second part time IT job, I was still attending university at the time. The team was great and I liked my tasks, but there were some organizational issues.

The lead dev was one of the greatest and most experienced persons I ever worked with. Very skilled, very knowledgeable. Their projects were also their baby. I suspect they could have held a much better position with much much higher salary, but they loved their project and remain there to this day to my knowledge. It was also pumped out with amazing speed, faster than I could have, but thus it came with a lot of technical debt.

Over time more students and non-students joined the dev ranks, but the lead kept working on the codebase, because this is what they liked doing and I get that. But with more and more projects they just started to burn. Later and later evenings, trying to finish this, trying to finish that, coding and maintaining servers on weekend, on vacation, during sick leave and so on.

Meanwhile company policy had no review or testing protocols in place. Several devs myself included asked the lead for less coding and more managing, because we needed proper versioning structure, proper repository organization and so on, but that just did not come to be. They genuinely promised we would, but were always to overloaded with work to do DevOps.

And so, two things developed. One thing were islands. I maintained my project, which was a large source of income for the company, as a student on my own. I knew all the secret paths, all the code intricacities, but there was not enough time to do all that was asked. Pumped out features, tried to find some organization in the repository, did customer support and kept putting out fires. The second thing - our codebase deteriorated. Nobody reviewed my code, nobody could at some point, there was zero time for documentation and always ad hoc patchwork.

This was also true for other colleagues.

So everything slowed more and more w.r.t. feature development on all but the newest projects, because ever more technical debt started to take its toll and we were under constant pressure from management. Psychologial pressure. I once caught a colleague crying in the bathroom, talked a bit to them, realized that I have been offloading my stress on my family and my partner for almost a year - and decided it was time to leave.

To this day I am ashamed to leave this codebase behind in such a messy state, because I worked a lot on it, a lot of it is stuff I put in. But if you ever only do patchwork, quick and dirty stuff and so on, then your code becomes an irredeemabe mess. As i quit, a few other people left as well. Another two islands. No one was ever familiar with their codebases, except the lead to a degree.

The conclusion of this tale - these projects are mostly dead. The company still makes money of them afaik, but there have been no further development, except for some things the lead may have changed. The positions stayed vacant, newly hired devs apprently were unable to keep maintaining the respective codebases.

Now I am working in a company with proper code reviews, testing, automated pipelines, process.. it is so good. Sure we have our specialties in the codebase, but there is effectively no island knowledge at all, besides there are code reviews, so no code ever reaches the master branch, that has not been seen by someone else. My mental health w.r.t. to my workplace improved as well and my skills are a lot sharper now too.

I understand, criticism to your work is hard to deal with emotionally, but you should see critique as a good thing, that means your devs may improve the codebase, because they see things that could be different. Don't create codebase islands, because you will lose people at some point and don't try to fix everything yourself, you will work yourself into the ICU.

Answer 5

To move forward, I suggest a strategy meeting with you and the other two developers. The objective should be to plan the next phases. There are at least three things that need to be covered:

1. Any new features that are needed.
2. Cross training.
3. Bringing the early quick-out code up to full production quality.

Topics should include how to balance work on these objectives, what level of testing and documentation to aim for in the next round of development, and how to get there. If either of them starts talking about the deficiencies of the early code, return the discussion to planning for what to do about it.

Answer 6

Why do you even care?!
They can criticize all they want, just as long as they also PR good, valid fixes.
As others said, the code they're fixing is what got the money to hire them in the first place.
You might want to remind them of that. Daily.

Seriously though, let them complain their heart out, write a page long commit messages, the whole shebang.
Just make sure, as their tech reviewer, they do a good job taking your old codebase and making it better.

The only exception is if they get cheeky and/or plain out rude with their critique. It's one thing thinknig "Oh boy, this code sucks!", and another thing completely airing it out in those exact words.
In which case, fire their asses on the spot.
But otherwise... dude, you built the prototype. You are "the Woz" of your company.
Why do you even care what they think?!

Answer 7

Get them together for a little talk. Tell them like it is: You put this code together quickly to get the company to a point where it would get funding which is used to pay their salaries. Without the code they are complaining about, they wouldn't be working there.

Tell them: If you don't like it, fix it. Quietly. Without complaining to me.

PS. If they produce "fixes" instead of fixes then a major telling off is in order. If you organise your work through backlogs, then doing anything without it being in the backlog needs a telling off. HOWEVER it is entirely appropriate and best practice when doing one task to improve code related to it.