# Different Beliefs About Software Quality *Some thoughts about software quality among your team* 2022-10-08 | `clean-code` `agile` `xp` `communication` `career` > What to do when working on \ --- ![blog-cover](/images/blog/2022-10-08/cover.jpg) I recently got a great question on Twitter which got me thinking for a while and I decided to share my thoughts about it. --- ## Context But first, some context: I am feeling great because the codebase where I work is getting better and better, so I am tweeting this: > "As software improves with time, you can feel you're doing right." And then I got a question asking for suggestions: ![blog-tweet](/images/blog/2022-10-08/tweet.jpg) So there we go... --- ## My answer ### Create agreements The first thing is to create agreements about what quality software means for your team and yourself. This helps clarify what software culture you want to establish and work towards that direction. Leaving your company should be the *last resort* once you have no other option. Before thinking about leaving your company, I would ask you: - **Why do you think** you cannot improve the working codebase of your company? - **What can you do** to reduce the friction between your different beliefs regarding what quality means for software? There is no perfect codebase to work on because software is a living entity and constantly changes. So, at least for me, quality software is the one that can cope with change smoothly. Once you have agreed on that goal, and while there are multiple ways to achieve that result, my favorite way of working is keeping an **agile mindset** with doses of **extreme programming** values, principles, and practices in mind. ### Software is about people Software is not just about writing _clean and solid code_. This is indeed desired, and we should aim for that, but we must first understand why we want that. The "_why_" is based on the **values** that you have as a team. If you don't share the same purpose, the same "why," then you won't _enjoy_ working together, and in such a case, I would advise looking for another company that shares your values. But, before that, I would strongly suggest fixing the deeper issue and helping your team improve. ### Understanding your why You first need to deeply understand your "_why_" so you can transmit this to your peers and the people around you. Have you tried all you can to create awareness about your "_why_"? Some ideas include encouraging collaborative programming (pair/mob), presenting some internal tech talks, creating a culture of sharing knowledge on a regular daily basis, creating awareness about the current status quo, and looking for opportunities to improve everywhere. ### Your career path If, after several months of (really) trying these ideas, none of them work, look for a new company that shares your beliefs. After all, you're the first and primary responsible person for taking care of your career path. > Original [twitter thread](https://x.com/Chemaclass/status/1578425454562021376). --- ![blog-footer](/images/blog/2022-10-08/footer.jpg) ## Extra thoughts If **you want something to be different**, don't wait till it's changed automatically. Try to **change it**; if it's not working, leave it. Maybe you don't belong in that place. On the other hand, it’s crucial to reflect if you see that pattern often repeating (changing companies too quickly). In such a case, maybe the problem isn’t the companies but yourself. Software development is not just about code but **business**. It's essential to be aware of finding a fair _trade-off_ between speed, costs, and quality, depending on the situation. You might want to use some _tech debt_ to conquer the market as soon as possible. It doesn't make sense to have "low quality" as part of the identity of any team. Every team has certain quality expectations. Therefore, the **key** here is to **agree on what good quality is**. > Thanks to my former Engineer Manager, Evgenii Sokolov, who inspired me to write these extra lines after sharing the original post.