Vox

Leitura de 18 min

Habits of Successful Software Engineers - Getting to Code Quickly and Model Thinking

Summary

In this episode of Developer Tea, host Jonathan Cutrell continues the series on habits of successful software engineers by focusing on two critical practices for effective problem-solving.

The first habit is to “get to the code as quickly as possible.” This doesn’t mean rushing into implementation without thought, but rather finding the optimal balance between upfront design and hands-on learning. Cutrell explains that while initial discussions provide high value, each subsequent deliberation yields diminishing returns. Meanwhile, the learning gained from actual implementation increases in value. The goal is to identify the crossover point where further discussion becomes less valuable than starting to build, thereby avoiding expensive rework while still benefiting from iterative learning.

The second habit is “thinking in models” during the design phase. This involves using mental models, programming paradigms, and proven structures to frame problems more efficiently. Cutrell provides examples like event-based programming (with senders, messages, and receivers) and the graph metaphor used earlier to explain the value curve of deliberation. By having a repertoire of models to apply to different situations—whether technical, interpersonal, or organizational—developers can avoid solving every problem from scratch and instead leverage existing patterns that have proven effective.

Cutrell emphasizes that these habits represent business skills as much as technical ones, focusing on resource efficiency and return on investment rather than mere productivity. He encourages developers to actively seek out and learn different models and paradigms, as this meta-level thinking can significantly transform their career effectiveness. The episode concludes with a reminder that these approaches apply beyond coding to soft skills and organizational challenges as well.

Recommendations

People

  • Charlie Munger — Referenced as one of the most famous proponents of mental models. His approach to using systems and models from various disciplines to solve problems is presented as an inspiration for the ‘thinking in models’ habit.

Resources

  • Tea Break Challenge — A free daily email service that sends soft skills challenges. Each day’s email contains an insight to ponder or a brief read designed to improve developers’ non-technical skills.

Tools

  • Sentry — A multi-tiered solution for finding bugs in production code. It provides full stack traces, commit information, and identifies the developer responsible for bugs, helping teams resolve issues quickly and find problems before users do.

Topic Timeline

  • 00:00:00 — Introduction to problem-solving habits — Jonathan Cutrell introduces the episode’s focus on two habits employed by successful software engineers when facing problems. He explains that responses are contextual to personality, experience, and environment, but these habits can be cultivated. The episode continues a series on developer habits, building on previous discussions.
  • 00:01:38 — First habit: Get to the code quickly — Cutrell explains the first habit: getting to implementation (code, prototype, spreadsheet, or tool) as quickly as possible. This means avoiding excessive discussion about things that won’t affect the outcome and instead reaching a point where the team experiences and processes the problem directly. He clarifies this doesn’t mean immediate coding, but finding the right balance to avoid expensive mistakes from premature implementation while still learning through iteration.
  • 00:02:45 — The cost of implementation and iteration — The host discusses why coding and implementation are expensive, and why doing them multiple times can be prohibitively costly, sometimes outweighing the value gained. He acknowledges that multiple iterations are sometimes necessary, but reducing their number through upfront thinking improves efficiency. This skill of finding the optimum point of upfront design is framed as a crucial business skill for developers.
  • 00:03:31 — The value curve of deliberation vs. implementation — Cutrell uses a graph metaphor to illustrate the relationship between upfront deliberation and its value. Initial discussions provide high value (steep slope), but each additional deliberation yields diminishing returns (shallower slope), potentially becoming negative. Meanwhile, the learning value from implementation increases over time. The key skill is identifying where these curves cross—the point where further discussion is less valuable than starting to build.
  • 00:08:42 — Recap of first habit and introduction to second — After a sponsor segment for Sentry, Cutrell recaps the first habit: getting to implementation quickly to learn through iteration. He then introduces the second habit, which operates in the phase before implementation: thinking in models. This habit aims to make the ‘as quickly as possible’ phase more effective by providing structured ways to approach problems.
  • 00:09:19 — Second habit: Thinking in models — The host defines ‘thinking in models’ as using frameworks to explain ideas and understand how things work together. He references the graph metaphor from earlier as one type of model and mentions mental models popularized by figures like Charlie Munger. The idea is to have a collection of proven systems or paradigms that can be applied to various problems, saving time and providing structure.
  • 00:10:58 — Example: Event-based programming model — Cutrell provides a concrete example of a model: event-based programming with senders, messages, and receivers. He explains how this model creates a structure for thinking about interactions without directly expressing code. By asking what a message, sender, and receiver look like within a problem, developers can use the model to prop up their thinking and solve problems more efficiently than starting from scratch.
  • 00:12:56 — Seeking out models and applying them broadly — The host encourages listeners to actively seek out different types of models, mental models, programming paradigms, and patterns. He emphasizes that these apply not just to programming but also to soft skills, people problems, and organizational challenges. Developing this skill of cycling through models when faced with a problem can fundamentally improve a developer’s career by providing meta-level structures similar to data structures for problem-solving.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-03-13T09:00:00Z
  • Duration: 00:14:20

