Vox

Leitura de 17 min

4 Things You Have to Leave Behind as a Beginning Engineer

Summary

In this episode of Developer Tea, host Jonathan Cottrell addresses early-career software engineers, urging them to let go of four specific mindsets that can hinder growth and cause unnecessary stress. The discussion centers on shifting from control to observation, accepting the inevitability of bugs, moving beyond the search for a perfect tech stack, and understanding that coding is just one part of a software engineer’s role.

The first thing to leave behind is the desire to control every outcome. Cottrell argues that this desire is damaging and suggests engineers should instead focus on controlling and refining their process, experimentation, and learning. By shifting mentally from control to observation, outcomes become something to learn from rather than something to dominate.

Second, new engineers should let go of the feeling that they should have caught every bug before it happened. While best practices and testing are important, the belief that all bugs are preventable is harmful. It leads to over-engineering systems for bug prevention at a high opportunity cost. Accepting that some bugs will reach users is frustrating but also liberating, allowing engineers to focus on more valuable work.

The third item is the belief in a perfect, one-size-fits-all tech stack. Cottrell explains that no such stack exists because the engineer is a critical part of the equation. A stack must fit the individual and the task at hand. Letting go of this endless pursuit is liberating and allows engineers to work effectively with the tools they have, improving them over time.

Finally, and most fundamentally, engineers must let go of the illusion that coding is the job. Through a thought experiment—imagining the job without writing code—Cottrell illustrates that software engineering involves stakeholder communication, problem-solving, and understanding people. Focusing solely on coding creates a fragile career; developing broader skills leads to greater fulfillment and longevity.

Recommendations

Podcasts

  • React Podcast — Mentioned as one of the other incredible shows available on spec.fm, built specifically for developers.
  • Tools Day — Another show available on spec.fm, mentioned alongside React Podcast as content built for the developer audience.

Tools

  • Retool — A platform for building internal tools quickly with a drag-and-drop interface. It connects to any database or API, allowing engineers to write SQL or JavaScript to manipulate data, helping them spend less time on internal apps and more on customer-facing products.

Websites

  • spec.fm — The platform where Developer Tea and other shows like React Podcast and Tools Day can be found. It hosts podcasts built specifically for developers.

Topic Timeline

  • 00:00:00 — Introduction to leaving things behind as a new engineer — Host Jonathan Cottrell introduces the episode’s theme: instead of what to bring, he will discuss what beginning engineers should leave behind. He addresses early-career developers and outlines the goal of helping them find clarity, perspective, and purpose. The episode will cover four non-physical things to let go of.
  • 00:01:27 — First thing to leave: The desire to control every outcome — Cottrell identifies the first and potentially hardest thing to leave behind: the desire to control every outcome. He explains that this desire motivates actions and can be damaging. The recommended shift is to target controlling your process, iteration, and learning instead, making outcomes something you observe rather than control.
  • 00:02:56 — Second thing to leave: The feeling you should catch every bug — The second thing to let go is the feeling of guilt or duty that you should have caught every unexpected bug. Cottrell argues this belief is damaging because it leads to over-engineering systems focused solely on bug prevention. He acknowledges the importance of best practices but stresses that some bugs will always reach users, and accepting this can be liberating.
  • 00:05:25 — Sponsor segment: Retool for building internal tools — The episode takes a break for a sponsor message from Retool, a platform for building internal tools quickly. Cottrell describes how internal tools are often unglamorous and maintenance-heavy. Retool offers a drag-and-drop interface and connects to any database or API, allowing engineers to build tools in hours and focus more on customer-facing products.
  • 00:07:52 — Third thing to leave: The belief in a perfect tech stack — Cottrell presents the third thing to leave behind: the belief that there is a perfect tech stack waiting to be discovered. He explains that no one-size-fits-all solution exists because the engineer is part of the equation. Letting go of this pursuit is liberating, allowing engineers to choose tools that fit them and their work, and to improve the stack they have.
  • 00:10:21 — Fourth thing to leave: The illusion that coding is the job — The final and foundational thing to let go of is the illusion that coding is the job. Cottrell proposes a thought experiment: imagine your job without writing code. He argues that software engineering involves stakeholder communication, problem-solving, and understanding people. Focusing only on coding creates a fragile career; developing broader skills leads to greater fulfillment and resilience.
  • 00:12:24 — Closing remarks and call to action — Cottrell thanks the listener and the sponsor, Retool. He directs listeners to spec.fm for more shows like React Podcast and Tools Day. He ends with a request for listeners to leave a review on their podcast platform, explaining that reviews help other developers find the show and provide crucial support to keep it running.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-08-19T09:00:21Z
  • Duration: 00:13:41

