Vox

Leitura de 15 min

Habits of Successful Software Engineers - Clarity, Brevity and Context

Summary

In this episode of Developer Tea, host Jonathan Cuttrell continues the series on habits of successful software engineers. He focuses on two interconnected habits that are foundational for a long and successful career in development.

The first habit is the constant pursuit of clarity and brevity in written communication. Cuttrell emphasizes that coding is only part of a developer’s job, and much of their work exists in a written form—documentation, messages to colleagues, commit messages, etc. This written work must be clear for both immediate understanding and for future reference, even when the original author is no longer available. He illustrates the balance between clarity and brevity with a contrived example about requesting a cup, showing that the appropriate level of detail depends entirely on the context and the audience’s existing knowledge.

The second habit is the incessant questioning of context. Successful engineers constantly ask why their current task matters and examine the broader context of their work—be it a feature, a testing solution, or a new technology. Understanding this context is critical for making sound decisions and avoiding the pitfalls of relying solely on static rules or ‘best practices,’ which can fail when applied without considering the specific situation. Cuttrell positions this as a foundational habit that enables better communication and decision-making.

Both habits are presented as essential for ‘serially successful’ developers—those who build enduring careers. They are deeply related: understanding the context of a message is necessary to write with clarity and brevity, and clear communication is vital for aligning work with its proper context within a team or project.

Recommendations

Tools

  • Linode — A cloud hosting service offering SSD Linux servers. The host recommends it for learning developers to get hands-on experience, mentioning a $20 credit promo code.

Topic Timeline

  • 00:00:00 — Introduction to the developer’s role and the series — Jonathan Cuttrell introduces the episode as part of the ‘Habits of a Successful Software Engineer’ series. He challenges simplistic definitions of a developer’s job, noting that coding is often just the output. The bulk of a developer’s work involves other activities, which leads into the topic of today’s habits related to communication and context.
  • 00:01:17 — Connecting today’s habits to previous feedback discussion — Cuttrell connects today’s topics to the previous episode’s discussion on seeking feedback. He notes that much of a developer’s work centers on communication, and today’s habits are closely related to managing noise in communication signals. He encourages listeners to review past episodes on communication theory for foundational knowledge.
  • 00:02:29 — Introducing the first habit: writing with clarity and brevity — The first habit is introduced: successful software engineers seek to write with clarity and brevity. Cuttrell explains that this means meticulously crafting messages, packing words with meaning, and choosing them carefully for the audience. He stresses that all communication with coworkers, stakeholders, and customers is important to some degree.
  • 00:03:23 — The importance of writing as a fundamental developer skill — Cuttrell elaborates on why writing is a fundamental skill. Unlike high-bandwidth in-person communication, written work lacks non-verbal cues and tone. Since much work exists in a written form for the long term (for future reference or when the author is unavailable), developers must cultivate the habit of writing clearly and briefly.
  • 00:05:29 — Examples illustrating the balance of clarity and brevity — Using a contrived example about asking for a cup, Cuttrell provides several requests with varying detail. He demonstrates that the most clear and brief message depends on context (e.g., are there other cups?). The exercise highlights the need for developers to think carefully about adding necessary details without unnecessary qualifiers when communicating about ambiguous subjects like code.
  • 00:08:30 — Sponsor message from Linode — A sponsored segment for Linode cloud hosting. Cuttrell describes Linode’s services, including SSD servers and dedicated CPU instances. He offers a promo code (‘developert2019’) for $20 in credit, emphasizing the value for learning developers to have their own Linux server for hands-on experience.
  • 00:10:11 — Introducing the second habit: incessantly questioning context — The second habit is introduced: successful software engineers constantly ask about the context of their work. This involves questioning why a task matters and examining it from an objective perspective to decide what should change. Cuttrell connects this to the first habit, as understanding context is critical for writing clear messages.
  • 00:11:23 — Context as a foundational habit for decision-making — Cuttrell deepens the discussion on context, describing it as an inescapable metric for decision-making regarding features, testing, or technology choices. He defines ‘successful’ developers as those with serial, long-term success, and states that constantly seeking context is a foundational, not additive, habit. Relying solely on static best practices will eventually fail without contextual understanding.
  • 00:12:49 — Conclusion and call to action — Cuttrell concludes the episode, hoping it was challenging and empowering. He reiterates the sponsor thanks and promo details for Linode. He encourages listeners to subscribe to the podcast to not miss future episodes and signs off with the show’s tagline.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-03-09T10:00:00Z
  • Duration: 00:13:41

References

Podcast Info

Transcript

[00:00:00] what do you do as a developer this may sound like kind of a dense question something that

[00:00:13] may have some obvious answers and some not so obvious answers you may hear some quippy versions

[00:00:20] of this on social media like my job as a developer is to make people happy or my job as a developer

[00:00:29] is to guess until i’m right but none of these fully capture the wide gamut of things that we do

[00:00:39] as developers and as it turns out coding is typically only part of our jobs and in fact

[00:00:47] much of the time coding is the output of the rest the bulk of what we do that’s what we’re

