Vox

Leitura de 18 min

Make Programming Principles More Useful with These 3 New Angles

Summary

In this episode of Developer Tea, host Jonathan Cottrell challenges developers to move beyond blindly following programming rules and principles. He argues that while beginners must initially apply rules without full understanding, intermediate and advanced developers need to examine rules critically to use them effectively as tools for improvement rather than restrictive boundaries.

Cottrell introduces three novel angles for examining rules. The first is inversion—considering the opposite or a different character of a rule. Using the “Don’t Repeat Yourself” (DRY) principle as an example, he explores inversions like “Say one thing” or “Prefer brevity,” which offer more nuanced guidance. He extends this concept to behavior change, suggesting that replacing a bad habit with a good one (or vice versa) is more effective than simply trying to stop or start a behavior.

The second angle is time-shifting—considering a rule’s origin, its intended end goal, and whether it should be applied at different points in a project. Cottrell emphasizes the importance of context, noting that rules about “clean code” and maintainability may not apply to a script run only once. Understanding a rule’s genesis and purpose helps avoid over-optimization and ensures rules are applied appropriately to the situation.

The third, more abstract angle is examining a rule in an extra dimension—zooming out to inspect the rule itself as an adjustable model rather than a black box. This involves identifying the rule’s parameters, considering how it might apply in different spheres (like applying DRY to design elements), and transforming it into a construct theory—a useful tool rather than a provable truth. Cottrell concludes by encouraging listeners to use these angles to make principles actionable tools for better work.

Recommendations

Concepts

  • Dreyfus model — Referenced as research on how people move from beginner to intermediate levels, supporting the idea that beginners must first practice rules without fully understanding why.
  • Construct theory — Described as different from event theory; rules used as tools or mental models that can’t be proven true but are useful for improvement, as discussed in a previous Developer Tea episode.

People

  • Tim Ferriss — Mentioned in the context of his podcast episode discussing ‘questions that changed his life,’ specifically the question ‘What if I did the opposite?’ which relates to the inversion technique for examining rules.

Topic Timeline

  • 00:00:00 — Introduction to rules and heuristics in programming — Jonathan Cottrell introduces the episode’s theme: examining the rules and heuristics programmers encounter, such as code smells and anti-patterns. He notes the subjective nature of ‘good code’ and promises to explore new ways of thinking about and using rules. The goal is to help developers do better work by examining rules from novel angles.
  • 00:03:44 — First new angle: Inversion of rules — Cottrell explains the first angle: considering the inversion or opposite character of a rule. Using the ‘Don’t Repeat Yourself’ (DRY) principle, he demonstrates how inversions like ‘Say one thing’ or ‘Prefer brevity’ offer different, more open interpretations. He connects this to behavior change, arguing that replacing a habit (inversion) is more effective than simply trying to stop one, and references Tim Ferriss’s question, ‘What if I did the opposite?’
  • 00:09:24 — Second new angle: Time-shifting rules — The second angle involves time-shifting a rule—considering its origin, intended end goal, and the point in a project where it should be applied. Cottrell stresses the critical role of context, using the example that ‘clean code’ rules for sufficient maintainability don’t apply to a script run only once. He advises developers to understand a rule’s genesis and purpose to avoid misapplication and over-optimization.
  • 00:13:05 — Third new angle: Extra-dimensional rule inspection — The third, more abstract angle is to examine a rule in an ‘extra dimension’—zooming out to inspect the rule itself as an adjustable model rather than a black box to be applied. This involves identifying the rule’s parameters, considering how it might apply in different spheres (e.g., applying DRY to design), and transforming it into a construct theory—a useful, non-provable tool. The goal is to use rules as stepladders for improvement, not restrictive boundaries.
  • 00:16:17 — Conclusion and call to action — Cottrell concludes by encouraging listeners to use the three angles—inversion, time-shifting, and dimensional inspection—to re-examine the rules and principles they use regularly. He urges developers to see rules as tools for inspiration and improvement, not restriction. The episode ends with a prompt to subscribe to Developer Tea for future content.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-11-09T10:00:00Z
  • Duration: 00:17:30

