In this episode of the Mix the panelists talk about Seniority. They lay out their own personal journeys towards getting a senior title and how they define seniority for themselves - especially how it goes beyond the ability to write code well.

Among other things they discuss:

They close with some picks which they deem valuable for anybody who'd like to dig deeper into some of these ideas.

Connect with Adi aditya7iyengar@gmail.com

Hey everybody and welcome to another episode of Elixir Mix. And this week on the panel we have Adi Iyengar

 

Hello?

 

and me, social wolf. It's again a small round. It kind of feels cozy now. And Adi and me have been thinking, what do we talk about today? And we want to talk about seniority, seniority in the context of software development. So you could also, if you want to have a clickbait title for the pedicast, you might name it, how do you grab a tasty senior title? So yes, it was an idea of you, Adi, so why don't you take the helm and tell uswhat made you think of this topic?

 

Yeah, so lately a lot of the people I mentor have been asking this question to me and I know Chuck told us a while ago that a good amount of our listeners are early to mid engineers, so thought this would be a good topic. But yeah, I mean one thing I wanted to cover is like, you know, there's like no single path to that seniority, right? We can try to like talk about things that might maximize the likelihood for you to get there, but luck, like Sasha was talking about it. before the recording that luck is a big it's probably the biggest factor and really decides what works for you, you know, you making an individual path also is a big thing like for example, we talk about side projects, right? And like I this pretty much never a point in my life where I don't have an active side project going on Like ever since I started coding in 2011 Even when I was a student Whereas Sasha said he almost never had a side project that is outside

 

Yeah,

 

of

 

I don't

 

the current.

 

do side projects.

 

Yeah

 

I don't do side projects.

 

Right.

 

Ah! He said it!

 

Yeah, so each engineer can like take different paths, you know, and still, you know, be a very good engineer and be a senior, quote unquote, senior engineer. So, yeah, do want to preface this whole episode by saying that.

 

But, you know, Adi, have you actually seen my code yet? Maybe it sucks.

 

That's another thing. Do you define a senior engineer as someone who writes good code or define senior engineer as this kind of a meta term of someone who knows what they're talking about, right? From an architectural perspective, someone who has experience, someone who, through experience, has developed the sixth sense of what's the right thing to do, right? So I think code is important as well, but I think I generally use the latter things that I described to define as a senior engineer. So yeah, even if I'm not senior code Sasha, I've talked to you enough

 

Hehehe

 

that I know you're senior engineer.

 

I'm also going to answer your question, how do you define a senior engineer? I'm going to give a very senior answer and then say, it depends. Because this is actually a question we've been tackling at the current job also because at the status quo, we have senior engineers, we have mid-level engineers, we have early career engineers. I actually prefer the term developers because I think there's a very good article series from Hillel Wayne where he goes into his software. development, actually engineering category. And spoiler, the answer is sometimes it is, most of the time it's not. But yeah, I'm digressing. So we had basically the same topic about, okay, we have some seniors, we have some mid-levels, we have some early career people, but what criteria are we actually applying to that? Because until that point, that was pretty much nearly will you get your senior and you're not, but why, right? And we now have like some levels and expectations attached to that. And... What we ended up with is not something where you say, this is like a list of things you need to check the boxes and then you're senior, boom, but it's more of an aspirational topic. So like a very good senior would potentially check all of these boxes. But realistically speaking, most people probably won't. And then you can actually look at that and say, okay, hey, this is like some skills, maybe as a mid-level engineer, you already checked that senior box, but there's also some room for growth on that. because there are some topics where you're more in the early career area. And then you can actually talk about, okay, what are some growth areas? What are some topics you might want to look into? And yeah, code and code quality is part of that, but it's not everything at all. And knowing your tools is part of that, but it's not everything at all. So if you have had somebody and they have no freaking clue how to write any kind of code yet, then probably no senior developer. But if they're decent at writing code, but have some very good understanding about CI, CD pipelines, how to set that up properly and maintainable, how to potentially design a system in a bigger sense to have fail-safes, consider edge cases, all those kind of topics. Then all of those contribute to what's getting having a senior mindset. And then it might be okay that maybe the code you've write is just average, just average. everyday code, not great, not terrible. And still, you could very much call yourself a senior developer. So I would actually because I mean, this is a set of the path to seniority can be very different for different people. How was your path to seniority?

 

That's a great question. Yeah, I think I got super lucky. As I said, luck is a huge contributing factor. My first job, it's actually a funny story. I had offers from multiple companies after a couple months of not having any offer. I got like, ended up getting a ton. Suddenly I got a bunch of offers at the same time. And I picked a small company with a salary. almost half of the highest salary I was offered. The companies that I got offers from, IBM was one of them, which often had the highest salary. And there's this company in the middle of Boston called Anc-Sam, a startupy. They were thinking of doing Elixir. At that time it was like 2015, Elixir was like just 1.0, and Phoenix wasn't 1.0. So I was pretty excited about that. And I got paired with the CTO of the company. And I chose to go there because I had a positive, instinctive feeling that if I go here, I will really enjoy. And I was not probably financially, I guess, mature enough at that point to think that double the salary could really make a huge difference. So I was like, ah, this sounds great. I'm going to go work at this company. And,

 

Who needs money?

 