[00:00:56] talking about in today’s episode this is a continuation

[00:00:59] of

[00:00:59] of our habits of a successful software engineer series and today we’re going to share two

[00:01:05] different habits my name is jonathan cuttrell and you’re listening to developer t this show

[00:01:10] exists to help driven developers find clarity perspective and purpose in their careers

[00:01:17] in our last episode discussing habits of successful software engineers we talked about

[00:01:22] the fact that successful software engineers seek feedback as a habit not just any feedback

[00:01:29] not just specific feedback but also they’re looking for feedback that is unstructured they’re ready

[00:01:38] to receive those messages wherever they’re coming from but they also understand that not all feedback

[00:01:45] is perfectly clean but sometimes we get noisy signals from our environment today’s episode is

[00:01:54] and today’s habits are very closely related to this idea of

[00:01:59] noise and communication and so much of what we do as developers centers around

[00:02:05] communication on its own so i encourage you to go back and listen to the episodes we did recently

[00:02:12] on communication the the communication models the theory of communication we talk about all of those

[00:02:19] you know kind of fundamental elements of communication but in today’s episode i want

[00:02:24] to share these these basic habits with you so the first habit that i want to share today is

[00:02:29] seeking and communication and communication and communication and communication and communication and

[00:02:29] to write with clarity and brevity seeking to write with clarity and brevity in some ways the

[00:02:39] boundaries of clarity and brevity give us a sense that we need to pack our words with meaning we

[00:02:50] need to choose them carefully to meticulously craft messages that we’re sending to other people

[00:02:57] now in some cases we need to choose to write with clarity and brevity and in some cases we need to

[00:02:59] write with clarity and brevity and in some cases this is more important than others

[00:03:01] but successful software engineers know that all communication is important to some degree

[00:03:09] especially communication with our co-workers and with our stakeholders and customers so let’s talk

[00:03:17] about these boundaries a little bit more thoroughly clarity writing something with

[00:03:23] clarity now notice that we’re talking about writing because writing is a fundamental skill

[00:03:28] for developers to be able to write with clarity and brevity and brevity and brevity and brevity and brevity

[00:03:29] this is true in almost every knowledge working area many of us can communicate with other people

[00:03:37] in informal settings to a degree where we understand each other most of the time in-person

[00:03:44] communication naturally has a higher bandwidth we’re able to see and communicate more with our

[00:03:52] non-verbal signals and our tone and inflection even our gestures with our hands and these are

[00:03:59] things that you can’t really get from just writing now if you know someone very well then

[00:04:07] often you can kind of visualize them talking and you get a sense an intuitive sense for

[00:04:13] their tone once you’ve read enough of their writing but much of the time our co-workers

[00:04:20] haven’t spent enough time with us to get that intuition so we need to learn how to write

[00:04:26] clearly because much of our work

[00:04:29] it exists in a written form and a lot of the work that we do is not just for today but it’s also for

[00:04:37] three months from now or maybe it’s for whenever we are no longer working on that project maybe

[00:04:43] we’re at a different company or you know we’ve moved to a different place in some way or another

[00:04:49] we may be out for the day so the written kind of recorded work that we do it’s incredibly important

[00:04:57] for successful software engineers to be able to write in a written form and to be able to write

[00:04:59] to develop this habit of constantly seeking clarity and brevity so clarity in our writing

[00:05:06] what does this mean it means that we are communicating to a specific audience with a

[00:05:13] clear message that both identifies what we mean as well as what we don’t mean often this really

[00:05:23] entails adding important details to your message as an exercise i’m going to

[00:05:29] provide a handful of examples of someone asking to another person to bring them the cup that they

[00:05:36] want and you’ll see that there are varying degrees of clarity and brevity in these requests as a side

[00:05:45] note this probably wins the award for the most bizarre 30 seconds in a podcast that you’re going

[00:05:51] to listen to today and certainly the most 30 second the most bizarre 30 seconds in the history

[00:05:56] of developer t but nevertheless let’s go ahead and get started

[00:05:59] please bring me the cup please bring me the cup from the kitchen please bring me the blue cup from

[00:06:09] the kitchen please bring me the blue cup from the left counter in the kitchen please bring me the cup

[00:06:19] from the left counter in the kitchen now these are obviously contrived examples but how do you

[00:06:26] know which of these is the most clear well

[00:06:29] also being the most brief. Of course, brevity on its own isn’t enough, and clarity on its own

[00:06:39] may result in too much detail, an impractical amount of detail. And in these examples, as it

[00:06:48] turns out, there’s no way for you to know what the appropriate level of clarity versus brevity

[00:06:54] is. Because you don’t know, for example, is there another cup in the kitchen? By adding all of the

[00:07:02] qualifying terms based on what this person wants, which is for the person to bring them the cup,

[00:07:08] if you add a bunch of unnecessary qualifiers, you may be being very clear. You may be providing a

[00:07:16] lot of clarity, but you’re not necessarily providing brevity. It’s not necessary for you