References

Podcast Info

Transcript

[00:00:00] As programmers and as humans, we encounter a long list of rules.

[00:00:13] Sometimes these rules are more stringent than others on this list.

[00:00:20] Sometimes the rules are reflective of something that we can’t bypass.

[00:00:27] For example, we can’t, currently, go back in time.

[00:00:31] This is more of a law than it is a rule.

[00:00:36] As developers, we encounter these perhaps more often than we do in other careers because

[00:00:44] there’s a lot of subjectivity in what we do.

[00:00:48] We encounter things like code smells.

[00:00:50] These are heuristics that we use to uncover things like anti-patterns.

[00:00:55] These are all ideas around creating good code.

[00:01:00] We’ve talked about the subjective nature of even those terms on this show before.

[00:01:05] In today’s episode, though, I’m going to talk about new ways of thinking about rules,

[00:01:10] new ways of looking at rules and using them in novel ways as well.

[00:01:16] We’re going to use some logic to help us kind of examine rules in a different

[00:01:21] way in today’s episode.

[00:01:22] My name is Jonathan Cottrell and you’re listening to Developer Tea.

[00:01:24] My goal on this show is ultimately to help you connect to your career purpose so you

[00:01:29] can do better work and have a positive influence on the people around you.

[00:01:34] One of the ways that you can do better work, that’s what we’re talking about

[00:01:38] in today’s episode, but this is also a way that you can uncover more about the

[00:01:45] world around you.

[00:01:46] This is not just limited to rules that you encounter in software development, not

[00:01:51] just limited to anti-patterns or to code smells.

[00:01:55] These are ways of thinking, patterns of thinking, creative ways of slowing down

[00:02:01] your thought process and examining things from almost a literally new angle.

[00:02:08] So we’re going to talk about three things in today’s episode, three angles

[00:02:13] that you can see rules through.

[00:02:15] These are new angles.

[00:02:16] Instead of taking rules kind of blindly, right?

[00:02:20] This is kind of what the early beginner developer does, and rightly so.

[00:02:26] When we first learn a rule, we have to kind of practice that rule first, right?

[00:02:31] In order to contextualize and to grow, to understand the rule, first we have to

[00:02:39] kind of apply it without really knowing why.

[00:02:44] This is supported by research on how people move from beginner to intermediate

[00:02:50] levels, and we talked about that on a recent episode when we discussed the

[00:02:55] Dreyfus model, but it’s important to understand that rules exist to kind of

[00:03:03] be an easily transferable way of practicing, of operating, of doing.

[00:03:12] A rule contains sometimes a lot of information.

[00:03:17] Sometimes the rule is based on years of experiences, years of failures,

[00:03:24] years of experimentation.

[00:03:26] Sometimes those rules, those heuristics are based on very little experience,

[00:03:33] very little experimentation.

[00:03:36] So it’s important to kind of investigate and kind of flip these rules around.

[00:03:41] Look at them from new angles, and that’s exactly what we’re talking about today.

[00:03:44] So the first new angle that I want you to consider a rule through is it’s

[00:03:48] inversion, the opposite of the rule, the inversion of the rule.

[00:03:53] And I like to think of this as kind of like a color inversion.

[00:03:56] The inversion should not be a restating of the rule or the heuristic.

[00:04:02] It should have a new character, right, for it to be useful at least, right?

[00:04:07] So you want to not just restate and use logical operators to flip the rule around,

[00:04:14] but instead consider the character of that inversion,

[00:04:18] a different and opposite meaning.

[00:04:20] Now when I say opposite, I don’t mean opposing the original rule,

[00:04:25] but instead the character of that.

[00:04:27] So let’s give an example.

