Vox

Leitura de 33 min

Swizec Teller and the Senior Engineering Mindset, Part One

Summary

The episode explores the fundamental shift in mindset required to transition from a competent software engineer to a senior engineer. Swizec Teller argues that the biggest differentiator is moving from a focus on writing perfect, beautiful code to using code as a tool to solve business problems. This involves becoming a partner to product managers, understanding the core business objectives, and focusing on the most efficient way to achieve outcomes rather than technical perfection.

A key responsibility of a senior engineer is to act as a force multiplier for the team. This involves “bushwhacking”—looking ahead to clear obstacles before the team encounters them, fixing small annoyances that slow everyone down, and steering the team away from known pitfalls based on past experience. Senior engineers develop a “spidey sense” for potential future problems, particularly in areas like domain modeling, which has an outsized impact on how difficult the code will be to write and maintain.

The discussion delves into the practical dynamics of working with product. In empowered team models, the senior engineer is not stepping out of their role but becoming a crucial partner, similar to a caddy for a golfer or a race engineer for an F1 driver. They provide technical options, cost estimates, and ramifications of decisions, enabling the product owner to make informed calls. The episode also tackles the strategic use of technical debt, illustrated by a story of successfully rewriting a jQuery app to React while the business continued to grow and raise significant funding.

Finally, the conversation highlights subtle but critical skills that come with experience, such as effective domain modeling and naming. Poor naming (like database columns scheduled_time and booked_time that are synonyms) creates cognitive overhead and future bugs. A senior engineer’s value often lies in knowing what bad paths to avoid and helping the team establish a solid foundational model for the problem, which makes all subsequent implementation work easier.

Recommendations

Communities

  • Developer Tea Discord — A free Discord community for listeners of the Developer Tea podcast to discuss episodes and career growth with other engineers.

Tools

  • Cord — A messaging tool sponsored in the episode that gives engineers direct access to hiring teams at tech companies, presented as a new way to find jobs through conversations.

Websites

  • seniormindset.com — Swizec’s website dedicated to the topic of the senior engineering mindset, which is the central theme of the episode.
  • serverlesshandbook.dev — The website for the Serverless Handbook, which Swizec Teller authored.

Topic Timeline

  • 00:00:00 — Introduction to the senior engineering mindset — The host introduces the topic of what it means to be a senior engineer, focusing on responsibilities, intuition, and mindset rather than title or pay. Guest Swizec Teller is introduced as a senior engineer at TIA and creator of seniormindset.com.
  • 00:02:36 — The biggest differentiator of a senior engineer — Swizec identifies the core shift: moving from focusing on implementing perfect code to a given spec, to focusing on solving the underlying business problem. He analogizes it as going from being a good hammerer to being good at solving problems with a hammer.
  • 00:06:43 — Partnering with product and the context of caring about code — The host notes that successful senior engineers have tight relationships with product managers. They discuss the context behind ‘not caring about the code’—it means caring about code as a tool for solving future problems efficiently, not for its intrinsic perfection. The goal is code that is ‘good enough’ and maintainable.
  • 00:09:27 — The value of not writing code and looking ahead — Swizec explains that a senior engineer’s role involves ‘bushwhacking’—looking ahead to clear obstacles so the team doesn’t get tangled in the weeds. This involves being involved early to ensure the right thing is being built or to prepare for future needs, saving immense time.
  • 00:10:38 — Navigating the engineer-product partnership dynamic — The host asks if this closer product involvement feels like stepping out of the engineering role. Swizec clarifies that in empowered team models, the PM is a teammate, not a boss. The senior engineer’s role is to be a good partner who speaks the product language while being deep in the codebase to provide realistic technical constraints and options.
  • 00:15:34 — Balancing business needs with engineering best practices — The host presents a scenario where a business need is at odds with ‘clean engineering.’ Swizec advocates for the strategic use of technical debt, especially in startups, and shares a success story of rewriting a jQuery app to React while the business continued to grow and raise massive funding rounds.
  • 00:20:15 — Senior engineer’s role in team morale and as a force multiplier — Swizec discusses the partnership with engineering managers on team morale. He emphasizes that senior engineers, being in the weeds, should vocalize team annoyances and proactively fix them. Spending time to make the whole team slightly faster is a powerful force multiplier that pays back quickly.
  • 00:22:52 — Using experience to steer teams and the importance of domain modeling — Swizec highlights the ‘sixth sense’ from battle scars that lets senior engineers steer teams away from rabbit holes and known bad paths. He identifies domain/data modeling as a critical, experience-based skill that, when done well, makes all subsequent implementation much easier and has a huge impact.
  • 00:27:21 — The critical impact of naming and vague data definitions — The discussion turns to how fundamental lessons like ‘naming things is hard’ are deeply connected to domain modeling. Vague names for data (like database columns) create interfaces that lead to misuse, subtly different meanings for similar-looking data, and future suffering. Examples include ‘scheduled_time’ vs ‘booked_time’ and the ambiguity of ‘first_name’.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2022-03-21T07:00:00Z
  • Duration: 00:33:51

