Soft Skills Engineering - Episode 130 (rerun of episode 87): Stand up and fight! and Metrics

Episode Date: October 29, 2018

This is a rerun of episode 87 from December 14, 2017. In this episode, Dave and Jamison answer these questions: ‘I’ve been working on a project for the past year with two other senior developers. One of them is the lead, and the other, is my peer. We all have a lot of respect for each others opinions and resolve our engineering disputes amicably. My problem is that sometimes my peer will just give up saying ““have it your way”” etc. I want to have it out with him and evaluate each solution on its merits. I’ve considered saying ““STAND AND FIGHT YOU MANGY CUR””, but then looked up ““Mangy Cur”” and decided against it. How do i get him to be more vocal about his opinions? (so that i can prove to him that i’m right) I like the idea of measuring things, but I also feel like work “metrics” are easy to game and hard to make indicative of actual quality work being done / product being produced. In particular I worry when the data collected leads people to choose work that will bump stats rather than lead to better end user experiences / product / maintainable code. What kind of data do you think is useful to collect in terms of developer activity? Can you share some examples of ways you’ve been able to assess your own and your coworkers productivity? I’m interested in this both on a team level and a personal one. How can I get better if I don’t have a way to track what “good” is for myself? Is trying to turn the complicated and messy thing that is what I actually do all day into a trackable, data driven domain a fool’s errand?

Greetings, Soft Skills Engineering listeners. This is Dave, your host, and we're coming at you this week for episode 130 with a rerun of episode 87 from last year, when we talk about co-workers who won't stand up for themselves and productivity metrics. We hope you enjoy this week's episode. It takes more than a Turing-complete constraint-based layout system to be a great software engineer. This is episode 87 of the Soft Skills Engineering podcast. I'm your host, Jameson Dance. I'm your host, Dave Smith. Soft Skills Engineering is a podcast where we answer all of your non-technical questions about the technical field of software engineering that's right and turing complete constraint-based layout systems i don't even know if they are

turing complete i just assume because they're isn't isn't the proof of turing completeness just like it's pretty complicated so probably they can probably do everything a turing machine can i guess yeah that's what it is in my head anything i don't understand so this constraint based layout system is this css no css is not a constraint based layout system what is css is a different category i think so i think we're i've heard these words i don't understand them super well i know ios has one i think oh i think it's about where you say like i i want to constrain these elements to have these widths between them and then it kind of like lays everything out automatically in hard to predict ways yeah yeah okay cool uh but this is very technical and this

shows about non-technical things so we should talk about those let's just take 20 minutes where we just listen to the sounds of me let's just go into a deep dive just switch it up jameson's keyboard sounds like when he's googling things he doesn't know about yeah we we know the listeners listen to this show for hard-hitting totally non-expert off the top of our head off the first page of google search results technical information in the dark we have no personal experience with yeah that's what they crave we're just humble servants we're here to deliver what you crave um speaking no real real quick we do not want to answer our first question And yet I wanted to say a shout out to people who have been leaving comments on our website for each episode and taking the discussion in new directions.

I read through a bunch of the comments recently and was, as usual, both surprised and humbled by how little Jameson and I know about anything. Y'all are smart. Good work. It's great. Yeah, it's really it was a frequent and necessary reminder about how limited our scope of existence has been. and it's great to hear what other people have to say about these topics so go check it out at softskills.audio you can click on an episode and scroll to the bottom you can see comments that people have left very interesting yeah for sure all right do you want to read our first question

dave yes this cousin sorry i'm laughing because i remembered how this individual asked us to pronounce his name it's david okay not david david okay david um david writes i've been working on a project for the past year with two other senior developers one of them is the lead and the other is my peer we all have a lot of respect for each other's opinions and resolve our engineering disputes amicably my problem is that sometimes my peer will just give up saying have it your way i want to have it out with him and evaluate each solution on its merits i've considered staying stand and fight you mangy cur but then i looked up mangy cur and decided against it how do i get him to be more vocal about his opinions so that i can prove to him that i'm right