uh, Yeah. Well, what happened is like my first project, because I was paired with CTO, we were a two people team, my first project was a CTO level project. It was architecting and building a new software, which talks to like a legacy Rails app and writing it in Elixir when Phoenix was just 1.0. Right. And I was like, that experience has changed my mind. Right. Like instead of using packages that people have written in the Elixir community at that time. it was so new, we were building packages. We built the authentication package. We didn't use device in Rails, we built device, right? And like that experience, two hours of working in a project like that is equivalent to like a day, eight hours of working in a project that's not like that. So again, got super lucky and that field of passion I already had of coding and allowed me to do site projects and like write open source libraries and kind of like try to push my site projects. beyond my work projects, I can bring something into our work projects to impress our CTO, who is like, you know, this like a godlike figure, like in my eyes, like he was, he was,

 

Hahaha

 

he's still the best engineer I've worked with. We actually had him on this podcast. Eric, he built, Eric Sillern was his name. He built, he started his own company a few months ago. We had him a couple months ago, but anyway, yeah. It's like having that beginning to my career, I was, extremely lucky. And, you know, because of that elixir experience and initial, you know, learning the salary also is probably much higher than what I would have been if I stayed in IBM, right? So that worked out, you know, it worked out because I did not have financial maturity to make quote unquote the right financial decision at that time and went with my gut and got paid luckily with the CTO and, you know, kind of had a company that believed in me, right? It's actually quite funny because that company, I started my own company in 2018 as well and the company I joined, they mentored me to start my own company. Again, it's just a bunch of series of lucky breaks, one after other, which again is the overarching kind of theme of career development in my eyes is luck. Sasha, what was your path? Christina, hurry.

 

I would expect that my path is a bit more traditional in that sense. Like basically I came out of my, when I had my degree, right, I started at a smallish consultancy slash agency which had a very big working contract with Volkswagen. So I actually worked at the software development part of Volkswagen. We didn't write any code for cars. We actually wrote software which was used by different parts of Volkswagen to basically send bills between each other. So like, do billing internal top Volkswagen billing software. Yeah, that exists. That was all in Java. And the thing is like, I worked there for roughly two years and that was at least, it was a very interesting experience in the context of learning. ropes of what agile development actually means, because I have to say, while there was a lot of technical depth at that place, they actually did Scrum real well. That was the really working system they had there in a particular part of Volkswagen. So still think to that day that that probably is the best implementation of Scrum I've seen yet. So that was an interesting experience to see how you can potentially deal with changing requirements, things. doing estimations in a big group of developers, all the kind of things. Uh, but I left there after two years because of what's in Volkswagen and Volkswagen's in Wolfsburg. And I don't come from that area. So I wanted to come back to where I originally came from, back to family, back to friends. And then I started a very small company because I also like Volkswagen, super big company. But yeah, I wasn't directly working for, uh, as an employee of Volkswagen, but I was still like a super big environment, right, corporate environment. And so I went to a very small company. where I did all kinds of things. I mostly did iOS development, but I also did some web development. I did some backend development in PHP. I, at some point, did some embedded development in C. So I dealt with all kinds of things. I then, after two years again, left there because it was actually too small for me. It was too stressful, just having to handle all of that. But it was also a very valuable experience in the context of having to see the. full product life, project life cycle, right? Because we didn't have any project managers, that didn't exist, there was like a company of like six people. So like we had to do all of that ourselves, sit in the rooms with customers also, like figure things out. So that gave me a very valuable perspective on what it actually means at the end of the day to take customer requirements, take something or customize an idea bot and make great working software out of that. Then I ended up at a... mid-level company because I figured hey, Volkswagen too big, right? Six people too small, why not try mid-level? It was like, I don't know, like 80ish people at that point, I think. Where I originally encountered Elixir and that was just classic agency work. So, and that was, yeah, but that was also an interesting and valuable experience in the context of, because I said, okay, I want to do more backend work. That was a part of the things I did before, which I enjoyed most. And that project also at some point took over some technical, not lead ownership. I didn't have any, like I didn't lead anybody, but I was basically the technical link to the customer. So like we had to always say like a twofold set up with like a project manager and somebody who had like this technical architecture perspective. So that was something where. where I really started to dig into what it actually means to figure out, okay, people say they need X, but actually they need Y, right? Because they, you have to drill down toward actually what, what they actually mean when they say they need X and those kinds of topics. And that, at that point I was still like, of course, at Volkswagen I was only career slash junior, then at the mid-level company, I was just a developer, right? Like everybody just was just a developer there. hired as a mid-level backend engineer, and the developer at that company. And then my next company, because I figured, okay, now I did mid-level company size, I actually like that, but I don't like this project agency work because it's just super stressful. You kind of have always a bit of headbutting with customers because they think you want to oversell them, even though maybe you don't. So it's not really, it's like more of a antagonistic relationship than like a collaboration relationship. So I was, hey, let's do product work. product work is like more aligned, everybody's aligned, I'm also deliver the best possible thing. And that is then where I landed my first senior job. And up until that point, I was kind of concerned because like I did all kinds of things, like Java, I did IRS, I did embedded, I did web development, I did front end development, and all these different things. I was like, how does it look on my CV, right? Like am I actually ever gonna end up getting that senior title because my skills are kinda... all over the place, but it actually turns out that was a boon. Um, because now, for example, this case, for example, I, um, we had like a, we wanted, we were looking for full stack people and that company was also using Elixir. So we were like, Hey, you did mobile development, front end development. You did that. I was like, it's good that you have this holistic perspective on things. Uh, and yeah, my specialization was backend, but it boils down to being this T-shaped engineer, right? This T-shaped developer, like having a developer of a lot of different things. Um. And that was also one of the main reasons like how I ended up with my current employer, which is basically that and after that, where we actually have a mobile app we're building. And I know what it's like to build a mobile app. I don't actually beneficial from a backend and developer perspective to know the daily struggles of mobile developers, to know what it means when you have to work with a device where the stable internet connection is not guaranteed. And... So yeah, that is basically why I say that most traditional because it boils down to me getting that senior title by switching employers every two years. That was never a plan from the get go. It's just how it ended up happening. Um, I hope that now I kind of am in a place where I can stay a bit longer. I'm kind of tired of switching all the time. Uh, because then I feel like after two years, you really have settled into like, okay, this is your worth for the company. Like, you know what you're doing. You, uh, you really start to feel familiar with everything. It's just for me personally that always like a different, either the environment changed in a way I didn't like or a different opportunity came around the corner, which I just was too good to pass up. Yeah, so this is my path to seniority, which then boils down to always staying curious and trying different things and not being afraid to take a jump into the unknown, you know? And it always was of help for me personally that I'm just inherently a very curious person. And I always, I never stop when I don't understand something, but it's just like, well, my brain is wired. Like if somebody tells me that this is just the way it works, I'm always like, yeah, but why? Tell me why? I need to understand why. And I think this is also, like, we don't have need to have the quality to get the scene title, but it's very beneficial as a software developer in general. Because that was also something like In the beginning, you work on a project and there's this framework and you think, this thing is magic, right? How does this thing work? It does all these different things. I could never write something like that. But if you then at some point figure out, okay, this is how you work with it, but how does it actually work? Most of the stuff out there, most of the libraries out there, they're not magic. It's just written by average people like you and me, right? Under the hood, it's still code which does things. And... I guess at some point each of us could have come up with those topics if they work long enough in that environment. It's not magic. It's not magic sauce. And

 