References

Podcast Info

Transcript

[00:00:00] What exactly does it mean to be a senior engineer?

[00:00:06] We don’t mean necessarily how much is a senior engineer paid or what is the title.

[00:00:13] Really, we’re talking about the responsibilities, the intuitions, the mindset.

[00:00:20] How do you become a senior engineer?

[00:00:25] Today’s guest argues that it starts with that mindset.

[00:00:30] Today we’re joined by Svazek Teller.

[00:00:32] Svaz is a senior engineer at TIA.

[00:00:36] He also authored the Serverless Handbook, which you can find at serverlesshandbook.dev.

[00:00:42] And most importantly for today’s episode, he created seniormindset.com.

[00:00:47] Go and check that out. That’s seniormindset.com.

[00:00:51] Let’s get straight into the discussion with Svazek Teller.

[00:00:55] Svaz, welcome to the show.

[00:00:57] Hi.

[00:00:59] I’m excited to have you on.

[00:01:01] This topic is, I’m sure, top of mind for a lot of engineers.

[00:01:06] And if it’s not top of mind this year, it might be next year.

[00:01:10] And I’m really excited to discuss this with you.

[00:01:14] But first, I’d love to give you the 30-second window here to give a pitch for who you are.

[00:01:21] What kind of work do you do?

[00:01:23] And then we’ll get into our discussion.

[00:01:26] Yeah. So hi, I’m Svaz.

[00:01:28] I’m a software engineer at TIA, which is a health tech company.

[00:01:34] I’ve been in Silicon Valley now for, wow, seven years.

[00:01:38] I’m getting old.

[00:01:40] And lately I’ve kind of been exploring what it is that I’ve done in the last couple of years

[00:01:45] that has really unlocked my career from being a really good, solid technologist

[00:01:51] to being more someone who can take on bigger challenges and do some team-leading stuff

[00:01:56] and cool things like that.

[00:02:00] And I’m sure that the people who are listening right now,

[00:02:04] if they’re in that phase of their career where they’re trying to say,

[00:02:08] trying to figure out how do I go from just writing code to being in some kind of higher-level position,

[00:02:17] higher-level thinking, maybe they want to employ a different kind of thinking pattern

[00:02:23] and get out of some of that day-to-day just coding is all they do.

[00:02:29] I’d love for us to kind of dive into this, but I want to start with a framing question here.

[00:02:36] If you had to sum up what it means to be a senior engineer, what is the biggest differentiator?

[00:02:46] If you had to just pick one, what is the biggest differentiator between a senior engineer

[00:02:52] and let’s say someone who isn’t a senior?

[00:02:55] It’s hard to decide what the name of that is, but a non-senior engineer.

[00:03:00] Yeah, so it’s funny that you have a hard time coming up with that

[00:03:06] because I think a lot of people who aren’t really seniors quite yet do have the title of senior engineer.

[00:03:13] And this is something we see especially in fast-growing startups.

[00:03:17] If you just stick around for three, five years, you’re going to get that senior title.

[00:03:22] But it doesn’t necessarily mean that you’re actually a senior, senior engineer.

