Did anyone of you worked for a company where:

- there was a financial success
- code was clean and was enabler for fast delivery
- tests were professional
- CI/CD pipeline was working as expected
- features were developed in small chunks (few PRs per day)
- managers were trustful and were solving real issues to help you
- refactor was part of the everyday development

Is it even possible? Is there at least one company who achieved success doing the above?

If it's financially successful, it cut corners somewhere.

If it's financially screwed, it's paid way to much time making everything perfect.

It is what it is 🤷‍♂️

@AtuM want to share more?

I have most of these at my current job

A few sections of code are just awful but for the most part the code is super clean.

At the current company I can say apart from second point all others are more or less present. In terms of code quality it is over a decade old company with a few acquisitions and take overs so there is bad code in some untouched areas. However there is certainly process for new code and proper reviews so not complaining that much.

I'm in the phrase of life of "I wish I work in these kind of company"

Pretty much, yeah.

No but why do you expect so much? Even the biggest success stories in the history of programming don't meet your standards

@ArtOfBBQ that's why I'm asking. Because from the perspective of good practices, this is how it suppose to be.

So if successful software happens without this practices, then why even bother?

@bzq84 Yeah that's my opinion at least. A lot of people who are passionate about best practices present it to you as if there's no room for discussion but the reality is that there's always another great engineer who completely disagrees with them.

The best practices are also derived from experience/ anecdotal evidence, it's not as if there's someone out there doing giant scientific studies of engineer performance under varying circumstances

I try to focus on learning things that everyone agrees on first, because there's so much to study that you have to prioritize anyway

@ArtOfBBQ i know, that it varies. I'm just saying some "basics" that are obviously true, like "have coding standards" or "don't access production db directly" or "don't use patterns if you don't understand them".

I believe that certain BEST PRACTICES are so obvious, that there's no room for discussing the basics.

Or am I wrong?

@bzq84 I'm not saying you're right or wrong about some specific practice, I'm on team agnostic. It could easily be that most or all of the things you listed lead to better results 90%+ of the time.

I just don't think things are as obvious or black and white as you claim in general. I also don't like cultures where people form committee type groups with lists of things that other programmers aren't allowed to do. Different programmers work in different ways and that's fine imo. The freedom is a big part of why I enjoy programming.

@ArtOfBBQ i also love freedom, and I agree with you.

My problem is, that so many times "freedom" is used as an excuse to write bad code. Maybe it's just my experience that is negative.

Yes, to all of them, although a handful of MRs were massive and spanned more than 2-3 weeks worth of work, and some people in the team (although the main culprit was moved to another team) were writing dirty code.

But at the same time, my team is fairly new in a massive company (16k employees), and I know from a colleague that other codebases are absolutely crap (which is telling coming from someone who has low standards compared to me).