21
bzq84
3y

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?

Comments
  • 8
    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 🤷‍♂️
  • 1
    @AtuM want to share more?
  • 4
    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.
  • 1
    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.
  • 1
    I'm in the phrase of life of "I wish I work in these kind of company"
  • 0
    Pretty much, yeah.
  • 0
    No but why do you expect so much? Even the biggest success stories in the history of programming don't meet your standards
  • 1
    @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?
  • 0
    @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
  • 0
    @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?
  • 0
    @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.
  • 2
    @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.
  • 1
    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).
  • 2
    I have interned at such a company.
    It all sounds nice but the reality is that they shrank from 150 to 18 developers (because those 18 were the ones instrinsically motivated to do better).

    So that's problem #1: there aren't a lot of developers who care enough.

    The company also had real trouble hauling in projects. All the competition mentioned half the development time (which in turn is half the costs) that we needed. In at least 80% of projects, we didn't even get to the first round of talks. Even though the company portfolio was incredibly impressive and spoke for itself.

    So problem #2: Good luck explaining to prospect clients that your robust code base will save them truckloads money and stress in the long run, but it will take twice as long to make.

    The company still exists and is still financially healthy but they continuously go through a lot of stress to keep it that way.
    Learned so much there though. Would recommend.
  • 0
    @Lucky-Loek oh and pay was very mediocre at best. I'm earning more as a teacher than I would have done as senior developer there. You really only worked there because of the projects and intrinsic motivation to become the best developer you can.
Add Comment