Vox

Leitura de 13 min

Steps to Become a Terrible Developer

Summary

In this satirical episode of Developer Tea, host Jonathan Cattrell outlines a series of behaviors that lead to becoming a terrible developer—while still maintaining employment. The episode frames common professional pitfalls as deliberate steps one could take to sabotage their own growth and effectiveness.

The first major theme is distraction. Cattrell suggests constantly checking email, engaging in endless debates about tooling without resolution, learning multiple programming languages superficially without mastering any, and keeping all phone notifications enabled. He also recommends attending all meetings but not paying attention, splitting focus during work hours, and keeping team members in the dark about your priorities.

Another critical aspect is ego protection. Cattrell advises subtly making others feel inferior, attaching opinions to dogmatic approaches borrowed from respected programmers, and using evidence selectively to support one’s own views. This behavior, he notes, might even lead to promotions while undermining team cohesion.

For developers in leadership roles, Cattrell highlights additional destructive behaviors: over-optimizing technical aspects without considering product needs, being too busy to support junior developers, and making newcomers feel their questions are obvious or unimportant. These actions create a toxic environment while maintaining an appearance of technical prowess.

The episode concludes by acknowledging that these behaviors sound ridiculous when framed satirically, but they represent traps developers often fall into naturally. Cattrell encourages mindful consideration of one’s responsibility to teammates and personal growth, suggesting that awareness of these pitfalls is the first step toward avoiding them.

Topic Timeline

  • 00:00:00 — Introduction to becoming a terrible developer — Jonathan Cattrell introduces the episode’s satirical premise: exploring how to become a bad developer while keeping your job. He distinguishes this from behaviors that would get someone fired, focusing instead on actions that stifle growth and career advancement.
  • 00:01:28 — The critical role of constant distraction — Cattrell identifies distraction as the most critical factor in becoming a terrible developer. He suggests constantly checking email, engaging in endless tooling debates without resolution, superficially learning multiple languages, and keeping all phone notifications enabled to maintain divided attention.
  • 00:03:53 — Meeting attendance without engagement — The host recommends attending all meetings, even optional ones, but not paying attention. He suggests working during meetings and splitting focus between tasks, arguing that this creates the appearance of engagement while actually preventing meaningful contribution to either activity.
  • 00:04:36 — Withholding information from your team — Cattrell advises against sharing what you’re working on with teammates and recommends not knowing what they’re working on either. He suggests tuning out during stand-ups and working on unapproved priorities, creating a ‘rogue developer’ mentality that undermines team coordination.
  • 00:07:20 — Protecting your ego and appearing superior — The episode discusses how to protect your ego by subtly making others feel you know more than they do. Cattrell recommends attaching opinions to dogmatic approaches borrowed from respected programmers and using evidence selectively to support your views, which might even lead to promotions.
  • 00:09:04 — Over-optimizing without product context — For developers in technical leadership roles, Cattrell suggests focusing exclusively on optimization without considering product needs. He notes that as a ‘technical guru,’ you might spend time optimizing things the product team wouldn’t prioritize, but others will let it slide due to your perceived expertise.
  • 00:09:46 — Neglecting junior developer support — The host advises being too busy to support junior developers during onboarding. When they ask questions, make them feel the answers are obvious. This behavior creates barriers to knowledge sharing and reinforces a hierarchical dynamic that stifles team growth.

Episode Info

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

References

Podcast Info

Transcript

[00:00:00] a couple of episodes ago we did an episode talking about how to be a terrible manager

[00:00:09] of course this was done satirically we don’t want you to go and become a terrible manager

[00:00:15] if you’re a developer there are similar things that you can take to heart about how to become

[00:00:23] well a terrible developer what does it mean to be a bad developer

[00:00:29] that’s what we’re talking about in today’s episode my name is jonathan cattrell and you’re

[00:00:34] listening to developer t and my goal in the show is to help driven developers like you

[00:00:38] find clarity perspective and purpose in your careers and so we’re going to talk about what

[00:00:44] it means to be a bad developer and notice that i’m i’m not saying what it takes to get fired

[00:00:51] as a developer

[00:00:53] instead i want to focus on the kinds of actions that you might be able to take

[00:00:59] and still sustain your career still hold a job still continue being a developer

[00:01:06] just not a good one and ultimately this will stifle your career it’ll stifle your growth

[00:01:14] and much of what you want to do you may never get a chance to do

