Latest / DevQuestions with Tim Corey / 182 How Do I Establish Best Practices for a Team of Developers?

Transcript

182 How Do I Establish Best Practices for a Team of Developers? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:25
  SPEAKER_02: How do I establish best practices for a team of developers?
• 0:30
  SPEAKER_02: This is a question that's asked on a suggestion site, and it's one I think that's really important to address in today's episode of DevQuesti.
• 0:39
  SPEAKER_02: Now, this is a podcast, so if you're watching this on YouTube, you can also get on your local podcast player, wherever you use Spotify, whatever you want to do.
• 0:47
  SPEAKER_02: Or if you're listening to it right now, you can also watch it on YouTube if you want to.
• 0:51
  SPEAKER_02: Either way.
• 0:52
  SPEAKER_02: All right, so this question: how do I establish best practices for a team of developers?
• 0:58
  SPEAKER_02: This question was asked by a person who is starting up a new team or just getting together with a new team and wants to establish the best ways of doing things, like uh file naming and variable naming and file structures in your products and solutions and so on.
• 1:16
  SPEAKER_02: What are the best ways of doing that?
• 1:17
  SPEAKER_02: Because every person does it a little differently and they don't want to cause an immediate problem when they first step into leading this team.
• 1:25
  SPEAKER_02: So it's a great one to talk about.
• 1:28
  SPEAKER_02: So let's dive right in.
• 1:30
  SPEAKER_02: I have quite a few suggestions, let's go through them.
• 1:33
  SPEAKER_02: The first suggestion I have is to have the conversation with your team, but don't make it a democracy.
• 1:42
  SPEAKER_02: So if you walk into a team and say, hey, what's the best practices you want to follow when establishing the naming structures?
• 1:51
  SPEAKER_02: Well, everybody's gonna have their own opinion and to cause one big fight.
• 1:55
  SPEAKER_02: And maybe you get to a point where half the room wants to do one thing and half the room wants to do something else.
• 2:02
  SPEAKER_02: And you have to choose, but now you're causing it to be something where it's them versus you, or maybe you even side with a smaller group versus the larger group.
• 2:13
  SPEAKER_02: You need to maintain control.
• 2:15
  SPEAKER_02: So you have to be clear on what you're doing.
• 2:18
  SPEAKER_02: So have the conversation, but don't say, I want you to tell me what you want to do and we'll we'll uh vote on it.
• 2:27
  SPEAKER_02: What you want to do instead is you want to say, hey, I'm working through these things.
• 2:32
  SPEAKER_02: Is there any feedback you want to give or any thoughts you want to give before I kind of wrap these things up?
• 2:39
  SPEAKER_02: Okay, so that's the first thing is make sure you don't just make it a vote on everything because that can cause chaos.
• 2:45
  SPEAKER_02: You need to have some leadership in this.
• 2:48
  SPEAKER_02: Number two is start with industry standards.
• 2:53
  SPEAKER_02: This is a great place to start, and it's a great way to have a starting point.
• 2:58
  SPEAKER_02: When you are trying to establish or build anything, it's always great to have something to throw darts at.
• 3:04
  SPEAKER_02: Something where you can say, well, I like most of that, but I want to tweak these things, as opposed to trying to start from a blank piece of paper.
• 3:12
  SPEAKER_02: So start with the industry standards and then have a clear and important reason for anyone to deviate from one of those standards.
• 3:25
  SPEAKER_02: So if a person says, you know what, I want to use Hungarian notation, okay, that's a deviation from the standard.
• 3:34
  SPEAKER_02: Microsoft gave that a will long ago, and so has the rest of the industry.
• 3:38
  SPEAKER_02: So why do you want to do it?
• 3:41
  SPEAKER_02: Well, if the answer is, I think it's better, you've got to have more than that.
• 3:46
  SPEAKER_02: You've got to have a very clear reason why it's going to be a marked improvement in your code.
• 3:52
  SPEAKER_02: And then have that conversation.
• 3:54
  SPEAKER_02: And it may come down to that's my preference, and it's somebody else's preference not to.
• 4:00
  SPEAKER_02: And I would say, unless there's a clear reason why you should deviate, I would stick with the industry standards.
• 4:09
  SPEAKER_02: That way, when you bring someone new in, one of the benefits is they're more likely to be versed in those industry standards and have an easier time conforming to your standards.
• 4:20
  SPEAKER_02: Okay.
• 4:21
  SPEAKER_02: Next up, keep it simple.
• 4:24
  SPEAKER_02: You can go into great depth on laying out exactly how you're going to create every little thing and how you're going to design every little thing.