[00:03:27] I think the biggest difference that I’ve seen in my career and in team members’ careers and just in general

[00:03:35] is that you kind of switch from thinking about focusing on just the code and thinking about the code

[00:03:42] into more about thinking of using the code as a tool to solve some problem.

[00:03:48] So to kind of expand on that, I think the biggest difference is going from

[00:03:57] give me the spec, tell me what to do, and I’m going to implement it and I will make sure that it’s perfect and amazing

[00:04:05] and the code is beautiful, readable, everyone else can understand it on the team and stuff like that

[00:04:10] to more like, I don’t really care about the code, tell me what’s the problem we’re solving

[00:04:16] and I’m going to be a really solid partner to my product owner or my PM

[00:04:22] and work with them to figure out what is the smallest, quickest way we can get this to fit in the rest of the project

[00:04:30] so that we can solve the problem rather than focusing so much on the code.

[00:04:37] Yeah, it’s like one way I like to sum it up is that at least in the last couple of years

[00:04:46] I’ve gone from being a really good hammerer to being someone who’s really good at solving problems with a hammer.

[00:04:57] Yeah, that’s a good way to think about it. You’re a craftsman or you’re kind of getting above that

[00:05:03] just whatever that kind of mechanistic action is and thinking more about how does that action support some larger goal.

[00:05:15] Exactly. Yeah, like what is the actual business objective we’re trying to solve

[00:05:22] and one interesting thing that I’ve noticed as I’ve started talking more about this and being more vocal with the PM

[00:05:30] they come up with really good ideas, but they don’t always have the best ideas.

[00:05:35] That’s why they need engineers. Otherwise, they could just go and code it themselves.

[00:05:40] And as I started talking more about, you know, if we change this requirement a little bit and we do it this other way

[00:05:48] it’s going to be much quicker and it’s still going to solve the actual problem that you’re solving.

[00:05:55] The more of that that I did, I found myself naturally getting involved earlier and earlier in the cycle

[00:06:01] because the product owners and the leadership team on my companies was like,

[00:06:07] oh, hey, this guy is actually thinking about this stuff.

[00:06:10] Why don’t we just go ask him before we even come up with a solution and just be like,

[00:06:14] hey, we’re solving this problem. Come help us solve it.

[00:06:18] And then through those conversations, you suddenly find yourself being able to kind of steer the whole

[00:06:27] technical direction of the company and think more further ahead.

[00:06:33] Yes. So I’ve noticed this with senior engineers, often the ones who tend to be the most successful.

[00:06:43] I’ve noticed two things. One, that statement that you made, which probably is,

[00:06:49] it may feel controversial to some engineers who are listening to this that I don’t care about the code,

[00:06:56] which there’s a lot of context to that. I’m sure we’ll get into it.

[00:07:00] And then the other thing that I’ve noticed about successful senior engineers is that they tend to have a very tight

[00:07:06] relationship with product managers or product owners or whatever that role is on your team.

[00:07:13] It’s essentially the person who is responsible for driving whatever that business outcome is.

[00:07:20] And those two things kind of go hand in hand. The context for I don’t care about the code is

[00:07:27] I care less about the code than I do about it working to solve this problem.

[00:07:34] I can come in and care very much about the code because especially over the long run,

[00:07:41] let’s say we have 10 problems that are stacked back to back.

[00:07:45] If we continue to write poor code, then it’s harder to solve problem number 5, 6, 7, 8, 9, 10.

[00:07:52] And so we care about the code. As a senior engineer, you care about the code because of that,

[00:07:58] not just for the intrinsic value necessarily of the code itself.

[00:08:04] And then… Oh, go ahead.

[00:08:06] Yeah, exactly. It’s like you still care about the code being good enough,

[00:08:10] but you don’t care about it being perfect because as long as it’s good enough and it’s maintainable enough,

[00:08:18] that’s what you care about because you’re solving the problem.

[00:08:20] And like you said, you still care about solving the fifth and sixth problems.

[00:08:25] So you’re more thinking about how the code sets you up for that rather than the initial perfection