[00:01:21] so i’m going to share a list of

[00:01:23] things that will really help you become a terrible developer

[00:01:28] perhaps the most critical thing that you can do to become a terrible developer

[00:01:33] is to always stay distracted and this distraction can come from anywhere really

[00:01:41] probably from your email at least because that’s the most common distraction that we all have and

[00:01:49] so you can easily let that one slide by but

[00:01:53] eventually you will get through those emails and there’s going to be some lull

[00:01:56] in those emails hitting your inbox so other ways that you might stay distracted

[00:02:02] as a developer is in endless conversations about your tooling if you have strong opinions

[00:02:11] or even if you have weak opinions if you continuously discuss those opinions with

[00:02:18] other developers and you never come to any common ground that will actually help you become a terrible

[00:02:23] as a strong distractor for you in your career now let’s say that you don’t yet have opinions

[00:02:29] and you work with other people who do or maybe you don’t have a job as a developer at all and

[00:02:35] you want to start out your career totally distracted well i encourage you if you want

[00:02:42] to be entirely distracted at the beginning to try to learn as many languages as possible

[00:02:48] now what this will do is it will constantly keep you in that

[00:02:53] hello world state you’ll never really learn anything majorly different between the languages

[00:02:59] you might learn some semantic differences of a very small subset of the languages but

[00:03:06] you’re never going to learn anything meaningful or practically productive by switching between

[00:03:14] them all the time so now you have a strong sense of distraction in your day-to-day work

[00:03:20] to kind of add a little bit of a sense of distraction to your day-to-day work

[00:03:23] you’re going to want to make sure that your notifications on your phone are all turned on

[00:03:29] they’re all enabled and that all of your social accounts are enabled as well so that you are

[00:03:34] getting those notifications at all hours of the day once you have this major amount of distraction

[00:03:42] with the time that you have left in your day there’s a handful of other things you can do

[00:03:47] to make sure that you become a terrible developer we’re going to list a couple of these

[00:03:53] before we go to our sponsor break first make sure you attend all of the meetings on your calendar

[00:04:00] even the ones that are optional be certain to be present but don’t pay attention

[00:04:07] try to do work during these meetings and try to split your focus between them remember

[00:04:14] distraction is kind of the critical factor in becoming a terrible developer and so if you

[00:04:20] attend the meetings the external distractions are going to be the ones that are going to be

[00:04:23] present and the ones that are going to be present the internal perception is that you are engaged

[00:04:25] but actually because your mind is split between two things you’re not really giving either one

[00:04:31] the attention that it deserves of course as a terrible developer you shouldn’t ever tell your

[00:04:36] team what you’re working on you shouldn’t share that information with them and you certainly

[00:04:41] shouldn’t know what they are working on so if you can tune out during your daily stand-up

[00:04:47] or work on something entirely different from what you say is priority maybe even something that is

[00:04:53] not even kind of agreed on by the team as important enough to work on now you are kind of a rogue

[00:05:01] developer and a rogue developer is one of the characteristics of a terrible developer we’re

[00:05:07] going to take a quick break and then we’re going to come back and talk about some other things

[00:05:11] that might help you become a terrible developer but first let’s talk about today’s sponsor

[00:05:16] blue madora blue madora is monitoring integration unlocked with blue madora you can seamlessly

[00:05:22] stream metrics and new features for your team and create your own campaign from scratch so if you’re

[00:05:22] watching this right now and you’re watching this on your phone or if you’re watching this on your

[00:05:23] and logs from all of your on-premises hybrid cloud and multi-cloud technologies to your

[00:05:28] favorite monitoring platform. You can easily access metrics and logs from over 150 of these

[00:05:35] different sources and bring them into your favorite monitoring tool. For example, Google

[00:05:40] Stackdriver, New Relic, Azure Monitor, Wavefront, or Datadog. You can achieve a single pane of glass

[00:05:47] that gives you insight into your entire stack. With Blue Medora, you get frictionless integration,

[00:05:53] no more dealing with open source configuration or managing monitoring agents. You’ll also get

[00:05:59] a visual health dashboard of all of these monitoring integrations. And on top of all this,

[00:06:04] it’s free to install and upgrade your Google Stackdriver monitoring. You only pay for the

[00:06:10] more metrics that you end up streaming reflected in your normal GCP bill. On top of that, you’ll

[00:06:16] get $200.