References

Podcast Info

Transcript

[00:00:00] what is the first thing you do when you’re trying to solve a problem or discuss that

[00:00:11] potential solution with your teammates take a moment to think about your initial reaction

[00:00:17] how do you respond to those situations this will be highly contextual to you as a person

[00:00:25] your personality your experiences your environment all of these things will play

[00:00:31] into how you naturally respond but in today’s episode i want to talk about two habits that

[00:00:37] successful software engineers employ when they face these situations my name is jonathan cutrell

[00:00:43] and you’re listening to developer t my goal in the show is to help driven developers find clarity

[00:00:48] perspective and purpose in their careers and we’ve been talking about the habits

[00:00:55] of successful software engineers on the show for the past couple of episodes

[00:01:00] aside from the interview that we had with brian helmick and in today’s episode we’re going to

[00:01:06] continue this by talking about two habits that successful software engineers employ when they’re

[00:01:12] facing a problem and it’s not just a coding problem this is any kind of problem that you’re

[00:01:20] trying to solve as a team the first habit that i want to talk about we’re going to kind of

[00:01:24] approach it as a problem and we’re going to talk about how to solve a problem that you’re

[00:01:25] going to approach this from uh from the backwards perspective and we’ll provide you the motivation

[00:01:31] habit right this is the habit that you can kind of look at as the outcome or the goal and that is

[00:01:38] to get to the code as quickly as you can get to the code as quickly as you can now what does this

[00:01:46] mean well it means that number one you’re not spending a bunch of time talking about things

[00:01:52] that ultimately are not going to affect what you’re doing and you’re not going to be able to

[00:01:55] change what you’re doing and you’re not going to be able to change whatever it is that you change

[00:01:56] now you can sub in a different word for code but really what you’re talking about is getting to

[00:02:02] some kind of implementation or some kind of proof of your processing right uh whether that’s a

[00:02:09] prototype or it could be a spreadsheet it could be actual code maybe it’s some kind of tool that

[00:02:16] you’re trying to decide whether or not you’re going to use it and the hope here is to get to

[00:02:20] the place where you’re not just talking about the thing but you’re experiencing it and you’re

[00:02:25] processing the thing right both by yourself and as a team now notice that we’re not saying

[00:02:30] get to the code immediately that’s because if you go to code too quickly if you go to

[00:02:37] implementation too quickly what you’ll often find is that you make expensive mistakes that you could

[00:02:45] have avoided coding is expensive implementation is expensive and so doing it twice or three times

[00:02:54] or four times

[00:02:55] is often prohibitively expensive sometimes you end up outspending the value that you would have

[00:03:02] gained in the first place now this isn’t always true sometimes we need to go through multiple

[00:03:08] prototypes multiple iterations but even in those cases if you can cut down the number of iterations

[00:03:15] in half for example by doing some upfront thinking then you’re going to drastically

[00:03:21] improve both that

[00:03:25] iteration process and also the efficiency of what you’re doing in the first place

[00:03:31] but there is kind of an optimum point of upfront design of upfront discussion

[00:03:39] you can think about this as a curve on a graph where you have lots of gain immediately right and

[00:03:47] think about this as a curve that starts out with a high slope and then slowly changes to a much

[00:03:54] shallower slope and then slowly changes to a much shallower slope and then slowly changes to a much

[00:03:55] shallower slope and perhaps even goes downward you may start out with a lot of value in the original

[00:04:02] discussion the first discussion you you have is infinitely more valuable than the than not having

[00:04:08] into any discussion at all right but the second discussion is slightly less valuable than the

[00:04:13] first one the second opinion that you share and as you continue to share those opinions or continue

[00:04:21] to design and deliberate

[00:04:24] uh

[00:04:25] each iteration on that design and deliberation becomes less and less valuable all the while

