1

So I am less than a month in to a wonderful new job and I will get right to the point. From day one the CTO has told me to please poke holes and look for inconsistencies and what needs improvement.

On my first and second week, it was too early to find any, but on my third week I have found something.

Well, now I am meeting with the Senior Developer more so than the CTO and so I brought these inconsistencies up with him.

The response I get is, well, the client is not worried about that and we are moving away from that technology anyways.

The piece that I need to also disclose is that its a piece of technology I have spent countless hours mastering and also implementing in other companies and for other customers and so the philosophy that we are replacing it with something better and new falls short of the fact that its not going to completely go away so it behooves us to all learn it, especially for devs that come after me.

Anyway, my question is, what is the best way to address this in a way that I safeguard myself as the new guy and I am not throwing the Senior Dev under the bus?

I could have made the argument and may possibly still have the chance to make the argument to the Senior Dev, that it affects my productivity when I look at a codebase that is unnecessarily disorganized and snippets of code here and there implemented in the past that for someone of my experience, I know are not providing any improved quality to the product.

How do I communicate my concerns?

Improve this question
3
  • What do you mean by mediocre code? Is the code functioning? or just poorly documented? inefficient? repeated? disorganized? Is it being replaced later or being made redundant? Are there any dependencies on it or does it depend on too many things? It may simply not be worth the time and effort to fix, especially if the client wants to push other features.
    – Shadowzee
    Commented Jan 30, 2019 at 3:50
  • @Shadowzee, I don't mean anything by mediocre code. I use it as an example of how it may be interpreted in a worse case scenario. I would never present it as such because I don't see it that way, but it may be interpreted that way. I will revise for clarity.
    – Daniel
    Commented Jan 30, 2019 at 7:47
  • This is a common duplicate on the site. The answer is just "work harder and don't complain."
    – Fattie
    Commented Jan 30, 2019 at 14:30

2 Answers 2

Reset to default
8

Contradicting the accepted answer

  1. A formal letter like this is basically the text book example of "throwing someone under the bus" and it's very likely to sour the relationship with the Sen Dev. The letter can easily be as interpreted as "I found a problem, the Sen Dev is an idiot and doesn't want to deal with it, so I need you to step in and make my point". It's a clear vote of "no confidence".
  2. After only three weeks, you really have no idea yet how the place runs, how decisions are made and what the complete history of these decision is. You also have very limited view yet on where things are going
  3. Before you bring this up, you need to learn everything there is to learn about the current state, including why it exists and why it was created in the first place.
  4. Only after you have done your homework, you approach the Sen Dev with your findings. Not to have do anything done, but to have your findings checked. "Hi Bob, I found something and it's a bit different from what I would have expected. Could you check whether I see this correctly and help me understand the discrepancy?". Listen a lot, talk little.
  5. If you are sure you understand the full background and if you still believe that there is room for significant improvement, bring it up as an idea. Show data and research that clearly demonstrate that your idea will result in a measurable improvement that's aligned with the company business goals
  6. If the Sen Dev doesn't go for it and you cant' convince him with real data and a good analysis, you let it go. He has way more experience and familiarity with the business and in most cases his gut instinct will be right.
  7. However, if you feel extremely strongly about this and/or it's vital and extremely impactful to the business, you can decide to elevate to the CTO. Elevation is tricky: you only elevate as a last resort and you admit to full failure in resolving this through the normal day-to-day channels. Use with extreme caution
  8. If you do, let the Sen Dev know up front. Sit down with him, and tell him that you will elevate and why. Listen to him and adjust the message to the CTO based on his input as much as possible. He won't like it, this may be difficult conversation.
  9. Then bring it to the CTO, be data driven and focused on the facts. Leave the Sen Dev out as much as possible. Don't bring him up unless the CTO specifically asks about it.
  10. Consider the possibility that the CTO is just being friendly and actually doesn't really mean you should be going on a bug hunt. "I'm interested in all new things you find" can just be nice thing to say without the expectation of strong follow up.

So it's entirely possible that you are right, but its also equally (or more) probable that you are not and are seeing only an incomplete picture. Even if you are right, proceed with caution. You only elevate to the C level if it's really important and if there is no other way.