i assume that last part is a joke it has to be it was in parentheses so that means joking right yeah and david sounds like a jokester because his email address was david normally but that's okay we like we like jokes that's why we do this podcast that's right is this like a deep embedded advertisement for whatever fast food company says have it your way is that still is that mcdonald's burger i i don't know is this one of those native yeah are you like a sock puppet for big fast food big burger yeah big burger part of the big burger conglomerate probably because if so that will be several million dollars please that's right and that will be seven several million dollars wasted what are you talking about i

could really go for a good have it your way brand burger at a local establishment right now delicious there are some cultures where where uh there's lots of vigorous debate and i think those have problems all of their own but one of the problems usually is not like people don't stand up to each other and express their opinions all the way sometimes actually but i i guess the flip side of that is if you have a culture of people being really nice and kind and communicating well with each other um sometimes the sometimes the instinct is to smooth things over which might mean that uh some discussions don't happen as vigorously as you would like and i i have been the smooth over a lot i'm definitely a people pleaser and so i feel like if there's a technical

discussion that i have opinions about but that i don't necessarily feel like is worth yelling about or we're just going in circles or something i'll just kind of back off and be like well it's not that big of a deal it's i think i think it should be different but whatever but have it your way yeah but and then there's a glint on my teeth and it makes a noise as i smile and give them the finger guns and then burgers drop from the skies so i understand where your co-worker is coming from i think have you ever been on the on the

giving end of this like stay and fight where i wished people wanted yeah actually there's one specific co-worker well it wasn't quite it did kind of work out like this actually sometimes there's one specific co-worker who who i've talked about him before he didn't speak up as much as we wanted him to um the whole team because he was just a little more shy a little more reserved very very very very very very very smart and we had to tell him like please tell us what you think when you think we are wrong and when you disagree with us uh and he just started doing it more based on feedback we gave him and it was very helpful it wasn't it wasn't as much about debates as this question is that was more about um just feedback and and architecture discussions and things like

that so i have been on that end and and i have yeah i have been on the other end as the person who just kind of backed off a little bit i worked with a a guy who was very tall and very large and had this like giant viking ponytail oh and smoked hand-rolled cigarettes and was very nice but just like an imposing human you know so like like as soon as he walked in the room you were like um you just have it your way okay anything you want on your hamburger sir so did he like you want a taco on your hamburger sure i'll do it have it your way buddy have it your way so like did he did he just say things and you were like yep we should definitely do that no no it wasn't quite like that it wasn't just like me cowering before him it was like we

had some different backgrounds technic technology wise we had some different opinions about the right way to do stuff and uh i just found myself deferring to him a lot both out of this desire to like smooth things over and not caring that much and also like he's just i don't know just just a big imposing human um who wasn't definitely not trying to be intimidating or anything but that that does affect how people interact for sure yeah and i think our technology decisions and our technical output was worse for my behavior even though it was the most comfortable thing to do at the time wow dang so look yeah looking back i would do it differently now but i was just a young lad just going with a young burger king sales associate making my way in the big city

with the wonderful opportunities afforded me by the company so you're saying you probably could of course corrected something that turned out badly but you felt intimidated into going along with the yeah and it wasn't a huge disaster we just we just ended up with things that i wasn't happy with and that caused some friction with the rest of the company some of it was around technology choice it was just this weird one-off kind of frankenstein thing um that we didn't know how to operate very well and some of it was yeah it was was more tactical like the way we did things inside the inside the code we were working on together wow that's very interesting so so i i think if i was in that situation again i would have just talked to him explicitly and said like

hey i feel weird about how we work together i i feel like i need to kind of like back off and let you get your way more but i don't think that's the right thing to do so i i'm gonna try and discuss it more i'm gonna try to i'm gonna try to stand up to you you big bully yeah and and uh knowing him i think he would have been fine with that i think he would have he would have appreciated that it wouldn't have been awkward um he's like you are literally the first human that's ever stood up to me what how dare you do you see how big i am no no don't you know that i roll my own cigarettes again very nice yeah so i i've been weird thing i've worked with a couple of people who one person in particular who was uh uh the kind of person who would give in a little bit