[00:04:31] the learning that you would experience by actually implementing becomes more and more valuable and so

[00:04:38] you have to find where that graph kind of crosses and this isn’t an easy thing to do that’s the

[00:04:44] spoiler alert is that this is hard this is one of the most important skills that develop developers

[00:04:50] learn over the course of their career because this is actually a business skill

[00:04:55] this has less to do with whether you can write good code or come up with you know a clever solution

[00:05:02] and more to do with can you do it with the most efficient approach now again when we talk about

[00:05:10] efficiency on the show we’re not talking about squeezing every single you know perfect productivity

[00:05:15] out of every single minute of your time instead we’re talking about using resources in a way that

[00:05:23] provides the return that you’re looking for so i’m going to talk a little bit more about that in just a moment

[00:05:24] so i’m going to talk a little bit more about that in just a moment so i’m going to talk a little bit more about that in just a moment

[00:05:25] looking for it’s as simple as that and so doing enough upfront thinking enough research

[00:05:32] that’s important before you get to the code but once you get to the code you begin to learn more

[00:05:39] once you get to implementation you learn much more and imagining that you’re going to get it

[00:05:45] all right on the first implementation is arguably 100 likely to let you down so what is another habit

[00:05:54] that we can employ during that upfront design process that will help us get to where we want to

[00:06:02] go so we can get to implementation as quickly as possible that’s what we’re going to talk about

[00:06:08] right after we talk about today’s sponsor sentry if you have ever had a customer tell you that your

[00:06:16] code is broken you know the feeling of panic that you have and also a feeling of frustration

[00:06:22] often customers don’t really know why they’re going to get to the code they’re going to get to the code

[00:06:24] something is broken and they provide you with limited information if you don’t have eyes on

[00:06:31] their side of the fence then you’re kind of treating them as a qa team and they’re not going

[00:06:36] to be very good at that also you’re not paying them for that they’re probably going to leave

[00:06:41] and by the time you’ve had one customer report the problem who knows how many customers have

[00:06:48] actually experienced the problem you probably actually have no way of finding that out

[00:06:53] and unfortunately

[00:06:54] it’s probably impacted your business by that point as well. Now I know what you’re probably

[00:07:00] thinking. If I’ve experienced this kind of problem that impacts my business, then I probably didn’t

[00:07:06] write the test that I should have written. And that may be true in some cases, but we can’t

[00:07:12] cover every scenario with a test. Even the best developers with decades of experience still have

[00:07:19] bugs, sometimes really big bugs, that bring down the entire system. So it’s really hard to write

[00:07:26] perfect test coverage, perhaps even impossible. And in reality, humans are really bad at not only

[00:07:32] writing tests, but expecting what a user is going to do. We can’t really predict that very well.

[00:07:39] And so predicting their inputs is not a very good use of our time, because we’re probably not going

[00:07:45] to get all of them right. So we need a multitasking,

[00:07:49] multi-tiered strategy to figure out how to find bugs in our code. Not just tests. Certainly you

[00:07:57] should be writing tests, but also you need a system like Sentry. Sentry provides you with all

[00:08:04] of the information you need to find out what’s going on in your software in production. This is

[00:08:10] going to help you find bugs before your users do, and ultimately help save your business from being

[00:08:16] impacted from those bugs as well.

[00:08:19] You get the full stack trace, you get the commit, and even the developer who wrote the code that is

[00:08:24] responsible for that bug, so you can get it resolved as quickly as possible. Go and check out

[00:08:30] what Sentry has to offer. Head over to Sentry.io to get started today. That’s Sentry.io. Thanks

[00:08:36] again to Sentry for sponsoring today’s episode of Developer Tea. So the first habit of successful

[00:08:42] software engineers in today’s episode is to get to the implementation as quickly as possible.

[00:08:49] Get to the code as quickly as possible with the goal of learning through iteration. Now the second

[00:08:56] habit is going to be in that phase between now and the implementation. In that quickly as possible

[00:09:04] phase. How can you make that happen? We’ve already discussed some of these ideas that

[00:09:09] you know you can’t just jump straight into the code, but you shouldn’t deliberate for a long

[00:09:13] time either. So one of the most important things you can do, develop the habit,

[00:09:19] of thinking in models. Thinking in models. What does this mean? Well I’ll give an example. Earlier

[00:09:26] we talked about thinking about a graph with a very high slope at the beginning and then