[00:08:34] or textbook perfection, I like to call it, right now.

[00:08:38] The marker of a junior engineer is the inability to get past an argument about

[00:08:50] what particular tool between two very close tools are we going to pick.

[00:08:56] The marker of a senior engineer is someone who leaves their vote on the table sometimes

[00:09:05] and says that actually this is not where we need to spend our time or potentially even says we don’t need to write this code.

[00:09:13] Maybe they say, actually, this problem is the wrong problem altogether.

[00:09:17] We don’t need to write this code in the first place.

[00:09:20] The amount of time you can save by not writing code is ridiculous.

[00:09:27] That’s also why I like being involved in the earlier stages of something or of a new project is because I can…

[00:09:38] So one of the things I start to do is my manager calls it bushwhacking,

[00:09:43] is where instead of being in…

[00:09:46] I’m getting less and less involved in the day-to-day sprint work because I’m spending so much time looking ahead

[00:09:52] and working with product to get the whole project to a point so that we don’t even get tangled in the bushes or in the weeds

[00:10:00] because I already tried to clear them out because I know we’re going to get there eventually.

[00:10:05] So you can either do that by changing what you’re building, making sure you’re building the right thing,

[00:10:10] or by having those contacts with your product owners to look ahead and be like,

[00:10:15] oh, I know we’re going to be building that we’re going to be solving problem number five in three sprints.

[00:10:22] If we take that into account a little bit right now, it’s going to be a lot easier.

[00:10:27] Yeah, this all brings up a lot of both personal experience memories and stories that I’ve heard about interactions with product owners.

[00:10:38] And I’m curious, you know, when you start taking on this role of being more connected to the product

[00:10:46] or looking kind of upstream of some of the specifications, do you find yourself in conflict

[00:10:54] or otherwise feeling like you’re in some ways stepping out of your role and into more of a product role?

[00:11:03] And if so, how does that resolve with a good product manager?

[00:11:08] So I wouldn’t say I’m stepping out of the product role because at least how it works in Silicon

[00:11:17] in more Silicon Valley style companies, not necessarily companies that are physically here,

[00:11:22] is that you have this model of empowered teams.

[00:11:25] So instead of getting orders from up top that then get trickled down to the engineers,

[00:11:30] it’s more like your whole team gets an OKR or a business objective.

[00:11:35] And then you work together and to solve that business, to achieve that business objective.

[00:11:41] And the PM is considered to be part of your team.

[00:11:44] They’re not your boss. They’re not someone external.

[00:11:46] They are part of the product team.

[00:11:48] And you’re a product engineer because you work closely on a product that has an outcome for some type of user.

[00:11:56] So I don’t think you’re actually you’re not so much stepping out of the role of engineering and into product.

[00:12:02] It’s more about being a good partner and a good backup to product

[00:12:07] because they’re better at dealing with organizational complexity

[00:12:13] and coming up with ideas for features or things to try and then measuring them

[00:12:18] and figuring out if they actually solved the problem or didn’t.

[00:12:22] And they do a lot of glue work between business and design and engineering and all of that.

[00:12:29] And I think what they really need is an engineer who is able to speak their language

[00:12:34] and who understands product, has like a little bit of a business mind as well.

[00:12:40] But you still need to be very deep in the code and the code base to know to be able to tell them,

[00:12:46] hey, this isn’t possible or hey, this is going to take too long.

[00:12:51] And it’s probably not worth it.

[00:12:54] But also to be the person who says, hey, there are three different ways to solve this.

[00:12:59] They have these different pros and cons.

[00:13:02] And then the product owner makes the call on what gets done.

[00:13:07] Yeah, that makes sense.

[00:13:09] So you’re just teaming up with them in a way and trying to give them kind of surface more information for them to make decisions,

[00:13:17] but also kind of helping them see the ramifications of their decisions.

[00:13:23] If you go this way, it’s 20% more expensive than if you were to go the other way, for example.

[00:13:29] Exactly. I think it’s similar to what I imagine a relationship between a golfer and their caddy looks like.