Totally agree.

 

that is, it helps to arrive, it helps the fiscuosity mindset to arrive at that conclusion earlier than rather than later. Because I've also met software developers which were like, I don't know, I get a ticket, I write my code, I don't care, right? I'm done. I'm here for eight hours. I'm a warm body. And that is fine. That is fine, that is a way to do this job, but it's not a way where you will excel at that job. But not

 

Yes.

 

everybody needs to excel, right? I mean, coming back to that example of earlier, like if you're in a big place like Volkswagen, at some point in the scale of, like in a company of that scale, somebody needs to write some boring code, right?

 

Yeah, totally. There's so much to unpack there. Yeah, totally agree with the last part, but there are senior engineers too, who just do their job every day and do the boring, I guess, grind, right? And they're senior probably because of the value they add to the company in terms of context they hold of the code, right? Because it'll take them probably lesser time to do some work in that code than a new engineer who is not familiar with the code, right? So... they're seen as being a valid ad, but if they decide to leave the company, they might not come across as a senior engineer because again, they haven't put work into growing and building that curiosity, feeling the curiosity that you were talking about. And as a perfect segue to a very shameless picture I'm gonna make, I do agree, curiosity and wanting to know how things work under the hood, there's a correlation of that to seniority, which is why. There's a book coming out that teaches you how to build Phoenix from scratch. And I'm writing that book. It's gonna come out in a couple of months. So if you're curious, if you wanna take that path of that kind of like an extreme curiosity, right? How to build plugs, how to, the plug library itself, how to build a web server from scratch just using TCP connections, right? This book talks you through that and eventually wrap that into like a nice, neat meta programming interface. But I'll leave a link to that in the... the show notes, but I totally again, totally agree with Sasha. That's actually also the preface of the book, right? To cross that bridge to seniority, curiosity, and like demystifying all this magic is like a, in my eyes, like almost a necessary, you know, phase to kind of be senior, like a true senior. When a true senior is someone who'd be senior, you know, at most places they would go, not because of the context, but the... tenure that they have at a company.

 

Yeah, I'm always a bit careful if it was like too senior, like because that feels very gatekeep-y. But maybe you could say, not only a senior by title.

 

Right, right.

 

So...

 

And I mean, it is actually gatekeeping for me. Like when I hire engineers, this is something I really look forward, like look for, you know. And yeah, I mean, the curiosity element and wanting to know how things work is, it's life gets so much easier if you are managing or mentoring an engineer who has the curiosity and, what's the word, capacity really, you know, to. take in that knowledge because some people just don't have the capacity to dig into something. It's very easy to mentor an engineer into an amazing senior engineer. I have mentored a bunch of those engineers. I have seen them flourish and better engineers than me. I saw that when I hired them, this person would be better than me if mentored properly and they ended up being better engineers than me. I always try to hire engineers in that category. Another thing for me, and you mentioned Sasha about this too, it's like a transition to the code aspect. I do think it's very important that someone codes well too, and I think about it, at least when I hire someone. I do like to do a live coding interview, and I think, again, the value, especially for a startup, right, like a startup who has like, you know, less than 10 engineering team. If you hire an engineer who codes more naturally, you know, like, you know, They have coded so much that it's not a chore for them to be like, oh, how should I do this? Like, just simple, who can do simple tasks without really thinking much, you know, like as a reflex action, right? Have coded enough that they naturally put code that doesn't necessarily need refactoring, right? Like, all that, it makes a huge difference when you have, like, four people who code like that and you add a person who can't code like that, right? Like, it just changes dynamics completely. So it is that one bad apple. So I do gatekeep in that aspect as well. Like I, if I'm hiring someone that person needs to be able to, you know, you know, code, think in code, you know, so like as they write code, they're not naturally able to write code because they've written enough code in their life that they can, you know, churn out code for simple solutions pretty easily. So, and that's great because in a less productive day. the less productive day, which all engineers have, it's like a high productivity, less productivity days, the less productivity days too, they'll turn out code for less complex solutions. Like, ah, okay, no big deal. Just another API call, just another test. You know, like I really like people who can code as if they are talking or thinking. You know, it just comes naturally to them. It's just another means of communication.

 

