Welcome to Bytes in Balance, the podcast where we navigate the wild world of software engineering together. I'm Dan and this is Damian. We have been juggling code, teams and sanity for over 35 years combined. From junior devs to principal engineers, we have worn every hat in the industry. In this podcast, we're sharing our journey, lessons learned and mentoring tricks to help you find your own balance.
It's not just about the tech. We dive into people, psychology, communication, and all the messy bits in between. Think of it as group therapy for the digital age. We bend to swap word stories and share what we think is solid advice. Sometimes we even bring guests to shake things up. This podcast is our way of tackling the stress, burnout, and growth pains that come with the job. It's as much a balancing act for us as it is for you. Grab a seat and let's navigate this madness together.
You'll find some interesting links in the episode description if you want to learn more about us or the topics we discuss. All right, let's get started. Okay, Dan, who are we? Let's introduce yourself. Do you want to start? Yeah, sure. So my name is Dan Ford, and I have a little over 15 years of experience as a software engineer.
I originally studied computer engineering at university, and I was thinking that I might get into embedded hardware or low level software, robotics or something like that. But I found that I gravitated pretty quickly towards the pure software side.
I spent most of my career working at a handful of teams across Amazon and AWS. I eventually made it to the principal engineer role there. I spent some time in AWS infrastructure, working on kind of data center and server management software. Then I worked in
kindle and amazon publishing and then before bouncing back to aws again which is where i kind of cross paths with you i mostly consider myself a full stack generalist you know i've done a bit of front end and back end work and while i enjoy both tend to kind of gravitate towards the back end. At least that's where my interests lie.
While I was at Amazon, I did also a lot of technical interviewing. I was a bar raiser, which is kind of this special role that leads the interview loop all the way from planning what questions will be asked to facilitating the hiring decision.
The bar raiser technically has like a veto power over the hiring manager. Even if they don't think someone's good for Amazon, they can kind of block a hire. Of course, you try not to use that, but that's basically the framework that you're in. And over the course of my career there, I think I did a little over 1100 interviews. mostly SDEs, but also lots of other roles, tech and non-tech. It's been almost two years now that I left Amazon and decided to kind of
do some things on my own. And then at some point you got me into mentor crews and I decided to give mentoring and interview coaching a try. By now, I think I've been doing that for about a year, and I just want to say I really enjoy it. I love the flexibility that I get with being able to kind of set my own schedule and work for myself.
And it's been really fun trying to kind of develop my coaching practices and materials and try to scale this up into somewhat of a real job. Yeah. So do you want to introduce yourself? Yes. I've been around doing software or involved with the software industry for about 20 years. I started on my own as a freelancer, even before I got graduated from college.
And curiously, I got graduated from systems engineering, not software engineering. And people think of systems engineering as something related to software, and it's actually control systems. I never actually worked in control systems, so I find it very interesting. In Venezuela I worked with some folks from Germany and they taught me a lot and started growing and eventually started a small company.
to develop software for this company from Germany and government and other Venezuelan customers. I founded another company also in Venezuela about manufacturing enterprise systems. And those companies had to close with the 2008 crisis and a little bit of the economic situation of Venezuela. I jumped in to become a university professor, teaching software engineering and database systems and computer graphics and computer science in general.
And that was an amazing experience. Getting there and being able to teach after particularly having worked professionally for eight years was really great because you could see the gap between teachers that actually have been teachers all their life, have been researchers, of real life where they have not been professional software developers and there was so much that you could add to your students.
It was a very practical, hands-on approach to the point that I put my software engineering and computer graphics students to develop video games. Everything started with a simple web game and by the end when I left the university they were writing 3D games, things that had the Xbox Kinetics, they would move and things would happen. We would show the games in the main square of the faculty building. It became an arms race because every semester people that started the course wanted to do...
things more cool or better than the previous semester. Eventually I left Venezuela for political reasons and I ended going south to Chile and ending here in the US. Amazon recruited me there. And I worked for Amazon for eight years and I had a blast. I learned a lot in that time. And eventually, same as you, started to get a bit...
born out and left to try to do something on my own. And as a former teacher, I love mentoring and I started trying to figure it out how can I help others through mentoring. through sharing knowledge, and I ended in Mentor Cruise. And one thing led to the other, and we started working in this podcast. What is this show about? And what do you think? What are your expectations?
it's interesting because there's already a lot of content out there that's kind of talking about software engineering and writing code and technical concepts so i guess what i'm interested to talk about here is you know obviously i want to touch on technical things. I'm sure we'll deep dive into technical concepts here, but it's the people aspect of the job, the, you know, managing your own, both yourself, managing your own career and growing your own career.
working with other people in a functioning software team talking about strategies for working well with others, for building better software. Ultimately, I think that's what we're all passionate about is building better software and becoming better engineers. So I hope we can talk about all aspects of that. How about you?
I think after 20 years, you know, and the same probably happens to you, of seeing a lot of things and a lot of people and a lot of different growth scenarios and growing myself, I guess we have a lot of interesting things to say and opinions and knowledge. I think technical aspects are important, don't get me wrong, but I agree with you. People and growing are very important.
I just had a mentee that we were talking about. How do you grow a software engineer? How do you are more efficient? And some of the answers to those things are not about learning more technical things or algorithms. I don't know where this is exactly going to get us. I suspect we're going to talk with a lot of people. maybe do interviews and talk about a lot of topics but I think that is in general my expectation is how do you grow and how do you are a better software engineer.
If today we're talking about growing as a software engineer, why don't we start with talking about what are those fundamental skills that software engineers should have? What are those pillars that we see over and over in good software engineers? I think this is an interesting topic and it's a tricky topic. And I've seen a lot of middle level, sometimes even senior software engineers are stuck because of misunderstanding of this. Because you have technical skills, knowledge related skills.
you also have these other skills that they don't tell you that they are important. These people skills, management skills, time management skills. So I think it depends a lot of who you are and the level and the position in which you are, in which some skills will be better than others. I expect a software engineer to be able to code.
Don't get me wrong. That's really important. I expect a software engineer to be able to learn new frameworks and new things like that. It's also really important. With time, you keep growing knowledge on computer science, software architecture, and stuff like that. And there is a moment in which it's not that you cannot learn more. You can keep learning always. But there is a moment in which learning the shiny new framework, it kind of doesn't make sense. And then you start realizing that.
There are other skills that actually are very important, like people skills. Being able to give feedback in a reasonable way. Being able to say no to something instead of saying yes. Pushing back and communicating properly. So I think you have technical skills, coding systems assigned. You also have very important people skills.
I'm missing things here probably, being able to align people, being able to understand the business and the product. Yeah, I think a lot of what you said resonates with me. In some ways, the software engineering field is kind of unique.
things change more rapidly. The ways of doing things, of course, as you've realized a lot of the new ways are basically just the old ways repackaged, but still there's, there's always new things to learn and it can be stressful in the sense that you're constantly feeling like you have to keep up. But I think, I think.
This is actually one of the big things that a lot of people miss is that software engineers, good software engineers eventually become domain experts in whatever they're working on. I think this is one of the ways in which software engineering is unique in that not only do you have to be an expert in your own domain, you have to learn all these things about developing software, writing clean, maintainable code, systems design, architecting systems, whatever.
Ultimately, your value to the company is your ability to dive in and understand the domain of wherever you're working. One of the teams I worked on at Amazon was Amazon Publishing, but specifically I worked in the accounting division, or at least I worked on products supporting the accounting division.
And so we had to learn how accounting systems work and how do you account for it. And it was fairly complex. We had like royalties and advances and loans and all that kind of stuff. And learning how all that works is not learning about software. You're not learning about it from software books. It's not the kind.
of thing that you think about, I'm going to go learn a new technology, but it's still an important thing. You have to sit down with the business people and understand how they do their job and how the business processes work, because ultimately you have to be able to model those in software.
And if you don't understand your domain, there's a huge class of errors and bugs in our field caused by getting the domain wrong, somehow modeling some real world process or concept poorly in software. So good software engineers eventually.
become domain experts they have to learn all of that stuff because they have to be able to bridge both the technical and these business processes that may not be encoded in software in any kind of way I think you're hitting a very important point because One of the things that if I look at my 20 years of career that I have loved is actually the capability of learning about a lot of things.
like learning how oil business works learning how sugarcane they work at once in a sugarcane system to disorganize gathering sugar you know and bringing trucks into the plant and whatever thinking of all this ass and then you learn about logistics about a tourist system that organizes stores and a bunch of stuff. So this being exposed to all these types of different businesses and different domains, it builds that curiosity of how does this thing work?
yeah that was one of my favorite aspects when i was at amazon i did a lot of interviewing i was a bar raiser it's this internal role they have where you sit in on lots of interviews for other teams but that was one of my favorite aspects of it was i got to interview usually engineers but not always
sometimes non-technical folks, and they become from some other domain. I interviewed electrical engineers and mechanical engineers and talking with them about their experience and trying to map that to the Amazon leadership principles in my interview. It was interesting. I loved... talking about those other domains and being exposed to them.
I think that's an incredible aspect. And there could come a piece of feedback for software engineers. Don't just put yourself in the box of only learning technical aspects. Read books of other things. Read books about the economy. Read books about other domains, trying to understand how other domains are.
and things like that. The technical aspect is really interesting because I remember when I was a professor, you know, seeing a student's seventh semester close to graduating, and you could see them...
eager, you know, of learning a new framework. And how do we do this with framework X, Y, Z? And sometimes they pick frameworks that I did not know how it worked. And I remember telling them something like, guys are not going to believe this. How does the framework work? I don't care at this point. And you say,
you know, we can probably extrapolate this new way of doing things from the old ways to do things and the old frameworks. And there is a moment in which all the frameworks work pretty similar and just a few are worth going and learning in that sense.
The point is that learning the framework just for the happiness and amazing thing of just the technical aspect of it, it just doesn't make sense. This framework becomes a tool. I think it depends on where you are in your career. When you're just starting out, you absolutely can set these small goals. I want to go learn.
Rails, I want to learn Django, I want to learn Python. Once you've learned a few of these, you find there's diminishing value in learning a new one unless you're going to use it for a job. And you also find that if you need to, you can pick it up really quickly because all the concepts are really the same.
Absolutely, don't get me wrong. I totally agree with you. This depends on the level where you are in your career. I'm not saying people that are starting, don't go and learn frameworks because it's not worth it. Quite the opposite. They are in that moment in their careers in which...
Grasping all that knowledge and understanding how these frameworks work is going to help them to apply this knowledge later for new frameworks. But I think it's good not to get too attached to frameworks. There was a time in my career where I sort of pitched myself and I told myself, I'm a Ruby developer, I'm a Rails developer.
And I realized later on, I was kind of pigeonholing myself. I do think it's a good idea not to become too emotionally attached to one particular technology or framework or things like that, because more of them are going to come. They're going to go out of style. You can't predict sort of how those changes are going to. come. Well, I mean, that would bring us to an interesting topic eventually for another conversation probably, which is specialization.
Specializations on one side, but on the other side, all the extremist fanboys. I don't know what is the right word in English for this, which people get really, really angry about. This language is actually the best language. Oh, yeah. Every tech subculture has some aspects. I think. I think there's another aspect to learning too, which is in addition to sort of the domain and obviously getting better at your craft, a lot of the learning that I expected.
engineers to do, good engineers to do over their career is going deeper and learning how all the abstractions that they rely on kind of work under the hood. I think it's a really valuable thing to understand or the ability to be able to rely on abstractions because they're they're very powerful, but also understand when they're leaky.
and understand how things work under the hood. And every engineer will eventually reach a point where they say, okay, that's enough. That's how far deep I want to go. If you're a web developer, you don't need to take electrical engineering courses and learn about signals and systems, but it is helpful to learn. backend code and how that works and how server-side programming works. If you're a low-level
device driver programmer, yeah, you absolutely should learn electrical engineering and some understanding of signals and systems and things like that. So there's a range to it. But I think in general, being able to understand you know how your stack works to some extent understand the things that you rely on are they leaky abstractions you know can you rely on them to what extent can you rely on them i think that's another aspect of a good software engineer that i see
What you mentioned, let me see if I understand correctly, is like I as a I see a bunch of things and I say, I want to learn this thing. But there is a moment in which you have to pick. You cannot go deep in every aspect and everything like that because you just can't. You don't have an amount of time. So that's where you mentioned these abstractions actually make sense. Maybe it's related to this, like am I somewhere that has a high...
proficiency in networks. No, I'm not. We have folks in Amazon that basically know these things at the TCP IP level protocol and stuff like that. I know enough networks to move around and be dangerous, and I rely on those abstractions that I have.
actually use the network and trust that it's going to work as I expect it worked. Does that make sense? Yeah, definitely. And there's some places in my career where I worked where you couldn't take the network as a clean abstraction. You had to understand. I worked in low-level data.
center networking in my first team at Amazon. And we had to understand the difference between layer two and layer three, for instance. But nowadays, a lot of the things that I work on, you can absolutely take the network as just this magical abstraction that never fails and is perfect.
you have to think about some failure cases but it's a lot simpler so you can decide for yourself where that is in your career but in general i think it's a good a good way to think about growth is is often what are the abstractions that i don't understand What are the things that I could dive into and learn that would make my understanding of my current domain, my current work better? I have a story I remember very early on my career and I think this was one of these moments that actually
clicks with you and goes with you along. I remember I was using Hibernate. This is like 15 plus years ago or something that talking to a relational database and something was just not working, right? It's like we could not make this thing work. And then this fellow, it was my boss back then that I respected a lot. It was a German guy. It was very stereotypically German in that sense. It's just like...
did you try to get, look at the source code of the Hibernate? And I was like, no, should I? And he's like, yeah, I mean, so okay, I started clicking in the IDE and getting into the source code. probably even editing the thing and putting breakpoints and whatever. And it's scary because this code was written by somebody else and it's really complex code. It's non-priegal code.
But eventually you get there and you find where the place is and you get to the point in which you understand even better the framework, right? Understand how that abstraction works under the hood and that helps you to make better assumptions on top of this. That's a perfect example because ORMs... relational mappers. That's a great example of one of those abstractions that
is really useful to rely on, but you have to understand what it's doing under the hood. It's not magic. It's not changing your database technology. It's just generating a bunch of SQL queries for you and translating objects into result sets and all that.
And there's absolutely times when you have a whole batch of objects that you want to do something on and you don't want to turn that into a hundred different SQL statements, those kinds of things. That's a very clear leaky abstraction that you have to understand when it's okay to rely on and when it's not.
And I remember I learned a few things from that experience. Like if things are not working, you just go down, look at the code, or learn how the abstraction actually works. And the second thing is that... The hibernate is a very sharp knife that was very powerful, but you could yourself very easily. So understanding how the abstraction works under the hood helped me rethink the way I would approach the framework and use it in a much better one, correct way.
moments that you remember 15 years later or so and say like oh those were those aha moments it's very interesting because a lot of Our skill is also related to understanding other people's thought process and other people's things and other people's code. It's interesting because there is a lot of optimization of writing code faster and better. But we spend a lot of time reading code, actually.
And that's why writing good code is helpful and pays off because a lot of people later is going to have to actually read that code and understand what's happening. So it's closing the circle with that learning process in which you have to go read source code and learn and so forth.
thing that that people can do a lot of the things I think we'll talk about in this podcast are gonna be just fairly high level and I think we'll do our best obviously to provide people with concrete advice on what to do but sometimes it's hard but that right there reading through
source code for libraries and things that you rely on. That's absolutely something I've done many times in my career and I've always found it to be really useful. It's scary at first, you get in there and it's like, wow, this code is... so elegant or so complex or so crazy there's all kinds of things you can find
But yeah, it's been super useful to step through, see what's happening, see different. I've gotten so many ideas for writing my own code when I read through code from libraries. And I think, wow, that's, that's really clever.
Hard to predict what you'll find or what value you'll get out of it, but in general, it's a great practice. It's a good way to learn, because actually, when you see other people's code, you basically are understanding the patterns that they use and they are using some complexity and why are they using this complexity look they're using a proxy here why is this thing even called a proxy i think it's actually an excellent way to broaden your
horizons and learn different type of design patterns and stuff like that. So wait, when you say that we're going to talk about high level things, you mean that we are not going to describe how to set up a Kubernetes cluster step by step? That's next episode right there. Yeah, I think it makes a lot of sense to talk a lot of these high-level things and not entering the lines of code in a podcast. Summarizing a little bit what we have talked, we have said that
Software engineering is actually a social activity to some extent. So people skills are very important. Communication is very important. We have said that this is a business in which we have to learn a lot of things, not only technical things, but we also have to learn about domains and learning about domains is very fulfilling and very important.
And then, yes, you do have your technical skills. You have to be a good coder. You have to be a clean coder. You have to learn and know about system designs and technology and frameworks. Do you think, Dan, that summarizes it? I'm missing something. Yeah, I think that's a good summary.
So when do you think some of these skills are important and not? What are you looking, for example, when you're interviewing a very junior engineer? What are you looking when you're interviewing a senior engineer or even a principal engineer? What do you think?
I think that's an interesting topic and it's hard. It was actually hard. I started thinking about this and my first reaction was, oh, well, all those things are important and they're important in every level. And when I thought about it more, all those... things we talked about are important, but you kind of express them differently at different levels. When you're a junior, there are
tons of abstractions that you're going to rely on and you're not even going to think about because you have so many other things that you're learning, so many other things that you're thinking about. And one of the ways that you grow technically...
is diving deeper and deeper into your tech stack, understanding more and more how it works under the hood. And that's something that you can kind of do slowly over the course of your career as you grow from a junior to a mid level to a senior and so on. One of the biggest things beyond just technical understanding though, that I value in mid-level to senior engineers is decision-making and evaluating trade-offs.
I think the thing that it requires, the thing that makes it tricky is that it requires connecting your business requirements and the business value to the technical implementation. Well, there's all these different debates in our field about things like microservices versus monoliths and SQL versus NoSQL.
You can debate all those all day long. But until you really dive in and you understand the business requirements, you understand what's important to the customers, you won't really know how to value different pros and cons. And that's what I see in senior engineers is that they're able to very quickly look at those requirements and say, no, no, no, we need this kind of a system or we need this kind of a solution. That's definitely one of the things that I value.
I think it makes sense. I would use to call this, don't try to shoot or to kill a mosquito with a shotgun. And you see a lot of that. You see a lot of mid-level engineers or even junior engineers are trying to solve a very small problem with a bunch of microservices. This doesn't make sense.
And that's where the trade-off actually comes by. I think the progression that you described makes a lot of sense and very aligned, right? At the beginning, when an engineer that can code and that it's eager to learn and it's eager to actually go through that feedback loop and learn.
And I agree with you that the junior engineer uses a lot of these abstractions without understanding a lot of how they actually work under the hood. And as they progress on their careers, they start learning and diving deep on them. And there's also people skills that starts growing through the process and how to communicate.
I learned very that you have to communicate for the audience that you're targeting. And some mistakes that junior engineers do sometimes is they talk into technical terms for audience that actually are non-technical. So honing those communication skills is something that...
grows as an engineer grows. I expect a senior engineer to be able to crisply communicate complex concepts with simple words, but I don't expect necessarily a junior engineer to do that. Communication is one of those things that's valuable at every stage of your career, obviously.
But that's especially hard is being able to communicate at different levels and be able to sort of switch between those levels. And you're absolutely right. Like senior engineers, principal engineers, they have this ability to dive down and talk about low level code, if they're talking to another developer, or if that's what the conversation is about, or go up and talk at the sort of 10,000 foot view and speak to a CXO type person executives.
and not overwhelming them with technical details that don't matter, but quickly summarizing, here's the trade-off we have to make in business terms, or here's the decision. It comes down to this cost versus this cost or whatever. That's an extremely difficult skill, but super valuable as you. progress.
I used to joke that a lot of my work as a principal engineer was to actually talk to engineers, here's a bunch of techno bubbles, and then turn around and talk to your general manager, VP, or whatever I say. What he's actually saying is that blah, blah.
Or then talking with product and understanding something at high level. And then the engineer was very upset or something because he was overcomplicating things and saying, no, no, no, no, no. What he's really saying is that this is what the simplicity of this was translating work, which is, to some extent, that's the skill.
And I think as any other skill, it's something that grows with the years. So you don't expect a junior engineer to actually be an excellent communicator. It's just having the potential to grow and to learn. What kind of advice would you give to a junior engineer who wants to explicitly?
Focus on that. I agree with you. It is something that comes naturally as you have more experience and grow, but that's something I've actually struggled with. I've had people, you know, say, how do I improve my communication skills? Obviously I have things that I advise them to do, but I'm curious how you think about that. How do you grow those specifically?
I think there is a lot of watching other people, how they communicate. I remember working with a general manager in Amazon that I used to love being in meetings with this guy because you could see the thought process going on his mind and the way he would communicate and the way he would stop people that was rambling around and even the careful choice of words to do these things. I learned a lot.
in that sense. And looking how other people communicate, it's really important. Try to explicitly think on what is the audience you are communicating to. Is this the Saudis has technical knowledge or not? Try to go to simplicity.
we sometimes add a bunch of detail that doesn't make sense one thing that i do a lot with emails i write an email then i look the email and say what are the things that i can cut here that i can prune that they make no sense to be in this email and practice and be aware of what
That is the result. How do you are communicating something? Is the other person actually understanding or not? And if it's not understanding, truth is somewhere in the middle. It's like probably you have a lot of the responsibility of why the other person is not understanding. So look at how are you communicating and try to rephrase.
yeah it definitely does and i think there's there's strategies that work well with in-person communication like i think you're talking about i rely on sort of non-verbal language body language as i'm talking with someone i look to see are they folding their arms and shaking their head or are they not
nodding and in agreement. If I'm in a meeting with someone and I get the sense that they're not agreeing with me, I'll politely say, hey, it looks like you're skeptical of that. Or it looks like you don't fully agree with that statement. Tell us about it. And being able to pick up on those cues.
and use it to sort of further the conversation, further enhance understanding, I think is valuable. But you can't do that when you're writing, for instance. When you're writing, it's even more important what you said to think about the audience, think about what they'll care about.
summarize ruthlessly cut extraneous words and sentences and even concepts until you have kind of the bare bones thing of what you're trying to communicate you're hitting an important point here is that of course in-person writing communication is two different things even probably we can make difference between actual real in-person communication versus zoom communication to some extent the other important thing here is that if you want to be a good
communicator you have to listen and I think you basically mentioned that when you hey you see some skeptic look in the other person's face is okay what is what is causing noise well you're not understanding and
We tend to, people tend to sometimes to get to square with their ideas and just try to throw them out like a machine gun or get the idea across without getting that feedback loop from the people they are talking to. And it's like, listen, what is the other person saying? What do they think?
about it. Can they actually thread the story that you are telling and they can... say it with their own words when what they are saying makes sense or not do they feel puzzled so listening and getting those cues i think it's that's an amazing yeah and that's the first thing that i do when i'm faced with some kind of disagreement let's say i've just presented a design
document and someone clearly doesn't agree with a decision that I've made or a direction that I want to go with, the first thing that I'll do is try to summarize what their point of view is in my own words. make sure that I understand what their point is. They can correct me if I got it wrong. I can sort of give them the most charitable view of what they said. Sometimes inside my head, I'm thinking, you asshole, why don't you like my ideas? But out loud, I'll be like, okay, it's
like what you're saying is you're concerned about the maintainability of this and that'll get them to talk and feel like their concerns are heard maybe we will discover there is a problem with my strategy and i changed my mind maybe we don't maybe it just needs to be talked
through. But that's the first thing that I always do is just rephrasing what someone else said, and making sure that we're operating with a common shared understanding of things. Rephrasing is a very useful and powerful tool when somebody is talking to you and is explaining a very complex idea and you're following and you maybe are taking notes it's really important to make a pause and I tend to do the same say like okay
What I'm understanding up to now is that this is how XYZ works, right? And first this goes here, then it goes here. I'm getting right. That keeps you the capability of being aligned with the other person. It's like we're in the same page, we understand the same thing and then we can keep building on top of that. Another key advice that's coming to my mind now is I think good communicators are good storytellers. I don't know if this could be a good advice, but read.
stories and try to understand how the story is being told. And then you try to apply this to what you are trying to communicate. I use this a lot in design documents and I use this a lot when I'm trying to explain a complex concept. I'm trying to explain something works and say, you know, there is a user that is clicking this button and then that's creating this request. This request is being grabbed by a server and the server
put something on a queue and from that event in the queue there is this other producer that you know brings things and writes another database you can always tell this story as you know I woke up this morning and I got in the car and turned the car on then went to the supermarket
and then I decided to put gas on the car and grocery stores and you're telling that story. So I think that helps a lot to organize your ideas and to actually communicate complex ideas. Storytelling is a huge concept. It's interesting that you jumped to this.
technical story of the item on the queue and whatever because I use this concept a lot in my coaching practice when I'm talking about interview coaching when people are practicing their behavioral stories i have people talk using the star format situation task action result but a lot of times people's struggle isn't with just hitting those bullet points it's
Taking the real things that happened in their jobs, which are always messy and complicated, and trying to turn them into a story with a set of things that happened that are important to the story, a conclusion, your results, that's actually... What I find myself working on with people when we're doing behavioral interview practice is they tell me a project that they worked on or a thing that they did.
And then I'll help them craft that into a story, into a, here's the beginning of the story. Here's the end of the, here's the point of the story. Here's the meat of the story. The meat of the story was that because of my experience, I was able to write this project, get this project going in the right direction, or I was able to solve. this problem or whatever.
But it doesn't always come naturally to people to tell things in this storyteller, in this narrative way. And if you don't, a lot of times it leaves the interviewer, if we're talking about interviews specifically, it leaves the interviewer very confused about the scope of what happened and why.
And does it matter? And all those questions are left in their head when you don't have this good narrative that you've practiced. I don't know if reading helps necessarily, but it's... I don't know. I'm... I'm an avid reader, but I don't have data in that sense. But for example, if you think about the star format, it's a story. What was the situation? What was the task at hand? What happened? What happened? What were the actions? What were the results?
and that's a story like hey we were in this situation you know and this is what had to be done and this is what actually we did and happened and what i did in this part of the story and these were the results and sometimes the stories have happy endings
But yeah, we deliver. Sometimes stories have crappy endings and that's okay because you can always say, and I learned this and this and this and I wouldn't do this again. It's about how you tell the story. Maybe the ending was unsatisfying, but if you can...
tell the story in a different way where the ending is about all the things that you learned or about a decision that you were able to make with that information or you can always pitch that in a different more positive way i have this interview question
use a lot and I liked tell me about a situation when everything went south everything went wrong what happened we're in the software industry so this happens a lot and it's interesting because people isn't prepared sometimes to answer those type of questions Which is okay, because I get a genuine type of transparent answer. Yeah, you get their real emotional reaction to some horrible bug or some horrible operational event that is fun to walk through.
And then you realize you can hear several stories like, yeah, I was the hero that came into a very bad situation and saved the day. Okay, but how did you contribute to the disaster? I want to know what you learned from the whole thing. Are you throwing your manager under the bus? Are you throwing your peers under the bus? It's a good way to say, hey, this is a story that had a catastrophic ending, potentially.
But you can still get a lot of good things from it. Dan, we have talked a lot about skills and different skills at different levels of engineers' careers. And how do an engineer grow those skills? Who do a software engineer... What are good strategies, in your opinion, to do that? Well, some of them, when you're talking about technical skills or growing into different domains and things like that, I think you can do a lot of self-analysis of what are the areas that you're...
maybe less comfortable with what would challenge you. And then explicitly try to challenge yourself, try to take yourself out of your comfort zone. I think it's pretty possible to do that with technical topics. I think it's actually harder to do that for soft skills, because a lot of times you don't really know what you're lacking. But where you can identify, like, I need to get better at backend software, or I want to get better at this specific technology or whatever.
I think you can establish a practice of trying to get yourself a little bit out of your comfort zone, not so much that you fail and flounder, but find ways to stretch yourself. That kind of strategy has carried me pretty far in my own career. What do you think? How do you approach it? I think the same way. I think getting out of the comfort zone is a really important thing. What I'm wondering is that sometimes that's something that you can do at your job.
But it's not that often that you can actually in your daily job get out of the comfort zone enough to actually trigger that growing. Don't get me wrong, you grow a lot in the job and that's important. But are you talking about getting outside of the comfort zone in the job or getting outside of your comfort zone in your personal time when you are approaching to these things? How do you think about it? Yeah, most of this, I guess I was thinking about on the job. Of course, I've done a lot of...
personal growth and personal growth activities and stuff like that in my own time but i don't really associate that with work although yeah to be honest there is a lot of synergy there i guess what i do is i look for opportunities on the things that i'm already working on
to either dive deeper. I think we talked earlier about reading code from libraries or open source libraries and things like that. And sometimes you have a choice whether you dive into it or you treat it like a black box and just kind of debug around it.
And if it was something that I was explicitly interested in, sometimes you don't care, right? Sometimes it's like, I'm happy this being a black box and leaving the internals of databases or whatever to the experts. But there are plenty of times where you think, even though this is a bit scary, I think I need to dive in here.
a system or a technology or whatever that to do my job well, I need to understand how it works under the hood. And then I kind of like, oh, okay, this kind of sucks, but I'll jump in and start reading this obtuse code or start with some.
basic tutorial that feels really boring sort of starting from scratch accepting that i'm going to have to go through this process of learning from the beginning at least that's how i approach it yeah i think we agree that getting out of the comfort zone is the important thing
This is putting yourself in situations in which you have never been before and you basically don't necessarily know the answers and don't necessarily know how to solve the problem. It's a good thing. It's a way to force that growth. and people sometimes get stuck there because that's scary it's hard to do it it's hard to get into the hot spot and do that but i think it's really important and all the times in my life that i have done it grow is coming
I also think this is an art that is about practice too. And it's like practicing and practicing over and over and over is precisely the important thing. I am a believer of this theory of the 10,000 hours. Long ago I used to compare sometimes writing code and building software as making music.
a bit familiar with that is the type of things that you keep doing over and over and over and eventually becomes muscle memory and sometimes that practice comes from work I'm a true believer also on pet projects and things that you do on your own I did a lot of them when I was very early in my career. I was lucky enough in some moments of being able to define my own direction and the projects that you would do and I learned a lot from them.
Because you risk otherwise staying in the same domain and in the same area for too long. And then it gets harder and harder to grow sometimes. Yeah. And you can definitely, there's been a couple of times, well, probably more than a couple times where
recognized that I was in a rut. I think kind of what you're describing. I was comfortable. I wasn't growing. I was kind of avoiding certain things or certain things that I knew would force me to grow, would get me out of my comfort zone, but it's comfortable there. One of the things that I'm interested in is thinking about how do you grow in these soft skill areas where it's maybe harder to identify what you need.
I think you alluded to this earlier. Sometimes people, they want to grow from a mid-level engineer to a senior engineer. They think they mostly have to improve their technical skills. And a lot of times it's mostly about... actually improving their soft skills but how do you do that in a generic way that's a pretty vague complicated topic yeah that's a very good question i think doing getting into trouble and getting out of it interacting with people
and it's a lot on the job. I think being very open of what is going on, why things are going wrong or why things are going great and being... very vocally self-critical in the sense that how am I contributing negatively for these things to not go well? or what can i learn from it and how am i contributing positively for this thing to go well and also what can i learn from it i tend to reflect a lot about the past which is that
And to be very honest, right now I'm going to my own process after leaving Amazon of thinking of the last eight years of my life. And I'm thinking, okay, what were the learnings? What things went well? What things did not went well? And that analysis is important and I'm doing it for Amazon, but I did it also for my previous job and for my previous job and so on and so forth.
And it is normally not obvious. It's harder to do it when I am in the fog of war. Once you have moved on, it's easier. It's not that there is no grow when you are there in the fog of war, but once you are out and you put some distances, you see things that maybe did not.
Southern. Absolutely. Yeah. And in general, it's also hard to do this for yourself too. What you're describing is trying to self-reflect on situations and things in the past. And that is incredibly difficult. I'm sure you do this with your clients as well. I find that I'm able to have that distance with my mentoring.
clients where I just talk through a story and a project that didn't go the way they expected or whatever. And because I have that distance, I can ask questions that seem obvious to me, but maybe weren't obvious to them. Yeah, this is very difficult to do for yourself. I've had the same experience where I've also
reflected on my time at amazon and i had some teams there that i felt like i did really well on i was really happy i had some other teams that i didn't have as great of an experience at and it was always hard for me to tell well Is this about me or is this about the team or is it some kind of combination of both? And I think another aspect, and I mentioned this before in this conversation already, is watching other people. successful people.
more senior people actually handle situations and deal with situation i was mentioning this general manager that was really amazing to see him go through meetings and stuff like that you could see his clearly crisp thought process and you could see how he would stop people on their tracks in a very polite and great way when they were just rambling around and not going into any good direction. And there was a lot of learn from that.
So I think looking at other successful folks, how they behave, what they do, how they think, it's extremely powerful tool, particularly for those soft non-technical skills. Yeah, as you were talking about that, I remembered the kind of the early days at Amazon before everybody was working from home and COVID. This is interesting because I actually don't know if this part of the culture is still around now that Amazon has kind of gone through the return to office. And they're all in theory.
on site three days a week i don't know the realities of that but I remember the same thing that you described, looking at more senior people, seeing how they would operate at meetings, but also just the meeting culture at Amazon, especially big, important document reviews with senior leadership. You'd go in a room, sit down, everybody gets hands. handed out this 12-page packet of papers and a bunch of red pens, and then everybody just sits in total silence for 20, maybe 30 minutes. I did one.
I think it was with, I forget his name, the VP of AWS, you know, below Andy Jassy. And my God, the document review was 45 minutes of silence of people reading. You know, I got through the doc in like 15, 20 minutes. And after that, I was like, man. I better look smart. So scribble it on the paper. But really, I did get a lot out of that process. Just learning how people both respond to what's in the document, but also respond to other points of view in the room.
The people I learned the most from, of course, they came in with their own points of view and their own thoughts, but they were able to very quickly kind of reassemble those on the fly in the meeting. And I always struggled with that. I'm always someone who kind of mulls things over in my own head on my own time.
And I struggled with showing up, reading something and then having something smart to say about it in a short period of time. But observing that did help and to see how they kind of, how they kind of did that. Yeah. I'm pretty bad at comebacks. I don't know if that's English. Like you see something and I want to answer and I can't. It's going to come to me one hour later. I'm going to start having all these incredible ideas. Yeah, comeback is more in the context of like an insult, but sure.
you know, of course. But yeah, I get your point in that sense. You see a lot of that clarity in those Docker views. And I learned a lot from that, for sure. even what do you pay attention in the document and what you don't what you ignore it's like not nitpicking it's just focusing on what is really important a lot of learnings there coming back a bit to the technical
aspects of this. Moving outside of the regular technologies in your own time it's also important in my opinion like today there is a lot of jobs related to full stack backend UX and so on and so forth with very well-defined technologies and you could stay there all your life and not move out of those things. But then a lot of other interesting code and things to do that you can actually learn a lot.
and i don't see as much as developers as i would like getting into those things it's like how do you implement a graphical editor For example, people tend to focus too much on things that are extremely practiced technology-wise for the next job, which is okay. I'm not saying it is wrong, but a lot of those things also hide.
bunch of interesting learnings behind that if you don't touch other aspects and other type of projects and things like that, it's very hard to learn. A lot of my learnings on design patterns, for example, in my early career came from projects that I completely atypical like implementing a graph editor or implementing a report generator and were these things that you did sort of on your own like you call them pet projects or were they more some of them
Yes, corporate projects. I was also lucky enough to be in an environment in which I got paid for some of these of these ones. But I did not follow the path of becoming just a web developer and stay in my database, my MVC and call it good.
No, I was forced to some extent to do some of these things somewhat on my own interest and somewhat actually paid. Yeah, I've struggled with this sometimes over my career. Actually, when you said pet projects, I actually wasn't sure if you meant sort of like... projects that you do sort of on your own personal time for your own personal enjoyment or projects that you may pick up ostensibly for work.
but are somewhat of a personal interest. The lines are blurred a little bit. I actually wasn't sure which direction you were going because I have interesting things to say about both. I definitely, when I was at Amazon, there were some times during my career there where I had time and energy outside of work to write code and to work on projects. The majority of the time, I don't think I did.
energy to do that kind of stuff. Oftentimes I would be directing it into something work related. Like I had some really interesting project and I was super into that part of it. I was the one kind of writing the core bit of the code. And that's where all my passion project energy kind of ended up. Now, of course, I have a bunch of those things. I have a bunch of time that I'm trying to get into building games using a couple of interesting game design frameworks for
front-end technologies, HTML, CSS, JavaScript. And so I'm dabbling in that, like totally different, you know, Probably will not make me any money in my career, but it's a fun thing I'm trying to learn. And there's a whole bunch of new patterns that are kind of new to me that I'm dabbling in. But I never had the energy or the time to do this while I had a full-time job. Just totally honest.
For me, there has been times in which I have had the energy and I have actually used it. There has been times in which I hasn't. I did this a lot also very early in my career where some things like family, kids are not necessarily taking so much time from you. When I talk about pet projects, by the way, I'm talking about personal pet projects, not pet projects at work. And I still do. Through my years at Amazon, I did a few things. It's not that crazy amount of stuff.
But when pandemic started, I had a couple of extra hours a week because of lack of commute. And I would sit down, have breakfast and sit down in the morning instead of commuting and spend like an hour in the morning just writing some and I started writing a small video game. I didn't went too far away, but I was more interested in the video game itself in some of the technologies underlying the thing.
and eventually i spent two three months on that make some progress and then went to the refrigerator But that type of things. And what you described is an example of that you're working with some of these new technology. You're learning new patterns that you have never seen before.
And the interesting thing is that eventually you go to another domain or to another piece of technology that is not related to games. And some of those patterns will also have a positive impact on how you implement that other thing. So anyhow.
That has been my experience with pet projects. Yeah, well, I thought it was an interesting topic because I actually think pet projects at work can be a really valuable thing. Help me understand that. What is the difference? So, I mean, sometimes some jobs that I've had have been pretty structured.
and I didn't have a lot of flexibility in proposing new work but a lot of the places that I've been especially as I got more senior I did have more leeway and more hey wouldn't it be cool if we wrote a script that did this or wouldn't it be cool if we had a little
tool that did this that helped us out and i've always gravitated towards little things like that i have to be careful of course because they can be kind of little distractions and i have to make sure that i'm focusing on solving some real use case and not dedicating too much time to it I've never worked at Google, but I've read about the 20% time. And whether that's always worked out that way in practice or how that worked out, I don't know. But the idea is there.
So yeah, I think when you're looking for ways to grow and specifically technical skills, looking for opportunities to propose pet projects so you know sometimes i they would be things that i wouldn't even propose i would just kind of work on them in my own time and if i decided i'm not going to be able to get something useful out of this in a small amount of time
then I might abandon it. If I felt like I needed more time and it's worth it, I might go say, Hey manager, I'd like to do this part-time for the next month or two. Does this seem reasonable? And then I could have an opportunity to pick things that would. stretch me like we talked about getting out of our comfort zone. I could explore new ideas for things that I thought maybe would be valuable for the team to invest in, but I wasn't totally sure.
Most of the time it was just because I had an idea and I wanted to prove it. And I wanted, I felt like no one else would be convinced unless I actually built a prototype and showed them. A lot of the times that's where the motivation to actually build it comes from is thinking. Yeah, just talking about this isn't enough. I need someone to actually see it and go, yeah, wow, that's cool. Yeah, it's easier to show than to just talk about it.
Yeah. Now, granted, if I added up all the pet projects I've done over the course of my career, probably like 70% of them have just been abandoned. So let's like take that. I mean, it's actually a great success rate if you think about it. Which is probably okay. Yeah. Pull that number out of wherever.
you know. I get your point. I see your point too. Something that I tell a lot of my mentees and my coach practices is go and find those projects. Try to figure it out. What is the project that gets you out of the comfort zone and try to talk with manager to get into those projects one maybe it's not a pet project there but it's that willingness of find yourself what is that next project that is going to help you grow instead of just be okay and be content with
whatever, you just get a sign. Another thing that for me has been fundamental and I also learned pretty young is My dad would say open the fan of possibilities. And I was thinking a lot recently is you're trying to solve a problem. There are like 10 different ways to solve the problem. If you get stuck in the first one that comes to your mind, a lot of things could happen. First, it may not be the best way to solve the problem necessarily.
and second you may not learn from that approach and from what you're trying to do and i found a lot in my early career moving back and forth between solutions and until i was like okay let's prototype this a little bit It doesn't look that it's the right approach. It doesn't feel comfortable. It's not flowing. Okay, let's backtrace a bit and let's do this other approach. And it's time consuming, but also you learn a lot from that process if you have time and you're willing to do it.
Yeah, that's kind of one of the markers of a mature senior engineer is the ability to consider and hold multiple solutions to some problem, technical or non-technical, be able to explore them. to some extent, but not also get too emotionally tied to one of them that when it ends up not working out, they're able to kind of regroup and...
go, okay, well, let's go down one of these other paths. I definitely see more junior people falling into this trap of they very quickly settle on approach. Yep, this seems good. They start diving in, they hit some wall, and then suddenly they don't know what to do. Definitely being explicit about that and cultivating that habit, I think is a good idea for sure. Yeah. And a lot in my case in my early career was design pattern approach and code structure and object structure and things like that.
But the same applies, for example, when you're designing it. a bigger system. It's like, what are your alternatives? What are your technology choices? What are your structures? Are you actually going to go microservices or not? Or is it worth it or not? And start considering those options.
I think eventually you do it a lot and it becomes a second nature. Okay, so we've talked about kind of growing some of these skills, technical or otherwise, on your own. What do you think is the role of a mentor or mentorship? in kind of growing some of these skills i think there are many aspects in my own career my own mentors one of the aspects has been a reality check of telling me
What is the difference between what I think I am versus what I really am, right? It's like, oh, I think I'm ready for a promotion or I think I'm ready for this new challenge when maybe things are not going the way I would like them to go.
Why? And then is having this conversation with a mentor that it's an external party that can look at things with a more... cult mindset and tell you like okay I see these gaps I see these problems and these are opportunities for you to grow and to learn and that's why things are not working the way they should so that's one of the things that I see another is that a mentor
will point you to what you don't know you don't know. There are those things that you know, those things that you don't know, but you know you don't know. And there are those things that you generally don't know, but you have no idea that they are there. And a mentor could actually look at you and point you into those directions and make you more aware of those things that you don't know that you could actually grow and learn.
This happens a lot with senior engineers or mid-level engineers that want to grow on their careers or get a promotion and they are stuck in the technical aspects only. and they think that they are not evolving or growing because there is something technical that they need to learn. realities that you start talking with them and you realize that they are really good at the technical aspects of it but they actually need to grow other skills that are more softer skills you can point them into
into that direction. So those are some aspects that mentors can actually help. Yeah, I think that makes a lot of sense. I've definitely experienced some of that. both in my own career, reaching out informally to mentors. It was always really valuable. And I would always try to find
a mentor or someone just to chat with who was outside of my organization. Usually someone that I used to work with because I had a good relationship with him, but somebody that wasn't super close to my org. So I could kind of describe some problem that I was having or some, some situation that I was.
facing that i didn't quite know how to handle and they would never give me, you know, the answer was never obvious, but it was always their ability to ask questions that I hadn't thought of, reframe things that I was telling them in maybe a different way would always give me some perspective in either finding a different
solution that I hadn't thought of, or maybe oftentimes just reframing a solution that I already had seen and had thought of, but had rejected outright for some reason. That's actually been the most of my experience with that. Now that I am a mentor on my own, the way I think about this is kind of similar to what you said. What I try to do is talk through like work backwards from either a problem that a mentee is having. Oh, I'm trying to get promoted or I'm trying to
get this design approved by my team or trying to convince people on my team to go down this approach or whatever. Kind of work backwards from that and try to figure out, okay, well, are you thinking about this in the right way? Questions that you hadn't thought of are going to be stepped back and think about other alternatives or things like that. And again, usually I'm not telling them.
here's the right thing to do, go do this. But usually the process of asking those questions and giving kind of, okay, here's my uneducated take, hearing what you say, here's how I would look at this. It's usually not 100% accurate, but it's enough that. it will get people to think outside the box of whatever they're facing and get over the mental hurdle that they're stuck on i think a mentor makes you think differently and
Most mentors will never tell you what to do and they can't because they are not on your shoes. I think you have mentioned a part that is very, very critical. But they may point to things and shed light and you will see them and you will interpret them with your own perspective. They will change a little bit your perspective and that's going to have open space for you to move forward.
I remember this story of very, very long ago, a mentor. We worked together. He was my boss. He was my mentor, was a good friend, someone older than I, and he was in a very academic world to some extent. and I was in a very software development world and it was the kind of
person that came with these very complex ideas and would expect them to be implemented like in two or three days or something like that. And then I would come and show him like, hey, this is the ground reality that we have down here.
After a couple of years of working having coffee sitting down and talking we got to the conclusion that He on one side taught me to dream and go high and think of what could be possible and have those dreams and there was a moment in which i pushed him to code and it was like okay i pulled him down and ground to reality and actually
made a great combination. So anyhow. Yeah, you know, funny, as you were talking about that, I was thinking about someone else in my own career, also an old boss of mine, we had the same dynamic where he was always very over optimistic, in my opinion, about our ability to launch something into a product. And I would always, every time we'd be thinking about this.
In the back of my head, I'd be thinking, man, this isn't going to work. Nobody's going to use this. Nobody's going to like this. And over my career, I've had to kind of... think about that voice in my head. And obviously it's good to be a little bit of a pessimist and it's good to think about what could go wrong and poke holes in ideas and be a devil's advocate and things like that. But it's also...
Good to have some think big and have some faith in your ability to build something. And yeah, we did end up launching a product with him and it. Went way better than I expected. It's a similar thing. I think you have to keep those two opposing forces in balance. Yeah. And that's part of the growing process. And that's where a mentor, a coach can actually help you.
So it happens to me with some of my mentees, you know, that they are struggling in a situation in their daily jobs and they have a conflict with a senior engineer or something like that. And they are very frustrated. And then I have a conversation with them and it's like, have you seen this from this other perspective? Like, for example, it is good that you want to raise the bar in engineering excellence and operational excellence, a bunch of these things.
But what is the point of rising the bottom of those things if the ship is sinking because these other problem is still there or the product is not being profitable yet and maybe this senior engineer is actually focused on trying to solve that core problem and then it's like
you see those aha moment that it's like okay it kind of makes sense what is the point of having a perfect pipeline and non-flake intake test or whatever if we are actually not about if your product if nobody buys a product yes yeah and that's just an example But it's a great example of reframing, of thinking, helping people to think differently sometimes. By the way, folks, I don't think it's a secret that Dan and I are doing mentorships and taking on mentees.
So if you guys are interested, you can find Dan's website and my website down in the notes for the podcast. We would be happy to chat with you and put our experience at your disposal for your own career. Okay, I think we are getting to the end of the episode. Dan, can you help us summarizing what we talked?
Yeah. So we've been talking about kind of what are the skills of a good engineer? And I think we came up with some good ones. There's obvious technical skills. And we talked about how do you grow and stretch yourself in various technical areas. But then there's also a lot of soft skills. skills, and those are harder to grow. We talked about how do those skills kind of grow and evolve over your career. At the beginning of your career, you may be more focused on
learning technical skills and learning new frameworks, new languages, things like that. And some maybe low hanging fruit in terms of your soft skills. How do you interact in a professional environment with other people, things like that. And then as you progress in your career, you're more focused.
on either deep diving into specific technical areas or growing your soft skills. And you may find that your soft skills are your limiting factor when you're talking about getting promoted to senior and principal and things like that. And then I think we brought up the role of mentoring in this growth, learning and growing from people around you, people in my own career, my manager, peers, things like that have served as informal mentors to me.
But in other cases, both you and I are obviously working as mentors and sometimes professional mentorship is also a good way to see something from another perspective and to get yourself out of your comfort zone and get someone to challenge you on some of your course. Yeah, I think it has been a great conversation.
about those topics i think there are also some interesting strategies to actually learn a few things when we talk about pet projects and about approaches of how to learn on the job and get out in the comfort zone it has been amazing All right, folks. Thank you for listening and stay tuned for next episodes. Thank you, Dan, for the conversation. It has been great and I hope we keep talking about a bunch of other different and interesting topics.
And that's it for this episode of Bytes in Balance. We hope you enjoyed our deep dive into the world of software engineering. Thanks for tuning in. We would love to hear your thoughts, so don't hesitate to reach out. Connect with us on LinkedIn to continue the conversation or simply follow our updates.
You'll find the links in the episode description. We aim to release at least one episode a month, but with our busy lives, it might vary. Subscribe to stay updated, and you might catch some surprise episodes when we're feeling extra chatty. If you are enjoying the show, please rate, review, and share.
with your friends and colleagues. It really helps us reach more people in the community. To learn more about the podcast, check out our website. The link is in the episode description. And if you're looking for more personalized guidance, we're available for mentoring through Mentor Cruise. And there's a link for that too.
That's all for now. Until next time, keep coding, stay sane, and remember, even when it feels like a total shit show, you got this. Thanks again for listening, and we'll catch you on the next episode.