[00:13:37] Or I watch F1 between the driver and their engineer where the caddy is saying,

[00:13:44] hey, this is what the wind looks like.

[00:13:46] This is what the stats are.

[00:13:49] Or the engineer is saying, hey, your tires are going to last another 20 laps if you do this, if you do that.

[00:13:54] But then the driver or the golfer gets the final say in whether they’re going to go for the swing or not.

[00:14:00] Yeah, that makes sense.

[00:14:03] So you’re not necessarily kind of getting out of your role.

[00:14:07] This happens to be what the senior engineer role is, is this kind of higher level thinking and problem solving,

[00:14:18] not necessarily the decision making side of things, but helping surface the correct options for a given decision.

[00:14:26] Exactly. And then when it’s a purely technical decision, I think it’s best if you make it together with the whole team.

[00:14:35] But what I’ve noticed ends up happening a lot is that the team uses you as if you’re comfortable making those calls, they let you make them.

[00:14:45] It’s like we’re going to go to Swiss or whoever and we’re going to give them these two options and they’re going to make the call between them

[00:14:54] because they are the kind of person who is also then going to take ownership if the call was wrong.

[00:14:59] They’re going to say, I messed up. And if the call was right, they’re going to say the team did an amazing job.

[00:15:05] I think that’s also an important part of it.

[00:15:08] Yeah, well, we will definitely dig into how does how does the senior engineer dynamic support and champion the team?

[00:15:18] Because it does go beyond just looking at the problem or just working with the PM.

[00:15:23] There’s other engineers are around to how do they respond to this and how what are those dynamics?

[00:15:29] I do want to ask one quick question while we’re at it, because I think this is a common scenario.

[00:15:34] It’s one that I’ve recently faced when you have a an emerging need on the product side.

[00:15:45] And it’s it’s fairly clear that there is a business case in that in that need that is at odds in some ways with what you would consider to be,

[00:15:59] let’s say, clean engineering. That’s kind of a kind of a weird term, but we’ll we’ll stick with that.

[00:16:06] The best practices engineering is at odds with whatever this business need is.

[00:16:11] What is the role of the senior engineer to try to either find which direction to go or find the common ground between those things?

[00:16:21] Oh, yes. So we could probably do a whole episode on this.

[00:16:26] But I would say that technical debt is a tool that especially in startups should be used as much as possible.

[00:16:37] And I have a really great experience to share on that.

[00:16:40] The current startup I’m at, they got to the point of being on the verge of hockey sticking with a jQuery app.

[00:16:50] And then they decided this jQuery is getting out of hand.

[00:16:53] We we need to rewrite the whole app, but we also have users banging down our door and we can’t, you know,

[00:17:01] our like our biggest problem is that we have so much user demand that we can’t keep up with the technology that we have.

[00:17:08] And they ended up hiring me as the first person as the first React person.

[00:17:12] And the dictum was basically take our jQuery app and rewrite it to React.

[00:17:19] Oh, and by the way, the business is not slowing down for this.

[00:17:22] So figure it out. And we ended up so they just raised the series A, which I don’t know how big it was,

[00:17:31] but they used that to fund more time, better, more experts that could come in and work on a code base that wasn’t that that great,

[00:17:40] because they’ve proved that the business case is there.

[00:17:43] So they had essentially a prototype and now it was time to make it more serious.

[00:17:47] And over the next year, we rewrote the whole app in React from scratch.

[00:17:54] We hired an entire React team, taught everyone who didn’t know React yet, React,

[00:18:01] and we were able to at the same time grow the company enough to then raise a hundred million dollars Series B.

[00:18:09] Wow. Yeah. So that’s my story of leveraging technical debt and it is OK and you should totally do it.

[00:18:17] Yeah. Yeah. It’s you know, I think it is definitely an art form, right?

[00:18:23] To know when is that technical debt being leveraged versus when are we, you know, just kind of writing it out?

[00:18:33] And I guess, you know, some of that comes down to again, we’re going back to team dynamics here.

[00:18:40] The quality of life, even just for the engineers who are who are having to work on on that, on those problems.