I wouldn't necessarily disagree. I just think maybe that is where, where I guess you could say that. That, that, that it depends, right? Okay. That's the beginning. Um, in a, in a startup environment of like a small team,

 

Bye.

 

you really want to like have everybody pull their weight in that context, but if you're, for example, like in a, in a legacy maintenance situation, like you have this

 

Yep.

 

system, it needs to keep it's running, it's finished. It's just needs to be keep. keep running, it needs to be maintained, it needs to be updated. It's like a completely different skill set where the ability to write new code from scratch is just not as important. And then again, that is also fine. Like there are people who very much excel at that and very much it's an area where I probably don't excel that much since I never had yet to work in a scenario such as that for a longer period of time. So yeah, it depends. But yeah, I agree that like in a small team, it's very valuable to have a group of experienced people who like know what they're doing.

 

Right. And don't get intimidated by code. That's another thing.

 

Yeah,

 

Some people

 

to me

 

get

 

that

 

intimidated

 

makes sense.

 

by code. Yeah. So that's another thing I look for. Again, just for our listeners who want to place themselves in that category, I clearly remember when I was in that category and when I wasn't, the inflection point that took me. And that was reading through Bruce Tate's Actually, there's seven languages in three days. I finished that book in three days. But just coding through the exercises and actually making sure to follow the exercise of that book to improve on the code that's in the book, that's such a great way to just change how you approach coding, change how you approach solving a problem. Instead of thinking of the mental scale of a problem, what... A problem that had a mentally for me was at the scale of like a day. After doing that, it shrunk to an hour, you know, oh, this should take me an hour, not a day. You know, like that. Infection point came after reading that book. So another book, seven languages in seven weeks, try to finish that quickly, but that worked really well for me and one of my mentees as well. But it really helps, you know, to be at a place where code comes naturally to you. especially in interviews, because trust me, a lot of times it blows people away when you are literally coding while talking. And they're like, wait, how is this happening? And all it took was a few days of hard core coding to reach that point. If any of our listeners want to be in that place, it's hard work, but only for a week or two. And I think once you find a... rhythm that works for you. It's not that much harder.

 

I'm not sure I would agree with that to be honest, because I think it might have been the case for you Adi, but

 

Yeah.

 

I mean I would expect that you already had some experience at that point. So...

 

I think I was very junior at that point. I had less than a year of experience. And yeah, I think I did have a lot of interest and passion, I guess, right? That is something I had, but yeah. I mean, another thing is I kind of wanted to code like that all the time. I wanted to code. I saw a professor of mine in my first year who kind of fell in this category. Like whenever you'd seen code, everyone would like just like. in awe, you know, like how is he just like coding as if he has a mental compiler, you know, because he doesn't need to run the code to make sure it's working. He just knows what to write. And I guess I set my set set back goal for myself a while ago. Maybe that's what helped. But I have seen that happen to one of my mentees too. Like, he also read through the same book and in a week and he kind of had an inflection point over the course of reading that book and doing all the exercises as well. So it's not just one data point, it's two data points. I don't know much, but two is better than one.

 

Yeah, I can relate in the context of that. I feel that like for me personally as a software developer, I grew very much by having to switch paradigms. So like when I when I switch from the classic object oriented programming to functional programming, and to be honest, I think it would probably be it would have been the same would have been true if I switch from function to object oriented, because it just challenges a lot of biases you might have had at that point.

 

Yeah.

 

Like, okay, like a lot of ideas how you can solve certain problems. because that's the tools you know, and now suddenly you have this completely different thing which works completely different and your brain is like, wait, what? But how? How can I solve a problem like that? And I feel like at that point your brain kind of is forced to find a more generalistic approach to problem solving.

 

Exactly. But that's kind of hidden what I was saying. The 7.197 weeks has an opposite language, Ruby, but it also has a pure functional language, Haskell. So maybe that was part of that doing that book. But yeah, I do agree. Changing paradigms is one of the best way to train your mind as an engineer. I

 

Yeah.

 

remember I did Prologue and I was like, oh my God. Like just doing like the logic oriented programming was so foreign at that time. But yeah, it evolved. It kind of evolves as an engineer for sure. I totally agree.

 

Yeah, and I think maybe now we have spoken a lot about writing code. I think one skill, which in my opinion is even more important than writing good code, is being able to read and navigate code. Because I mean, yeah, if you are in a startup situation, you have to build a system from scratch, then writing code might be a little bit more important. But let's be honest, how often is that the case in day to day work? Most of the time,

 

Yeah,

 

not. And

 

reading

 

most of

 

is

 

the

 

definitely

 

time.

 

more important.

 

Yeah.

 

Even in a startup environment, I agree.

 