[00:04:29] Don’t repeat yourself.

[00:04:30] This is a rule that we come across as developers.

[00:04:33] This is more a heuristic than it is a rule.

[00:04:36] We’ve talked about times when repeating yourself might be the right thing to do.

[00:04:40] So how do we arrive at that conclusion?

[00:04:43] Well, let’s look at an inversion of the don’t repeat yourself rule.

[00:04:47] Do, right?

[00:04:48] So there’s the first inversion, the inverted word.

[00:04:52] Don’t repeat yourself.

[00:04:53] Do things once, right?

[00:04:57] Say one thing.

[00:05:00] Don’t repeat yourself.

[00:05:02] Say one thing.

[00:05:04] And so what we have to understand here is that not repeating yourself may be evaluated

[00:05:09] in a different way.

[00:05:12] We may see that rule differently than the inversion, the say one thing rule.

[00:05:18] You could also bend this a little bit because on the one end,

[00:05:22] don’t repeat yourself is kind of a binary scenario, right?

[00:05:26] You either do or you don’t repeat yourself.

[00:05:28] On the other end, the inversion could be a little bit of a soft inversion, right?

[00:05:34] When I say soft inversion, I mean you could say be simple.

[00:05:39] Make your code brief.

[00:05:42] Prefer brevity, right?

[00:05:45] The reason that this is important is because it still acts as an inversion of the same

[00:05:49] rule but it contains in it a little bit of a different approach, right?

[00:05:57] Not repeat yourself is a hardline rule whereas prefer brief code is a much more open rule.

[00:06:05] You can interpret it differently.

[00:06:07] And so repeating yourself, repeating code may still be saying different things.

[00:06:14] This is an extremely powerful concept.

[00:06:16] It’s extremely powerful especially when you are applying it to your own behaviors.

[00:06:22] We’ve talked about habit change in the past couple of episodes.

[00:06:25] We’ve talked about how behavior changes very hard.

[00:06:30] For a long time, years now, we’ve talked about bias and how we have overconfidence in ourselves.

[00:06:36] So if we’re looking at really any subject, it doesn’t even have to be a rule necessarily

[00:06:41] but certainly with things that are statements.

[00:06:45] These are not rules but they are claims or some kind of declaration, right?

[00:06:51] Something that we are asserting is true.

[00:06:54] If we look at the inversion of those assertions, often we can uncover more powerful ways of

[00:07:01] working with those assertions.

[00:07:03] This is particularly true if we are trying to develop a healthy habit of not doing

[00:07:09] something, right?

[00:07:10] If we’re trying to remove some behavior.

[00:07:13] This often fails for many reasons.

[00:07:16] One of the reasons that behavior change and trying to stop a bad habit fails is

[00:07:21] because we don’t look at the inversion.

[00:07:24] We don’t do something but the inversion is we do something else.

[00:07:30] If we can think about behavior change in terms of behavior replacement rather than simply

[00:07:37] ceasing or beginning, then we have a much more actionable plan, a much more cohesive

[00:07:43] plan.

[00:07:44] And the same is true on the flip side.

[00:07:45] If we want to start something, then perhaps we need to stop something else.

[00:07:52] A new habit of going to the gym absolutely requires not only the new habit, the new

[00:07:59] pattern of going to the gym, but it also requires setting an old habit aside or changing

[00:08:06] the old behavior, stopping doing something else.

[00:08:10] So doing these inversions can be really enlightening and perhaps even more than

[00:08:15] they seem, right?

[00:08:17] From the surface, you may kind of uncover something a lot quicker, a lot more thoroughly

[00:08:22] than you would have otherwise.

[00:08:24] And I encourage you to do this with all kinds of your thinking.

[00:08:30] Another version of this kind of inversion technique actually was mentioned on one of

[00:08:35] Tim Ferriss’s episodes, whether you listen to his podcast or not, this particular

[00:08:39] technique is pretty interesting.

