1. 66
  1. 16

    Excellent read! A huge part of transitioning into more senior roles is just letting things go. Style doesn’t have to be perfect, code coverage doesn’t have to be 100%, the system doesn’t have to be designed to your exact liking. It’s ok to hold yourself to a high standard, just don’t try to push that standard on others. Being senior (and beyond) means being able to work alongside people who have different values and priorities than you.

    1. 6

      Very good points. One of the bigger ones mentioned here that doesn’t get talked about enough IMO - basically every codebase that solves a business problem can be described as a horrible mess of spaghetti code riddled with technical debt, insufficient automated testing, etc. Our job is ideally to both improve it and add features and fix bugs while keeping everything running continuously. Not always easy, but that’s what we get paid for.

      And also that, if your team wants to enforce strict style standards, it’s much better in multiple ways to implement some kind of automated linting than for reviewing developers to leave comments on PRs about indenting and line breaks and such things.

      1. 5

        I’ve just started my first role at a larger-than-tiny company, and the point that resonates with me the first is the urge to document everyone else’s code. I’d encounter these 500-line functions consisting of totally undocumented business logic with tons of mutation, 3-level-deep forEach loops, and duplicated code everywhere.

        I’d spend the ~20 minutes necessary wrapping my head around it enough to get a feel for what it’s (probably) doing, and then my next thought is to add a big doc comment at the top explaining my archeological discovery.

        It was only after I had a co-worker slack me and ask “what this function does” that I’d carefully documented with argument + return types and everything that I realized the issue. I realize more and more that people rarely read comments, especially big blocks of text - and that problem is only exacerbated by the fact that several other people working on the codebase don’t have English as their native language.

        As an alternative, I’ve been switching out critical parts of the codebase to use TypeScript. While the added types aren’t quite “self-documenting” as some FP enthusiasts may extol, having a type to go-to-definition on is a lot better than an imperceptible entityDefinitionConfig variable that is indexed into 2 levels deep using dynamic keys.

        1. 3

          Why are people seemingly obsessed with the word ‘senior’?

          You can write a whole blog post about what you thought being a senior meant, how you were wrong and how you really learned what being a senior meant. Meanwhile the whole thing is just definition and semantic.

          1. 0

            People like titles apparently, it broadcasts their “success”. Its not specific to IT. Its similar thing as with women and uniforms.

          2. 1

            All the hierarchical segregation gives a company the perfect excuse to pay less to its employees. And that is about it. The side effect is that people will avoid logic and (real) teamplay and start throwing titles and years of experience around like they meant something (like the author did at the start of the article)

            1. -3

              You are senior when you are independently improving the project (without babysitting or mentoring or mansplaining), not when you have N years of experience. I think that summarize the best the properties such person must have.

              1. 4

                In the real world, you’re senior when you’re in your late 20s, apply for a new job, and get the “senior” title as part of your salary negotiation. Of course, some companies actually have true seniors, but in my experience the “senior” engineers we’ve hired end up doing the exact same work I do (<3 years of experience).

                1. 7

                  Please don’t use words like ‘mansplaining’, they don’t add anything sensible to the discussion. Babysitting and mentoring did the job just fine without politicising the issue.

                  1. -1

                    Mansplaining might well be entirely consistent with a senior programmer independently improving a software project. The term is a gendered insult for communicating with more confidence than your interlocutor (justifiably or unjustifiably) thinks you ought to have, it’s not uncontroversially bad.

                    1. 9

                      It’s not about overconfidence so much as explaining something to a person who knows more about it than you do.

                      1. 4

                        I think it’s even more so, about the unspoken assumption that, as a man, you are qualified to explain anything to anyone. My wife, who is a very accomplished lawyer in a male-dominated field, encounters this daily.

                        1. 1

                          Yeah, that’s specific to mansplaining. My point was a more general one, which applies to *splaining.

                          1. -1

                            My point is that its always about a man explaining to another male or female (nothing about correctness). In that regard, in 20y of xp I never had womansplaining (including all seniors in my team). I don’t care about politics, thats how it is in my environment.

                            1. 1

                              Oh, yeah, I don’t doubt that. My generalization wasn’t meant to imply that women tend to do this too. I was referring to things like whitesplaining, etc.