in today's episode we're going to continue our discussion on principles these are principles that i hold personally and you're welcome to use them however you want to i encourage you to develop your own based on your experiences on your observed uh observed realities on your observations and also on uh the various mental models and frameworks you may encounter the pieces of truth that you find along the way principles are not pure truth this is very important to understand as you develop your own and as you apply the ones that i talked to you about today principles are not uh just an unadulterated truth they are some kind of piece of truth okay some something uh that is observable in the world some system um that tends to work in a particular way and they have the capacity to be instructive they're not instructive on their own but they have the capacity to be used in an instructive way and you'll see this as we talk about today's principles you'll see how they are instructive most of the time they're instructive in individual ways ways that are specific to the person who is encountering the principle these may be useful to you they may not be if they're not discard them these are not uh some kind of uh religious texts to follow all right the whole idea of principles is to take the ones that work for you take the ones that matter to you and apply them principles are meant to be a practical tool not uh some kind of aspirational you know uh metaphorical thing these are things that you can use so the first principle is actually working off of some of the research that danny kahneman did and this doesn't get too complicated the basic idea the the principle itself is people tend to focus on the things that they are measuring more than they're focused on the things that they're not measuring this is the basis for the idea of measure what matters and the the research for this is summed up in danny kahneman's book when he talks about what you see is all there is the idea being that what is uh in front of you especially the things that you measure the things that you quantify uh you are going to weight those things as more important or more impactful than the things that you're not measuring even if that's not true a great example of this uh is trying to measure the things that you measure and the things that you measure are going to be measured by the impact of a given project and you're trying to measure let's say um the impact of a given project and you're trying to predict what will happen in the future and so you may use a number of things that you've measured in the past for example you might use what a similar project uh did what what impact did it have you may measure what another company who implemented a similar uh you know feature set uh what kind of impact did it have for them you may take guesses from the people in uh that are working on the project on what level of impact they believe it will have but there is a huge amount of unknown and uncertainty in these measurements and so you may rely on these predictions because they are all that you have to go on and you may kind of begin to believe uh or develop a belief or even make very important decisions based on a belief that the measurements that you have summarize the kind of principal components of the information in this case trying to predict the future there are so many unknowns that the measurements that you have very often are a minuscule part of what will actually happen and so uh if we wanted to improve on this this is where things get interesting if we wanted to improve on this then we need to regularly be considering how good are our measures how good are our measures at describing an outcome and the important thing here is that uh if you say that it's the best that we have uh then it still may not be good enough to use because of this specific principle this is how it becomes practical right if you say that you have a measurement that is not very descriptive but it's the best one that you have then you're not going to be able to use it because of the you're going to continue using it you're very very likely to fall prey to imagining that the that the measurement that you have is indeed more authoritative than it really is that's because it's very easy to ignore or discount the things that you're not measuring another great example of this is measuring the activity of your uh of a workforce of your reports of engineers on your team measuring activity is a very important part of measuring activity and measuring activity is a very important part of measuring activity uh very often reduces the total amount of work down to a series of numbers and so often uh these numbers are only a shadow of what is actually happening with the work this is one of the reasons why for example measuring lines of code is a very bad measurement it is not descriptive it does not have high cohesion to positive outcomes high number of lines of code is a very bad measurement it is not descriptive it does not have high number of lines of code is a very bad measurement it does not have high number of lines of code does not have a positive uh correlation to high uh high positive outcomes what will often happen in these scenarios by the way uh if you were to over rely on these pieces of information especially if you continue adding information right so if you continue adding these minuscule you know minor pieces of data uh that don't actually have a high cohesion to the outcomes um you're likely to increase your confidence that this data is descriptive without actually increasing whether the data is descriptive itself in other words you could have three pieces of information and be mildly confident or you could have 10 pieces of information and be very confident but the 10 pieces are not any more descriptive or helpful as measurements than the three pieces this is counterintuitive because we look at the data and we're not able to measure the data at the quantity of uh of information points that we have rather than looking at how uh correlated each of those information points actually are to the outcomes that we care about so once again the principle is that we tend to over index on the things that we are measuring relative to the things that we are not measuring even when the things that we're not measuring are more descriptive of reality than the things that we are not measuring and so we tend to over index on the things that we are we're going to take a quick break and then we're going to come back and talk about the second principle for today you've probably got bug reports sitting in your inbox right now and those same bug reports are probably not ready for you to work on them why why is that well because most bug reports come along with very little content and they're not ready for you to work on them so you're going to have to work on them so you're going to have to work on them so you're going to have to work on them usually it's just a quick description uh maybe there's a screenshot but half the time the screenshot's only only showing half of what you need to see uh no console logs or even partial logs which might be even worse uh no ids of course um you have to go chasing the information on the reproduction steps uh and once you get them you might not be able to actually even reproduce the thing anyway uh instead of fixing it you're you're bothering the person who made the ticket to try to reproduce it themselves so you're going to have to go chasing the information themselves you get on an hour-long call they can't reproduce it either ultimately it's frustrating to figure out what went wrong when you have so little information today's sponsor is jam.dev and they're working to fix that problem developer friendly bug reports in one click you may have heard of it is used by more than 75 000 people that was at the start of this campaign and it's grown quite a bit since then even uh that's because it's a free tool uh saves software engineers like you a ton of time and a lot of time and a lot of time and a lot of time and a lot of frustration because it forces those teammates who are filing those bug reports to do it perfectly they literally can't do it wrong because it automatically includes a video of the bug it includes console logs network requests all the information that you might need to reproduce and debug the problem it even includes their internet speed and automatically lists out the steps to reproduce the bug directly it's so easy to get your teammates to use because it's just a chrome extension so when they see a bug they click a button right away it creates a ticket in your issue tracker not a new proprietary one and it saves time for them it saves you a lot of hopping on calls and meetings to debug and using jam you can go from having a bug report that doesn't have a lot of information you know what to do with to having something that's so descriptive that you can make an automated test just by copying the attributes from the report go and check it out it's totally free at jam.dev that's j-a-m.d-e-v jam.dev so we're talking about principles in today's episode the first principle that we discussed is the fact that we over index on the things that we're measuring even if there's a lot more information out in the things that we're not measuring in other words we tend to hyper fixate on the things that we're not measuring and we tend to hyper fixate on the things that we're not measuring and we tend to hyper fixate on the things that we're not measuring and we tend to see and especially the things that we are intentionally measuring the things that we are looking at directly the second principle today comes from the field of communication and specifically the theory of communication and this is this is coming from kind of the classical theory of communication where you have a messenger you have a message and you have a receiver and then there's feedback in that and the principle that we're looking at is very simple. A message, once it leaves a messenger, okay, once it leaves the messenger, can only either remain the same quality or degrade in quality, and it is very likely to degrade. Let me say this again. A message, once it leaves a messenger, once it leaves a messenger, can only either stay the same in quality or degrade in quality, and it is likely to degrade. What does this mean? In the most basic sense for humans, we are messengers and receivers. We try to communicate messages, typically in the simplest fashion, a face-to-face conversation. And during a face-to-face conversation, the message can degrade at multiple, multiple points along the path. It can literally degrade because of the environment, right? This is a producer of some kind of noise. That noise can be something that is mentally distracting, so it's affecting the receiver of the message. It can be something that is interrupting the signal, directly interrupting the signal. It can be literally noise around, like, you know, audible noise. It could be an example of this. Another example might be something is distracting visually in the environment. So kind of crossing over from the audible environment to the visual environment here, and recognizing that there are so many, and this is why the second part of this principle exists, there are so many ways that a given message can degrade that it is likely that it will. And more specifically, uh, that if that's true as a broad rule, the, uh, only way that a message retains its quality is if the quality is explicitly protected. Think about it like this. The only way that you are 100% sure that somebody hears your message, we're not even talking about understanding the meaning, we can get into that. But the only way that you ensure that somebody hears your message is to make sure that you're in a quiet environment where there aren't visual, uh, or audible distractions. So that's talking about the kind of literal, uh, you know, logical message where somebody is saying some words, the receiver is not trying to decode that message in any particular way. They're just hearing the exact words that are being said, but there's a lot of philosophy and theory behind, uh, uh, communications more generally, like for example, uh, the idea of symbiotics where you say a word and that might mean something slightly different to me than it means to someone else because of, for example, cultural backgrounds, uh, personal experiences, their current state, uh, their current state of mind, uh, which is, is kind of like a personal ongoing personal experience. So there's a lot of reasons why a given message from one messenger to another, receiver, uh, not just in terms of its face value meaning, but also in terms of its decoded meaning can be thwarted. It can lose quality. And here, the quality that we're talking about is actually communicating from one person to another, some kind of signified meaning. And the result of this, the net result of all of this complication is that miscommunication is a part, a regular part of our experience as humans. Miscommunication is a regular part because of this principle. Miscommunication happens very frequently, probably every day of our lives. And you remember, we said that, um, that these principles can be instructive. Well, in one way, uh, if we know that miscommunication is going to happen, then we do those things to protect us from the consequences of miscommunication. And so, to protect the quality of that communication, we're not going to protect it completely because there's no way for us to totally understand, uh, both sides of the communication equation. There's no way for us to get on 100% the same wavelength. Uh, even yourself, if you were to talk to yourself, if you were to read something that you wrote a year ago, you would feel very differently about it than you did then. So because of this constant degrading of messages and messages, we're not going to be able to protect the quality of that communication. Meaning in our messages, we have to pay attention to one, protecting the meaning and two, over-communicating, sending the message many times, retrying, trying to get a reflection. That's where the feedback loop comes in. So this is why, uh, you know, it's, it's absolutely time well spent to communicate and over-communicate and re-communicate and have someone reflect that back to you and continue that loop and refine the message until you get to some kind of common understanding that is practically useful, even though it is still probably degraded to some degree. The next time you have a miscommunication, whether it's with someone in your personal life, someone at work, remember this principle. Remember that messages can never increase in quality. This is also why it's so important for you to be able to reflect on your in your working environment, to remember that the messages that you send can only get worse. Now, remember quality here is doing a lot of the heavy lifting in terms of language. Uh, we're not talking about, um, whether people understand you, it's a translation error, right? So, so quality in a previous example, we were talking about the literal, you know, ability to understand a signal. In this case, we're talking about, uh, the ability to understand a signal. The quality as it relates to the original intent or the original, uh, uh, kind of signified meaning of what you were saying. But if you are non-communicative in your working life, uh, this is a very difficult thing to get over because your non-communicativeness, which is an, in and of itself, a message is a very low signal kind of message. In other words, it's even more likely to get over. So, uh, if you're a non-communicative in your working life, you're going to be able to get over it. So, uh, I encourage you to take some time and think about your own. Think about whether these make sense to you. Do you want to adopt these and how, uh, maybe you want to adopt a version or you want to, uh, mutate these. I encourage this as a principle. Practice of developing your own principles over time and going back and revisiting them, you know, deleting this one when it's no longer useful. Thank you so much for listening to this episode. Thank you again to today's sponsor jam. If you're an engineer and you would rather spend your time writing code than responding to comments in your issue tracker, then send your team jam.dev that's jam.dev to get started. It's free. Thanks again for listening. And until next time, enjoy your tea. See you soon. See you soon.