[00:08:42] On the episode, he was talking about questions that changed his life.

[00:08:45] And one of the questions was, what if I did the opposite?

[00:08:51] And this seems nonsensical to developers.

[00:08:53] What if I did the opposite?

[00:08:54] Sometimes we might parse that into what if I did nothing at all?

[00:09:01] But instead we need to be thinking, what if I did the inverse?

[00:09:05] What if I did things in a completely different way?

[00:09:08] Or what if I thought about this?

[00:09:10] What if I thought about this rule in programming this heuristic, this code smell in the opposite

[00:09:16] way?

[00:09:17] What kind of character does that new code smell take on?

[00:09:21] Okay, so let’s talk about angle number two.

[00:09:24] Angle number two.

[00:09:26] We’ve talked about rules as kind of this single point in time, this or maybe even

[00:09:32] a timeless thing, something that we expect to kind of govern the way that we operate.

[00:09:38] Rules have an origin.

[00:09:40] Not only do they have an origin, but you encounter the rule at a certain point in

[00:09:45] your project.

[00:09:47] So what I want you to think about the new angle is time shifting that rule.

[00:09:52] Imagine if that rule applied earlier or applied in a different place than you are

[00:09:57] currently using it.

[00:09:59] Imagine also the origin of that rule.

[00:10:04] Where did it come from?

[00:10:05] Why was it even created?

[00:10:08] Was perhaps there another rule that preceded this one?

[00:10:12] What was the thinking behind this rule?

[00:10:16] And then beyond this, play it out.

[00:10:19] Go forward into the future.

[00:10:21] What is the end goal?

[00:10:23] What are the effects that we’re trying to get out of the rule?

[00:10:27] So here we’re time shifting the rule, and I’m using time shifting very loosely

[00:10:33] because all we’re trying to do is understand maybe the rule applies, but it applies at

[00:10:39] the end of the project.

[00:10:40] Or maybe the rule should be applied earlier in the project or earlier in the sprint

[00:10:45] or earlier in the task that you’re currently working on.

[00:10:50] And perhaps this rule doesn’t apply directly to the project, but the end goal might.

[00:10:57] Or maybe you don’t want the same end goal that this particular rule is shooting for.

[00:11:03] For example, we as developers tend to think of our rules about clean code as kind of

[00:11:10] a uniform set of rules that we should apply to all of our code, but this isn’t necessarily

[00:11:16] true.

[00:11:17] Typically, the business goals, at least, of clean code is sufficient maintainability.

[00:11:25] This idea of context is so important.

[00:11:28] Sufficient maintainability for a program that you’ll only use once is totally unmaintainable.

[00:11:36] And that’s not a popular opinion, and it’s not one that we really like to think about,

[00:11:41] but it’s true.

[00:11:42] If you’re only going to run this code once, then it’s okay for you to write an ugly

[00:11:47] shell script, for example.

[00:11:50] And we do this all the time with consoles.

[00:11:52] We run code once, and then the code essentially disappears.

[00:11:56] And so we can’t think about code that we’re shipping as one big thing, as one thing

[00:12:04] that we can apply all of the rules to unilaterally.

[00:12:09] That is devoid of context, and a great developer understands, perhaps more than

[00:12:13] anything else, the context that they’re working in.

[00:12:17] This helps you avoid things like overoptimization.

[00:12:21] So I encourage you to take the rules that you are considering applying and time shift

[00:12:26] them.

[00:12:28] Understand where they came from, what their end game is, what their end goal is, and

[00:12:32] then apply it at different points in the project.

[00:12:36] And by the way, these angles happen to be kind of multiplicative, right?

[00:12:40] Because you can have the same time shifting you can apply to the inversions of the rules

[00:12:47] that you’re exploring.

[00:12:49] And those inversions with the time shifting may have different goals, right?

[00:12:55] So you may change the goals of whatever it is that you are inverting.