[00:07:22] to explain where the color is.

[00:07:24] cup is or what color it is if it’s the only cup. Again, these are contrived examples, but imagine

[00:07:30] how much of this kind of thinking you can do as a developer working with code, working with

[00:07:39] ambiguous subjects. This is something that is very important because clarity is incredibly

[00:07:46] important. Without clarity, you may waste a bunch of time building things that you ultimately

[00:07:53] shouldn’t build or working under miscommunications, right? Working in a state where

[00:08:00] things are not really certain. So it’s important to focus on clarity. And then as you begin to

[00:08:10] build messages with clarity, you can also learn how to make those clear messages brief.

[00:08:18] So the first habit of successful software engineers for today’s episode is that they

[00:08:23] always…

[00:08:23] Always seek clarity and brevity in their writing. We’re going to talk about the second habit right

[00:08:30] after we discuss today’s sponsor, Linode. With Linode, you can instantly deploy and manage an

[00:08:36] SSD server in the Linode cloud. You can get a server running in just a few seconds with your

[00:08:41] choice of Linux distribution resources and the location of the node. Linode is also offering

[00:08:48] dedicated CPU instances. These are designed for consistent, high-performance computing

[00:08:53] needs like video encoding, game servers, or even busy application servers. As a new customer of

[00:09:00] Linode, you will get $20 worth of credit to use on any of their services. You can build pretty much

[00:09:06] anything on Linode. You can have distributed applications, hosted services, websites,

[00:09:12] even your own continuous integration and delivery environments. I highly recommend that learning

[00:09:18] developers get an account on Linode or some Linux server. If you’re a Linux developer, you should

[00:09:23] get an account on Linode. If you’re a Linux developer, you should get an account on Linode.

[00:09:25] This was some of the most important learning that I did was on my own Linux server. I encourage you

[00:09:33] as a developer, if you don’t have access to one and you’re in the learning environment, to go ahead

[00:09:38] and get one of these. Linode, again, is providing you with $20 worth of credit. The intro price for

[00:09:43] a Linode server is only $5 a month. You get four months, basically, for free. Go and check it out.

[00:09:50] Head over to linode.com slash developer T.

[00:09:53] That’s linode.com slash developer T, all one word, and use the code developer T 2019 at checkout.

[00:10:00] Again, that’s developer T 2019. That’s the code you’ll use at checkout to get that $20

[00:10:06] worth of credit. Thank you again to Linode for sponsoring today’s episode of developer T.

[00:10:11] The second habit that I want to discuss of successful software engineers is the incessant

[00:10:18] question of context.

[00:10:23] This isn’t a simple question. Really, what you’re asking is the work that I’m doing right now or the

[00:10:34] rest that I have right now. Why does it matter? Why am I doing what I’m doing right this second?

[00:10:42] Beyond that, being able to look at that context from an objective perspective and determine what

[00:10:49] should change or not change about whatever’s happening.

[00:10:53] This is very similar to the ability to write clearly. Understanding the context of the message

[00:11:01] is critical to being able to write clearly with clarity and brevity. Understanding the context

[00:11:09] of a given feature or of a proposed testing solution or of a new technology. These are all

[00:11:18] things where context is really critical. It’s kind of,

[00:11:23] inescapable as a decision-making metric. Successful developers, and when I say successful

[00:11:31] during this series, I don’t mean that they succeeded once or that they have a job.

[00:11:36] I mean serially successful developers. Developers who have either a long career behind them or a

[00:11:44] long career in front of them. These serially successful software engineers, sorry for the

[00:11:51] excessive alliteration,

[00:11:53] they have these things in common. And context, constantly seeking context, is one of those

[00:12:02] habits. And this habit is kind of a foundational habit. It’s not something that you add on later.

[00:12:09] It’s something that you create from the very beginning, constantly asking what is the context.

[00:12:16] Understanding context is how you generate the right kinds of decisions. If you were

[00:12:23] to rely on a static way of making decisions, eventually you find the edges of that. And

[00:12:30] very often this happens faster than we expect. If you only rely on best practices, that’s

[00:12:36] going to fail you at some point. Context is critical for pretty much every human process

[00:12:43] that we have. Working, communicating with each other, resting. We have to understand

[00:12:49] our context. Thank you so much for listening to today’s session. I hope you enjoyed it.

[00:12:50] I’ll see you next time. Bye-bye.

[00:12:53] Today’s episode of Developer Tea, I hope that this was a challenging episode. And I hope that

[00:12:58] you walk away feeling empowered to start developing these habits for yourself. Thank you again to

[00:13:06] Linode for sponsoring today’s episode. Head over to linode.com slash developer tea to get started

[00:13:11] today with $20 worth of free credit. Use that code developer tea 2019. It’s developer tea 2019.

[00:13:20] If you’re enjoying this episode and you want to, you don’t want to miss it,

[00:13:23] on future episodes, then I encourage you to subscribe in whatever podcasting app

[00:13:28] you currently use. Thanks so much for listening. And until next time, enjoy your tea.

Visão de gráfico