this post was submitted on 04 Jul 2024
14 points (100.0% liked)
Programming
16760 readers
85 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Something that definitely separates me from some of my less experienced coworkers is that, when I sit down and start to implement a plan I came up with in my head, if it turns out that things start exploding in complexity then I reevaluate my plan and see if I can find a simpler approach. By contrast, my less experienced coworkers buckle down and do whatever it takes to follow through on their plan, as if it has now become a test of their programming skills. This makes life not only more difficult for them but also for everyone who has to read their code later because their code is so hard to follow.
I try to push back against this when I can, but I do not have the time and energy to be constantly fighting against this tendency so I have to pick my battles. Part of the problem is that often when the code comes to me in a merge request it is essentially too late because it would have to be essentially completely rewritten with a different design in order to make it simpler. Worse, the "less experienced" coworker is often someone who is both about a decade older than me and has also been on the project longer than me, so even though I technically at this point have seniority over them in the hierarchy I find it really awkward to actually exercise this power. In practice what has happened is that they have been confined to working on a corner of the project where they can still do a lot of good without others having to understand the code that they produce. It helps that, as critical as I am being of this coworker, they are a huge believer in testing, so I am actually very confident that the code they are producing has the correct behavior, even when I cannot follow the details of how it works that well.
This definitely resonates with me. Guess it helps that we've all probably been on both sides here. The last time one of our juniors did something overly complicated I showed them some code from an old commit I made years ago, and asked them to explain what it did - neither of us could figure it out in a reasonable amount of time ๐คฃ
I vividly remember some of the garbage code I've written in the past. Huge interface definitions... Weird and brittle abstractions... Overly complex processes to do what should have been a simple task...
Funny thing is, I read and understood the same kinds of things as any other coder worth their salt: agile, SOLID, YAGNI, do one thing well, and so on -- but it was all just theory. It takes experience and mistakes to really grok it all.