3 ms·

I don't like this. This seems like a lack of transparency and an attitude like "I won't teach anyone anything because then they will take my job" This is not a

I don't like this. This seems like a lack of transparency and an attitude like "I won't teach anyone anything because then they will take my job" This is not a fun person to work with

derekp7 4y ago
There is a way to do this that doesn't involve (possibly unethical) knowledge hording, such as having skills in areas that the team you would typically be on wouldn't have. But skills that still enhance your role. For example, I've always been employed as a Unix (now Linux) sysadmin / engineer / devops whatever. Basically my team creates system build standards, installs and maintains infrastructure. However I also know systems level C programming for the past 30 years. What this means is that when a system is showing a high load, but tools such as top aren't pinpointing any given process, I can run strace on those processes and observe a lot of fork/exec short-lived child processes due to inefficient code. Then I can help the developers make the code better. Or, again using strace, diagnose why a third party vendor's license manager crashes on startup (it kept a few configuration related XML files opened read/write, and when disk full events happened one of the XML files went zero bytes which caused the app to crash on startup because it wasn't coded properly to handle exception conditions from the XML library it used). I've also thrown out a few sorely needed web utility apps with Javascript, low level server-side code interfacing with specialty equipment, and various data conversion and analysis tools that were useful for specialized in-house software. Oh, and I used my C programming skills to let a developer know why their code went into an infinite loop when porting it from big endian to little endian architecture (they didn't account for a null terminator when copying a string in a loop, overwriting the counter variable on the little-endian machine but the bug went unnoticed on the original big-endian host). Summary -- be a pinch hitter in addition to your day job.
- eric4smith 4y ago
  Yes this is exactly what I meant. Definitely not to be a knowledge hoarder - that would make no sense.
paulcole 4y ago
> Be the person that has the answers no one has. I think (hope) you’re misinterpreting this. Try to be the person everyone comes to for info and then give it to them. You can be the most fun person to work with because you’re the most helpful, have knowledge about systems/processes, will help those who need it to develop the knowledge you’ve gained over the years, and are reliable. You can thrive being very average at your job if you do this.

I don't like this. This seems like a lack of transparency and an attitude like "I won't teach anyone anything because then they will take my job" This is not a fun person to work with

derekp7 4y ago

There is a way to do this that doesn't involve (possibly unethical) knowledge hording, such as having skills in areas that the team you would typically be on wouldn't have. But skills that still enhance your role. For example, I've always been employed as a Unix (now Linux) sysadmin / engineer / devops whatever. Basically my team creates system build standards, installs and maintains infrastructure. However I also know systems level C programming for the past 30 years. What this means is that when a system is showing a high load, but tools such as top aren't pinpointing any given process, I can run strace on those processes and observe a lot of fork/exec short-lived child processes due to inefficient code. Then I can help the developers make the code better. Or, again using strace, diagnose why a third party vendor's license manager crashes on startup (it kept a few configuration related XML files opened read/write, and when disk full events happened one of the XML files went zero bytes which caused the app to crash on startup because it wasn't coded properly to handle exception conditions from the XML library it used). I've also thrown out a few sorely needed web utility apps with Javascript, low level server-side code interfacing with specialty equipment, and various data conversion and analysis tools that were useful for specialized in-house software. Oh, and I used my C programming skills to let a developer know why their code went into an infinite loop when porting it from big endian to little endian architecture (they didn't account for a null terminator when copying a string in a loop, overwriting the counter variable on the little-endian machine but the bug went unnoticed on the original big-endian host). Summary -- be a pinch hitter in addition to your day job.

eric4smith 4y ago
Yes this is exactly what I meant. Definitely not to be a knowledge hoarder - that would make no sense.

paulcole 4y ago

> Be the person that has the answers no one has. I think (hope) you’re misinterpreting this. Try to be the person everyone comes to for info and then give it to them. You can be the most fun person to work with because you’re the most helpful, have knowledge about systems/processes, will help those who need it to develop the knowledge you’ve gained over the years, and are reliable. You can thrive being very average at your job if you do this.