too quickly um and at my last company i remember uh several occasions where i was discussing an idea with this person and at strange points in the conversation at least unexpected for me he would just say yep okay that's fine and i and to me like we were just barely beginning to explore the surface of what we needed to cover to make a good engineering decision and he would just like insta cave you know just boom caved in and even even in situations where i would ask him about how something works or ask because i was curious about something you know and maybe we were trying to make a decision together and i would have a bunch of questions for him he would just kind of be like oh no you know what never mind so i saw this pattern a few times and the

thing is he was a really good engineer and super smart and uh had a good reputation over many years of making good decisions and i really look up looked up to him so when i saw this behavior it struck me as very odd so what did i do well i confronted him about it over chat i i said hey i've noticed a pattern where i'll be asking you a question or we'll be discussing something and you kind of like end the conversation and um i think we should i just i didn't really go i didn't really spend too much time like asking him why or what i just threw it out there and said i think that's going on i didn't really well i didn't i don't remember asking what's going on i just kind of said hey i'd like you to uh follow these conversations

with me all the way to their conclusion and not you know cut cut it off um and it would even happen when he would come to me with a question where i would you know his question would be something and i would start answering and then i would ask him some follow-up questions to clarify things and and he'd be like oh never mind never mind you know so so um i in hindsight i probably was intimidating to him and it turns out that you can be intimidating without intending it at all were you peers at at the time we were probably not peers i think i was probably his uh manager in a managerial reporting hierarchy sure so i could see why that would have imposed like a some kind of pressure that i didn't even realize i was imposing did you see the same behavior with

other people no other developers no i didn't and and that's why this one stood out to me sure so i don't think i was universally imposing but i i certainly think that i was in this case targeted you you understood his psyche and knew how to break it down childhood fears humiliations you you have subtle exactly his his lost childhood toys on your clothing yep anyway um i i'm trying to remember it's been enough years now that i don't remember but i think things improved after that where he was more willing to engage in the conversation all the way to the end at least i don't remember an instance of him withdrawing abruptly after that conversation sure sure yeah so maybe just just hanging a lampshade on it just being open about

it and saying hey i've noticed this yeah and please stand up to me more okay whatever you say i know like you're you're in this bad situation already right so it's really hard to address it but yeah yeah without making without making it worse yeah did i stand up right oh go go ahead nothing it's just you go ahead oh uh some of it could just be communication style so i this doesn't happen to me much for technical things but for non-technical things i have a really hard time pushing back and disagreeing and and saying things i think people might not like or agree with in person like in the moment it's much easier for me to do it in text um kind of asynchronously where I have a little more time to think it over so it could I mean you don't want

to constrain all your communication this way but it it could be easier for for your co-worker to do it if you talk it over in text format maybe you have a design document or you do it over chat or something like that um maybe you are the large and intimidating one have you tried being smaller maybe come in on your knees or something or yeah yeah yeah do that or i know they have um you can have like platform shoes to make you a little bit taller um so they probably have shoes that make you a little bit shorter yeah probably imagine that exists just the opposite of a platform shoe right yeah it's just yeah yeah and i mean the platform goes down then you're a little shorter so try that maybe like suck in your gut a little bit make yourself look look you don't have to just

be shorter you can be you can be have smaller width smaller volume overall it's like the opposite of a puffer fish yeah maybe where suck your cheeks in wear like horizontal stripes or something isn't doesn't that make yeah yeah or or like wear camouflage so it's hard to tell where the boundaries end of your shape and then you kind of blend it into the outside to stuff around you and then maybe assume you're smaller um yeah but just just be smaller speak speak quietly not too quietly because that's intimidating to the co-worker who only whispers why are you whispering i believe our our deployment process could do with some changes like oh no i'm gonna get stabbed does it need human sacrifice

well yeah i mean i think it's worth just talking openly i have seen that work in other in cases yeah i've seen that work and when i've been the person who didn't stand up enough that's what i would have tried um but and you should this needs to be resolved because what i you know jameson's example from a few minutes ago is totally representative of what i've seen which is that the more back and forth discussion you have about important decisions the better the decision becomes now obviously there's diminishing returns here but if you if the conversation ends prematurely you're more likely to make a bad engineering decision yeah and it's possible to build up resentment about this too to feel like um things are moving in a direction you don't like