[00:18:49] We’ll get right back to our interview with Swizz right after we talk about today’s sponsor.

[00:18:59] Developer team is proudly supported by Cord.

[00:19:02] Cord is the messaging tool that gives you direct access to hiring teams inside technology companies in London, Europe and New York.

[00:19:09] It is the new way to find your next job.

[00:19:12] Cord enables what is currently not possible.

[00:19:14] A simple conversation with someone who wants to hire you with Cord engineers find work through these conversations rather than applications.

[00:19:23] The interactions and replies are meaningful, fast, direct and relevant.

[00:19:27] And the impact of the conversations that you have could change not only your career, but also the world around you.

[00:19:33] There are hiring teams inside the world’s most advanced technology companies who use Cord to hire.

[00:19:38] Including recent Y Combinator alumni and publicly listed technology companies and everything in between.

[00:19:44] Entire engineering teams are built on Cord that wouldn’t otherwise exist.

[00:19:49] Inside companies whose innovative work is enabling vaccines, tackling climate change and powering the next wave of autonomous vehicles.

[00:19:56] Learn more today by going to cord.co.tea.

[00:20:05] Thanks again to Cord for sponsoring today’s episode of Developer Team.

[00:20:15] How does the senior engineer, we’ll start kind of at a big level or a high level.

[00:20:20] What are the senior engineers responsibilities when it comes to the team morale?

[00:20:26] And specifically, I’m thinking about, you know, between kind of the difference between a senior engineer versus engineering manager.

[00:20:35] Are they would you say that that’s kind of a team?

[00:20:39] Those two kind of team up to think about morale together or where do you see those responsibilities?

[00:20:47] I think they do. They team up to an extent.

[00:20:50] I think the manager has the actual manager has a lot more time to work on team morale.

[00:20:57] And good managers usually spend a lot more time talking to the team one on one than a senior would.

[00:21:05] Because as a senior, you’re still an IC and you’re very in the weeds.

[00:21:09] You don’t necessarily have time for all of those one on ones.

[00:21:14] So I think it’s a partnership in that the manager is kind of setting the tone and the senior engineer is, you know, because you’re more in the weeds.

[00:21:26] You can you maybe not just can, but you should be loud about things that are bugging the team.

[00:21:32] Like, hey, we keep dealing with this stupid thing that’s in our way all the time.

[00:21:38] How about we go fix it?

[00:21:40] And I think senior engineers especially are encouraged to whenever you find something annoying, just at least put it on the backlog somewhere.

[00:21:50] Even better, create some time, maybe take an hour twice a week and work on those little annoying things and fix them to make the whole rest of the team faster.

[00:22:01] It’s kind of like working as a force multiplier where a lot more of your work is focused on making life easier and faster for the rest of the team than on exact implementations.

[00:22:14] Because, you know, if you spend an hour implementing something, some feature, that’s an hour you spent implementing a feature.

[00:22:22] But if you spent an hour making everyone’s day go five minutes faster and your team is 10 people or this even spreads to the whole engineering work and you’ve made everyone in the engineering work five minutes faster every day, you get that hour back very, very quickly.

[00:22:42] And I think the other thing that you do as a senior engineer is kind of steer the team out of rabbit holes.

[00:22:52] And this is where I think the difference between the senior engineer title and the senior engineer as someone with actual real world experience and a lot of battle scars.

[00:23:06] You get this sixth sense and you can say, if we build it that way, we’re going to suffer in six months, it’s going to really hurt.

[00:23:14] So why don’t we try building it this other way that I’ve seen work in other companies or just, hey, you know, I see that you’re all heading in a direction.

[00:23:24] I’ve been there before in this, like two companies ago or in this or in whatever project.

[00:23:30] And these are the lessons I learned. So we should really not go that way.

[00:23:34] Let’s try to find, even if I don’t know yet what the better solution is, at least I know what the bad ones are.

[00:23:42] Yeah, it’s funny how much of our jobs as engineers is knowing what the bad things are and just avoiding those.

[00:23:52] And if we can find something that’s less bad, it tends to be a little bit better.

