3 ms·

Agree on some points (first 3 for sure), disagree on others. A major missing one is the demoralizing effect of having to work with incompetent team members, wi

Agree on some points (first 3 for sure), disagree on others. A major missing one is the demoralizing effect of having to work with incompetent team members, with management unwilling or unable to do anything about it. An incompetent person is likely not a bad person - more likely a good person who is the wrong position, or who just isn't capable. I recall working on a team where I was called over by one of the members to help out. I was new on the team, and wondered what the sidelong looks from other team members were about. She wanted to know why her program did not run. I asked to see the compiler output. She asked what a compiler was. How a person could attain a masters degree without actually knowing that is beyond me, but her skillset clearly had nothing to do with software. This was in a government agency, so she was promoted to management where she became one of those other problems on the list.

LaurensBER 4y ago
I'm glad you said that this was at a government agency otherwise I would have been sure that we worked together in the same team, with the same person. I worked together for a year with A. who is a "senior" engineer, some of the stuff that A. pulled was; - Not being able to use GIT. At some point we decided that I would have to do all merges because he just wasn't capable of doing them. - Editing the project using nano on a server because he couldn't figure out how to install GIT on his laptop. This included YAML files where he would manually count the indentation... - Reviewing the old code in a pull-request, multiple times... - Copying the requirements from project A to unrelated project B because they're both Python projects so it should work? - Claiming to be able to program in multiple languages, giving examples such as INI, YAML and JSON... - Claiming expert knowledge in C++ and Java, I haven't seen him read or write a single line in all the time that we worked together. - Sending endless questions over Slack about the most basic things that he could figure out himself (e.g did you look at that PR? When I had already approved and merged it or how do I change something using SQL?) - In general just not getting anything done, there was one sprint in which he finished two tasks, one of which was changing a password in a text file After a while he was made temporary lead and the following happend; - Killed my CI/CD pipeline because "automation is dangerous", manual releases now routinely take over 12 hours... - Introduced a rule that PRs now had to include screenshots of manual tests instead of us writing automated tests - Lying to stakeholders about issues, literally: "we can just claim it was a bug in vendor X code, it will look better!" - Proposing to re-review old PRs every two weeks, because PRs are like fine wine? - Giving tasks to the team that made no sense. E.g a task to clean-up old versions of software X that was upgraded using YUM on a Linux server. I tried to raise the point that the package already included a clean-up script. He got angry and didn't want to hear it, I chilled for a day and closed the ticket. - Insisting that production password would be encrypted on disk (granted, not the worst idea!) just to proceed with then storing the plain-text password on Confluence (where it was accessible to the whole company) and in GIT :) - Killing our database replica's because: "they were misconfigured, someone linked them to the production database. That's very dangerous!" I documented and raised these issues with my manager who didn't want to address them because: "it would be bad for A. motivation". I said screw this, I can't work like this and stopped working with him on that specific project. Productivity dropped 80%. He's currently scheduled for a promotion to "tech-lead" at the end of the year. I've left that place, some places are just not worth saving.
alephxyz 4y ago
> How a person could attain a masters degree without actually knowing that is beyond me, but her skillset clearly had nothing to do with software. I've worked with a few PhD's whose software engineering experience was limited to Matlab scripting. One even refused technical training because that's "not what they're interested in". Another co-worker with a masters still had no idea what they were doing after 4 years working there, often asking the same basic questions at a few weeks interval. Stuff like which branches to merge in a PR or questions that are answered verbatim in a readme file. Having to babysit educated people who refuse or are unable to learn is a great way to get demotivated. When those people start getting promoted to management positions and training junior employees is when things really start to derail.

LaurensBER 4y ago

I'm glad you said that this was at a government agency otherwise I would have been sure that we worked together in the same team, with the same person. I worked together for a year with A. who is a "senior" engineer, some of the stuff that A. pulled was; - Not being able to use GIT. At some point we decided that I would have to do all merges because he just wasn't capable of doing them. - Editing the project using nano on a server because he couldn't figure out how to install GIT on his laptop. This included YAML files where he would manually count the indentation... - Reviewing the old code in a pull-request, multiple times... - Copying the requirements from project A to unrelated project B because they're both Python projects so it should work? - Claiming to be able to program in multiple languages, giving examples such as INI, YAML and JSON... - Claiming expert knowledge in C++ and Java, I haven't seen him read or write a single line in all the time that we worked together. - Sending endless questions over Slack about the most basic things that he could figure out himself (e.g did you look at that PR? When I had already approved and merged it or how do I change something using SQL?) - In general just not getting anything done, there was one sprint in which he finished two tasks, one of which was changing a password in a text file After a while he was made temporary lead and the following happend; - Killed my CI/CD pipeline because "automation is dangerous", manual releases now routinely take over 12 hours... - Introduced a rule that PRs now had to include screenshots of manual tests instead of us writing automated tests - Lying to stakeholders about issues, literally: "we can just claim it was a bug in vendor X code, it will look better!" - Proposing to re-review old PRs every two weeks, because PRs are like fine wine? - Giving tasks to the team that made no sense. E.g a task to clean-up old versions of software X that was upgraded using YUM on a Linux server. I tried to raise the point that the package already included a clean-up script. He got angry and didn't want to hear it, I chilled for a day and closed the ticket. - Insisting that production password would be encrypted on disk (granted, not the worst idea!) just to proceed with then storing the plain-text password on Confluence (where it was accessible to the whole company) and in GIT :) - Killing our database replica's because: "they were misconfigured, someone linked them to the production database. That's very dangerous!" I documented and raised these issues with my manager who didn't want to address them because: "it would be bad for A. motivation". I said screw this, I can't work like this and stopped working with him on that specific project. Productivity dropped 80%. He's currently scheduled for a promotion to "tech-lead" at the end of the year. I've left that place, some places are just not worth saving.

alephxyz 4y ago

> How a person could attain a masters degree without actually knowing that is beyond me, but her skillset clearly had nothing to do with software. I've worked with a few PhD's whose software engineering experience was limited to Matlab scripting. One even refused technical training because that's "not what they're interested in". Another co-worker with a masters still had no idea what they were doing after 4 years working there, often asking the same basic questions at a few weeks interval. Stuff like which branches to merge in a PR or questions that are answered verbatim in a readme file. Having to babysit educated people who refuse or are unable to learn is a great way to get demotivated. When those people start getting promoted to management positions and training junior employees is when things really start to derail.