[00:13:01] Okay, let’s move on to our last angle.

[00:13:05] This one’s a little bit more difficult to explain, but the best way that I can

[00:13:09] describe it is to understand things in terms of an extra dimension.

[00:13:16] Rather than understanding, let’s say, two dimensions, a front and a back of a piece

[00:13:22] of paper, for example, we’re going to think about things in a third dimension.

[00:13:27] Mentally, I imagine this being like a parallel understanding of a rule.

[00:13:34] You’re not really trying to understand if your code follows a rule or not, but rather

[00:13:39] you’re inspecting the rule itself.

[00:13:41] You can imagine this being like rule of self-awareness.

[00:13:45] We’re looking at the rule from the side.

[00:13:48] So as I said, this is a little bit difficult to explain how I have kind of this mental

[00:13:53] vision of this, but imagine that you’re essentially you’re zooming out, right?

[00:13:57] And instead of trying to apply the rule, you’re inspecting the rule itself.

[00:14:02] This may allow you to do things like substitute concepts.

[00:14:06] So you can substitute the idea of code for design and then apply that same principle,

[00:14:14] the dry principle, for example.

[00:14:17] You can apply that to your design elements.

[00:14:20] When you zoom out, you’re kind of looking at the rule itself.

[00:14:23] You have this awareness of the working pieces of the rule.

[00:14:28] And then you can also, as we said in the second new angle, the time shifting angle,

[00:14:34] you can also start to think more about context that this rule applies in.

[00:14:39] You can investigate how the rule kind of changes depending on the types of input that

[00:14:44] you give it.

[00:14:45] And really the whole idea here is instead of applying the rule as if it is in itself

[00:14:52] like a black box, right?

[00:14:54] You apply it as an adjustable model.

[00:14:59] You find the parameters of that rule and maybe you change those parameters.

[00:15:05] You imagine ways that this rule can be applied in other scenarios.

[00:15:10] Maybe this gives you the opportunity to use the rule in a different sphere, right?

[00:15:16] This is the idea of a mental model.

[00:15:18] If you can use the same kind of guiding principle in multiple places, well that

[00:15:24] means that you understand that principle more thoroughly.

[00:15:28] You’ve given some time to understand the parameters and how those parameters move through

[00:15:34] the rule.

[00:15:35] Very often what this results in, and I encourage you to go back and listen to the last episode

[00:15:41] of Developer T on this subject, but what this often results in is a construct theory.

[00:15:48] A construct theory, just a quick reminder, is different from an event theory because

[00:15:52] you can’t really prove that it’s true or that it’s going to work.

[00:15:56] And instead you’re using rules as tools at this point.

[00:16:02] Rather than using rules as kind of boundaries for yourself, you’re using them as a stepladder,

[00:16:10] as a way to improve.

[00:16:13] And perhaps that’s the most important takeaway from today’s episode.

[00:16:17] I want you to take this episode as inspiration to use rules, use these patterns, these

[00:16:25] not as a way to restrict yourself, but instead as a way to improve the work that you do.

[00:16:33] Thank you so much for listening to today’s episode of Developer T. I hope it was inspiring

[00:16:39] and I encourage you to take some time to look over the rules that you use on a

[00:16:46] regular basis and any time you hear a principle mentioned, maybe mentally think

[00:16:51] for a moment. What would the useful inversion of that principle be?

[00:16:56] How can I apply this principle in a different place? What are the parameters of this principle?

[00:17:02] What if I applied it earlier or maybe I delayed and applied it later?

[00:17:07] Thanks so much for listening. If you enjoyed today’s episode, I encourage you

[00:17:10] to go and subscribe in whatever podcasting app you use. The one you’re using right now

[00:17:15] to listen to this episode is probably a good one. Go and subscribe so you don’t

[00:17:19] miss out on future episodes. Thanks so much for listening and until next time, enjoy your tea.

Visão de gráfico