and you didn't get to or weren't able to influence it like you would want yeah so over time it gets more and more frustrating that that finished product doesn't have your input even though the other person might feel like they're trying to give your input it's it yeah yep exactly it's a resentment breeding ground yes that is a good way to put it all right just talk to him that's our advice um have we answered the question i think so should we go on to our next one let's totally do it i will read the next question this is from a listener named ryan moore he said it's pronounced ryan as in ryan gosling and more as in roger moore roger so it's pronounced roger gosling

yeah no i like the idea of measuring things but i also feel like work metrics are easy to game and hard to make indicative of actual quality work being done and product being produced in particular i worry when the data collected leads people to choose work that will bump stats rather than lead to a better end user experience or more maintainable code what kind of data do you think is useful to collect in terms of developer activity can you share some examples of ways you've been able to assess your own and your co-workers productivity i'm interested in this both on a team level and a personal one how can i get better if i don't have a way to track what good is for myself is trying to turn the complicated and messy thing that i actually do all day into

trackable data-driven domain a fool's errand absolutely not it's not a fool's errand all you have to do is count the semicolons that you and your co-workers type and i'm telling you that is the metric i use prettier so when i write javascript i don't type any semicolons and it puts them all in for me um so you have defeated my system my perfect metric is defeated do you remember we we did talk about productively a while ago and we came up with a number of keyboards that you own or something right as like the null metric so it has to be better than that that's the baseline that was episode 79 i think what how do you know that my mind is blown right now well you know that all i know is there was a title there was a question titled developer

productivity so i just went out on a limb oh are you looking at our trello board yeah okay i thought man i thought it was like a memento thing where you had them all tattooed on your body or something i also have that but those those are harder to search they only show up under uv lights yeah so that's the baseline better than mechanical keyboards that you own that's right so i like how it split into personal productivity and team productivity because i think you can afford to be much more dystopian about personal productivity metrics totally because you're doing it to yourself so like if you measure the number of times you get up and talk to your friend it's not gonna make you i don't know you can't fire yourself over talking to your friend too much

although you could bring that to your boss at annual review time and say you know just so you know here's my dashboard yeah i i should probably be fired i'm really into quantified self i quantified the number of tweets that i read each day and it gets real high sometimes yeah so i think i think it's it's wise to split those up because you can be much more aggressive and and get a lot more info that feels a lot less evil about yourself have you done any personal productivity tracking stuff just for yourself i have about two years ago i started using a tool called rescue time yeah we may have talked about this on the show before i don't remember actually um I love it.

Absolutely love it. The way it works is you run it on your computer. So it only tracks time spent on your computer, but it will categorize things based on the window titles of the applications that you're using. So you can even do it down to the website name. So certain websites can be categorized as productive and others can be categorized as distracting.

And then each week you get a productivity score, which tells you what percentage of your time was spent on productive things and distracting things and how many hours you spent on your computer. and let me just tell you that for me was the eye-opening metric is just the number of hours on your computer yes so many so many more than i expected how about you what would what did you find when you started using um yeah i've used rescue time and yeah i found that i'm not very productive according to rescue time that's probably the most invasive one i've used i've also done

other things i've tracked the number of commits and number of pull requests closed number of issues closed and stuff just for myself um i think i did i think i did one other thing i have like a little text-based to-do system i use sometimes and for a while i just tracked like some little metrics off of that it was it was very very simple just like parsing this text file um i don't think i've gotten too fancy though and i haven't i mean there's so much data like i i read a blog post about a person who just recorded all their keystrokes for all time oh my gosh put them in a database and then they like mine them for patterns and and i don't know there's some interesting things they looked at i thought you were gonna say mine them for passwords

oh no i mean hopefully you know the passwords that you're typing in let's that's that could be very sensitive data and very damaging if it got out right oh for sure yeah for sure um there's there's also you know a lot more hopefully about the impact that your work has so so there's there's two sides to it there's the input there's what you put in and then there's the effect that it has on the code quality or the product or the end user ryan talked about those two things and i think it's really measuring what you put in is is pretty easy it takes some work but there's a lot of tools to do it measuring the output is like the purpose of a business almost measuring the effect on users like that's that's hard and i don't know how you'd tie those things together because i think to some