• 4:33
  SPEAKER_02: Don't do that.
• 4:34
  SPEAKER_02: You don't want to have a 30-page, 60-page, 100-page document that describes every particular best practice you're going to follow.
• 4:43
  SPEAKER_02: Try and keep it simple.
• 4:45
  SPEAKER_02: Keep it as clear as possible, as few identifications as possible while still covering the majority of things.
• 4:54
  SPEAKER_02: Allow for some deviation at the edges, because you know what?
• 4:59
  SPEAKER_02: Life is messy.
• 5:01
  SPEAKER_02: But try and keep the overall idea simple.
• 5:04
  SPEAKER_02: And then clearly document it.
• 5:07
  SPEAKER_02: And if you start getting into documentation, go, wow, there is so much document, maybe you've done too much.
• 5:14
  SPEAKER_02: Okay?
• 5:14
  SPEAKER_02: So try and keep it limited.
• 5:16
  SPEAKER_02: And then even after you've done that, even after you've gone through all the pain of trying to figure out what you're going to do and maybe even arguing over what best practices to deviate from all the rest, and you've you've kept it simple and you've documented it, you're you're done, right?
• 5:31
  SPEAKER_02: Well, no, you're not.
• 5:33
  SPEAKER_02: Because like anything else in software development, it's going to probably change over time.
• 5:38
  SPEAKER_02: You're going to have some things where you go, ooh, we didn't think about that.
• 5:41
  SPEAKER_02: Let's make a change.
• 5:43
  SPEAKER_02: And that's the next point is to be open to change.
• 5:47
  SPEAKER_02: Be open to the ability to not allow this document to chain you down, but instead to free you.
• 5:56
  SPEAKER_02: So that when you when it makes sense, it helps keep you in the same groove.
• 6:02
  SPEAKER_02: And when it no longer makes sense, you're okay to make a change.
• 6:06
  SPEAKER_02: Okay.
• 6:07
  SPEAKER_02: So make sure it's not a ball and chain, but rather something to free you up to do things well and not to think as much about what standard to adopt.
• 6:19
  SPEAKER_02: But instead, here's the simple way we do things.
• 6:22
  SPEAKER_02: Okay.
• 6:22
  SPEAKER_02: But then when that doesn't become simple anymore, or there's something better, you can make that change if you decide it's necessary or beneficial.
• 6:32
  SPEAKER_02: And you know what?
• 6:34
  SPEAKER_02: Last point, don't stress out about it.
• 6:36
  SPEAKER_02: This is something where this is not the end of the day.
• 6:39
  SPEAKER_02: I mean, this is not the end of software development if you don't get it right.
• 6:43
  SPEAKER_02: Nothing in software development do we get right the first time, or ever.
• 6:48
  SPEAKER_02: Instead, when we try to embark in software development on a new project, we always say, hey, what would be the perfect project?
• 6:55
  SPEAKER_02: You try to aim for that, but we never achieve perfect.
• 6:59
  SPEAKER_02: What we achieve is good enough, close enough that it's acceptable.
• 7:07
  SPEAKER_02: But there's always more to do.
• 7:08
  SPEAKER_02: There's fix, you know, bug fixes to implement, and there's new features we didn't have time to implement, and things that now that we're done, we look back on and go, ooh, we should do that differently next time.
• 7:19
  SPEAKER_02: These are all part of software development.
• 7:21
  SPEAKER_02: So why wouldn't they be a part of our design standards?
• 7:26
  SPEAKER_02: So when you're thinking that through, don't stress because it's going to change, and that's okay.
• 7:31
  SPEAKER_02: Remember, be open to change.
• 7:33
  SPEAKER_02: So those are my thoughts.
• 7:35
  SPEAKER_02: Um, those points again are have a conversation with your team, but don't make it a democracy.
• 7:40
  SPEAKER_02: Start with the industry standards, identify and agree upon any reason for a deviation, keep it simple, document it, be open to change, and don't stress out about it.
• 7:52
  SPEAKER_02: All right.
• 7:53
  SPEAKER_02: So those are my thoughts on what to do when you first get together as a team to identify how are we going to build software going forward.
• 8:01
  SPEAKER_02: All right, thanks for listening, and as always, I am Tim Corey.
• 8:05
  SPEAKER_01: Thank you for joining us for this episode of Dev Questions.
• 8:08
  SPEAKER_01: Tim is committed to making it easier for you to become a developer.
• 8:11
  SPEAKER_01: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 8:19
  SPEAKER_01: You can also send your questions to questions at IamTimcore.com.
• 8:24
  SPEAKER_01: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 8:31
  SPEAKER_01: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.