[00:09:33] a shallow slope, perhaps a slope that goes down towards the end of the graph, towards the right

[00:09:39] side of the graph. As x increases, y decreases. With the idea that x is the number of deliberations

[00:09:49] you share, the amount of design up front that you do, and y would be the value that that provides.

[00:09:55] If you can think about those relationships, that is a type of model. You’re thinking in

[00:10:03] terms of how do these things work together? And how can I explain them in a way that is

[00:10:11] comprehensive? So that’s one kind of model. You can think about models as a way of explaining

[00:10:18] an idea.

[00:10:19] Another example of this is the mental models that we talked about on the show before. You’ve

[00:10:23] probably heard about these outside of this podcast. In other podcasts, Charlie Munger

[00:10:29] is amongst the most famous for talking about mental models. The idea here is that there

[00:10:35] are many different systems that exist in the world outside of development and in software

[00:10:43] development that you can take advantage of. That certain types of information kind of

[00:10:48] wrap around.

[00:10:49] For example, if you have event-based programming, the model that you would be thinking of is

[00:10:58] a sender, some kind of sending object, or sending a player in the game that sends a

[00:11:06] message. They may send it into an open space where a receiver can listen for that message

[00:11:13] and then do something about it. Senders may also be receivers.

[00:11:18] So that’s one example.

[00:11:19] This concept doesn’t necessarily express itself in code directly, but you can use this concept

[00:11:27] and wrap a bunch of different types of problems around it.

[00:11:32] Once you’ve learned these different models or paradigms, you can develop the skill of

[00:11:38] kind of cycling through them when you’re faced with a problem to see if your problem can

[00:11:43] fit one of those paradigms, one of those models.

[00:11:46] And the hope is that these models will help you.

[00:11:48] So that’s one example.

[00:11:49] We’ll kind of explain to you how different things will interact given that model implementation.

[00:11:57] So you can have the concept of a message sending to a receiver and the semantics around that

[00:12:05] help you solve the problem in a unique way.

[00:12:10] In other words, imagine what does a message look like?

[00:12:14] What does a sender look like?

[00:12:17] And what does a receiver look like?

[00:12:19] If you can use the model to help kind of prop up and provide to you a structure, kind

[00:12:28] of a predetermined structure for the way that you’re thinking, when you have multiple shapes,

[00:12:33] multiple models to choose from, a lot of the time those structures are going to help you

[00:12:38] solve your problem in a much more efficient way.

[00:12:41] Rather than trying to solve it from the ground up without any structure, without any models,

[00:12:46] you can rely on these proven models.

[00:12:49] These interactive kind of landscapes to help you solve problems more efficiently.

[00:12:56] I encourage you to seek out these different types of models, mental models, programming

[00:13:00] paradigms.

[00:13:01] These are all different shapes, ways, kind of programming patterns.

[00:13:06] And not just programming, but these things apply to soft skills problems, people problems,

[00:13:11] organizational problems.

[00:13:13] These are very similar to imagine like data structures, but at a meta level.

[00:13:19] And this is something that will totally change your career for the better.

[00:13:24] Thank you so much for listening to today’s episode.

[00:13:26] Thank you again to today’s sponsor Sentry.

[00:13:27] Head over to sentry.io to get started with your multi-tiered solution to dealing with

[00:13:33] problems and bugs in your code.

[00:13:36] Thank you so much for listening.

[00:13:37] If you haven’t yet subscribed to this podcast, I encourage you before this episode finishes,

[00:13:42] click the button.

[00:13:43] I’ll give you a second.

[00:13:45] Click the subscribe button in whatever podcasting app you’re currently listening to.

[00:13:47] And I’ll see you in the next episode.

[00:13:49] Welcome back.

[00:13:50] I’m Nate Smith and you are listening to Don’t Forget to weten………………….

[00:13:54] with.

[00:13:55] Lastly, a quick reminder, if you haven’t subscribed to Tea Break Challenge, these are daily soft

[00:13:59] skills challenges that get sent directly to your email.

[00:14:00] Head over to tea break challenge.com.

[00:14:03] This is totally free.

[00:14:05] Enter your email there and you’ll get a challenge each day.

[00:14:08] Usually it’s an insight to ponder.

[00:14:10] Uh, something that will take you just a few minutes to read.

[00:14:13] Thank you so much for listening, and until next time, enjoy your tea.

[00:14:19] Thank you.

Visão de gráfico