Yeah, most of the time you actually need to work with an existing code base. You need to make modifications to that. You probably will have to work with code you have never seen in your life before. And you need to figure out where the problem is, if it's a case of a bug or also where some part of the logic lifts, you might want to change and how you change it. So, um, I think that is also why I've, I've used to also do life coding exercises for like, okay, let's build something like that. But I'm kind of coming around on that way. I say. I still think that coding is like something you probably should do in the context of an interview because at the end of the day, I don't see a better tool to figure out, okay, is somebody actually capable of doing it? But I'm coming around and saying like, it doesn't necessarily have to be live coding because some people might just be not, might not be good in the live context. Right. It's not very good if like somebody they don't know looking over their shoulder. Um, but I. In my perfect world scenario, my perfect interview scenario, I would say, hey, we have this existing project. It's maybe well prepared ahead of time. It's a small project, which I don't know, provides an API in the context of a backend developer, right? And there's a bug in there. Or maybe a feature, like a thing you need to build in there. You need to change a feature. And then I would ask people to set up a pull request. Like actually go through the motions of what you do day to day and navigate this unfamiliar code base and see what they do. I would potentially hide maybe one or two bugs in there. on purpose, maybe some bad variable naming, all those kind of things. Because in a very senior developer, I would expect, okay, they might catch one of the bugs, they might do some refactoring along the way, they might add some missing tests, right? They might do all of these little things which help you maintain the health of a project in the long run. And also I would expect like from a senior developer, I would expect that they challenge potentially what exactly the requirements were.

 

Yeah.

 

In that interview context, I would actually give some requirements to them which are in some places deliberately vague. Because most of the time you don't get a perfect ticket, you get a ticket which is in some places vague. And then you have to ask questions, you have to figure out what it actually means. And that is then... You can practice your coding skills day in and day out. And that is something I wanted to get at. You can do, I don't know, like some lead skills. challenges. You can do Exorcism a lot, which I think is actually if you want to get better at coding in general and like it at understanding a problem and like how tests can be written or you can write testable code, how to learn some best practices. Then Exorcism is actually a very good platform because you have people mentoring you and like especially if you engage with the mentors and Refactor your code. That's like potentially something where you can really learn these best practices very well. But that only covers part of the job. like on one area of a job. And this is what it for me means to have somebody who is like a senior software developer is, I, I know, let me start that, talk about that differently, basically. So if I have like an early career developer and junior developer, I would say, I give you a well-defined task, I give you a well-defined problem, and I'm point you where you need to put, where you need to go to solve this, right? Like for example, hey, this is a bug. This is the code base. It's probably over there figured out. But this is a very small defined problem. Like a mid-level developer, I would expect, OK, we have this feature we want to build. This is a well-defined area already. This is the thing we want to build. This is potentially inside of the app, inside of the screen. It should change to be like this. But now go figure out what exactly you do in the best way, how you can do that. And for a senior, I would say, hey, we have this problem. How do we solve this problem? And I would not necessarily like a for really about a senior developer. I would not expect to have any kind of solution at that point. Yeah. You might have, you might think this could be a good idea, but maybe there's a different solution about this, right? I want to be able for like a somebody who is really senior. I want to be able to give you, give them a problem and they come with a solution. And then if you think about it that way, coding is only part of the, like part of a tool set and yeah, you need to be very fluent in coding to actually pull that off. But it's just like, it's a foundation. I don't want to build your skills as a senior developer. I would actually be curious, what do you think about that? How do you like, what I just did there? Do you think it makes sense?

 

Totally makes sense, yeah. And I'm gonna give you the senior of the answer, and it depends, right? Yeah, how much of that is true depends really on, your definition of senior, what phase the company's at, but overall, the heart of it, it makes a lot of sense, I agree, yeah.

 

Yeah. And I mean, I wouldn't say that like a senior then has to come up with designs or anything. They might still collaborate with somebody from who's more in the design area, but they would, like a senior developer would be really be responsible of figuring out, okay, we have this problem. This might be a possible solution to it, but like we can delegate it, right? Like this is, I don't need to think about the details of it anymore. I can trust somebody to deal with it. And then when you look at that. There's coding in there, yeah, but there's also people skills in there. There's also general problem solving skills in there. And there's, I think, a very strong ability of a senior is also to decide when not to code, because there's a very great quote from Marko Heim, software, it says like, code is expensive to write, to maintain and to, um, there's something else I forgot,

 

Run.

 

to run. Yeah. And to educate, to educate, because it's expensive to write, to maintain or to educate. So. If you can solve this problem with less code, you're better off. So exactly those kinds of thoughts and those kinds of considerations are something which, for me, like where you would say, okay, this is like a senior level, this is an excellent senior level. This is really where you can go beyond and then at some point also go beyond the senior title. Like where you go, okay, now I'm going to go into a leadership position. Now maybe

 

Right.

 

I'm going to go into a principal area. And where to potentially to make a kind of the connection to some past episode, like what we talked about last week in the DDD episode, like all the strategic work. And that has been something that I've learned along the way in like this, in the small scale environment of six company of six people, because I by necessity had to do some of that work and then also inside of like the agency, like getting working with the customers. And then I looked into what is domain-driven design, what are the ideas there, like what does it mean to speak the language of stakeholders, all those kinds of things. Yeah,

 

Yeah.

 

monologue end.

 

Well, I think just to add to one more thing, right? Yeah, he said so many things that are outside of coding that make a senior engineer. I think one more thing, probably lower in the priorities, someone who can be like a multiplier, someone who's

 

Yeah.

 

addition to the team by either changing processes, by either inflicting, inducing positivity and inducing. There's some people. this is passion and other people to like code more and either like change single-handedly can positively influence the entire culture. Like, you know, maybe post-CVC, like big enough companies, it could have a huge difference. Oh yeah, I know one engineer who might not be the fastest in coding, but very good at like designing and architecture. And like, but I think his contribution is like the... He, I'll just give his name, I think it's Jeffrey Matias. He's the author of Testing Elixir, but he was community and I think he is probably the biggest reason why a lot of engineers work there or continue to work there, right? He single-handedly creates a positive work environment for everyone, most engineers, and also keeps that normal relationship with them to... help them improve and grow, right? I think that's huge, doing that in itself. Even he's a very good coder, he might not be the fastest, and he is a very good sense of architecture, but even without all that, the value he adds just by being that person, that glue, is principle and genevodic value, if that makes sense.

 