[00:23:57] Yeah, exactly. Like one thing that I see a lot is it’s hard to put into words, but basically if you get the right data model or the right domain model of the problem you’re solving, everything else becomes so much easier.

[00:24:14] But it takes a lot of battle scars and that spidey sense to be able to do data modeling well.

[00:24:23] I think it’s one of those things that’s really hard to learn unless you’ve just done it a lot.

[00:24:30] I don’t think you can just read a book or take a course and now you’re better at domain modeling.

[00:24:35] It’s something that just takes a lot of experience.

[00:24:38] And that’s a really good way to force multiply your team or to just help with the team morale is to step into those design conversations and just help everyone define a better data or domain model so that they can then focus on the details or on the weeds of implementing the code.

[00:25:04] Because the part that has the biggest impact on how hard the code is going to be to write has already been solved.

[00:25:14] This is amazingly applicable to so many problems that I’ve faced in software engineering.

[00:25:22] I want to kind of stick on it for just a second and talk about how these problems that you’re pointing out like domain modeling, they come back over and over to these things that we’ve probably heard a million times as engineers.

[00:25:38] For example, one of the hardest things that we do as software engineers is name things.

[00:25:43] That’s what domain modeling is all about.

[00:25:46] It’s about knowing how to name a group of things so that it makes the most sense.

[00:25:52] And as you move forward with that, whatever that application is that wraps that model, that the model itself kind of becomes obvious, it helps kind of guide the way that it’s used.

[00:26:06] And it’s amazing how so much of this comes back to that.

[00:26:10] Many of these things come back to some fundamental truth that we learned when we were very early in our careers.

[00:26:21] Okay, yeah, we got to come up with good variable names.

[00:26:24] And I think we substituted some of those lessons rather than saying, oh, this is a hard problem, right?

[00:26:31] Naming things is actually a hard problem.

[00:26:34] It’s not just we’re just saying that it’s a hard problem.

[00:26:36] It really is.

[00:26:38] In our heads, we substituted something like, oh, that means that we can’t use names like X and Y.

[00:26:44] We need to use descriptive names.

[00:26:46] Well, no, it’s more than that.

[00:26:48] Yeah.

[00:26:49] Yeah, I think the best lesson I’ve learned from domain driven development is that naming things isn’t hard.

[00:27:00] It’s super easy once you know what you’re building.

[00:27:03] If you can’t come up with a name for it, you probably don’t know what it is yet.

[00:27:08] Yeah.

[00:27:09] Well, yeah, that’s a good point.

[00:27:11] If you know exactly what it is, I’ll give you a practical example and we can use this as kind of a way to talk about this subject.

[00:27:21] I was talking with a colleague one time about how having vague names for, let’s say, columns in a database almost ensures that those columns are going to be used for more than one purpose.

[00:27:38] Yep.

[00:27:39] So if you had a name that suggests a type, for example, but doesn’t necessarily require that type, then two different people looking at this database, they don’t know.

[00:27:55] And so the name itself becomes kind of an interface for the people who are using this piece of data.

[00:28:02] The names of those columns becomes an interface.

[00:28:05] And because it’s nonspecific, there’s a very high likelihood that the data itself is going to come in and not be normalized between those two consumers or those two customers to that data.

[00:28:20] And one of the worst problems to deal with is when you have data that looks roughly the same but has subtly different meanings.

[00:28:31] Absolutely.

[00:28:33] And that is just you are going to suffer at some point somewhere.

[00:28:37] Yeah.

[00:28:38] What’s an example?

[00:28:40] I know this is hard to come up with on the spot, but I’d love an example of that because I know there are junior engineers that are listening.

[00:28:46] They’re wanting to know one step further.

[00:28:49] Like, what does that mean?

[00:28:50] What does it mean to have data that looks similar but means two different things?

[00:28:54] I have a really good example from actually my current startup.

[00:28:58] And this is an old decision that has been following us since it’s been made.

[00:29:03] But one of the things we build is appointment booking for when you want to see a mental health provider or some sort of doctor.

[00:29:15] And there are two columns on the appointment table called scheduled time and booked time.