Chances are, you will spend way more time with the Sen Dev than with the CTO, so make sure you prioritize your relationships accordingly.

Improve this answer
5
  • I'm sorry that you misunderstood -it means I most likely was not clear enough- but my point was not to antagonize the Senior dev, but to acknowledge his input and give a full report on a task given by the CTO. The point being that if the CTO is giving the task, he should be the one getting the full report when the task is done, it's in no way a case of escalating the issue. Quite the opposite in fact, if you don't report your findings to the person who asked you to investigate, it would be seen as highly unprofessional in all the workplaces I've been in before.
    – BriseFlots
    Commented Jan 30, 2019 at 13:14
  • It's specifically not antagonizing because of the last sentence of my answer: "please refrain to repeat your arguments for action in the mail to the CTO: they were already discussed and overruled". Again the point is not to bring up an argument, but to inform on conclusions reached
    – BriseFlots
    Commented Jan 30, 2019 at 13:18
  • I understand the intent, but the e-mail as written will antagonize the heck out of the Sen Dev.
    – Hilmar
    Commented Jan 30, 2019 at 13:46
  • @Hilmar, thanks, especially point 4 and 5. I did get a background on why it was done that way by the Sen Dev. Basically, a guy that was only with us for three months like it done that way and the Sen Dev added, you would be a hero if you could fix it, but right now we can't charge the client for that buttoning up since they do not see it as a problem. Now, of course, the client doesn't they don't have to look at their own code, they just point and click and if it works they are happy. My issue is when point and click does not work, I have to stare at the nightmare code which is challenging.
    – Daniel
    Commented Jan 30, 2019 at 14:41
  • @Hilmar, also I did not take it literally to go on a bug hunt. I just happen to see something poorly put together from the standpoint that when its time to debug, it will be a pain to do so and so since that door was opened to say something if I see something, I did. And it got shot down, not by the leader who opened that door, but another leader, which makes it uncomfortable because I was also tasked with other things the Senior Dev shot down. So do I complete them or not? I guess that is another question.
    – Daniel
    Commented Jan 30, 2019 at 17:30
-3

What I would do in this situation is report to the CTO, since he's the one who gave you assignement with your findings and the Senior devs plan of action. Since Senior dev is involved, don't forget to cc him so that he can add information or correct something you might have gotten wrong:

As you requested, I looked into [...] and find the following inconsistencies / points that could benefit from improvement: [the list there]

I discussed them with Senior Dev, and he assured me that these were not critical and didn't need any action to be taken because: [senior dev arguments]

This is all I was able to find and will continue working on other tasks from now on.

Sincerely

Your name

In short, just CYA and let the persons taking decisions take them. Just make sure that you give all the info needed for them to take the best one. Also, please refrain to repeat your arguments for action in the mail to the CTO: they were already discussed and overruled.

Improve this answer
5
  • 2
    Sorry, I think this is a bad idea. It is very likely to make the Senior Dev mad. It also feels very passive aggressive.
    – Hilmar
    Commented Jan 30, 2019 at 11:59
  • @Hilmar Well, my point of view is that it is very matter-of-factly. Since there is nothing in there to suggest that the Senior Dev is wrong. Its' just an objective report on a task done with conclusion reached. I don't see the aggression in it nor thinks the Senior should be mad to be acknowledged.
    – BriseFlots
    Commented Jan 30, 2019 at 13:10
  • Basically, my answers boils down to "I talked to someone who knows about he issues, and he concluded this"
    – BriseFlots
    Commented Jan 30, 2019 at 13:20
  • I understand what you are trying to do, I just don't think this will work. Chances are the Sen Dev will be seriously offended (and has every right to be). Also the likelihood that a junior guy after only 3 weeks has found something important enough to raise to the CTO level are small at best. More likely he stumbled into a small tidbit and lacks the proper context and background to interpret it properly
    – Hilmar
    Commented Jan 30, 2019 at 13:42
  • Well, YMMV of course. It worked for me in the past (ok I was reporting to the team leader rather than CTO, but it was the same situation). If I got the idea across, then that's what matters. Cheers and thanks for developing your viewpoint in another answer.
    – BriseFlots
    Commented Jan 30, 2019 at 13:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .