[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today we’re talking about what it means to be a part of the software development life cycle with Cliff Craig, Senior Software Engineering Manager at Samsung.

[00:00:21] CC: So it’s really a process of divide and conquer. Like you take the big picture and break it into slightly small boxes and iterate on each one of those boxes and each one of those boxes would be assigned to a specific leader.

[00:00:32] SY: Cliff talks about getting into software engineering over 22 years ago, why it’s important for developers at every level to understand the software development life cycle, and what the major stages of the software development life cycle are after this.

[MUSIC BREAK]

[00:00:56] SY: Thanks so much for being here.

[00:00:58] CC: Thank you for having me.

[00:01:00] SY: So Cliff, you’ve been a software engineer for a couple decades, 22 years. And you’ve worked at some well-known companies like Microsoft, Apple, GE, even MapQuest. Shout out to MapQuest.

[00:01:11] CC: I like the smell of a fresh printed map.

[00:01:14] SY: And now you’ve been at Samsung for a couple of years. When did you first get into coding?

[00:01:19] CC: I’ve been coding ever since I was six years old, off and on.

[00:01:22] SY: Wow!

[00:01:23] CC: Yeah. My first experience was when my father got us a video game, the Intellivision II, I think it was, and had this computer attachment and you can kind of plug it in like a keyboard. You can steal graphics from a video game and write code in BASIC. So that’s kind where I got my beginning. I was trying to make my own video games.

[00:01:41] SY: And did you study computer science?

[00:01:43] CC: No, I’m mostly self-taught. I did take a class. I went to tech school, Seton University in New Jersey for like two and a half, three years.

[00:01:52] SY: And how did you end up going from that passion, that really early interest to actually landing your first job?

[00:01:58] CC: I got lucky. I always say I was blessed to have this career and to be where I’m at, at this point in life. I was working as a file clerk in a temp agency as a temporary job, seasonal kind of deal. I think I was on a six-month assignment or something like that. I can’t remember. It’s so long ago. I have been in tech school, of course like I said, Seton Institute, and struggling. Like I was in a very, I guess, you can say precarious part of my life, where my ex-wife was pregnant with my oldest daughter at the time and I was scrambling trying to find a full-time job. And I’ll never forget. I was sitting down at this temp agency and my job there was just to stuff envelopes and file cabinets and file things. Like I was working in the mail room. And one of the women, I guess, took pity on me and wanted to give me some busy work and sat me down. She gave me an Excel Spreadsheet, like hundreds of addresses, and then a Word document with this template of like stickers they want to print. And she wanted me to type the addresses from the Excel Spreadsheet into the Word document. And she thought that it would take me the better part of my remaining tenure there to do it, and I have knocked it out in like 15, 20 minutes because I was studying Office at the time. They just so happened to be teaching us Office automation at my school. And I think it was called a mail merge. And she was like, “How did you do that in so little time? I thought I was going to take you like days, weeks.” I was like, “No, I just did a little mail merge.” I explained it to her. And then from that point on, she introduced me to the engineering manager there and he took a liking to me. He interviewed me and asked me what my passions were, reminisced about kind of like what you did, how did you get into a program that’s from the same store? Well, video games. I want to build my own video game one day. So he shot me around trying to get me hired at different places before he eventually decided to hire me himself. And he hired me on the same day that my daughter was born. So that’s how I know how long I’ve been in the industry. She just turned 23 last December.

[00:03:49] SY: Oh, nice.

[00:03:50] CC: So I’ve been in the industry for over 23 years. Yes.

[00:03:52] SY: Wow!

[00:03:54] CC: Happiest day of my life. I got my new career.

[00:03:57] SY: For two reasons. Yeah.

[00:03:58] CC: Yes. Yes.

[00:03:59] SY: So you got into software engineering back in the ’90s then, it would be…

[00:04:04] CC: Yes.

[00:04:04] SY: When the industry was really in its, as far as like web stuff especially, in its early stages, and also even more socially homogeneous than it is even now. What was it like being in this industry as a person of color in those early days?

[00:04:19] CC: Oh man, it wasn’t. Like I got lucky. I was the only person of color in the room for the majority of my career. It wasn't until most recently that I actually saw other black people in the industry and I’m like, “Wow, you guys actually exist.” Be on sites like Twitter and being able to communicate and network with people, Black Tech Twitter is a thing. I’m starting to find all these different resources for people or not just black people, people from different walks of society, every walk of life, all different types of people looking for the same thing, wanting to getting to software engineering and trying to get their start.

[00:04:53] SY: What was that experience like for you not having that community for most of your career? Was it isolating? Was it alienating? How did that feel?

[00:05:02] CC: It was definitely isolating and alienated. I did feel alone, but I was driven because I’ve always had this passion for software engineering. I love computers. I love tech. So there was nothing that was going to stop me. If anything, I felt more motivated to do more. There were specific moments in my career where I felt singled out or even looked over or passed up on because I would be, of course, the only person of color in the room. And early on in my career, I was sometimes doing the most, doing too much, you can say. And there were moments where I felt like I should have been out shining the efforts of my coworkers, but I wasn’t. I wasn’t given the recognition that I felt I deserve. But through the years, I’ve learned to grow with that. I look back on those challenges as opportunities now.

[00:05:45] SY: So now you are at Samsung. And when I think of Samsung, it definitely, I think more hardware than software, just because I think of like the phones and the devices and that sort of thing. As a software engineering manager, what kinds of things do you get to work on?

[00:06:00] CC: So right now, I’m working on TV ads. We work as an ad campaign manager and we build the whole ad experience on the Samsung smart TVs and our division is also responsible for putting ads on mobile devices, desktop.

[00:06:13] SY: Oh, cool.

[00:06:13] CC: Our responsibility has expanded. We started off just doing TV ads. It was actually started from a small group of developers. We built a business out of nowhere. Like I’d say about six or seven years ago, this business did not even exist and we grew it into like a multimillion-dollar business in like a span of a few years now.

[00:06:29] SY: Wow. Nice.

[00:06:29] CC: So It’s been an interesting story.

[00:06:30] SY: It sounds like it has such a big business impact as well.

[00:06:34] CC: Oh yeah, absolutely. We’re putting new experiences on the smart TVs. The biggest compliment that we get is people buy our smart TVs and they see our ads and they don’t recognize them as ads because they look like part of their natural content that’s part of the interface.

[00:06:49] SY: Very cool. So out of the 23 years that you’ve been in tech, what would you say has been your most favorite thing that you’ve been a part of building?

[00:06:59] CC: I love to tell this story. It sounds far-fetched, but way back in 2008, I believe, when iPhone App Store first came out and back then I was experimenting with voice to text and text to speech and I actually built like a Siri prototype and had it working on an iPhone. I think it was an iPhone 3G.

[00:07:17] SY: That’s cool.

[00:07:18] CC: This was before Siri’s release. I was working on this technology from way back.

[00:07:22] SY: Wow. Very cool. So because of your wide-ranging career working at so many different companies, different types of technologies, I feel like you’re such a great person to talk to about the overall development life cycle. So let’s zoom out and define what we mean by development life cycle. How would you define that? It’s a cycle that comprises your planning, your analysis, your design, your implementation phase and maintenance. It’s really a cycle of, I would say, through those different phases, when you’re implementing software, when you're building some sort of software-based solution. And it encompasses everything we do in industry and software engineers. And we don’t really think about it, but no matter what company you’re working at, no matter what platform you’re working on, we all follow the same cycle of planning, analysis, design, implementation, and maintenance.

[00:08:14] SY: So you’ve worked at big companies for sure, huge, huge companies. And I feel like, if I were to imagine what the development life cycle would look like at those companies, it feels like there’s probably a lot going on. So break that down a little bit more for me. You mentioned kind of the steps very briefly, but if we can dig into that a little bit, unpack some of the major steps of the life cycle and then maybe some principles and core concepts that’s helpful to know.

[00:08:43] CC: I think it actually makes more sense to kind of ask why is it important to know what this life cycle is. And I think it’s important because of the different phases, it’s important to know which stage you’re in. For example, if you’re in the implementation phase and you haven’t done enough planning, then you’re doing something wrong. A lot of times you might be in the planning phase, and this is very common, especially when you're doing your sprint planning and you have a bunch of engineers talk about a specific technology solution. They’re in the implementation stage. In their brains, they’re coding the solution real time when you’re supposed to be planning. So I think a very important part of the SDLC, Software Development Life Cycle, is knowing which phase you’re in and acting accordingly. So planning is all about, I guess you could call it like the requirements gathering and everything, and it’s important at that stage to have the right kinds of discussions. You want to ask the right question. What are we building? Because a lot of times software engineers go into this body, they obsess over details, over the technologies and tools and you don’t even sometimes know what it is we’re working on. I’ve had so many interactions with developers over my career where they don’t know how they fit in in the organization. They just know, “Oh, I’m just a Python coder. I’m working on this little solution,” Or, “I’m a Java guy. I got this little quirk thing, this little vibrate, but I don’t know how this fits into the bigger picture.” So it really helps to have a big scope of outside zoomed out view of what it is you’re building. It also helps to know what the business need is. I like to ask the right questions. Like, “What is the need? What is the actual pain point that we’re trying to solve? Are we trying to automate some sort of manual set of steps? Or are we saving the business money by implementing a solution?” Like a value add basically. When you recognize my SCRUM master will love me for this. Having a value added statement in your Jira tickets, you always get something. Yeah. What is the value added? So you want to make sure you’re adding business value when you’re doing requirements gathering.

[00:10:34] SY: What I’m hearing you talk, it sounds very similar to product development. What is the difference between product development principles, concepts, and the software development life cycle?

[00:10:47] CC: So product development is different because you’re dealing with a physical product. Software is different because software, sometimes it could be ephemeral, it changes and it adapts and it follows a different life cycle basically. You can update software in a way that you can’t update a physical product on a shelf, basically. You can just zap and update over the web and update millions of clients and not lose a sweat or you can deploy software and continue to make money over time without you having any additional effort. But it’s very similar in a way that you’re still going through the same stages. Difference with software development is the implications of getting something wrong can be catastrophic because everything you do in software expands exponentially basically. So if you release buggy software, it can impact millions of users. It could take out an entire company from a buggy update.

[00:11:41] SY: Who is responsible for the different phases of the life cycle? Like, for example, when you talk about identifying the need, identifying a pain point, a PM comes to mind, for example, or maybe someone on the marketing team or the sales team. It doesn’t necessarily scream engineer to me in terms of figuring out what’s the problem. Value add is kind of similar. These seem more business-y questions rather than kind of technical questions. And so I’m wondering when you think about the different roles that are involved in the software development life cycle, beyond the software developer, are there other participants and other people that play a role in that journey?

[00:12:20] CC: Yeah, there are definitely key players in each stage of the phase, but I believe the entire team should be involved in every stage basically. When you’re in the planning phase, of course the product owner or the PM has the biggest voice. He’s the one who’s calling the shots and deciding the direction. He’s identifying the business need, calling out pain points, defining the strategy, building out the roadmap. And then when you go into the analysis phase, then you typically have like analysts. But going back to planning phase though, you still need your team members. You still need your developers in that phase. Going back to those important questions I was talking about earlier because you want to be able to ask those pertinent questions. What are we building? What’s the need? What’s the business value? That’s part of your requirements gathering, but there’s also something like I talked about which is anti-requirements. And these are the questions that we sometimes forget to ask. Why are we building this? What is the cost of building this? Most times when we’re building some sort of solution, there’s a cost. There’s a financial cost. There’s a cost and time and money. That may be Kubernetes pods and infrastructure to stand up, cost to business in other ways. You want to understand that cost correctly and then you want to ask the question, “What is the impact?” it’s like a negative value. “What’s the impact if we don’t? What if we don’t build this?” This is something that we absolutely need to build. And you’d be surprised sometimes that some of the best solutions don’t require technology. And you wouldn’t know that unless you are a technologist. Sometimes if you use your skills as a software engineer to not write software, you can add in more value than you would be by coding a solution. And it’s very easy for developers to get trapped in that too because we tend to love our tools. We love our IDEs. We love writing code and it’s the most difficult thing to tell a developer not to write code. The best code that you write is a code that you didn’t write basically. Because it’s easy to do. It’s easy to do.

[00:14:11] SY: Or the code that you deleted.

[00:14:13] CC: Exactly. Exactly. Exactly. And sometimes, it might be something that a product owner has or a business stakeholder has some vision of something that they need, and it’s not necessarily the most important thing, but you hear something or a buzzword that reminds you of some sort of cool technology you want to implement or play with. So you might be the biggest person in that room trying to drive the discussion to a highly, heavily, over baked solution because you want to play with your cool toy. You want to play with the latest Next.js. So you want to play with the latest, greatest back-end Erlang or Ruby Rails, whatever, and you’re so passionate about building the solution that you lose sight of the business direction. So does it really need this over big solution? Or is this something very simple that doesn’t require technology that can solve the problem?

[MUSIC BREAK]

[00:15:20] SY: Okay. So let’s dig into the different phases. We have planning, designing, developing, testing, and deploying. When it comes to that planning phase, you talked about how really important it is to figure out what are we doing, why are we doing it, do we need to do it at all. And if we do need to do it, does it require a technical solution? What is the engineer’s role in that planning phase? What is the developer doing? What do their tasks look like to contribute to that phase in the cycle?

[00:15:48] CC: So the engineer-developer’s role is critical because they translate human thought into technology solutions. So people think a certain way and machines think differently. So they’re able to bridge the divide and connect the dots, identify the specific pieces of technology that might play a part in the solution, estimating the amount of time that would take potentially to build out a specific solution. And they would work in collaboration with the product owner to decide whether or not do we need technology, do we need solution A or solution B, or maybe there’s a solution C that’s a hybrid between A and B and some sort of compromise. So the technologist, the engineer is very critical in those discussions because they have that insight. They know what tools to use, how to use them, how to connect the dots and they can help identify the potential costs to business along with the net value added. So how much is the business going to put out to build the solution? How much value is it going to add long term? How soon can we get to market with the solution?

[00:16:50] SY: Okay. So in this stage where we’re doing more translation than maybe actually coding, what tools are we talking about? If I’m a developer and I’m working in this stage of the cycle, am I like writing a memo? What does that actually look like in terms of the tools that I’m using?

[00:17:09] CC: It’s different, depending on different companies. Some companies have heavy upfront planning where they build out their roadmaps. They have like what you call your engineer manager that works with the product owners, kind of estimates what the roadmap is going to look like for the next quarter, for the next half, and then they take it to engineers and architects and they get into a room and they decide and start going down a little bit deeper and try to figure out what the actual implementation might look like in which tools they would need. But in the beginning of the planning, it’s mostly maybe Figma documents, some rough drawings, Jira, any kind of planning tool, something that kind of helps you, a lot of Google Spreadsheets, whatever, Google Docs. It’s mostly a presentation base. You’re doing the requirements gathering. You’re laying at the vision. This is what I see us building. This is the need that we’re trying to fill. This is the market that the company is now trying to get into. We’re trying to take advantage of this new opportunity that’s emerging and find the vision. So there’s not a lot of technology involved in the planning, in requirements gathering. It’s more or less getting the big picture, getting a scope of what we need to build if we want to build it basically, pros and the solution. Then when you move into the later phases, which is your analysis, that’s when you’re getting in the room with your engineers and your architects and actually doing the grunt work of prototype. Sometimes there’s some prototyping involved and it depends on what it is you’re building. Are you building front-end solutions? Are you doing a mobile? Are you doing something for smart TVs? Are you doing something with some machine learning? There’s some analysis that’s involved in there. And then you would eventually move into the design phase. And then your design phase, you would have tools such as wireframes and Figma. You would have some pixel perfect diagrams that your UI designer put together. You discuss it. That would be more for front-end development. But if you’re more in the back end, you’d have some system architecture diagrams, cloud layout, different microservices talking between one another. You have maybe a Kafka message bus. You have some DB schema authentication, data flow, things of that nature. Again, you’re doing diagrams and whiteboarding and you’re doing the analysis and trying to fit the big picture into slightly smaller boxes. And then your architects and your tech managers, your project leads would take those slightly small boxes and break them up even further. And that’s kind of what this whole picture looks like. When you talk about the software development life cycle, it’s actually comprised of several mini cycles. Each one of these phases has its own cycle in and of itself. So for example, I’m an architect working at one of these big companies and my job is to build the back end, that’s a big box. That’s a part of a bigger picture. So that I’m going to take that box and break that down and do my own little requirements gathering and wireframes and diagrams and break that down into pieces and then give it to my team leads and then have them carry out the vision. So it’s really a process of divide and conquer. Like you take the big picture and break it into slightly small boxes and iterate on each one of those boxes and each one of those boxes would be assigned to a specific leader.

[00:20:11] SY: Yeah. Because one thing I was thinking about when I was imagining and envisioning these five different phases is it feels very linear. Even though it’s a cycle, it feels very linear and it reminds me of kind of the waterfall style of product development that was really popular many years ago. And now we’ve moved after that to kind of agile. And I’m thinking about the common thing that happens at a lot of companies, depending on the size of sprints, two week sprints, deploying. I mean, some people try to deploy every day, every week. When you are trying to work at that level of output where you’re trying to deploy as frequently as possible, much more responsive and maybe not spending as much time, how does the software development life cycle change to reflect that kind of more, at least it feels to me like in a more aggressive timeline? How does that fit in?

[00:21:11] CC: Yeah. So that’s a very good question. So it does definitely take a transformation once you’ve gotten your slightly small box in your TV and you jump into a sprint, now you’re iterating. You’re taking a small piece of that vision and you’re carving it out into something that can fit in a two-week cycle. You’re doing a little bit of planning. Like that much, you do a sprint plan where you decide how many tickets out of your Jira system you’re going to work on within this sprint and you’re going to iterate. And the important part of this is being able to be agile and be adaptive, adaptive to change. Because as you’re working, the direction and the vision might shift and the business might shift directions and that’s why you want to be able to focus on just the simplest thing. You don’t want to look at the big picture. You want to do the simplest thing to get you the next. You want to have a milestone basically, work toward a tangible, achievable milestone, something that you call a smart goal or something that’s specific and measurable and attainable, something that you can say, “I can do this one piece of the puzzle,” basically. I can release this login screen or I can release this reporting page basically, and it doesn’t have everything in the big picture. It just has the smallest part that I can iterate on. And I’m doing something that’s very dynamic and I’m working in a cycle. So you get down into the actual tools that we’re using now. Now you’re talking about actually writing code. One of my favorite tools to obsess over is, of course, source control. You want to be able to integrate your changes with other people on your team. So you have to know a little bit about source control and how to merge changes and deal with conflicts and also how to test the software both locally and in production and also in a staging environment. So you’re going to need a few tools basically. So you’re going to need a staging environment, some place where everybody can combine their efforts and deploy it and test. A staging environment is something that’s supposed to be as close to production as possible without actually being in production. Then you have your production environment. It’s the actual platform or the location or the device or devices that your application will run on. So you’re going to need those two at a minimum. And then you’re also going to have your developer workstation, which is where you do your local testing. So it really becomes a process of now I have this objective, this small piece of the puzzle that I’m going to work on, and I’m going to implement something locally and have two more people on my team that are working along with me. And we’ve divided this idea into a couple of pieces. I got my piece, these other people have their pieces. How do we collaborate with one another? How do we integrate our changes? And I advise people to get comfortable with source control because that’s one of the most painful points of developing is when you’re trying to check in code. So my CRAB was all over your code. You always had developers squabbling and arguing. “Oh, so and so rewrote our code yesterday. I had a solution. I stayed up till 10 o’clock working on it. I just got it right. And this other person came in. They tripped over my changes.” So really understanding how to commit early and push often. I always follow that philosophy. Commit early and push often. Always push code to remote repositories so everyone can benefit and see what you’re working on. That way, if you’re going in a direction, you can explain your direction and you can explain the challenges and people can collaborate a lot easier. A lot of times as engineers, we tend to work in isolation. We don’t like to work with other people. Let me just build this whole thing in my head the way I envision it and then push it all at once and hope it works, but that’s not the right way to do it. The best way to do things is, again, breaking that one piece into smaller pieces. Even your piece that you’re working on, you have to work on a smallest portion of that and push it. Maybe it’s just putting a button on the screen, get that coded up, push it to the remote repository, even open a pull request, a work in progress pull request to show people, “Hey, I got this working.” And what that does is a number of things. It’s building transparency and trust with your team. They know what you’re working on. They know where you’re going. They know which challenges you’re facing. It also gives you a safety net. I can’t tell how many times developers have lost code. “Oh, I worked on it. It was working on my machine, but I don’t have the code because my dog bit my laptop.” If you commit your code often enough, you can’t lose code when you commit to Git. Git is peer to peer. A lot of people don’t realize that because it’s peer to peer nature, it’s very hard to lose code in Git.

[00:25:33] SY: Yep. Yep.

[00:25:33] CC: If you commit and push, then every developer is pulling for a repository, has a copy of your entire commit history. Even if you delete a bridge from the remote, that bridge exists on everybody else’s laptop.

[00:25:45] SY: Okay. So commit often, that sounds like that’s a pretty important principle or concept to keep in mind during the development life cycle. What are some others? What are some other things that really contribute to going through that life cycle smoothly and effectively?

[00:25:59] CC: I am a heavy advocate of test-driven design and designing from outside in. So really focusing on your requirements, you have mono tools nowadays. Back when I started, test-driven design was in its infancy, yet things like JUnit and JUnit Test and then you have more advanced testing frameworks, you have your Seleniums, your Cypresses, your BDD frameworks. Your tests can be expressed as specifications. And I like to encourage developers to work from a specification and really understand what is… it goes back to the beginning, like, what it is you’re building. If you don’t what you’re building, how do you know you got it right? And you don’t know what you’re building, unless you ask the right question. So when we’re developing, sometimes we’re working from the inside out. We’re talking about the implementation, the nuts and bolts, the low-level database schema and tables and columns that we’re going to put the data in and we haven’t even asked the right question. Who’s giving us the data? Where is it coming from? What is the use case? What is the data flow? What is the UI flow looking like? What are the interactions with this back-end API that I’m building? If you don’t obsess over those questions, then how do you know you’re building the right solution? That’s one thing, commit early, commit often. Always start from the outside spec. Always visit your spec. Make sure you’re working on the right pain points, right problems. You’re not inventing your own problems because it’s something that happens often. We write software for the sake of software. So try to avoid working in a bubble. Always come up for air, I guess you could say.

[00:27:26] SY: I think what’s really interesting about this process is it’s almost a separate skill set to coding, right? As an engineer, especially as a new developer, an early career developer, you are trying to learn just how to code, just trying to figure out how technology works, how to write good code and how to write code that is going to be effective and helpful. Now it sounds like I have to learn how to write that code within this framework, within this structure, this process, so that I’m not just writing useless code or code in a vacuum, but I’m actually helping solve a business problem, right? I’m helping to solve a product problem. As a new developer, as an early career developer, how do I get that practice? How do I understand the software development cycle as part of my technical education?

[00:28:19] CC: Actually the easiest thing to do is to pay attention to who’s speaking in the room and actually pay attention to where the business is going. Figure out what problem it is we’re trying to solve. Listen to your product owners. Listen to your QA engineers. Pay attention to them because they have the division. They know exactly what needs to actually happen. Don’t obsess so much, and it’s hard for an engineer, especially a new engineer to pull away from writing code. But if you obsess too much over the details, you get frustrated and you get kind of stuck in a cycle of almost like imposter syndrome. I see everybody else making progress and I don’t know what I’m doing. I’ve been spending all this time, all my effort, trying to get this one button lined up and the CSS just isn’t working out right and I’m frustrated. But if you could just pull away from that and some of the simple paths I was explaining, share your code. Develop in transparency. Be so opaque. Share your pain points. Speak up in your meetings, daily standup, so specifically for that reason. If you’re having a block or if you’re having trouble, raise your concerns. Getting back to, “How do you write with all these different ideas and concepts?” We’re talking about, I mean, writing a code right, but writing the right code basically. You want to get the right code if it’s the solution and that focuses so much on getting the code right basically.

[00:29:36] SY: It also kind of feels like the kind of thing that might be hard to learn on your own. It feels like the kind of thing where sure I can read about it, but it’s always going to be very theoretical until I’m in the room with the PM, with the manager, with the marketing person. You know what I mean? Like with the right people and I’m immersed in that business problem, I’m immersed in the user’s needs, and it sounds like something that’s kind of hard to get good at totally on your own before you start a job. Is that fair to say?

[00:30:07] CC: It is. I would suggest getting a good mentor, finding a good mentor, somebody you can partner with and kind of help guide you through the process. Some of the things I suggest people look at is their Git history. Look at the changes that have been committed, the pull requests that have merged to kind of follow what other people have done on the system, in a project. That’s a good way to kind of adapt to the general team’s development philosophy. Pay attention to other engineers in the room. How are they addressing problems? How are they coming to the solutions? And really just being more of a listening ear, using your ears basically, listening to what’s going on and being attentive to what’s happening in the room. You don’t have to be the sharpest engineer. You don’t have to be the best with technology to fit in. As long as you can identify a gap or a hole. And it’s very easy to see. If you kind of come up for air and pay attention to what’s happening in your meetings, you can kind of see where the needs are. And it’s very obvious because sometimes the biggest holes are the places that the most senior engineers steer away from. They don’t do the mundane tasks of documentation or bug fixes. And that’s where you can as a junior engineer dive in and actually add the most benefit. It sounds like a burden. It sounds sucky, but it actually does help build your career. It helps get you familiar with the system. It helps you get familiar with the errors and how things go wrong when they do go wrong, what to look for when the system crashes, how to prevent it from crashing. You get a history of, “Oh, we had this component writing incorrect data to the database and it went downstream and it caused headaches downstream. Maybe I should put some more validation upfront or maybe we should talk to the back-end engineers and tell them that they need to find their contract a little bit better. Their APIs are different than what we’re building on the front end. Can we have that communication?” That right there doesn’t involve technology. That just involves paying attention to patterns. We keep having same errors coming up, these same system problems, what can I do to help? Can I just have a conversation with somebody? I don’t have to write around a code, but I can solve a true business need by having a conversation.

[00:32:15] SY: Coming up next, Cliff talks about where the role of engineering manager and direct report exists within the software development life cycle and how you as a direct report can make sure you’re aligned with your manager’s priorities and make the most impact after this.

[MUSIC BREAK]

[00:32:42] SY: So I want to switch gears a bit and talk about being an engineering manager. Tell me about what that role looks like in the context of the development life cycle.

[00:32:52] CC: Yeah. So being an engineering manager is remarkably different than being an engineer. I still have had my issues or trouble pulling away. I love to write code and sometimes I feel like I tend to micromanage my engineers. So it’s hard for me to step away, but an engineering manager, my role is to kind of arrange the chairs in the office, make sure everybody’s comfortable, make sure everybody’s got work on their plate, working on the right stuff. My job is to build a roadmap, to come up with the technical roadmap, helping our product owner. I kind of fill that gap, the divide between the product owner and my engineers because the engineers mainly talk in ones and zeros and the product owner talks about high levels. So I need to be that voice that says, “Hey, when a product owner says this thing here in a meeting, he’s really talking about these three systems. Are these three API calls you need to make?” Almost like a team lead, defining a direction, a technical direction, helping with the technical direction, make sure you’re focused on the goals, building employee goals and objectives and performance evaluations. I’m kind of building the technical roadmap for my engineers and giving them a place to thrive, giving them a direction to go and helping them to build their career basically. My job was to build the career of my employees basically.

[00:34:05] SY: So as a direct report, as an engineer who has an engineering manager, what can engineers do, particularly in that relationship, in those one-on-ones, in those meetings with their manager to really make sure they are making the most impact at their jobs, making sure that they are aligned and have the same priorities in the development life cycle?

[00:34:29] CC: So that alignment is critical and it’s really about being transparent of where you’re suffering and not trying to hide things. I’m having trouble getting code to production on time. I’m having trouble with completing my tasks because maybe the machine’s slower, maybe I don’t really understand the technology or maybe my computer is disconnecting when I’m in these Zoom meetings and I can’t hear what’s going on in the room. Or maybe I just need more mentorship in a specific area and not being ashamed to hide that. Also, paying attention to what your manager needs. Sometimes as an engineer manager, we get bogged down with a ton of responsibilities. Anything from sometimes prototyping some code to architecting some solutions on our own and helping build the roadmap and hiring new headcounts, managing new headcounts, and making sure people fit in, making sure people get onboarded correctly. We get bogged down. So you might have an opportunity to say, “Hey, I’ve been working in this section of the system. I could take so and so and help partner with them and help them build that.” Come up with solutions. As a direct report, you can sometimes solve problems just by paying attention to your manager’s pain points and see he or she is struggling.

[00:35:39] SY: So let’s say we’ve convinced our audience that these concepts are really important for them to learn and understand, that they should immerse themselves in the development life cycle to make sure that they are contributing to their teams well. What is the best way for them to dig into all these different topics A little bit further? If they wanted to do some additional reading, some more understanding, are there resources that you might recommend or ways that they might be able to dig in and unpack some of this information?

[00:36:09] CC: There are different resources. Like I’ve been watching some YouTube tutorials on like test-driven design and system architecture. Fireship.io, I think it is, it’s a channel I’ve been subscribed to, and they give these like 90-second tutorials on all the latest and greatest technologies and techniques. Udemy courses, LinkedIn Learning. Technically just looking for articles online. Be connected to other individuals in the community, places like Tech Twitter, finding other people who have been down that road before and partner with them and talk to them and figure out how do they get to that level. Network with people. Build a network of decent people and contribute and help solve problems.

[00:36:53] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Cliff, are you ready to fill in the blanks?

[00:37:00] CC: Absolutely.

[00:37:01] SY: Number one, worst advice I’ve ever received is?

[00:37:05] CC: You have to look out for yourself. I say that because it comes from a spirit of distrust and fear and also a spirit of selfishness. And especially as a black person, you hear this often, like nobody’s going to look out for you. Things are going to happen that are outside your control. And I do get that. Sometimes you can be at a disadvantage, but that does not mean that you have to quit on humanity. I’m an advocate of helping other people.

[00:37:33] SY: Number two, best advice I’ve ever received is?

[00:37:36] CC: I had this guy early on in my career tell me this. And he said, “It’s not your time yet.” So early on in my career, I was having trouble. I felt like my voice wasn’t being heard. I felt like my contributions weren’t being recognized. The only person of color in the room, I felt like my contributions were less valued in other people. And I was doing a lot. I was doing a lot of extra stuff back then earlier in my career. And I got upset. I never forget when he told me this because I was almost in tears. I was working on this project. Again, it was like old school S100 programming and I was doing all this stuff, these full kind of like Excel Spreadsheets in SQL and everybody else is writing these Legacy ISAM record locking, RPG programs. I was able to dig in and grab chunks of data and do all kinds of weird data manipulation and combining that with Java. I was doing crazy stuff basically. And he recognized where I was going and told me it’s not my time yet. I didn’t understand where he was coming from when he told me that. But later on years later, I looked back, I realized I was trying to do too much. Years later, fast forward years later, I realized that yes, I did have raw talent, but I was looking for credit rather than trying to credit other people.

[00:38:49] SY: Number three, my first coding project was about?

[00:38:52] CC: My first professional coding project would be a parts of inventory project. I was working at a lighting fixture company. It was a client server program. It was a VP4, VP5 program that would use, I guess, OLE DB or ODBC to connect to an RPG midrange server and bring inventory from the database and bringing into these full color desktop Windows. It was a Windows program. And I didn’t know much about installing software in Windows. I was early on in my career. I was using these COM and COM+ building applications and getting it wrong, but it got close enough to the point where it looked interesting enough where I went from being an hourly employee at my first job to being a salaried employee. They really were shocked with the stuff that I was able to do in a short period of time there. So I started building my career from that point on.

[00:39:43] SY: Number four, one thing I wish I knew when I first started to code is?

[00:39:47] CC: You don’t have to try so hard. Again, early in my career…

[00:39:50] SY: Really? Tell me more. I never heard of that one. Tell me more.

[00:39:53] CC: Yeah. Yeah. I was doing a lot of extra stuff. Like I would go above and beyond. I was always like a swing-for-the-fences kind of dude. And sometimes the simplest thing that works will get you ahead a lot faster because when you try to do too much early on in your career, it gets stuck. You get into analysis paralysis. You get these big gigantic projects or walls of code that nobody can use or wants to use and it’s too much. Simplification, simplify, simplify, simplify. Don’t try to be the titan in the room, that know-it-all. Ask questions. Do the simplest thing that works. Iterate. If you can’t iterate, if you’re not coming up for error and asking questions and working on the very next small piece of the puzzle, then you’re doing too much and you don’t have to try so hard to be noticed. Sometimes the quieter people are the ones that make the biggest impact.

[00:40:40] SY: Well, thank you so much for joining us, Cliff.

[00:40:43] CC: Thank you for having me.

[00:40:50] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.