References

Podcast Info

Transcript

[00:00:00] There’s a lot of discussion about what you should bring with you when you start to learn

[00:00:11] a given subject, when you go to class, or when you begin a career as an engineer.

[00:00:19] In today’s episode, we’re going to talk about the exact opposite, what to leave behind.

[00:00:24] Specifically, I want to address the beginners who are listening to this episode, young

[00:00:29] developers.

[00:00:30] When I say young, I just mean at the beginning of your career as an engineer, young developers

[00:00:36] who are just now starting out.

[00:00:39] In today’s episode, we’re going to talk about four things that you should leave behind.

[00:00:44] My name is Jonathan Cottrell.

[00:00:45] You’re listening to Developer Tea, and my goal on this show is to help driven developers

[00:00:48] like you find clarity, perspective, and purpose in their careers.

[00:00:54] We’re going to jump straight into the four things, what to leave behind as a new developer,

[00:00:59] four things to let go, four things that you might be carrying without realizing it.

[00:01:05] These are obviously not physical objects.

[00:01:07] If you’ve listened to the show even once, then you know that we tend to talk about things

[00:01:12] that are evergreen, these abstract ideas, the principles that you can carry with you

[00:01:17] that are going to apply in 15 years from now.

[00:01:21] The first thing that I want you to leave behind, and you may be very attached to this one.

[00:01:27] This one’s a hard one to start out with.

[00:01:29] The first thing I want you to leave behind is the desire to control every outcome.

[00:01:34] The desire to control every outcome.

[00:01:37] It’s hard to leave the desire behind, and we’re specifically addressing this because

[00:01:42] I want you as a driven engineer to work on the desire itself.

[00:01:49] We may have the belief that it’s possible to control every outcome, and that is just

[00:01:57] as damaging.

[00:01:58] But if we can control the desire, the desire is the thing that motivates our actions.

[00:02:05] So if we no longer want, if we no longer strive or target controlling the outcome, and instead

[00:02:15] we target something different, which we talk about on plenty of other episodes on this

[00:02:19] show, if instead, for example, we target refining our process or refining our iteration on experimentation

[00:02:28] and learning as we go, if those are the things that we intend to control, then the outcomes

[00:02:34] become something that we can observe rather than control.

[00:02:40] That’s the shift that I want you to make.

[00:02:42] Instead of trying to control an outcome, imagine your mental shift going away from control

[00:02:49] and towards observation.

[00:02:51] The second thing that I want you to leave behind as a new engineer is the feeling that

[00:02:56] you should have caught every unexpected bug before it happened.

[00:03:02] This feeling is a sense of guilt, or maybe a sense of duty.

[00:03:07] The idea that every bug that you are responsible for, whether it comes from your code or from

[00:03:14] a team you’re working on, could have been caught, this can be a very damaging belief.

[00:03:23] And it’s a damaging belief because it causes us to build entire systems around trying to

[00:03:31] predict and prevent bugs from occurring.

[00:03:34] Now, that’s not to say that we can’t catch any of them.

[00:03:38] Of course, a lot of our best practices are built off of the idea that we can exercise

[00:03:45] the various pathways that are in our code in ways that should, hopefully, produce some

[00:03:51] kind of foresight, trigger those errors before they go out, before they’re shipped to our

[00:03:57] customers, before they’re shipped to users.

[00:04:00] But there is a line, and this is really a theme in this episode, the idea that things

[00:04:07] are difficult to control and there are very few absolutes in your career.

[00:04:13] And one of those things is that even though you may catch, let’s say, 80% of the bugs

[00:04:18] that will eventually show up in your code, or eventually could show up in your code,

[00:04:24] there’s another 20%, and that number is arbitrary, by the way, there’s another some amount of

