How to survive as a junior developer in workplace that does not tolerate mistakes?

Question

My friend is a junior at a workplace that requires staff to take 100% responsibility for their work. In practice this means no code reviews. Any errors, mistakes or inefficiencies are to be identified yourself.

While staff are encouraged to ask for help when they run into problems, you don't know what you don't know, and my friend is often disciplined by seniors (who are also managers in the company) when their work doesn't fit their expectations at the end of a project. This is the cause of a lot of stress for the junior in question and is destroying any confidence they have in their own work.

While I can see the merits of having a "get it right the first time" culture in a workplace full of senior developers, it seems like a hostile work environment for juniors who genuinely don't know any better.

Can anybody suggest techniques for reviewing and error checking your own work? Or alternatively, strategies for cultivating a healthy "learn by mistakes" review culture in a workplace?

I should add that this is apparently otherwise a friendly and pleasant place to work and the seniors seem entirely reasonable in all other aspects, the junior would like to stay on at the company if possible.

Answer 1

While there is a lot of good mileage in your friend learning Test Driven Development (TDD), the fact that he/she is being disciplined by multiple managers for falling short in Telepathy skills means that this looks like a toxic workplace. The person that never makes mistakes never makes anything at all.

My advice can only be to make rapid strides towards the exit. There are better, less stressful, places to work.

Answer 2

Understand that testing software is part of what being a software developer is

The job of a developer is to produce tested code, not just "code".

It is your responsibility to make sure that code does what it is intended to do and doesn't make any changes it isn't intended to.

Can anybody suggest techniques for reviewing and error checking your own work?

This question is, really, "how do I test software?". That is, obviously, a huge question. At the very least, read and understand what unit, integration, system testing are.

Even if there is a dedicated QA team, they are a second-line check, they are not a replacement for your testing.

For each change, you should come up with some sort of test plan, even informally, and code isn't "done" until it passes. You can look into test-driven development, dependency inversion and mocking; although those specific concepts are often taken to excess, and can lead to terrible code bloat, it is still good to be familiar with them.

strategies for cultivating a healthy "learn by mistakes" review culture

At the time of review, and afterwards, you need to think about why mistakes were made.

Not just, "what did I do wrong in my development" (because everyone makes mistakes), but "why didn't my testing find this fault".

Because when your testing improves, your code improves. And seniors will have more confidence, over time, in the quality of your output.

Answer 3

Can anybody suggest techniques for reviewing and error checking your own work? Or alternatively, strategies for cultivating a healthy "learn by mistakes" review culture in a workplace?

First, I must say that I agree with Philip's comment in part; if this unhealthy expectations and disciplining is the standard, perhaps your friend could consider looking for other job with a better work environment. But that should be done as a last resort.

Some strategies that could help here are:

• Team with other junior devs and peer-review you code. As other junior devs are most likely in a similar position (still learning, prone to do mistakes), helping each other is a good way to go. Not only will it strengthen their relationship and work dynamics, but will also help them deliver higher quality code and learn how to code better.

• Ask for help earlier, don't wait for the end of the project. As your friend is being disciplined when projects end, it would be a good idea to ask for help earlier, so they have chance to correct mistakes before delivering and learn in the process.

• Take a break or switch to other task before reviewing it. Sometimes one may become obfuscated or burnt out when working on a project continuously. This, in my experience, sometimes increases the chances that one misses an important detail, or is unable to find some bug. It has helped me greatly to switch to other tasks, or take a break before seeking for bugs, as one can then see it with a fresh mindset.

---

It's worth noticing that you state the ones disciplining your friend are his Senior coworkers, and not his boss/manager. Chances are that most of them are in no position to be disciplining your friend, as that would be a role the boss should take.

Senior coworkers can suggest or mentor, but they should not discipline unless that is part of their explicit responsibilities. I am noting this because chances are the senior coworkers who are not your friend's boss are trying to scare him off, or try to discourage him in such way for reasons unknown...