Vox

Leitura de 13 min

Habits of Successful Software Engineers - Multiplying Value by Thinking in Systems

Summary

In this episode of Developer Tea, host Jonathan Cuttrell explores a key habit of successful software engineers: thinking in systems to multiply value rather than simply adding value through problem-solving. He contrasts the approach of successful engineers who create compounding value with less successful ones who only add value when solving immediate problems.

Cuttrell explains that developers constantly face problems where something is either “done wrong” or “isn’t done yet” in their specific context. While all developers solve problems, successful ones approach problem-solving with a multiplier mindset. They look beyond the immediate tactical solution to consider broader impacts and parallel value creation opportunities.

A concrete example provided is reducing “time to value” for end users. Rather than just fixing a specific interface issue, successful engineers consider the entire user journey and look for ways to decrease time to value before users even begin using a feature, or increase the total value provided. They also identify overlapping value opportunities, such as improving accessibility while addressing performance issues.

The episode emphasizes thinking in terms of “system effects” - understanding what systems a particular piece of work belongs to and how it affects those systems. Cuttrell suggests asking questions like “What else is affected by this work?” and “What may have caused this to begin with?” to identify opportunities to improve entire systems while solving individual problems, thereby multiplying value across the organization.

Topic Timeline

  • 00:00:00 — Introduction to habits of successful software engineers — Jonathan Cuttrell introduces the episode as part of a series on habits of successful software engineers. He mentions previous episodes covered skills like seeking feedback, clarity, brevity, context, and model thinking. Today’s episode focuses on a nuanced skill that even successful engineers can learn from.
  • 00:01:04 — The core problem-solving nature of software development — Cuttrell establishes that developers solve problems every day - either things that are “done wrong” or “aren’t done yet” in their specific context. He clarifies that “done wrong” doesn’t necessarily mean broken, and “isn’t done yet” means the problem hasn’t been addressed for their particular context.
  • 00:01:56 — Difference between adding value and multiplying value — The host introduces the key distinction: successful software engineers create value when they solve problems, while less successful ones only add value when solving problems. He promises to explore how successful engineers multiply value rather than simply adding it, emphasizing this nuanced difference.
  • 00:03:01 — Example: Reducing time to value with systems thinking — Using “reducing end user’s time to value” as an example, Cuttrell explains how successful engineers think broadly rather than tactically. They consider the entire problem space, asking what users are doing before using a feature and looking for ways to decrease time to value before feature usage begins.
  • 00:04:17 — Finding parallel value opportunities — Cuttrell discusses how successful engineers identify parallel value creation opportunities. He gives the example of a front-end engineer who might improve interface speed while simultaneously enhancing accessibility. Finding these overlaps and parallel ways to create value distinguishes successful software engineers.
  • 00:06:30 — Contrast with 10x engineer concept — The host clarifies that multiplying value differs from the oversimplified “10x engineer” concept often discussed online. While 10x engineers supposedly deliver 10x more code, successful engineers think about value as compounding and lifting the entire organization, not just being individually productive.
  • 00:07:13 — Practical example: Documentation as value multiplier — Cuttrell provides documentation as a tactical example of multiplying value. When solving new or organization-specific problems, creating documentation multiplies the value of that work by helping other engineers who face similar issues. This approach benefits the entire system rather than just solving the immediate problem.
  • 00:07:35 — Thinking in system effects — The host explains the mindset of thinking in terms of “system effects” - considering what systems particular work belongs to and how it affects those systems. He uses the example of a visual bug, suggesting engineers should consider systems like other team members, design-to-engineering workflows, and QA processes.
  • 00:09:10 — Key questions for systems thinking — Cuttrell suggests two crucial questions for multiplying value: “What else is affected by this work?” and “What may have caused this to begin with?” These questions lead to higher-level understanding of systems at play, enabling work that benefits entire systems while solving individual problems.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-10-21T09:00:00Z
  • Duration: 00:10:33

References

Podcast Info

Transcript

[00:00:00] earlier this year in march we did a series called habits of successful software engineers

[00:00:10] i encourage you to go back and listen to those episodes we talked about seeking feedback

[00:00:17] clarity brevity context getting to code quickly model thinking it was a good but quick dive into

[00:00:27] some of the skills that make a great software engineer a successful software engineer in today’s

[00:00:33] episode we’re going to talk about another one of those skills it’s a little bit of a nuanced skill

[00:00:38] so if you already are a successful software engineer this might be something that you can

[00:00:44] still pick up and learn from my name is jonathan cuttrell and you’re listening to developer t

[00:00:48] my goal on the show is to help driven developers like you find clarity perspective and purpose in

