5 ms·

> It reduced the bias in the system from ICs writing up their own packets, which disadvantaged poor writers and poor self-promoters less. It got employees think

> It reduced the bias in the system from ICs writing up their own packets, which disadvantaged poor writers and poor self-promoters less. It got employees thinking less about promotion, since there was less they could control or do. I agree that this seems positive, but you lose some things with this sort of change as well. ICs often have knowledge of their own performance that their managers don't, even when you're having highly effective 1-on-1s. You definitely don't want engineers spending huge amounts of time and energy selling themselves, but you probably do want them to at least a little bit!

lanstin 4y ago
I have been using git logs and cvs logs to see who does what, across hundreds of developers, since 1997. I don't understand how people, managers, claim to not be able to figure it out. And if people are doing work in an engineering organization that isn't backed by commits to some durable and versioned system, that is a huge red flag. They should probably not get promotions till they automate and make their work flow use version control. Even in the 90s this was true (the "install the OS on the new hardware" team would have things more automated than many "application dev" teams). Now in 2020s, the whole AZ should be in git and the change implementation procedure should be a variation on a big button that does "push master to n% of live; wait for monitor/validate scripts roll back or push more; repeat"
- sidlls 4y ago
  There is so much more to engineering than slinging code into the repo. Using commit logs as anything other than a superficial note of trivia is absolutely terrible for anything but the most junior engineers.
  - daemin 4y ago
    There is more to software engineering than just version control logs, but those artefacts should be accessible in the system somewhere, be they documents, diagrams, meeting notes, system logs (for software releases), etc. There should be some way for a manager to see what someone has accomplished by the artefacts they have left on the company systems.

lanstin 4y ago

I have been using git logs and cvs logs to see who does what, across hundreds of developers, since 1997. I don't understand how people, managers, claim to not be able to figure it out. And if people are doing work in an engineering organization that isn't backed by commits to some durable and versioned system, that is a huge red flag. They should probably not get promotions till they automate and make their work flow use version control. Even in the 90s this was true (the "install the OS on the new hardware" team would have things more automated than many "application dev" teams). Now in 2020s, the whole AZ should be in git and the change implementation procedure should be a variation on a big button that does "push master to n% of live; wait for monitor/validate scripts roll back or push more; repeat"

sidlls 4y ago
There is so much more to engineering than slinging code into the repo. Using commit logs as anything other than a superficial note of trivia is absolutely terrible for anything but the most junior engineers.
- daemin 4y ago
  There is more to software engineering than just version control logs, but those artefacts should be accessible in the system somewhere, be they documents, diagrams, meeting notes, system logs (for software releases), etc. There should be some way for a manager to see what someone has accomplished by the artefacts they have left on the company systems.