Yeah, that makes a lot of sense. And I think, I mean, that was something I said before we pressed record, but I feel our industry and especially like the social media space around it is very much into this hustle, hustle, hustle mentality, right? And the, ah, you have to be a 10X engineer, blah, blah, blah, blah, blah. And I don't buy in to a lot of these topics, but I do think that sometimes you have people which are close to that 10X engineer not because they write code so well.

 

Right.

 

but because they enable other people to run faster.

 

Yeah.

 

And like, if you're, it doesn't mean to just imagine if you have like a software developer who maybe is average in code writing, right? But they're very good at like actually coaching and mentoring and like helping people find the answers. And then there's these people mentoring maybe three juniors and they, one of, an average, maybe a junior might need three days to solve a bug, but with support from them, like maybe even half an hour, one hour, you cut that

 

Yeah.

 

down to half a day, boom, right?

 

That's a 10x engineer right there.

 

Yeah, exactly. That's a 10x

 

Yeah.

 

engineer. And that is really where I said in the beginning, it depends like in some environments in some contexts, like, I don't know, if you work in like, aerospace engineering, and like you have right software for the NASA probe, then yeah, other skills are important. And if you're making a big team where you have a lot of early career engineers and you're into those, and all of the different skills are potentially important. And I, at this point in my career, I don't describe myself as like, I don't know, a senior developer. I often just say, I solve problems.

 

Yeah.

 

My weapon of choice is technology, but the end of the day, I solve problems. And I think a good example of that is like, I talked last week about this DDD workshop we did, right? And one outcome of this is for example, now that in the leadership round of a company, we actually talking about, okay, do we need to do some organizational changes because of the things we learned, because we see some misalignment between the things we would like to do. the things organizations currently structured around that. And well, how did that came to be? It came to, it was born from, we want to change our current software architecture because it's not really aligned with how you think about the business, but we first need to really learn how the business works under the hood, how we as a company think about the business. And I already suspected that we might get to, hey, maybe our organizational structure is suboptimal.

 

Right.

 

But you can't go to the CEO and think like, hey, the organization sucks or sucks, right? But you can go there and say, hey, to actually build good software, we need to figure out how the organization works. So why not just do a workshop about that?

 

It's not like there's a law by a guy

 

Yeah,

 

that talks about that. Like, oh yeah.

 

exactly. Like there's a very excellent book which is called Team Topologies, which is basically about that as like take Conway's Law and like

 

Yeah.

 

for everybody who does not know Conway's Law, it's basically any. any organization which designs a system in a broad sense, which software is a system, is, what was the exact wording there? Is

 

S-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s

 

doomed to produce a copy of the communication

 

Right.

 

structure of that

 

I think it's opposite.

 

organization. No,

 

I think it's opposite. The organization

 

no, no.

 

takes a structure of the domains and the software.

 

No, no, I'll be other way around. It's actually a good if you any I'm gonna look it up now. I'm gonna

 

Oh,

 

look it up now

 

me too. Me too.

 

keep

 

I know it goes both ways, but let's see.

 

There's the reverse Conway maneuver, which actually takes that into consideration.

 

Oh, I think

 

Any

 

you're right.

 

o-

 

You're

 

any-

 

right.

 

any-

 

Organizations, you're right. Organizations design systems

 

Okay.

 

that mirror their own communication structure. Yep. Okay. Cool.

 

Yeah, I have it now. Any organization that designs a system defined broadly will produce a design whose structure is a copy of an organization's communication structure. And that is true. That is just true. It's insanely true. Like if you have, I don't know, and there's also like a very good rephrasing of that. If you have four groups working on a compiler, you got a four-pass compiler.

 

Hahaha

 

And if you have five groups working on a compiler, you got a five-pass compiler. And that is just true because like that's the way we humans, our brains are wired. But it's hints towards a significant truth is you can't design software in a vacuum. You can't

 

Right.

 

ignore communication structures. You can't ignore people. It does

 

Right.

 

not work because software is written by people for people. How the fuck

 

Yeah.

 

can you remove people from that equation? It doesn't make sense.

 

Right, right.

 

And I think that is like the core, one of the core things as a software developer. If you really grok that. and that really work towards making improvements in that area, like in a holistic perspective, then there's nothing stopping you from becoming an excellent senior developer in my opinion.

 

Yeah, I agree.

 

So yeah.

 

You

 

Yeah,

 

can easily

 

and like I

 

tie

 

said,

 

that

 

yeah.

 

whole BDD episode into this too. Yeah, but yeah, I agree that there's so much to it.

 