[00:06:17] worth of GCP credit. These credits can be combined with GCP’s free trial credits when

[00:06:24] you upgrade Stackdriver with BindPlane at bluemedora.com slash T. That’s bluemedora.com

[00:06:31] slash T-E-A. Thanks again to Blue Medora for sponsoring today’s episode of Developer Tea.

[00:06:37] So we’re talking about how you can become a terrible developer and specifically how you

[00:06:43] can become a terrible developer without losing your job.

[00:06:47] The kind of behavior that might even get you a raise. We already mentioned staying on top of

[00:06:54] your inbox at all times. This kind of responsiveness is typically applauded in the workplace, but

[00:07:01] unfortunately, it will totally divide your attention. So distraction is one thing. Most of

[00:07:08] the first part of this episode was kind of encouraging that kind of distraction if you

[00:07:13] want to be a terrible developer. In this part of the episode, we’re talking about how you can

[00:07:17] become a terrible developer. We’re going to talk about a few other things. The first one is about

[00:07:20] humility or the lack thereof. If you want to become a terrible developer, be sure that you

[00:07:28] protect your ego. Now, this can’t be obvious. You can’t walk in and say that you’re a know-it-all

[00:07:36] because that would get you fired. But instead, you should always make other people feel in subtle

[00:07:44] ways that you do know more than they do.

[00:07:47] This kind of power game reminds them that you have a lot more experience than they do, or

[00:07:54] that you just think your opinion is better than theirs. This is especially effective if you can

[00:08:00] attach your opinions to some kind of very strong dogmatic approach. Maybe take some of the ideas

[00:08:08] of the great programmers who are well-respected and have come before you and justify your

[00:08:16] opinion. If you can attach your opinions to some kind of very strong dogmatic approach,

[00:08:17] you can even use this podcast in that particular way. You could use this podcast to build up some

[00:08:26] dogmatic approach. And now, when you present your dogmatic approach with all of the evidence

[00:08:33] that you’ve gathered that supports it, well, of course, your ego is supported and the other

[00:08:40] person’s opinion seems to matter less. Often, this is just the criteria you need to know to

[00:08:46] get that raise and become a lead developer. And in that lead position, you continue to support your

[00:08:56] ego, but you can also begin to do things like over-optimize. You are a programmer after all,

[00:09:04] and so why should you be thinking about the product? Your strengths are entirely in the

[00:09:13] logical realm, and so you shouldn’t have to zoom out.

[00:09:16] You can do your job totally thinking about how to optimize things. And therefore, you end up

[00:09:23] spending a lot of time optimizing things that ultimately the product team wouldn’t really have

[00:09:30] had you optimize. But because you are still gaining your prowess as a developer, and because

[00:09:38] you are considered the technical guru on the team, well, everyone just kind of lets it slide.

[00:09:45] Of course, as a lead developer, you will

[00:09:46] also have an opportunity to participate in the onboarding of junior developers.

[00:09:52] And it’s your responsibility, if you are a terrible developer, to simply be too busy to

[00:10:00] support them. And when they do ask you questions, make sure they feel like you think the answer is

[00:10:07] obvious. These are just a handful of the ways that you can be a terrible developer. Of course,

[00:10:13] on the show, most of the time, we’re talking about ways to avoid

[00:10:16] these very easy-to-fall-in traps. Of course, they sound ridiculous in the frame that we’ve put them

[00:10:23] in in this episode. But as it turns out, these are some of the behaviors that we end up resorting to

[00:10:30] naturally. I encourage you to think mindfully about your responsibility as a developer to the

[00:10:36] people around you and to yourself. And as you kind of accept that responsibility, I encourage you to

[00:10:44] listen to this show and other shows like it.

[00:10:46] Thank you so much for listening. Today’s episode wouldn’t be possible without our wonderful producer,

[00:11:10] Sarah Jackson. Of course, you can find this episode and every other episode of Developer Tea

[00:11:14] at spec.fm.

[00:11:16] Make sure you subscribe in whatever podcasting app you’re listening to this episode on. And for those

[00:11:23] of you who use Mac OS, if you have recently upgraded your computer, the new Apple Podcasts app

[00:11:30] is available as a native application. Now iTunes is no more. So I encourage you to subscribe to

[00:11:37] Developer Tea in the native podcast app. Thank you so much for listening. And until next time,

[00:11:43] enjoy your tea.

[00:11:46] Bye.

Visão de gráfico