extent they're not linearly related i think it's possible to just crank out a bunch of features and have users not care oh for sure it's possible to sit in a hammock all day and think real hard and then type for like 20 minutes and have people just have their minds blown yep there's research behind that one too in fact i there was research that i read from amazon and microsoft that found that like two-thirds of the features that they produced either had a negative impact on the user or had no impact on the user at all. And it was only one-third of the features produced

that actually gave benefit. To which I say, well, you got to produce all the features in order to get those one-third. What if we just only do the good third? It's problem solved. Yeah, so that gets into like product development and I guess there are all kinds of metrics around user engagement and activity.

But I think linking those back to specific individual developer efforts. Oh, it's very difficult. Yeah, that'd be hard. There's so many steps that go into it from design to development to like review and mentorship. And other people might throw in ideas, even if you're the person that types the characters. Exactly. So even code authorship might not be the absolute truth. For sure.

For sure. And say maybe someone built the platform that you are using to stand on the shoulders of giants, you know? Yeah, yeah. I mean, it's super complicated to trace that back. Yeah, I think there are some areas that you could attach metrics to and then optimize those. But just getting the broad, the grand unified theory of like, how good is your work for the company and the code base? I think that's a little tricky. I think so, too.

I think the best you can do is more simple metrics that tell you more direct things about what you're spending your time on. Like, how many bugs did I fix? How many lines of code did I write week over week? And then those things, even those things are not absolutely useful. They're usually only useful relative to each other over time. Sure. You can identify trends in your own life. Like, oh, I typically write this many lines of code.

This week was an anomaly. Hi, because I, you know, copied and pasted a 10,000 line library into our code base or something, you know. Sure. I experimented with amphetamines at work. Turns out the short-term productivity gains are astounding. But then you might also see declines that you think are, you know, might be indicative of something else. Like, oh, I haven't written any code this week and that's very unusual for me. What's going on in my life?

And it might, I think what happens is it can act as a circuit breaker to stop behavior that you know isn't helpful to your own well-being. It'll help you notice it before it becomes burnout or some other negative effect. I experimented with amphetamines at work. turns out the long-term effects on productivity are also astounding yeah i i think if if you are working on developer facing things um it can be easier to measure the impacts of your work on your users say say you're trying to build a better deployment pipeline or something like that then you it's it's it's easy to assess metrics on specific targeted tasks like that how like how many deploys do we have how long does each deploy take and and i think those are

good productivity metrics for that task or if you're building a component library or something like that you could think like how much custom code does someone have to write to to finish a feature how much custom ui code so i think i think in more targeted tasks you might have better metrics but just overall yeah that's real hard maybe ask the product people maybe they have it all solved and we just don't know because we don't ask them about it enough that's probably right someone else knows the answer they're like oh this is easy all you do is blah so can i can i make a weird meta comment about metrics and personal tracking sure i believe that we use metrics for things that are too hard for us to understand directly so for example like say you're trying to

measure engagement for your user base if you knew all of your users you wouldn't have to measure engagement like you would just know but but we no single human being can take like a million people's lives and fully synthesize that in our own brain so instead we summarize their behavior through these numbers that are proxies for their actual behavior right so it's kind of it's kind of like the map is not the territory thing i don't know what that is what is that as i understand it it's kind of talking about abstractions and how you make a map and the instant you make a map you have made an abstraction because you've lost data and there's this trade-off between making a more accurate map and like recreating the physical world that it is

a map of so you have to leave information out in order to make it useful but then you have missing information okay yeah so it's like uh yeah like it would be impossible to identify the political boundary for every grain of sand right so you draw a line and some of the grains of sand are like not exactly in that line and right is that yeah yeah it's yeah it's kind of about um models and how they reflect reality and they're always abstractions of reality and so if a model tells you something that doesn't mean like that's how reality is that means that's what the model tells you that's exactly right and that's exactly the thought i'm thinking and it when that's why we use metrics because especially for like large user bases there's no way to track that um and there's no

way for a single human being to fully synthesize the behavior of all their users but if you only had one user and you could watch them every day all day you wouldn't need metrics really right i mean, maybe for remembering over time, you'd need to look back and do that. But, but I'm getting to a point here, which is that maybe numerical metrics are not the best way to track your own personal productivity. And this week I started doing something new, which I didn't even realize was related to this question until just now, which is I've started writing journal entries every night, actually every morning. I picked up this idea from a little workshop that I've been taking each week through my church and all my life people have said you should write a journal and I just

