I'm personally trying to gradually loosen my own similar role within the context of the dev.to codebase. It seems that the only times I ever have to request changes to a @rhymes
pull request is when I have some deep knowledge of a hack or undocumented decision taken a few years ago when I was solo-hacking on the project.
It's easier said than done, but I pray for the day I don't have this "special role" of just knowing things other people probably don't. If I were a 10x engineer I probably wouldn't have created that role for myself in the first place 🙃 (or perhaps 10x engineers aren't a thing).
Agreed, I don't really maintain as huge a codebase but it's getting to the point where I'd rather keep track of why something was done than how it was done. Especially when working with other contributors, it is easy to review their approach by comparing it to your design and not the way you may have implemented the same thing.
Yes, your approach is one of servant leadership, which is a much healthier approach (in my opinion). I always hope to raise up my team to a place where I’ve made myself obsolete.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Haha I hear you. But if you focus on your technical and soft skills, then you will never have to worry about having a job. Your position might go away but you’re free to focus on a more difficult challenge.
In management courses they teach the topic of "chief vs leader". The leader inspire and the others follow it by mean of good examples. The chief commands and the others obey it by obligation.
If someone delegate tasks, he should trust the one in charge giving only non-mandatory feedback.
The ultimate goal is for a pure management is to delegate everything.
In software engineering it is to divide the complexity of the software and make it flow through persons or group of persons that can fully understand it.
In this book the author treat also the topic of why the industry should not be based in the inspiration of geniuses that could handle all the complexity of the software.
That's why the focus of the Book, and also the software development methodologies of the last decades, has been the "industrial strength software". They define such software as a software that has enough complexity that no person can not fully understand in details.
I don't know if an internet forum can achieve such a level of complexity, but a rule of thumb can fit here:
If just one person can understand it, then the software is not complex enough... or that person is a genius.
I would say in practice geniuses are good for a project, as long as they are humble and cooperative. I would hire them, but I would make them part of the design or the quality team. They would be only be able to touch the code by mean of pair programming, so that there is a redundant backup.
Geniuses trend to be a high demand resource, and there is not guarantee that they can be retained forever.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Absolutely.
The Problem With Heroes In Software Development
Beekey Cheung ・ Sep 23 '17 ・ 5 min read
I'm personally trying to gradually loosen my own similar role within the context of the dev.to codebase. It seems that the only times I ever have to request changes to a @rhymes pull request is when I have some deep knowledge of a hack or undocumented decision taken a few years ago when I was solo-hacking on the project.
It's easier said than done, but I pray for the day I don't have this "special role" of just knowing things other people probably don't. If I were a 10x engineer I probably wouldn't have created that role for myself in the first place 🙃 (or perhaps 10x engineers aren't a thing).
Agreed, I don't really maintain as huge a codebase but it's getting to the point where I'd rather keep track of why something was done than how it was done. Especially when working with other contributors, it is easy to review their approach by comparing it to your design and not the way you may have implemented the same thing.
Yes, your approach is one of servant leadership, which is a much healthier approach (in my opinion). I always hope to raise up my team to a place where I’ve made myself obsolete.
Iv heard this obsolete thing before. I've seen it too, 💯 agree, but honestly I don't want to be a VHS, I want to be blueray.
Haha I hear you. But if you focus on your technical and soft skills, then you will never have to worry about having a job. Your position might go away but you’re free to focus on a more difficult challenge.
That's a good approach for a leader.
In management courses they teach the topic of "chief vs leader". The leader inspire and the others follow it by mean of good examples. The chief commands and the others obey it by obligation.
If someone delegate tasks, he should trust the one in charge giving only non-mandatory feedback.
The ultimate goal is for a pure management is to delegate everything.
In software engineering it is to divide the complexity of the software and make it flow through persons or group of persons that can fully understand it.
In this book the author treat also the topic of why the industry should not be based in the inspiration of geniuses that could handle all the complexity of the software.
That's why the focus of the Book, and also the software development methodologies of the last decades, has been the "industrial strength software". They define such software as a software that has enough complexity that no person can not fully understand in details.
I don't know if an internet forum can achieve such a level of complexity, but a rule of thumb can fit here:
I would say in practice geniuses are good for a project, as long as they are humble and cooperative. I would hire them, but I would make them part of the design or the quality team. They would be only be able to touch the code by mean of pair programming, so that there is a redundant backup.
Geniuses trend to be a high demand resource, and there is not guarantee that they can be retained forever.