I find it funny that someone would go out of their way to configure a test plugin, only to exclude all tests. That’s how im choosing to interpret this meme.

I came in just to talk about Planet X as well! It was certainly a fun little adventure.

Have you posted this question on the lemmy_admin community over on lemmy.ml? Or possibly joined their matrix chat as linked on their github project? I suspect you will be able to get much more targeted support directly from the team or their community rather than the selfhosted community which is more general to all kinds of self hosting.

I do agree with the sentiment with lists being dangerous, especially when thrown around title discussions. It’s far too tempting to interpret it as a checklist when in reality every engineer is so different and provides value through different strengths.

As a self-reflection tool, this is a decent list. When I onboard new team members at the start of their career, I like to boil this down into its broad theme in hope that i can shape their perspective on work from the outset – There’s being a software coder, or a software professional. Soft skills are just as important as technical ones. We’re here to work together as a team and get stuff done. As you grow your soft skills, the scope of your influence will grow. Starting from influencing the path of a single ticket, to the team, multiple teams, and then to the org.

Many of these soft skills revolve around ego, trust, collaboration, and communication. The only item that stands out from the rest in that regard is

• How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid

It gives off a vibe of superiority. Being able to explain a technical concept to someone that isn’t quite understanding it is certainly important. But it’s not about indulging. You need to be able to alert a product manager when their design will lead to an implementation that’s bad for the system so that they can address it. You need to be able to let you manager know when a project will be delayed because you need to take care of an unforseen complex technical issue that puts the project at risk. You need to be able to point out areas your code impacts such that a QA engineer can include edge cases for the most complete coverage. These all require knowing how to break down an explanation in more detail until thry understand it. It’s possible that someone wants to know more about something that’s out of their depth because they’re curious and want to learn. That’s ok too.

This article and many others are part of the awesome-cto list. If you’re not already aware of it, I’d recommend poking through and reading the ones that stand out to you. My manager started a “book club” with the managers that report to him and this has been serving as a source of interesting discussion each month.

I switched from develoment to management (of the same team) just under 5 years ago now. Early on, I made the mistake of trying to still participate in some of the work, but I quickly abandoned that when it was obvious I was just getting in the way. My methods for staying sharp have adapted over the years. I don’t really think full pendulum swings are necessary to stay effective.