And like I said, there's an excellent book for them. It's called team topologies, which is basically about taking this idea of Conway and like, okay, what does that mean? Like how can you then structure organizations to actually deliver the kind of software you want to build? Because this is a nice side effect of it. If you accept that this is true, you can say, okay, so now how do we need to build our setup, our teams to get the architecture we want to get? To get like the system we want to get and to get fast flow where we want to get it. And yeah, this then leaves the realm. of senior developer responsibilities. But that is something that I've always done in my career. Like I always, when I came to a point of, okay, this is like my responsibility bubble, I always look beyond. I always like, okay, like what does it mean? Like, okay, I see some issues. And I see some people talk about this Conway's law thing. Like, what does that mean? Like, let me look it up. And while I was never in a position in that particular moment to actually impact the organizational structure, it gave me context. It gave me understanding about why things were the way they are, which then boils down to, again, like I wanted to figure out why things are the way they are. And it always enabled me then to go the next step in my career, right? Because I already digged into some of these topics, and that helped me to go further. And now, I mean, I basically, since the beginning of this month, I've been I've been the technical team lead at my current employer, because I bring a lot of these skills we're talking about that actually helped me get snatched that title, right?

 

F

 

And now, like I said, we have this discussion in the team lead, in the lead circle, like, hey, we need to do organizational changes. This design never stops, I guess. Assistant design.

 

It doesn't, yeah. Yeah, in fact, it's funny, you mentioned we were just talking about how, and this is like the reverse Conway, right? Like how the... us defining a domain in our software, which again, without getting too much into this, after a patient pays for our service, and starting creating that as an entire domain will inevitably create its own internetting team, right? Because

 

Yep.

 

the domain is completely different. So we just had a conversation, yeah, you're right. Those kind of conversations are also being part of being like a senior, seniority, it comes with seniority.

 

Yeah,

 

Yeah.

 

and I think that maybe to calm some nerves of that, you don't have to do all of that, but it really helps because by the nature of these topics, you will touch on a lot of subjects which are then very relevant to your day-to-day work.

 

Bye.

 

Yeah, but maybe to go back to something we said earlier, because I mean, like I said, it helps you to figure out why things are the way they are. And that is also like in the small scale and again, figure out why, like, for example, Phoenix is not magic, but also OTP is not magic, right?

 

Right.

 

It's the same, like, you understand how the system as a whole actually works, why it works the way it does, right, you don't just use processes in Elixir, you understand how they work, and that enables you to do other things. And there's also a book on that, and which I think has not aged that well, because it's been quite a lot been updated a lot, but it's the little Elixir and OTP guidebook.

 

I think it's a great book,

 

Yeah,

 

still.

 

it's a great book. I'm not sure how, like, it's, I think it's Elixir 1.3 or something. So like, you have to navigate it a bit carefully in that context. But it's what it basically does. It makes you rebuild some of the primitives of OTP, like a supervisor and an agent server and all those kinds of things. And that really enables you to like figure out, okay, how do you want to design systems and stable systems inside of OTP and why are things the way they are? So yeah, I feel like we've kind of given a complete, maybe to come back to one subject of the very beginning side projects. I mean, like, especially for example, getting fluid with code side projects are a great way to go about it, but

 

Thank

 

you don't

 

you.

 

have to. Like I'm living proof of it.

 

I mean, it's a good way of getting more experience and less years of experience, right? And also getting opportunities to solve problems that you would not otherwise have worked, especially if you're working in a big organization, a lot of bureaucracy, a lot of red tape, I guess. Then side projects give you opportunities to explore topics, I think, about domain learning design, and explore things that you

 

Yeah.

 

would probably never

 

Yeah.

 

get an opportunity at work.

 

I was always in a very lucky, to be honest, privileged position to never work, never have to work on boring stuff. Like it was always challenging in one way or never. Right now, my job right now is not be challenging because we solve super hard technical problems, but oh, we, I have to now solve organizational problems. So it never has been boring. So I never had the inherent desire to say, okay, I want to have more, even more challenges outside of my, but I always, like what I like to do occasionally is being like I've done a fair bit of like advent of coding and I did it in Haskell just to tickle my brain in ways work cannot. And I also did the pure script track on exorcism. Like I didn't complete it, right? But I did that. So that's like. look beyond my immediate

 

Yeah.

 

horizon. So yeah, you can do Cyproject, you don't have to do Cyproject. It's maybe your place of work also gives you some time to grow as a developer, right? Some innovation time or whatever you might want to call it, some 20% time. That can be an excellent source of Cyproject. That's where most of my open source work comes from. Like I've worked at places where we could invest some of our time into work-related topics, but not directly. Like I didn't have to contribute towards solving a concrete problem at work, but there still had to be related to my data-related work, so I couldn't do yoga at that time, but I was perfectly fine to write an open source library and to scratch like a personal itch of mine at work. For example, that's where Knigger was born, which was the main reason I'm on this Office Plan podcast. That was

 

Hehehe

 

why I was invited in the beginning. So, yeah, side projects can take many forms. They don't have to be from your free time. As I mentioned in the past, I have two kids, I'm married. I don't have a lot of time on my hands. And while there are a gazillion things I would like to build, I still have this idea about some application to help organize gaming events with friends. It's just not high enough on my list of priorities to end up on my schedule.

 

sense.

 

Okay, then I guess we can transition to PIX. Do you

 

Yeah,

 

have any

 

so,

 

pics for us this week, Adi?

 

yeah, not really. I mean, the two books that I mentioned, yeah, check out my book if you wanna learn how Phoenix was built and definitely check out Seven Languages in Seven Weeks by Bruce Tate. It actually covers, it has Haskell and Prologue, two of the most amazing paradigms I've worked with. If you guys wanna challenge yourself with paradigms, Prologue and Haskell are great and this book has them. Yeah, I think, oh, one more thing. I guess it's not really a pick. Maybe it's a very small point. Like, be one thing as you learn and as you start to contribute and take initiatives, you know, to show that you are gaining in seniority, just be careful of just Dun & Kruger's effect, right? Like that's something, you don't wanna make a fool out of yourself, just make sure you know what you're talking about. And I know most people, engineers don't have that, but it's something I had an affinity towards. early on a couple of times in my career so it didn't even really affect me when you think you know a lot more than you actually do and it's happened to me a couple of times so it could be embarrassing and it could be also hard to you know erase that impression once you already meet someone so just a side pick. Oh also video games right I forgot we do video games now man I was going to pick Yeah, I think I picked Stray already. I think I already picked Stray. Yeah, I think all my games have been picked. Well, yeah, if you guys are not aware, the next God of War is coming out in a couple months, so. reorder it, it's going to be amazing.

 