[00:00:54] their careers

[00:00:55] most of what we’re going to talk about today is going to be a little bit more of a

[00:00:57] what we do as developers is solve problems this might sound a little bit kitschy or like a sound

[00:01:04] bite but the truth is every day as developers we face something that is either done wrong

[00:01:12] or isn’t done yet of course we should mention as always that context is important when we say

[00:01:19] that something is done wrong that doesn’t necessarily mean that it’s broken

[00:01:23] and when we say that something isn’t done yet we don’t mean

[00:01:26] that nobody is addressing the same problem but instead we mean that for our context this problem

[00:01:34] has not been addressed yet but if this is such a major part of what we do as developers

[00:01:40] then it seems like we’re underserving the skill of problem solving that we might benefit from

[00:01:48] exploring how we solve problems a little bit more deeply successful software engineers

[00:01:56] value when they solve problems

[00:01:59] while less successful software engineers only add value when they solve problems

[00:02:05] we’re going to talk about this nuanced difference because it often feels quite similar

[00:02:11] but we’re going to get very specific in today’s episode and how a successful software engineer

[00:02:17] goes about multiplying value rather than simply adding value

[00:02:21] but first let’s talk about what it means to have multiplied value

[00:02:26] first we have to think of kind of the unit of value that we’re talking about in the first place

[00:02:31] we’re not going to try to define value in today’s episode that would take maybe a whole podcast to figure that out

[00:02:38] but instead let’s imagine that we know a particular type of value that we want to increase

[00:02:43] now it’s probably unlikely that successful software engineers have the power to multiply

[00:02:50] every single value in every problem that they ever solve but instead they should be thinking

[00:02:56] in ways that are multipliers rather than simply adding

[00:03:01] so let’s imagine that the value that we add by solving this particular problem

[00:03:06] reducing the end user’s time to value

[00:03:09] right this is the amount of time that it takes for someone to go from kind of the starting point

[00:03:15] whatever the start of that process or feature is to actually getting value from that process or feature

[00:03:21] a successful software engineer is going to look at the time to value problem

[00:03:26] more broadly rather than simply tactically

[00:03:31] in other words are there ways that we can improve the time to value for this feature

[00:03:36] not just by solving this particular interface area

[00:03:41] but instead by considering the broader problem space

[00:03:45] what exactly is this user doing when they start using this feature

[00:03:50] can we decrease the time to value before they begin using this particular feature

[00:03:56] or can we increase the total value provided by this feature

[00:04:01] so a successful software engineer not only expands on the value that’s created in a particular feature

[00:04:09] but they can also look at parallel values that they can increase in the process of building this feature

[00:04:17] for example a great front-end engineer might look at ways to make the interface a little bit faster

[00:04:24] for this particular feature

[00:04:25] for this particular area this feature

[00:04:28] but they may simultaneously make adjustments that improve accessibility

[00:04:33] accessibility and time to value are probably overlapped in most applications

[00:04:39] finding these overlaps and parallel options parallel ways of creating value

[00:04:45] that’s what a successful software engineer does

[00:04:48] we’re going to take a quick sponsor break

[00:04:50] and then we’re going to come back and talk about another way you might increase value

[00:04:54] in a given scenario

[00:04:55] and then more broadly kind of the mindset that’s required to think multiplicatively

[00:05:02] today’s episode is sponsored by Flatiron School

[00:05:07] at Flatiron School you learn how the future is being built

[00:05:10] so you can change anything

[00:05:11] starting with a new career in user experience or in UI design

[00:05:16] no matter where you are in your career

[00:05:18] Flatiron School can help you level up in your creative skills

[00:05:24] in just 24 weeks you’ll be able to learn more about Flatiron School

[00:05:25] and you’ll be able to learn more about Flatiron School

[00:05:25] in just 24 weeks you’ll be able to learn more about Flatiron School

[00:05:25] and you’ll be able to learn more about Flatiron School

[00:05:25] either at one of the global WeWork campuses

[00:05:29] or from anywhere online

[00:05:31] you can change your career with confidence

[00:05:35] Flatiron School’s instructors have both industry and teaching experience

[00:05:39] and are backed by Flatiron School’s master teachers

[00:05:42] and learning experience designers

[00:05:44] to ensure you get the best possible support

[00:05:47] you’ll also have one-on-one support from your dedicated career coach

[00:05:51] and a money-back guarantee

[00:05:53] you can find out more details about Flatiron School

[00:05:55] at flatironschool.com slash terms

[00:05:58] you can join the global community of changemakers

[00:06:01] at flatironschool.com slash developer T

[00:06:05] that’s flatironschool.com slash developer T

