My very first real job was for a big insurance company and they had hired me as a junior. I was timid and fresh. I even asked my manager when I wanted to excuse myself to go to the bathroom until he told me that wasn't neccesary. I was given an absolute clunker of a PC that was bad even at 2008 standards. Back then continuous anything was not a widely spread practice, and testing was something you did by yourself on your own machine, before copying files manually to an IIS server and getting file in use errors before seeing your application go down for everyone. That's why we did that only on saturdays.

There was no pairing and basically no onboarding either. I can't remember if there was source control, but I know at some point there was Team Foundation Server. Besides the trauma of using TFS, waiting 15 minutes for my VB .Net project to open and having to use IIS, there was basically no oversight, pairing or code review and everyone worked alone. The project I received was aptly not production critical (because I was a junior), but it did serve an important function. It was the complaints and compliments system for a large insurance company. If you spend any amount of time in the insurance industry it becomes quite obvious why they would need something like that. Let's just say they were pretty light on the compliment side and the complaint side was much more important.

Fresh out of university and ready to start my life as a working programmer I was excited to start working on the project. The tasks looked managable. Add a report field there, a filter here, an additional input validation there.

What greeted me when I opened the code base was something that would be a good campfire horror story at a programmer camp. As I shine the light on my chin, fire crackling and everyone dead silent I drop the scare.

"And as he looked through the code, he found that instead of a for loop there was..."

Add the obligatory moment of suspense as everyone leans forward in anticipation.

"The same code copied and pasted 31 times!"

Everyone recoils in horror. One person runs to their tent. Another starts to sob quietly.

I spent my first year of working as a professional software developer refactoring a code base that was like a dying camel in the desert. You had to keep riding it because you can't survive by yourself in the desert, but it had no chance of surviving all the way until you found your way out. I had to deliver the news about the state of the application to the business person I was in contact with. The company had appointed champions to represent each application. This was a precursor to what would be called a product owner nowadays. I didn't pull any punches when it came to the previous guy and the mess he made. I was disappointed and angry that this is what the real world looked like. I was told by my champion that small requests were taking months to complete, and that this former developer came from being a mainframe programmer to web development. He was apparently not adjusting very well. He sat in another office as I was in a satellite office and I heard that he was eventually placed under performance review and then finally dismissed.

I felt that this was the right thing to do. The good thing. The best thing!

It took many years of trudging through various code bases in various states of disrepair and insanity to learn what was really transpiring. My moment of realisation came when I started with a medium sized financial company who had what seemed like brilliant developers. And they were! The resident de facto architect showed me around the source code and told me to let him know if I had any questions. I saw some less than savoury practices and I asked him about it. To paraphrase: "business wanted that feature in a few days. We kind of did that because we were working late and had to deliver no matter what. It's not the way I would like it either. We haven't had time to fix it."

This simple admission opened my mind to what was really going on. Quality was not just a function of the work of a single developer or even a team, it was the combination of many factors that conspired together to result in what would be the end product. Over many years still I realised that most, if not all quality issues were not about how many super ninja 10x rockstars were working in a team, because I saw those teams dropping the ball badly as well.

The truth is that organisations are the most fundamental part of what makes good software. Good teams can produce working software even if the organisation they are in is making it difficult. But average teams can make great software if the organisation they are a part of enables that. Circumstances matter. Culture matters. Procedure (or lack thereof) matters.

Blaming the previous guy seemed like the right thing to do at first. A business had the right to know that their employee was messing up, and that I could help them fix it. Not so. Telling a non software business person that bad programmers or "bad practices" are the problem effectively absolves that person who is in charge from responsibility and allows them to continue doing whatever it is they do that ruins the software. It also creates an environment of distrust. One of the jobs I started at had a manager that told me that he expects that I will want to rewrite everything that the previous guy did because developers like things their own way. That was his understanding of the situation. Some programmers also make their careers by slagging off the work of other programmers. They get promotions and kudos from management because they are the heroes, speaking the real truth. Nothing could be further from the truth.

Another thing happens that is even more direct and painful. When you refactor some code that someone else wrote they feel that you are disrespecting them or looking down on their hard work. Some programmers are apologetic about the bad parts of the code as if it's a reflection on them, regardless of the fact that they wrote that code at 01:30 on a Sunday morning. Context matters. Circumstances matter. Above all: organisations matter. Some businesses make it damn near impossible to deliver working software. Between developers fighting about the only right way to do things and their inability to understand their role in the problems that are faced, everything goes south in no time. Culture becomes toxic because the most brazen "truth tellers" are praised for their honesty and everyone else gradually resigns. Sometimes not even gradually. I worked in a team that had an average staff turnaround of 6 months. New hires were like making friends on death row.

"How long you been in?" "6 months. you?" "4 months"

Before you know it you are saying goodbye. At that point it isn't even an event anymore, and the people who have been there soaking in the toxicity they love so much are upset because so and so couldn't hack it. Real men work at least 15 hours a day!

Fixing this situation starts with us. As a professional programmer you have to realise a few things. If you slag off other peoples' work in a meeting with business people, you are slagging off our entire industry. If you are doing it to others, then understand that it will be done to you as well. Someone is going to come around and say your work is "shit". Usually this is after you've left, but you need to realise that doing it makes it worse for everyone. So don't do it.

If you drop expletives about the quality of your colleagues' work it sends a message that the organisation or the way the work is carried out is flawless. The blame lies entirely on Dave's desk, with his stupid anime wallpaper and his stinky fish lunch. Sometimes that person is just an e-mail address on a git blame. Regardless of that, organisations need to learn that they are responsible for the failures. Individual programmers make a lot of important decisions on a daily basis. In order to do that effectively they require a lot of support. They need to have the space and ability to learn and grow. They need to be able to focus on the problems they are facing. They need a team environment where everyone is collaborating effectively and everyone is working toward common goals. In organisations where these things are not present, things fall apart no matter how talented or skilled an individual is. The software we build at work cannot be built alone in any reasonable time span. We need other people to do their part, and management has a massive responsibility in this regard.

When you join any organisation that is building software, you can learn a lot more by looking at how people interact than by looking at the code. Seeing how effectively and efficiently the operation runs can tell you much more than poring over source files can. Are programmers afraid? Afraid of making mistakes? Afraid of deadlines? Essentially bad code != bad programmer. Nobody operates at peak efficiency under duress. Nobody thinks clearly when they are tired or burned out. Nobody thinks clearly when they have to attend to endless procedures to get their work done.

The biggest question should be what to do about the situation. Firstly, don't criticize code without also critizing the process by which it's made. Secondly, don't target people present or not to try and lay the blame. Programming is a grand and humbling learning journey. Everyone makes mitsakes. All the time. You did that bad thing when the chips were down. Other people also find themselves in situations like that. That's not all. People could be in a bad place in their personal lives. How do you know?

Blame is a comfortable and easy answer to any problem. We blame someone and move on. Disentangling the messy real world where things often have multiple causes that conspire to create a snafu is the hard work. The quicker we realise this and take that work on as a team and organisation, the quicker we start seeing positive results that would be unexpected if a single person or team was to blame. When you do that hard work you find that when the dust clears everything is better. Even poor performers are suddenly performing well. That's because it was never about an individual or the "shitty" code. It was always about a big, messy picture where everyone involved had some measure of blame.