Don't pre-order. Pre-ordering is evil.

 

No, pre-order is good. That's

 

No!

 

how engineers get paid more. Based on the pre-orders, that's how these gaming companies determine success and that's how gaming engineers' salaries significantly influences gaming engineers' salaries in post-release sales if they do pre-orders. That's something I learned recently.

 

But it also encourages to deliver a shitty product because I mean if you already made bank, eh? Why make a great product? I'm not gonna say this is the case for the God of War, but... Pre-orders...

 

Generally companies pre-order and even early post orders for the next game, not the current game. They already have money allocated for patches and stuff. Generally that's how it works unless you're like a very new studio. Anyway, I think you should pre-order a God of War, Sasha thinks he should. But if you guys have played the first God of War, I'm pretty sure you'll like it.

 

I'm pretty much in the camp of patient gamer. I always pretend that a game gets released two years later. And then I have like a full picture about how good is this game? Is the DLC, other DLCs worth it? And oh, it's only 20 bucks.

 

Yeah, only if I could fight the addictive feeling of that instant gratification, right? But, you know, if I was mature enough to fight that, I would. I want it as soon as it's out.

 

Fair enough, I get it, but for my wallet it's been very good. I have a bunch of picks and I would like to repick some things I picked in the past already. So I would first, one repick is Specification by Example and it's an excellent book written by and now don't let me lie. It's written by... I don't find it right now. I'm gonna come back to it in a second. But it's basically a book about doing a case study on different projects and different companies doing different things. And the author extracted some do's and don'ts from these different projects. And maybe not that surprisingly, it has a lot of overlap with some of the ideas from Domain-Driven Design, even though it's not a Domain-Driven Design book. Not at all. There's never a single mention of the word domain driven design in the book. But there's close collaboration with stakeholders, with experts, and so on and so forth. And it is definitely something, if you really want to get closer to that seniority title, that senior title, it's very worth your read because it's very interesting to see how projects succeed and don't succeed. There's also a very cool... I think it's from this book. I'm not, sometimes I mix some books up, but I think in that box is like an example of like how the F-16, like the fighter jet, fighter jet was built. And originally in the specifications, it said, Hey, um, we want to have a jet which can get muck, whatever, I don't know, six, seven, whatever, like get this high speed. And at that point in time was kind of difficult to pull that off. Um, and then like the the company who took that contract, they've asked why, why, why, why do you want that? And it turns out the reason was that it needs to escape from combat if things go sour. So what they ended up building was not a jet, which could get that speed, but it was super maneuverable. So it could just outmaneuver the opponent and get out of combat that way. And the F-16, as far as I know, is still in service today, even though it's quite old, because it's, well, it has actually taken the underlying problem and found a different solution to that. And it's very, very... or if you read even in this software development book, but it takes examples from all kinds of industries and how you actually want to solve problems and find solutions. So specification by example, and it has been written by Gurkha Ajit. Right, great author in general, he has some very wise things coming from this person. Okay, another pick I would like to do and I've already hinted at it earlier is accessism. which is a great platform if you actually want to, well, maybe devil in other languages, want to learn some best practices. It's like a, it's an page where you can do code exercises, but you also have people volunteering with free time to mentor. So like you can submit solutions and then you can get somebody to mentor, to give feedback on the solution, kind of like a code review. And it's really helpful in like getting an idea about some of the best practices in the language, like how you might want to solve, how you should. approach solving problems in some languages. And if you are in your state of your career where writing code fluently is still not something which comes naturally to you, then that is not the worst place to go to, to be honest. And then last but not least, I'm now gonna do a shameless self pick because we talked about, okay, what is... What is something like coding and reading code and all that kind of coding topics are just something which is helpful in getting the senior title, but not exclusively. There's much more to being a great software developer. And a few years back, I actually gave a talk which was titled, you know nothing or do you? And that was at the height of the John Snow craze and this is the Game of Thrones craze. So it's like, it has some Game of Thrones references in it, but what it boils down to is talking about, okay. We are software developers. We like to define ourselves by our skills, by our abilities to write JavaScript, to write Elixir, to react well, to build great APIs. But there is more to each person than just these technical skills. And there's more to each person bringing experience in from all kinds of areas. I, for example, in the talk, I give an example of I'm very calm in stressful situations and that... to reflect on what I do wrong. And actually that's a skill I attained by playing a lot of League of Legends. Because doing a lot of solo queue games where the only person I can reasonably influence is myself. So yeah, and that is kind of what this whole talk hints at. It's like, yeah, maybe some people think, I don't know nothing. How can I ever be a great software developer? But there's probably more skills you're not even aware of you bring to the table. than just your ability to write JavaScript. So yeah, I'm going to pick that talk. OK, those are my three picks. So it was a pleasure, as always, Adi. And

 

Sure.

 

I hope you also enjoyed the episode, folks. And tune in next time when we have another episode of Elixir Mix. Bye bye.