never did and so I started writing down my thoughts each morning just like what are some of the things I did yesterday what are some of the decisions I made how do I feel about them and you know I found that I got a lot more clarity about what's going on in my life than I ever did from things like rescue time or other metrics that I've used to collect and so it's kind of an alternative approach and maybe maybe it's a complementary approach but I think that when we're measuring our own productivity we don't necessarily have to resort to metrics only so you're talking about using narrative a little bit more yeah exactly like um it's kind of like self-reflection more so than just saying well the numbers say i'm happy so i should be happy yeah you know yeah i like

that i i have a developer journal where i talk about um work stuff it's cool it's kind of a combination of things that i'm doing things that i've learned and just how i feel about work stuff And I found that very helpful. I think a key point you hit on is this is very useful for personal productivity because you have the whole story. Right. And it would be very easy to produce a very biased narrative about a team's productivity because you don't have the whole story there. And it's subject to all the biases that people are subject to. But I like that idea.

Sprinkle in a little bit of narrative, a little bit of reflection. A little bit of qualitative, you know? Yeah, yeah. yeah i think the dream is you get a number and then you make that number go up and that means everything is better yeah exactly and that's that's hard to do it's just crap it's not it's just to answer the question that the person wrote uh is it a fool's errand um yes absolutely for your own personal happiness finding a metric or even a small number of metrics that can uh measure your own like productivity and happiness is just i think it absolutely is a

fool's errand you think it's worthless not worth doing at all no i don't think it i think it can have value as one item on your palette of many ways of tracking your own productivity and personal you know personal well-being okay but you're saying as the as the true measure yeah yeah so i i think i agree with that i think i think i agree it can be helpful but it's not like like like we were saying earlier the map is not the territory yes and also a metric won't ever tell you what's important to you right like the metric just measures actions but how do you actually find out like what do i really want to achieve what's important to me that's pure self-reflection totally qualitative right yeah yeah that's true we're getting a little philosophical

here yeah wouldn't want that what would it be an okay time to transition over to measuring the productivity of your team uh sure yeah we could talk about that so earlier you said that it's okay to get really uh you didn't say orwellian what did you say dystopian yeah dystopian orwellian is dystopian that's right i think you're right it's okay to get really orwellian on your own self but with a team that's when you need to get really dystopian microchips implanted in the skin yes like smart carpet that tracks where everyone walks absolutely microphones i mean well there already are microphones everywhere so we live in that

reality welcome to the future but you just need to ask them for their data and then mind that mine all their cell phones for locations all yeah okay so we've got that plan another plan is i think there are two approaches one is you talk very openly with the team about what the metrics are in order to get their buy-in in order to make clear that you don't want these things to be biased or drivers, but, and, and they're not going to affect directly hiring or firing or salary or anything like that. And that way you hopefully avoid, um, some of the negative effects of metrics on, on your actions. Another approach could be to keep them all secret and try and avoid the negative effects of, of metrics on people's actions by having them not know the

metrics. That feels a little weirder, like you're a spy master, but I think if you use them responsibly then maybe maybe the outcome is okay how do you feel about those two options i think that um there's probably a hybrid approach that's best for many teams which is that the team agrees on what's important to the team and they strive to achieve that and they have a measurable way to achieve that and i wouldn't even call that like a metric i would call that like a goal you know and you use metrics to achieve that goal because again metrics can't tell you what's important they just help measure progress towards something so i think i think it's really good for teams to have goals and really good for them to have

nice measurable easily quantifiable and clear uh metrics for lack of a better word to know how they're doing toward that goal absolutely but then so goal is the broad thing and metric is how you're doing towards your goal exactly you're saying yeah exactly but then also i think management needs certain tools at their disposal to be able to quantify how well their people are performing and this is where you get into really dangerous territory but also really valuable information so i mean story points is the big one right um i i don't think i've ever felt like story points were used well around me but that's a metric that almost everyone tracks and i think if you use them for feedback well they could be maybe more than more than useless it's a pretty