[00:04:31] bugs that are going to eventually show up and you’re going to have to deal with them

[00:04:35] after they’ve made it to your users.

[00:04:38] This is frustrating, but it can also be liberating.

[00:04:42] When we think about the bugs that we need to catch versus the ones that we’re trying

[00:04:48] to catch just because we’ve labeled it as a bug, then we can start to consider other

[00:04:55] opportunities and the opportunity cost of building those systems we were talking about

[00:05:00] to try to engineer our entire organization around bug catching.

[00:05:06] Our job is not to be a bug catcher.

[00:05:09] So that is something I want you to leave behind, that title of bug catcher, the idea that you’re

[00:05:14] going to catch every bug before it goes out.

[00:05:18] That’s just not going to happen, and it shouldn’t.

[00:05:22] We’re going to take a quick break and talk about today’s brand new sponsor, Retool, and

[00:05:25] then we’re going to come back and talk about two more things to leave behind as a beginner

[00:05:30] engineer.

[00:05:32] Retool is the fastest way to build internal tools.

[00:05:36] Now, if I’m being honest, most engineers don’t love building internal tools.

[00:05:41] Some of us do, but apps like admin panels or basic CRUD operations, customer support,

[00:05:48] inventory management tools, these are not the reasons why we got into being engineers.

[00:05:54] We’d rather focus on products.

[00:05:56] But every business runs off of internal tools like these, and no one really wants to deal

[00:06:00] with the headache of the build and perhaps more importantly, the maintenance of those

[00:06:08] Because there’s always these requests that come in, they’re very specific to a given

[00:06:13] use case, and it feels like those projects are never done and they tend to be underappreciated

[00:06:20] for that matter.

[00:06:21] So when you think about it, internal tools are almost entirely comprised of the same

[00:06:25] building blocks, tables, dropdowns, buttons, text inputs.

[00:06:30] These are all things that we see in all of those internal tools and that we’ve built

[00:06:34] a hundred times over.

[00:06:35] They all pretty much need to connect to the data source and then with some code to function

[00:06:41] on that data source.

[00:06:43] This is pretty straightforward.

[00:06:45] This is exactly how Retool can help you.

[00:06:49] Retool gives you a drag and drop interface so you as the engineer can build internal

[00:06:54] app UIs in hours rather than days and spend more time building features that your customers

[00:07:00] will see, spend more time on your products.

[00:07:04] It connects to any database or any API.

[00:07:07] For example, to pull in data from Postgres, you just write a SQL query and then drag a

[00:07:11] table onto the canvas.

[00:07:15] And you can also write JavaScript pretty much anywhere inside of Retool to manipulate the

[00:07:19] data in any way that you would like.

[00:07:21] Go and check it out.

[00:07:22] Head over to Retool.com slash DevT.

[00:07:25] That’s Retool.com slash D-E-V-T-E-A to get started today.

[00:07:31] Thanks again to Retool for sponsoring today’s episode of Developer T.

[00:07:36] There’s two more things that I want you to let go of, to leave behind on your pathway

[00:07:42] to becoming a software engineer.

[00:07:45] And realistically, you’re going to be on that pathway indefinitely.

[00:07:50] And that kind of inspires the next two things.

[00:07:52] The first one is the belief that there is a perfect tech stack waiting to be discovered.

[00:07:58] This is an easy thing to believe because there are people who have bought in very deeply

[00:08:04] to a given tech stack and that stack works really well for them.

[00:08:08] And perhaps when they write a blog post or they do a podcast or they go and speak at

[00:08:13] a conference, they talk about that stack as if it’s kind of a one size fits all solution

[00:08:19] or as if it’s the pinnacle of computer science.

[00:08:23] But the truth is that there is no one perfect tech stack.

[00:08:29] How can this be when we’re told this over and over and over that we’re supposed to

[00:08:33] be refining our tools and building new ones and abstracting on top of those and getting

[00:08:39] better and better?

[00:08:40] Well, the truth is that your tech stack is only part of the equation and you are a huge

[00:08:46] factor in that equation.

[00:08:50] Think about it for a second.

[00:08:51] You are a part of the tech stack.

[00:08:53] The tech stack doesn’t build itself and it doesn’t exist as some kind of autonomous entity.