[00:29:22] Now, tell me what is the difference between those two?

[00:29:27] Oh, yeah.

[00:29:29] Hard to know unless you have some special context, right?

[00:29:33] Exactly. Because booked and scheduled are kind of synonyms.

[00:29:38] One of them means the actual timestamp when the appointment was created.

[00:29:43] And the other one is when it’s actually happening.

[00:29:48] And I always get confused about which is which.

[00:29:52] And so as a senior engineer, and this is where it all comes together for me, as a senior engineer, you could see this column.

[00:30:00] And I’m obviously not speaking into your situation.

[00:30:03] I’m sure there’s a lot more complication to it than this.

[00:30:05] But you could see this column and say, OK, scheduled time.

[00:30:10] Well, actually, this is appointment created at.

[00:30:16] That’s maybe a better or more specific name than scheduled time and suggest that as a design kind of refactor that makes it may seem small.

[00:30:29] Right. This is the amazing thing about these kinds of problems.

[00:30:32] So the change is small and it’s not fixing anything necessarily.

[00:30:37] Right. But you imagine all these future cognitive overhead and all of these future bugs that could come as a result of this vagueness in the data.

[00:30:48] And down the line, things are necessarily better as a result of this.

[00:30:56] Good example that I’ve come across myself is especially when dealing with the kind of data that I deal with, having a first name.

[00:31:06] Right. This is a really interesting one.

[00:31:08] Addresses are a whole or another example of this.

[00:31:13] But first name is a really good example of this, because what does that mean?

[00:31:18] What does a first name mean?

[00:31:19] Well, for most people, they say, well, it’s whatever people call me is whatever I normally put down on a form.

[00:31:25] But is it your legal first name or is it your nickname?

[00:31:29] Is it a shortened version of your legal first?

[00:31:32] What thing is it specifically and how as a result of that, what can we rely on this for?

[00:31:39] Can we rely on it just to send you a marketing email or can we rely on it if we’re looking into a workday database or something like that?

[00:31:48] And then there’s entire cultures that don’t even have first and last names.

[00:31:52] Exactly. Names. Yeah.

[00:31:55] And really funny, back to the example from earlier, in our case, it’s actually booked time that’s created at not scheduled time.

[00:32:03] Oh, yeah. So even even when you describe it, it still is confusing, right?

[00:32:09] Exactly.

[00:32:14] Thanks so much for listening to today’s episode of Developer Tea.

[00:32:16] The first part of my interview with Swes Teller.

[00:32:18] You can find links to the things that Swes is doing in the show notes.

[00:32:22] You can obviously find him on Twitter at Swesec.

[00:32:25] That’s S-W-I-Z-E-C.

[00:32:28] Thanks again for listening to this episode and a huge thank you to today’s sponsor, CORD.

[00:32:33] CORD is the messaging tool that gives you direct access to hiring teams inside technology companies in London, Europe and New York.

[00:32:40] Get direct access to hundreds of people hiring your skill set.

[00:32:44] You can send and receive messages directly from hiring teams themselves with everything happening in a simple messaging thread.

[00:32:50] There’s a calendar integration that’s built in as well.

[00:32:53] And all data is live and transparent, including salary, tech stack, interview process and response times.

[00:32:58] Go and check it out.

[00:32:59] CORD.CO.ST.

[00:33:01] That’s C-O-R-D.C-O slash T-E-A.

[00:33:04] Thanks so much for listening to this episode.

[00:33:06] If you enjoyed this first part of the interview with Swes,

[00:33:10] make sure you subscribe to this podcast and whatever app you’re currently using.

[00:33:15] And if you want to discuss this episode or anything about your career in your life with other engineers who are driven to grow and enjoy this podcast as well,

[00:33:26] you should consider joining the developer T discord community.

[00:33:29] Head over to developer T dot com slash discord.

[00:33:32] That is free.

[00:33:33] It always has been and always will be as developer T dot com slash discord.

[00:33:37] Thanks so much for listening.

[00:33:38] And until next time, enjoy your tea.

Visão de gráfico