high bar actually the bar is it has to be better than the number of mechanical keyboards you own and i think it potentially could be better than that how could you see that's the thing with metrics is more than useless is a bar but it's so easy for a metric to become actually harmful right yeah it is and there's this really fancy law called good hearts law that says when a measure becomes a target it ceases to be a good measure which means that when someone knows that they're being measured by a certain metric and that they will benefit by that or that it's an important metric um they will then start targeting that metric instead of the thing instead of focusing on the goal the metric was meant to measure they will focus on the metric

yeah have you ever seen that happen at work i don't think we've ever done metrics rigorously enough for that to come into effect well the way i mean the way these things usually happen is like management leaks that they pay attention to some number you know and or they'll say something like well that'll come up in his review you know and then you're like oh that's a target right yeah i mean it could be the giant wall size dashboard of a bar graph of commits across the team there's each person's picture underneath the bar the the commit leaderboard exactly um one of my friends ryan florence when he was working at a local company called instructure he was on a small team they wanted to measure their productivity so he just made a little dashboard and all it was was

the number of tickets closed each day and it would just show each person's name and a giant number next to them the number of tickets stay closed and i think he found that helpful and it was also very much self-imposed but also that could totally affect how you approach tickets you could try and close them early you could make them smaller so that you can close more tickets and even if you are aware that you will not be judged in in this case it's a self-imposed metric i think just the fact that it exists could bias your behavior unconsciously absolutely you you might act differently in ways you don't perceive as doing deliberately just yeah because there's a number that you can make go up in fact boy do we like making numbers go up yeah we do and i think a lot

of people are extrinsically motivated by that not everyone i think some people are more intrinsically motivated but some people love to push that bar upward and when management signals that that's important you want to do it because you want to please your company like your management has said this is important so you say okay well i'm going to focus on that i'm going to do that that's obviously important i think i think some people are a little bit more negative about that and they they assume that humans must be inherently selfish because they're always trying to game the metric system for their own selfish game but i think that view is mostly crap because i think what happens is when a company's leadership signals that something is important that most

people will respond by trying to become excellent in that thing and that's why good hearts law i believe is good hearts law because people really want to do not malicious it's just yeah yeah it's not selfish it's that i want to do a good job and my company has told me that this is how i define a good job so i'm going to do that now having said that there definitely are people who respond to the metric for selfish you know basically for selfish marketing reasons where they say i just want to look better than my peers and we track those people in this chart over here we have metrics on how many of them exist and what their effect is on the company yeah so i mean yeah we've talked about tickets closed uh story points commits pull requests are there any other

there are other tools you could look at oh yes there certainly are knowing all the trade-offs associated with them right and and before i enumerate some of my favorite terrible metrics that i use to measure people's uh personal self-worth people's value yes humans let's make that clear yeah i will say that all developer productivity metrics are proxy metrics so you have to be very careful there are no direct metrics of a developer's productivity just absolutely none it's not like that so instead we use proxy metrics and we must be very careful about how we apply them so um you can use lines of code and i think that as a as a leader it's good to know how many lines of code people are writing of course there has to be a story behind

that and you better you better be familiar with the story and not just the number because the number can be easily gamed not even intentionally not even maliciously and also not all lines of code are created equal so you know it has huge caveats but as a broad stroke you can use it to see roughly what's going on in a developer's world at work you said tickets i like to break that up into like features delivered and bugs fixed which i think is really useful another one that i really like is how many code reviews did a person ask for and how many code reviews were sent to a person to get their feedback because that's a proxy for trust between the team if they are going to the same people over and over it's a signal that those people are trusted and their opinion is well

regarded on the team and like how many comments do people make on code reviews do they are they active in the code review system or do they never make comments and then of course on a more anecdotal front i like to use just anecdotal peer feedback where i ask people how are they doing and they can just tell me in story form not number form uh how they're doing and the combination of all of these things even still doesn't paint a complete picture you as a leader have to be plugged in and know this person's story in their day-to-day life but it can supplement that picture i think there's a an interesting tweet by a guy named dan lu he cited someone's blog post about personal programming productivity and this person ended up recording themselves program so they