[00:09:01] You are working with the tech stack and if it doesn’t fit you or if it doesn’t fit the

[00:09:06] thing that you’re trying to do, then it doesn’t matter what someone says about it at a conference

[00:09:13] or on Hacker News.

[00:09:16] So you’re not going to find the perfect tech stack and that should also feel liberating.

[00:09:21] It’s a little bit disappointing because it’d be nice if we all agreed and we just went

[00:09:26] in one direction and we could find a tool that just works for everyone magically.

[00:09:30] But it’s not going to happen and that can be liberating because we can let go of that

[00:09:35] constant pursuit and be okay.

[00:09:38] We can choose tools that we like.

[00:09:42] We can choose tools that are safe or we can accept the fact that the job that we have

[00:09:48] or working with a tool that maybe has some downfalls, right?

[00:09:53] It has some weak spots.

[00:09:55] That doesn’t necessarily mean the end of the world.

[00:09:57] It certainly doesn’t mean that your engineering organization doesn’t see the light.

[00:10:03] Once you are able to accept the fact that there’s not a perfect tech stack, then you

[00:10:08] can work towards making the one that you have more valuable.

[00:10:13] Now, I have one final thing that I want you to let go of and this really is an underpinning

[00:10:21] theme of this podcast entirely and that is that coding is not the job.

[00:10:28] Let go of the illusion that coding is the job and understand that there is so much more

[00:10:34] to being a software engineer than just writing code.

[00:10:38] And to illustrate this point, I want you to do a kind of mental exercise.

[00:10:44] This is just a thought experiment.

[00:10:47] Imagine that you have your job today, right?

[00:10:50] You have your job today, but that we’ve somehow removed the responsibility of writing code

[00:10:56] from your plate.

[00:10:58] You no longer have to write the code.

[00:11:01] You still have to go through the same thought processes that you had before.

[00:11:05] You still have to think through all the same scenarios.

[00:11:08] You have to understand the people that you work with.

[00:11:11] You still have to work with the same stakeholders, etc.

[00:11:16] How would your job look different?

[00:11:19] What would change about your job?

[00:11:22] It’s important to understand that there are people who are hired just to be coders, but

[00:11:29] This is a fragile job.

[00:11:31] It’s a job that could easily be replaced.

[00:11:35] And if you’re just now starting out in your career, especially if you have many years

[00:11:40] theoretically in front of you in your career, then focusing on just coding is not kind of

[00:11:47] the the pinnacle of what you’ll do in your career.

[00:11:51] It certainly will be a part of it.

[00:11:53] But imagine that your coding is only one tool in a very wide array of tools that we

[00:12:01] already just mentioned, right?

[00:12:03] Imagine taking that tool away.

[00:12:04] What is left in your skill set?

[00:12:08] Focus on developing those things as much and perhaps even more than your coding skills

[00:12:14] because they’re going to, you know, pay you back in spades, not just in money, but certainly

[00:12:19] in relationships and in personal fulfillment.

[00:12:24] Thank you so much for listening to today’s episode of Developer T. Thank you again to

[00:12:27] Retool for sponsoring this episode, a brand new sponsor.

[00:12:31] Head over to Retool.com slash DevT, that’s R-E-T-O-O-L dot com slash D-E-V-T-E-A.

[00:12:41] This episode and every other episode of Developer T can be found on spec.fm along with other

[00:12:45] incredible shows.

[00:12:47] They’re built specifically for you, shows like React Podcast and Tools Day.

[00:12:53] Go and check it out, spec.fm.

[00:12:55] Thank you so much for listening to this episode.

[00:12:57] If you’ve enjoyed this episode or another episode of Developer T, the best way that

[00:13:03] you can show your appreciation for the show is to go and leave a review.

[00:13:08] You can leave a review in whatever platform you use to listen to podcasts that allows

[00:13:14] reviews, iTunes or Google Play, for example.

[00:13:17] This is a huge way that you can help other developers like you find Developer T and you

[00:13:23] can provide feedback and appreciation to us.

[00:13:27] And ultimately, this is one of the best ways you can help us keep the lights on on this

[00:13:31] show.

[00:13:32] Thanks so much for listening and until next time, enjoy your tea.

Visão de gráfico