I think what was missing here was lack of developer buy-in into the actual changes implemented, and making sure that they were reasonable and sustainable. Sounds to me like a blanket mandate was handed out without buy-in and also wasn't achievable, and the developers felt they had to work around it to get their real jobs done.
I agree. At the very least, it seems like he didn't communicate the "why". It certainly wasn't "to make as many tests as possible". I suspect the developers knew that, which is why is also a little unprofessional on their part to treat it like that was the goal.
I think the bigger problem here was inappropriate expectations: "two tests a day". That's not a reasonable way to increase test coverage. And so the developers quite reasonably just tried to minimise the time spent on it.
>Number of unit tests isn't the best proxy for that goal…
However, I don’t think mindlessly creating tests is acting in good faith. It’s bordering on malicious compliance. I doubt they were thinking they can just knock out that metric so they can otherwise create better test coverage. (The OP conceded their coverage wasn’t good). Better employees would work to create a better understanding/goal. All of that points to some cultural problems.
Malicious compliance is exactly what you get when people think your target is stupid and you put some automated, non-negotiable measurement in place.
If I was a developer there, I'd totally started adding those generated tests. I have a job to do (ship products) and you put in some stupid requirements which actually interfere with it (since my time is limited I can either work on tests or my daily tasks like developing new features or fixing bugs), but we both know that if my primary job suffers, I'll pay for it. So the best solution, from my point of view, is the one that takes that requirement away and lets me go on actually working.
When we had a similar problem in a previous company, we just created an epic, assigned a couple of people to it and have them churning out tickets for specific improvements, like "Class X has a coverage of Y on this method, add tests for the missing execution branches", which were clear, non-generic and fully integrated in our flow. If anybody complained about our velocity or whatever, we could show them the full trail which lead us to choose to work on that ticket and how much we spent on it. The coverage issue got solved in less than a month.
>If I was a developer there, I'd totally started adding those generated tests.
If I were a manager there, I probably wouldn’t hire you. You want people who are actively solving problems that matter, not just automatons beating their chest about how stupid everyone else is while they add to existing problems.
I you were a manager there and would approve that metric, no worries, I'd manage to fly it past you.
Any smart manager, having to deal with this kind of policy, would either push back or approve any way to game it and then get the work done. But I doubt that a company which allows this kind of BS can retain smart managers for more than a couple of months.
If you read any of my posts on this thread, it’s pretty obvious I don’t agree with the managers approach. But I also don’t agree that the devs are doing the right thing either.
It’s telling that you show such dichotomous and defensive thinking.
I made the point that the metric used (raw number of tests) is a bad way to enforce a good goal (higher code quality). I also made the point that metrics aren’t inherently bad, but they have to be chosen judiciously.
You seemed to take those two points and extrapolate an entirely different story as a personal affront and apply motives that, frankly, reads as a bit unhinged. So i also hope we don’t cross paths, because in safety critical code development where I come from where bad practices and toxic teammates can kill people.
As someone who’s mid career trying to navigate corporate life and understand the hidden whys in business, I think so. I think of it like a Patreon or Substack. The blog has changed my mental model for the better on quite a few subjects and has changed how I view the world. I think it’s worth the spare change that I have.
a lot of it is hubris as well, they just assume that others will be able to understand it because it's easy and intuitive to them, and if others cannot understand it they must not be good developers
I think the reason why I've found 1:1's so effective is because of the recurring schedule. We're all busy people, and having a structured time to sit down and talk about things helps, even when we don't think it will initially. Yes, bringing up and resolving issues in real time is still key, but there are always things that slip because we have more pressing concerns or we just never found the right time to discuss the issue.
It's like having regular meetings with a mentor, coach, or even a counsellor. I find these meetings to be very useful because the discussion inevitably leads to revelations that I would otherwise not have thought of. Could they have been discovered ad-hoc? Some of them, maybe. But it would be a coin toss with the hundreds of other distractions and responsibilities tugging us from every direction. Even with my spouse, I've found that having regular meetings where we sit down and really talk about things has been extremely helpful.
That being said, everyone runs 1:1s differently and I've been on some really bad 1:1s that had no value or always ended with a negative, bitter taste in my mouth. I use it as an opportunity to connect personally and to provide coaching and mentoring towards their goals, especially when they align with company goals.
I then poke and prod in a way to really get at what the other person is thinking and feeling, what they are struggling with, and ultimately what the root cause of the problems are. The key in my mind is to surface issues that would otherwise not be discussed, and normalize it. I then work diligently with them to make sure we're addressing those issues, and if I have action items to report back to them on how I've been able to make progress. 1:1s are definitely not the only way of approaching this, but the one I've found the most effective.
Granted, some individuals are very vocal and constantly raise and discuss issues outside of the 1:1s to the point where we don't need them as frequently. For them I just push out the schedule more and have them less frequently, or we just use the extra time to again, build that relationship.
The question should be "does my standup provide enough value to the participants to be worth the time? Why or why not? Are there other ways in which we can provide this value?". There is no 1 size fits all solution. Some teams may not find any value in standups, so they should be removed. Some teams find it a valuable time to sync up as a team so they should be kept. Some teams adapt standups to add value in ways that were not originally intended.
All I see here are arguments around a one size fits all solutions. Be fluid. Observe, listen to your team, and adapt.
I've seen this interpreted by smart engineers in a counter-productive way, in that they believe their code is so good that none of it ever needs any comments and hence they never write them despite the fact that their code isn't all that clear. It's more hubris than anything.
Otherwise, there are many techniques you can use to make the code self-explanatory. I've taken a comment before and restructured the code to literally read like the comment.
Tribe (tribemgmt.com) | Vancouver, BC | Front-End, Back-End/FS, Azure DevOps, Mobile, SDET | On-Site or Remote (CAN/US)
Tribe is a property-tech company whose mission is to provide the most comprehensive suite of products and services for building and managing residential communities. Our vision is to change the way people experience community living, connect with their neighbours and interact with their homes. We are ramping up our team after a major round of funding which will also make us public.
Still working on the full job descriptions today but want everyone here to get the first crack at it:
- Front-End (React + AngularJS, TypeScript)
Regardless of whether one chooses to use ADRs or not, recording the factors that went into a major decision is a great practice which can help counter the tendency to use Resulting. That is, we have a tendency to judge whether or not a decision was sound based on the outcome, rather than all the factors and conditions that made up the decision at the time we were making it.
