3 ms·
> That's easy: HR Unfortunately, that approach doesn't scale well. In a larger company, there are always new users discovering the systems and how they work (t
by jameskraus 6y ago
> That's easy: HR
Unfortunately, that approach doesn't scale well. In a larger company, there are always new users discovering the systems and how they work (to varying degrees). If doing the right thing isn't by-and-far the easiest path, then it's highly likely someone will misuse the tool – no matter how smart they are. It's far easier to make the interface really easy to use than it is to educate users on proper usage.
- thanksforfish 6y ago> there are always new users discovering the systems Software engineering turnover rates can be high, like 13%/year [1]. Add to that engineers who internally switch teams. New users is a real concern. In this case, it sounds like a custom deployment tool, so even engineers with good experience at other companies may not find the feature. Good team on-boarding and documentation is important. I think code review should catch something like this. Even with the high rate of new users, there should be enough experienced code reviewers to catch the issue. [1] https://www.techrepublic.com/article/software-had-the-highest-job-turnover-rate-of-any-industry-in-2017/ https://www.techrepublic.com/article/software-had-the-highes...
- asveikau 6y agoThe problem is when the distance between the team writing the package manager and random team trying to work on some feature is high. That entire team might not be aware of the team that wants them to deploy gradually and in a specific way. To them, maybe even it's a lot of noise and useless complaining and they don't see it as at all connected to getting their feature done. A common large company problem. People who should be talking are not. New hires are also hired into the "local" subculture of their team and something very, very important elsewhere in the company is not on their radar.