6

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?

  • 4
    Have you sat down with the new developers and discussed schedule trade-offs? – Patricia Shanahan Oct 26 at 17:50
  • 29
    "But their areas do not overlap. This makes them ideal coworkers since each one cannot really criticise the other person's work." You have that exactly backwards. Criticism is good and ultimately necessary. If you ever want to grow out of the prototype phase, your goal should be to improve the code, not to defend it. You need your staff to be looking through, understanding, and finding issues in each other's code. Otherwise you'll just keep repeating the original mistake and never grow beyond the "move fast and clean up later" attitude of a proof-of-concept. – Chris Stratton Oct 26 at 18:14
  • The problem here I think is management. The startup is very small and the CTO wants to keep it "flat" (as I wrote earlier this doesn't really make too sense, ot will eventually get hierarchies in place). I talked with the CTO about this but nothing really happens, I guess they are happy if people just work and they do not need to get into uncomfortable discussions. I will stand my ground and try to take this as zen as possible but I may decide to go elsewhere, I am not bound and I would prefer a more humane environment – AnotherWorker Oct 26 at 22:45
  • 1
    @ChrisStratton yeah, I don't think any developer can really grow until they're participating actively in code review with their peers (both reviewing and being reviewed). An environment where developers are not able to actively do that sounds like it's storing up even more problems for the future. – delinear Oct 28 at 12:02
  • To add on the comment of @ChrisStratton and maybe also give you an argument for management: Having critical knowledge only in the head of a single individual can be really problematic. I would suggest reading up on the bus factor (en.wikipedia.org/wiki/Bus_factor) and then try to create some overlap between areas. – Dirk Oct 29 at 12:47
27

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.

  • 3
    Thanks for your comment, I really appreciate that! I am more than willing to have "my baby" completely rewritten if that's necessary. I just wish that the criticism would be constructive rather than harsh. I myself try to cope with this telling that my colleagues are too junior to understand what agile really means, ie not a buzz word to attract investors but rather a mentality which has pros and cons, like everything else – AnotherWorker Oct 26 at 22:30
  • 1
    Whether it's you or whoever is their manager, it might be worth setting up 1 on 1s if there aren't any. During these, have a discussion with them about the importance of soft skills and emotional intelligence. You want your developers to be able to critique code in a way that's beneficial. Just saying 'this code stinks' isn't helping anyone. They should be able to have a discussion about the code with you and between your domain knowledge and their area of expertise you should be able to continue improving the code. – n_plum Oct 28 at 13:12
  • 1
    @AnotherWorker While I agree that it's preferable to voice constructive criticism, agile also doesn't mean "use the prototype live and skip the tests" to be "agile" in the sense of fast out to the market. To the contrary, if anything in that regard, agile means test (and fail) fast and often to improve quickly. There is also nothing wrong with a harsh situation analysis, as long as it's about the product not the person and focussed on the way to improve. It's better to decide early that a component is not economically salvageable and rewrite it than drag such decisions out, for instance. – Frank Hopkins Oct 29 at 17:46
3

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".

  • Thanks for commenting! I agree with what you are saying, it is just damn hard! I don't want to retaliate in any way by taking advantage of their mistakes (because they make them too, although they laugh about those) since I don't want to create a vicious circle. I always try to be polite because I know that we are all in a very fast-paced environment – AnotherWorker Oct 26 at 22:33
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.

1

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.

  • Thanks for taking time to write this. I carefully read it and it was very inspiring. The CTO currently wants the startup to remain "flat" (which makes little sense since we are growing and hierarchy naturally occurs whether you like ot or not). As I also commented on @PeteCon 's answer, I welcome criticism, provided it's human and constructive. It is pointless to blame imo. The product is now getting more stable and with this we are starting to have some more time for proper tests and improvements. I hope that if my colleagues will make errors too, this will help them understand. – AnotherWorker Oct 26 at 22:36
  • You are very welcome. To clarify - I don't think that having a flat hierarchy is in the way of you doing DevOps and managing the team. Someone assigned those devs their areas within the codebase, that someone may as well be you, since you understand the domain best. You don't have to bark them around, just organize. Read up on best practices. How to do reviews, how to enforce documentation, prevent people becoming the only ones knowing their own large corners in the codebase. You are not alone, these are very common pitfalls in software dev. I meant to share what they can lead to. – Mär Oct 26 at 22:52
  • Thanks for this. I am no manager in the company but this gives me ideas on how to approach the issue with the CTO. Thanks again. I would upvote you but this is a brand new account and it hasn't enough reputation to do so! – AnotherWorker Oct 26 at 22:58
  • Don't worry about that. :) – Mär Oct 29 at 18:56
1

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.

1

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?!

0

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.

  • 1
    might unleash swarm of "fixes" that are not in the backlog – aaaaa says reinstate Monica Oct 26 at 20:48
  • Fixing the technical debt could mean to rewrite big parts or even change the architecture. This should be done together and in coordination. – FooTheBar Oct 28 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.