[00:06:09] thanks again to Flatiron School for sponsoring today’s episode of developer T

[00:06:13] so you want to become a successful engineer

[00:06:18] that’s why you’re listening to this episode

[00:06:19] and more specifically

[00:06:21] you want to learn how to multiply value

[00:06:24] rather than simply add value to your business

[00:06:25] rather than simply adding value

[00:06:26] now I want to be clear that this is not the same discussion

[00:06:30] that you’ve probably seen online about 10x engineers

[00:06:33] we’ve talked about that on other episodes of this show

[00:06:37] the idea of a 10x engineer is totally oversimplified

[00:06:41] in terms of how that value is delivered

[00:06:44] typically a 10x engineer delivers 10x the amount of code

[00:06:49] and we’re talking about more than that in this episode

[00:06:52] successful software engineers

[00:06:54] think about the value of 10x engineers

[00:06:55] think about the value that they add to an organization

[00:06:57] as compounding

[00:06:59] not simply being 5x or 10x better than the next engineer that comes along

[00:07:06] but instead lifting the whole organization up with you

[00:07:11] a simple kind of tactical example of this

[00:07:13] is no matter what problem you’re solving

[00:07:16] especially if it is somewhat of a new problem

[00:07:19] somewhat unique to the organization that you work with

[00:07:22] documentation

[00:07:24] can be used to solve problems like this

[00:07:24] documentation can be a simple way to multiply the value

[00:07:28] that you’re adding through that process

[00:07:30] so here is the mindset to have

[00:07:34] as a successful engineer

[00:07:35] you want to be thinking in terms of system effects

[00:07:41] and when I say system effects

[00:07:43] I mean thinking about the work that you’re getting ready to perform

[00:07:46] in terms of the systems that that work belongs to

[00:07:50] so an interface issue

[00:07:52] let’s say there’s a visual bug

[00:07:54] in an application that you’re working on

[00:07:56] what systems is this work a part of

[00:08:00] one of the most obvious systems is

[00:08:03] the system of other engineers on the team

[00:08:06] as we just mentioned

[00:08:07] providing documentation for particular fixes that you make

[00:08:11] is crucial to multiplying value

[00:08:14] what other systems might a front-end visual bug belong to

[00:08:20] well you might think about the combination of teams

[00:08:24] so from designers to engineers or engineers

[00:08:28] to a QA team

[00:08:30] if that’s something that your team has as participants

[00:08:33] these overlaps

[00:08:36] they might benefit from some kind of work as well

[00:08:39] you also have systems that are actually entirely encapsulated

[00:08:43] by whatever products you’re working on

[00:08:44] in this case the front-end system

[00:08:47] at a very practical level

[00:08:49] if you are writing new CSS

[00:08:52] for example as a front-end developer

[00:08:53] for every system that you’re working on

[00:08:54] every single bug that you find

[00:08:56] then you’re probably having a negative effect

[00:09:00] on the front-end system

[00:09:01] even though you’re adding value

[00:09:04] by fixing the bug for that particular problem

[00:09:07] so the question that you can ask yourself

[00:09:10] during this kind of work

[00:09:11] is what else is affected by this work

[00:09:15] and what may have caused this to begin with

[00:09:19] these questions often lead you

[00:09:21] to higher level understandings

[00:09:24] of the systems that are at play

[00:09:26] once you can do work that benefits the systems

[00:09:30] now you are multiplying value

[00:09:33] you can fix the individual problem

[00:09:36] and improve systems

[00:09:38] sometimes with the same amount of energy

[00:09:40] or with a very high leverage amount of extra energy

[00:09:45] in other words a small amount of energy

[00:09:47] that goes a much longer way

[00:09:49] I encourage you

[00:09:50] as you are solving problems in your work today

[00:09:53] as you solve problems in your work today

[00:09:54] as you solve problems in your work tomorrow

[00:09:55] start thinking about the systems

[00:09:58] that are surrounding those problems

[00:10:00] thank you so much for listening to

[00:10:02] today’s episode of Developer Tea

[00:10:04] of course today’s episode

[00:10:06] would not be possible

[00:10:07] without our wonderful sponsor

[00:10:08] Flatiron School

[00:10:10] you can join the global community of change makers

[00:10:12] at flatironschool.com

[00:10:14] slash developer tea

[00:10:16] that’s flatironschool.com

[00:10:18] slash developer tea

[00:10:19] today’s episode was produced by Sarah Jackson

[00:10:23] my name is Sarah Jackson

[00:10:24] my name is Jonathan Cottrell

[00:10:25] and until next time

[00:10:26] enjoy your tea

Visão de gráfico