1. 16
  1.  

  2. 10

    I’m surprised none of the strategies were “Stop it in advance.” If garbage doesn’t pass code review, garbage doesn’t get checked in.

    1. 5

      And even better if it can be stopped before it gets to code review by automatically running lint/static analysis tools. This won’t fix all bad code, but it does help prevent broken window syndrome.

      1. 3

        Yeah, proper code review is really the solution here. That does require an organizational change at some companies, unfortunately.

      2. 8

        My experience has been that it is usually futile. If you are both equally powerful, organizationally, then you grumble to yourself and continue. It isn’t until someone who is more powerful than the NNPP takes notice—and cares—that change happens, and, generally speaking, the only “change” that I’ve seen that worked was termination.

        If it’s a junior developer who’s just starting out, you can sometimes mentor them into a better place; but this is reliance on a more powerful position, as well.

        Fundamentally, if someone is relatively experienced and hasn’t picked up good habits or the desire to improve their skills, you certainly aren’t going to revolutionize their self-image or approach. Studies in our industry are incredibly fluffy, relying on toy problems or based on case studies of situations that can never be repeated. Everything is debatable. My best conversations have been with peers who disagree with me on various subjects (I don’t like TDD, but do like testing; I like static typing; I find higher abstractions like monads useful and powerful; I use vim instead of Sublime…), but these peers, generally speaking, don’t write terrible code. Any disagreements are good-natured, and both parties come away from discussions with more knowledge.

        1. 5

          This means a CEO or founder has tremendous power regarding culture. They are the only person who can:

          Fire anyone

          Hire anyone

          Decide how/why people are rewarded

          Decide how/why people are punished

          And with those 4 powers, every CEO is in fact a Chief Cultural Officer. The terrifying thing is it’s the CEO’s actual behavior, not their speeches or the list of values they have put up on posters, that defines what the culture is. Without these four powers any employee at the company is along for the ride in a culture driven by someone more powerful than they are. By the time the first handful of employees are hired, the culture already exists whether anyone realizes it or not. The people with the most power to fuck up the culture are simply the ones with the most power.

          http://scottberkun.com/2014/critique-dont-fuck-up-culture/

          This is my observation: raw organizational power is how you change the organization, of which code is only one facet of. If the wielder of power understands technical skill and encourages it, the org has better technical chops. Otherwise… no. Won’t really happen.

          1. 7

            This is a good synopsis, and I’d add something else: while bad code sometimes comes from talentless programmers, it just as often comes from good programmers working to deadline, cutting corners, and building up technical debt to hit one more target that the business guys called “urgent”.

            Often, the person writing shitty code is giving The Business what it wants: requested features quickly, with no pushback. Of course, giving The Business what it wants is like feeding someone a diet of pure sugar: years later, that person dies a horrible death.

            This makes it hard to oppose, attempt to direct, or otherwise modify the behavior of, the person writing the shittiest code. That person’s often already a managerial favorite, code quality be damned. The Business can’t see technical debt. And while there are good things as well as bad ones to the current job-hopping climate, one of the major negatives is that people don’t care about their technical legacies because they’ll either be promoted away from their messes, or in other companies, long before anything could stick to them.

            How this tends to play out is that, at some point much later, The Business realizes that its performance is being wrecked by the shitty tech, but this is usually 3-5 years after the bad decisions were already made and the deadline culture is already established. This leads to a rewrite and an old team vs. new team dynamic, but the new team often has to suffer idiotic deadlines as well as the old, and is getting no support from the old team due to a mutual animosity, so a lot of buried business logic is lost forever and the result is that the new system is even less useful, so the rewrite fails. This is career-negative for the people on the “old team” and the “new team” when it happens, but the people responsible for the old team’s underperformance– the long-since-promoted-away programmers who let the deadline culture in– are unaffected.

            1. 2

              As a junior programmer who is constantly insecure re: the quality of my work, I really hope someone would do this rather than wait for it to bubble up, and would welcome it from another junior as well.

              1. 5

                It is not a good idea to work on the assumption that coworkers are going to attempt to mentor you. There are a few reasons for this: there is always too much work, deadlines are too tight, and there are HR risks involved.

                The best thing to do, in my opinion, is to independently seek to improve the quality of your work. Continue to learn more languages, do exercises you find online, read papers and books. Read code. Consider subscribing to some mailing lists for projects you find interesting, where pull requests and feature requests are discussed; even if you don’t participate, some of the discussion will be edifying. If you do find a coworker approachable and skilled, ask questions (in an asynchronous way, not interrupting their work). Always make sure to try things before asking; nothing is more frustrating than answering the same question a dozen times for the same person. Focus on developing your skills, not getting over the next hurdle.

                1. 1

                  I’d suggest working on open source projects and letting that feedback help improve your code…. there’s nothing more aggravating when two seniors disagree on code direction, specially when both don’t appear to have looked outside the company in years (hasn’t happened in a few years to me, but it was horrid when it did happen).

              2. 4

                Addressing your coworker’s bad code is subsidizing your company’s bad hiring judgement, and it’s not in your long term interest.

                If it’s bad enough to be a problem, you’re probably not going to be able to fix it, because without substantial leadership authority you can’t change organizational values (i.e. misguided acceptance of bad programmers.) You can nudge the needle, but you cannot swing it. If it’s a real problem, vote with your feet.

                1. 3

                  I think the one strategy that this article missed was: “approach the conversation with an open mind”. If you are really all responsible, then finding out why Bob did what he did is just as important as correcting it. Of course there are obvious issues like method length, but often the code discrepancy is going to be subtle and worth discussing.

                  Code reviews can help at the strategic level too. If you have time and management buy in, they are fantastic ways to both disseminate knowledge and make code corrections in a relatively unloaded arena.