196
Your Engineers Aren't Lazy, Your Codebase Is Punishing Them (piechowski.io)
submitted 7 months ago by to c/programming@programming.dev
62 comments fedilink hide all child comments
 

A client’s team spent a full week adding a CSV export to their admin panel. Two engineers, clear requirements, maybe a day of actual work. The rest of the time went to understanding existing code well enough to change it safely. That’s what I call codebase drag: when the codebase makes every task take longer than it should. It doesn’t show up in any dashboard or sprint report.

you are viewing a single comment's thread
view the rest of the comments
[–] 19 points 7 months ago (3 children)

If your team is only focused on tabs/spaces or soapboxing during code reviews, you have bigger issues to take care of.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 7 months ago (2 children)

    Show me a place where this isn’t the case. Because I’ve never seen it not be the case in 20+ years in the field.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 7 months ago

    15+ years in engineering here. 10+ in leadership.

    Code formatting hasn't been an issue since the early '10s. Tabs or spaces? Who cares. Your editor can make it look like whatever you want and it won't effect the code.

    As for other asshole-ish behavior or gatekeeping, I open it up to a vote. Let the team determine best practices. Don't like what your team decides? Find another team to shitlord over.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 7 months ago

    You must work in dreadful places. I've seen it a few times, but most places have been productive.

    It needs a good lead dev to set the culture though.

    Whitespace change debates can be avoided by using rule sets in IDEs and agreeing standards within the team.

    Good static code analysis tools in pipelines and IDEs handle most technical issues leaving reviewers to focus on design, maintainability, clarity and readability.

    You can avoid pickiness if you communicate why, so they learn and understand. If you use PRs as a training and learning tool they're quite productive. If not sure, ask why something was done.

    And if you get picky comments respond with "personal preference and not part of team rules". But also, you cannot be defensive in your PRS. You have to be open to feedback and points and happy to discuss. Be polite even when feedback is invalid. Defendivesness kills constructive feedback and no matter how old you are and how long you've been doing it, you can still improve. Oh and if you been doing it that long, you're a senior or lead and can influence how things are done.

  • permalink
  • fedilink
  • source
  • parent