would just turn on a screen recorder do their work and then watch it oh my gosh look at things that they saw as mistakes they look at where they got stuck they look at where they ended up to and then look at kind of the path they took there so maybe they were working on this gnarly function and they kind of poked around for a while and they ended up with something clean but like they took some detours and they tried to use that to to basically do deliberate practice to allow themselves to improve that's awesome what was the outcome they felt better i don't think there were i don't think there were metrics around it i can read you the headlines though eliminating distractions getting into the habit of getting into flow scheduling my day around when

i'm most productive being patient those those were the the h2 tags in the article so i think those were kind of the behavior changes that this person made interesting so there weren't numbers attached to it but ryan brought up the idea of like how do i improve personally if i'm not tracking things and this is one approach and it gets into the the broader question of how do you practice stuff at work um yeah there's there's deliberate practice and then i forgot what the other term is just incidental practice or something it's kind of where you just like do the work without trying things deliberately to improve at it and the value of just doing the work is not really very high any improvement that happens there is much smaller than people deliberately trying to improve so i

think another broader point is um you don't just improve automatically by experience if it's not experience that you're using to try to improve if that makes sense that's awesome that's very interesting i've never been that deliberate about my about practicing my craft yeah neither have i all i yeah just made me feel real bad that's the outcome of this also i i want to try it someday do you think that if you watch yourself make mistakes and then watch yourself recover and and get to a better outcome that you could somehow prevent yourself from making similar mistakes in the future in software development i know there are things i do that are very inefficient and dumb and bad and i don't know you don't need a screencast to tell you no no i also

know i don't know what they are oh i just know that the way i work is not optimal i think some of it is like there's a journey you go through to get to the right answer and i don't know that you can always just skip the journey and just sit down and think the right answer but i i think i think there has to be stuff to improve on i want to believe that i think i haven't done it pretty pretty much a master jameson i mean what yeah how could you get better i did stream myself programming on twitch once and that was very stressful how long uh it was like two hours or something wow okay i was just making an html page which is not just like doing layout stuff which is not something i i enjoy that much so that was also pretty stressful i recently heard someone doing uh

small programming challenges and streaming it while they do it as like a newbie they aren't they were not newbies but they were saying look as a newbie you might want to watch how an experienced person writes code here you go sure i thought that's actually a few programmers that stream on twitch and i found it pretty interesting to look at them just watch how they do it i've never had the patience to do that long to stick with that though i mean yeah yeah like you get to watch someone sit and think a lot congratulations anyways that's that's one approach to look at improving your own personal productivity. I will, I will link the tweet and the article in the show notes. Anything else you want to say on this topic? Oh, I don't think we can underscore enough

how tricky metrics can be, especially for measuring other people. So tread with caution if you do this and, um, be sure you have the full story before you make any important decisions based on metrics, which are inherently proxy metrics. Yeah, this is a fascinating and deep subject. And my tendency is to kind of dismiss it as useless, but I feel like I could be missing out on some value because of that. It's just easier to say, oh, it's all garbage than to explore and get good at it. I think one more thing I'd say about it is one problem with over-metricizing, over-quantizing, is that the verb? Yeah, probably. Quantitizing, over-numbering someone's work is that you might crank up the efficiency so high that there isn't

really time to sit back and think ever. And a lot of time, the concrete value to users and customers, like we said, is from sitting back and thinking, doing less work, but it's more important work. And if all you're doing is heads down, trying to make all the numbers go up, you might not sit back and think like, what if we threw all this away and did this simple thing instead? So if you do have pretty intense metrics, make sure you leave room for that kind of behavior as well. Awesome. All right. Question answered. Where can people go if they want to ask a question like this they well don't ask this question we already answered it but if you want to ask a different question go to softskills.audio that is our website there's a

big old button on the top ask a question uh you can put in as much or as little detail as you like you can give us your name you can give us a pseudonym you can um give us a series of unpronounceable characters like prince did with his name and we'll try and figure out pronunciations for emoji if you do that and and yeah we'd love to answer your questions thank you so much for sending them in we are slowly working through them all and we hope to work through all of them and then at last we will expire our life's mission complete i look forward to that day on that happy shining note i think we're done all right next week bye