Want to know what makes a senior developer? We know a thing or two. In this episode, the Jabberers sit down with Shem Magnezi, a senior developer at Wilco who shares what he’s learned over his seasoned career. They talk about the do’s and don’ts of being a manager, why small and large companies share this ONE feature, and a HUGE mindset reset that will keep you ahead of the game.

“It’s important for people to understand where they can make an impact.”
- Shem Magnezi

In This Episode

1) The KEY differences between smaller and larger companies (and how to hedge your bets when applying)
 2) What separates the novice from the expert in a company (and what managers are looking for!)
 3) If you’re considering the managerial route, consider THIS risk before going down that road
 4) Why THIS mindset shift will make your job easier AND make a larger impact on your company
On YouTube
How to Become a Senior Developer with Shem Magnezi - JSJ 521

Sponsors

Links

Picks

Special Guest: Shem Magnezi.

Sponsored By:

DAN_SHAPPIR: Hi everybody and welcome to another exciting episode of JavaScript Jabber. With us today, we've got Steve Edwards. 

STEVE_EDWARDS: Hello from Portland. 

DAN_SHAPPIR: AJ O'Neill. 

AJ_ONEAL: Yo, yo, yo, coming at you live, but not as live as last time from Pleasant, Pleasant Grove.

DAN_SHAPPIR: And Shem, and I forgot to ask your last name. Ah, Magnesic, right? 

SHEM_MAGNEZI: Yeah. Hi everyone. 

DAN_SHAPPIR: Hi Shem. 

SHEM_MAGNEZI: Oh, hi Dan. Hey everyone. Hello from Tel Aviv, Israel. 

DAN_SHAPPIR: And, uh, hi Shem. And I'm really happy that you joined us to talk today about the exciting path to becoming a senior developer, correct? 

SHEM_MAGNEZI: Yes. Thank you for having me. 

DAN_SHAPPIR: You're welcome. And before we start, can you tell us, you know what, actually I promised AJ that before everything else. I'll give him a couple of minutes to get something off his chest. 

 

Looking for cloud flexibility, but not the complexity or cost. I've got a solution for you. The name is Volter. That's V-U-L-T-R. They offer powerful cloud compute at a price that AWS and the other big tech clouds can't compete with. We've the benefits of VPC peering, managed Kubernetes, a developer friendly API and more than 20 global locations offering elastically scalable computing power. Over 45 million cloud servers have been deployed on Volter. Volta in 60 seconds or less across 12 pre-selected operating systems or their own ISO with pricing starting as low as $2 and 50 cents per month for Volta cloud compute. They offer plans for developers and businesses of all sizes. You can try Volta today by visiting Volta.com slash Jabber and you'll receive $100 in credit. That's vultr.com slash Jabber. 

 

AJ_ONEAL: So I owe a public apology to VAR and ESLint. I apologize to VAR because I said VAR, the rule of, there's one rule to VAR and one exception and I was mistaken. There is no exception. The whole try catch thing that I mentioned, I got it wrong. Doesn't happen that way. VAR is perfectly consistent in every way. And obviously the best choice of all the way to declare the variables. My second apology to ESLint. I said something about how I was frustrated with it because it can't even parse JavaScript and it's got to do this Babel thing. And I tried to use it with some sort of a sinker promises and I couldn't get the plugin to work because something, something, something. I think I might've been confused with web pack. I don't remember why I last time about a year ago, I decided not to use the ESlint other than that it's got a million dependencies, but they've turned that down to less than a hundred now, but yes, Lent. I may actually be switching to it because I tried it again last night and it seems that all of the features that I need and the things that I want to be able to do with a lender, I think, are now possible in ESLint. So I don't know if that was stupidity on my part or what it was. 

DAN_SHAPPIR: All I can add is that both of my current employer, Next Insurance, and my previous employer, Wix, we use ESLint. And it's a great tool to enforce consistency in coding style and conventions and whatnot between developers and also to avoid some of the gotchas that are inherent in the JavaScript syntax. So all in all, I'm pretty much in favor of this tool. 

AJ_ONEAL: But if you want something lightweight, JSHint. Super light, no dependencies, really secure. Well, it has a few dependencies. Sorry, not noted. It has a handful of dependencies. 

DAN_SHAPPIR: Yeah, it's interesting. I was using JSHint before. And then as I said, when I joined Wix, they were using ESLint. And I think it has to do with the ability to configure it in a way that really matches the style of whomever decided to dictate the style within that organization. 

AJ_ONEAL: Yeah. ESLint can give you the ability to write a custom language, whereas JS Hint is really just about JavaScript. You know, whatever JavaScript happens to be that particular day. Whereas ESLint, you can get really, really nitpicky and you can define a custom language. 

DAN_SHAPPIR: And now back to our scheduled show. So hi, Shem, and maybe you can introduce yourself and tell us why you're famous and why everybody should, or at least why you should be famous and why everybody should know about you. 

SHEM_MAGNEZI: Cool. Not sure about the famous stuff, but I'm Shem Magnezi. I'm a software engineer in the past 15 years, I'd say. I started as a backend engineer, did mostly Java stuff, low level stuff, C, C++, lots about like behind the scenes stuff, processing and data and big data. And after a couple of years, I went to the front end stuff. I started in mobile, in a couple of startups, in iOS and then Android. And then I say, a couple of years ago, something like five to six, I joined WeWork when they opened their tech offices here in Tel Aviv. And then I started my web development. If you can, if you can't react as the true web, then I started with React, did a couple of years there. After work, I worked in Facebook. And in the past six months, I work as a CTO and co-founder of a really new startup called Wilco like the band and like Roger Wilco from Space Quest. In Wilco, we are trying to help software engineers to grow inside their role and become a senior engineer, whatever that means for them. 

DAN_SHAPPIR: And that's exactly what we're here to talk about today. I will just add that although it seems that on the one hand, nobody really knows what Wilco is exactly about, or at the very least how it's planning to achieve what it's going to achieve. It seems to be all the hotness and everybody's like putting stickers of Wilco on their laptops and whatnot here. So it will be interesting to see what actually happens with you guys. And since your focus is about the senior developer journey, let's talk about that because I actually saw you giving a presentation on this topic at a recent conference here in Israel, a conference called Reversim, where I also happen to speak. And your session was really popular and I saw you also got a lot of positive feedback afterwards. So I would be happy to discuss that topic. 

SHEM_MAGNEZI: Yeah, it's great. And let's maybe start from the motivation. Like what is senior engineer or what does it really mean? I got this topic from my experience like a couple of like five or six years ago when I started WeWork. In the first week or something when they introduce me to the team. They say, welcome Shem to the team is the brand new senior engineer. They're joining us. And it's one that came from startups. I thought that everyone are a senior engineer, right? Like title doesn't mean anything for startup, but then I joined a real company and actually titles and level do mean something there. 

AJ_ONEAL: So define real company just for a second.

STEVE_EDWARDS: Yes, you took my question. I was just about to ask the same thing. 

SHEM_MAGNEZI: So I would say let's talk why we even had some kind of titles or levels. I think this is because they had a couple of engineers that came from Twitter or Facebook or Google. I'm not really sure back then who came out with this level system. But in the previous companies, we were like tens or a few thousands of engineers. And no one really came from big corporates or American corporates. And here in Israel, most of the small companies don't really understand what are levels and what are the typical ICs levels. I don't really talk about managers and non-managers. So when you are a small company and they don't have a lot of experienced engineers that came from companies that has these levels, you don't really understand the meaning or the importance of titles or have some kind of path or leather. That's why I mean real companies. 

DAN_SHAPPIR: So you were saying that in Israel, in smaller companies, again, it might be the same case in smaller companies in other countries as well. I just don't know, because like you, I worked in smaller companies, but only in Israel, titles matter less. More or less the division is between the the founders and the rest, you might even say. And, but when you do move into larger companies, then titles indeed start to have a meaning and to great extent, this has to do with salary brackets. Because at the end of the day, you want people of similar, like might be capabilities or contributions or whatnot to be paid more or less on the same scale or range, both for the sake of fairness, I think, and also because otherwise you're afraid that you lose them to other companies. 

SHEM_MAGNEZI: We can also talk about not only salary, but also impact. When you are working in a very small company, everyone are really impactful, everyone on its own way. But there is not a lot of difference on the impact that you can do in small company where you are a team of 10 or 20, but when you are hundreds, there is a lot of difference between someone that's just joined as a junior team and someone that is in the company as a lot of experience in specific field and the impact, two of them may vary. 

DAN_SHAPPIR: Yeah, it's also an issue of hierarchies, because again, at the end of the day, in smaller companies, everybody knows everybody. So, you know, this guy is really good at that or or that guy really doesn't like to deal with that particular topic, so discuss that with somebody else and stuff like that. In a larger organization, you're obviously not going to be able to know everybody. And in that sort of a scenario, when you understand the hierarchy, the roles, it really provides you some sort of a guidance in understanding where people fit in and what is their what they do within the scope of their organization. And obviously, people need that when you just can't know everybody on a personal level. I kind of remember the time where I realized that this is what is actually happening at Wix. My previous employer, when I joined them, they were still small enough that most people within R&D knew almost everybody else. But, and I realized that this was no longer the case when went to speak to one of the newer developers and actually told him that he was supposed to perform some task and he asked why and I thought that it's that Yaniv said that he should. Now Yaniv was the VP of R&D or is the VP of R&D at Wix and that guy basically said well who's Yaniv and at that point in time I realized that the company has grown large enough that some people just don't know even the name of the VP of R&D. And I, you know, in scenarios like that, you, you start to, you need to have roles and hierarchies and definitions. So instead of saying, and Yaniv said to do that, I need to tell them, well, our VP said that you should do that. And he's your boss's boss's boss or something like that. 

SHEM_MAGNEZI: Yeah, definitely. The alignment is very important. Both from the expectation level that what you need to do or what you expected to do and the actual day to day and the hierarchy and who listened to who how the communication works. So again, I don't think it is necessary in very small companies. Creating some kind of hierarchy sometimes hurts the productivity, but when you get to a certain size, this hierarchy works both for the organization, where the communication flows better, and both for the individual, where each one understands what is the scope of the work what you can expect and how they can grow inside the company and the organization from junior to tech lead to senior to staff and et cetera. 

STEVE_EDWARDS: So let me clarify for a minute. Am I hearing correctly that you're saying that the hierarchy really isn't needed in a smaller company but it is a larger company or are you just saying it's more needed at a larger company? 

SHEM_MAGNEZI: I think I don't want to be like it's definitely not needed in small company. I feel this is much more important when you get to a certain threshold? 

STEVE_EDWARDS: Well, as someone who has spent most of his career working in smaller organizations and smaller departments or groups within an organization, I don't buy that. I think I've just seen too many experiences where no matter how small you are, you got to have some sort of hierarchy. Who knows, who's telling who to do what? And I guess part of it is...For the most part, the people I've dealt with have been fairly professional, but there was one organization where we only had two or three developers below as CTO. But we had one very junior guy that came in. And unfortunately, he sort of fit the millennial stereotype in that he thought he was the hot stuff and deserved to have the same powers and everything else as people had been there around for years. And so in that case, you sort of need some set definitions so that people like that say, OK, they understand what they're supposed to do and how to do it. And even if you don't, even if everybody's professional and, you know, immature, some type of hierarchy is needed just to avoid confusion. You know, I guess you can put it that way. And part of that could be because I, you know, I'm part of the fire service as well and where everything is highly structured and there's a reason for it is because you have known roles, you have known authorities, you have known jobs that have to be done and it just avoids confusion.

DAN_SHAPPIR: I don't think that the organization doesn't have hierarchy at all. I think that the big difference is that in a smaller organization, and especially by smaller organization, I mean startups, less so, let's say, just smaller companies that just are like that or departments within large organization, I think that in those cases, there is a hierarchy, but the hierarchy is more on a personal level. You have authority because of you are. Everybody knows that you're a great, that you're really great at TypeScript because everybody knows you and has seen your work and you have your credibility like exists within the entire organization. When the organization is too large, is not too large, is larger, then you can't depend anymore on your just personal credibility you need to have some sort of official authority. That's a distinction, I think, that we're aiming at. Correction? 

SHEM_MAGNEZI: Yeah, definitely. Whether you are doing it formally or informally, you do need to have some kind of who decides what, who is the last voice, who is the person to look for or talk to when you get to these kind of decisions. 

DAN_SHAPPIR: So you joined WeWork and  you were told that you're quote unquote, the senior engineer in the team, and you weren't even sure what that means. So what does it mean? 

SHEM_MAGNEZI: So I started with some kind of research, like talking with my managers, talking with colleagues, people from the other sides and other companies understand what does it mean to be senior engineer in a team. And then this is started my journey. And back then, I wrote a couple of blog posts about it like what does it mean to be a senior engineer? What can be expected from one? And this started some kind of journey for me to change my role because until I got to be a senior engineer, I worked in the past that most of the software engineers work into. Like you starting from the bottom, you get some kind of task from your manager, from your product manager, from your mentor, and you slowly started building stuff, right? On first, on your first years, you get small bugs that you need to fix, a feature that you need to build, and et cetera, et cetera. And slowly those tasks getting bigger in sense of scope, and impact, the type of code that you write. But in the end of the day, most of your first years looks alike you got a task from someone above you that they already decide what's important. They already set up the sprint, set up the board, set up the priorities, and you get a task. And you implement it, test it, see it in production, see how it affects users, and then go to the next one. And after a couple of years, you start to get some confidence and started to understand, okay, what's next? Now from a single task that just fixing a UI, I'm now building a page. Okay, I built a page. What next? I'm building an app. It doesn't scale. And then you get to some kind of point that you trying to ask whether it's yourself or your manager or other people in the team, how can I advance in my career? What is the next step for to grow inside the organization? 

DAN_SHAPPIR: Before we go about growing to the next position, I would like just to give my point of view that for me, the big difference between a junior engineer and a senior engineer is a question of trust. It's not trust in the sense that I think that somebody would try to convey incorrect information. It's more a trust in that person's ability to complete a task on their own. Um, when it's a junior, my trust level is fairly low. Uh, after handing the assignment is going to be very well defined and I'm probably going to monitor progress a lot more often. Uh, and then, you know, ask questions like is, is everything going fine? Show me what you're doing. Can you explain your thought processes, et cetera? When somebody is a senior, I feel much more secure in handing them a more, a bigger problem without such exact specifications and expecting them to either complete the tasks on their own, you know, ask questions that are not clearly specified in the specifications. And if they run into some sort of an issue which prevents them you know blocks them then to raise the flag on their own rather than just you know spin cycles trying to literally being stuck against some sort of a roadblock and not being able to make any progress. So that for me is the big difference between a junior and a senior. What do you guys think about that? 

AJ_ONEAL: I think that's a difference between a junior and a mid-level. I don't think that that's the difference between a senior So and I see your nod in your head, Shem. So maybe I should let you go where you want to go with this, but I'm kind of looking at your engineer growth path slide. And there's this ramp where there's kind of a significant difference between student and junior and junior and mid. But then the difference between mid and senior is long and little slope. 

SHEM_MAGNEZI: Yes. Like the, the independence of the individual and the amount of tasks that he can take on by himself. It's really crucial for the first part of his career, as AJ put it, from junior to mid, okay? Because as you said, the difference between those roles really depends on how they handle, like you say, you give them a task or a problem, and now they're gonna handle it. There is a step or a point in your career where you don't get tasks or problems to your hands. You are the one that needs to go and scout and find the problems. And this point is crucial because there is points in a team or in a manager work where they don't have the time to find the problems that they're going to tackle in six months from now or three months from now. Maybe because they don't have time. You know, managers have so many things on their plate. Maybe because they don't have the technical skills, because after all, they are managers, maybe not the most technical expert in the team. So there are some problems that they don't see, whether the managers or the product managers or someone there. And this is the crucial role for the senior engineers, because they know the code so well because they are expert in JavaScript, for example. And they are the one that need to raise a flag to find those bugs, to find those problems, and to be the ones that prepare the team, prepare the code, and scouting for those problems. And this is the big difference. You get a lot of confidence in the people that will be able to deliver. And then this confidence should somehow become confidence for them to raise flags and show and shout for problems that you or your team don't know yet. And this is how they will change. 

DAN_SHAPPIR: What I've, what you're describing, I've seen in some organizations, I think Google, for example, described as technical leads, people within teams that are, don't allocate the tasks as it were, don't decide necessarily who works on what, or, you know, follow the, the Gantt chart to see progress and stuff like that but rather decide on the technical solutions? Is that kind of the role that you're trying to describe? 

SHEM_MAGNEZI: It might not be a technical solution. This is what I'm saying. Maybe it will be a process solution. Maybe it will be a product solution. But yes, those are the people that may be outside of the gantt, or maybe they will take and create some kind of ad hoc team to to solve a specific problem that can be via technical solution, but it might not be a technical solution.

AJ_ONEAL: So I agree with what you said there in particular about the, it's about the process, defining processes. Cause I think that's the big difference between a mid and a senior. A mid is gonna get the job done on their own. A senior is going to have developed the, the, What's the right word? Maturity isn't quite what I'm looking for, but, but the ability to, to follow a honed process that's, that's going to lead to simpler code and more correct outcomes. So when I think of, you know, the people I think of that are great examples of this in the community, they're the Rob Pikes, the Dave Cheney's, the Matt Ryers, the Douglas Crockfords, despite the fact that Douglas Crockford's not particularly a personable person, but these are people who have a process defined by which they choose to make code decisions, not based on whatever works, but based on what's going to be readable, what's going to be transferable knowledge, what are patterns that are going to make debugging easier. It's the holistic approach of, I guess the way that I think that Rob Pike summed it up is, the senior engineer is the person who focuses on making code transferable between teams. So something like that.

DAN_SHAPPIR: I do want to say that in a lot of organizations, the terms senior engineer doesn't necessarily have to do directly with capabilities, certainly not the ones you described. It's just a matter of rank and seniority. So somebody might be defined as being a senior engineer simply when they're no longer a junior engineer and from the organization's perspective, they stop being a junior engineer after two years or maybe three years. So it would be great if these kind of titles went along with capabilities like the ones you described, but that's certainly not always the case. 

SHEM_MAGNEZI: Yeah. More cases, for example, that are people that are five years in the same team. They know every bit and bite of the code. They know every bug and every product, every feature and everything in the code. And they are like the expert in this specific team, in this specific code, in this specific system. And they are considered senior or the most senior person in the team. But if they will move to another team, even in the same company, they won't be senior anymore, right? Because this is a new code base. They are not senior anymore. And for us to calibrate the senior level. It doesn't matter if you're working between teams and you're moving between departments in the same company, you should be still the same with the same title, with the same salary, with the same impact. So for me, this is the tool to understand if this is a truly senior title or just some kind of mechanism for the team lead, for the manager to give some kind of arrays or to keep people in the team.MSo they will be able to have the title and won't leave. 

DAN_SHAPPIR: So how would you differentiate, for example, between a senior engineer and architect and tech lead? 

SHEM_MAGNEZI: Yeah, this is a great question because there is place for architect and there is place for someone that is really expert in the team's code, but let's not call them seniors, so we'll be aligned or a tech lead, like some people call tech lead as a manager is equivalent, but let's say manager is a manager. Tech lead or architect is someone that know the code and the system, this specific systems, this specific code very, very well. And is the one that should go to when you need to implement a very big feature and you need to advise how what is the best way to integrate it into the system, into this specific system. This is for me an architecture technique, okay? And it's really, really hard to get from outside and start as a technique, right? Because you don't know the system. But senior is a different mindset, it's a different role and different expectation. Someone from outside, that for example came from Google. And so how monoreports react and how hundreds of people, hundreds of engineers working on the same code base is not, have the knowledge to help, to help company to grow. And this senior from day one. 

DAN_SHAPPIR: For me, a difference between a senior engineer or a principle engineer or anybody that goes that route and an architect is the level of abstraction at which they work. If I kind of use an analogy, and all analogies are obviously imperfect, but if I use an analogy to architects with houses, where the term kind of originates from, then it's kind of the difference between the master mason and the architect. Like the architect designs the house in its entirety, but if you want to have the best bricklayer, that wouldn't be or the guy that deals with the electric wiring or the plumbing, that wouldn't be the architect. That would be somebody with that level of expertise that's more down in a particular aspect of the system, as it were. So for me, a senior engineer or a principal engineer or something like that is somebody that deals directly with the code. An architect might deal with the code, but they should be looking at the system more holistically of like, this microservice should be talking to that microservice and we should be using this kind of protocol and stuff like that. Now, obviously, this is a distinction that doesn't always exist. I've seen people that work throughout the entire spectrum. I've also seen organizations that define these things differently because our field is not really a precise one. People, I know that a lot of people, for example, even just get upset for the fact that we use the term engineers for people who don't have an engineering degree. And I like to remind people that there's a difference between being a software engineer and being, and having engineering degree in computer science. One is an academic degree and the other is just a job title. And as a result, these kinds of distinctions indeed do become vague when you're trying to compare different companies. 

AJ_ONEAL: When you talk about the school aspect, so at least where I am, computer engineer actually refers to someone who works at the board level, not someone who works at the software level. I think that maybe one of the schools just introduced a software engineering program that sounds to be like the kind of definition that Rob Pike would give as what software engineering is because I agree. The terms get thrown around to mean anything and nothing. There's a lot of appropriation and co-opting and trying to make people feel better and politics, but I think there, I think it's virtuous to try to set a bar and a definition that is somewhat static and can be measured and can be attained rather than just throwing anything around. And I understand that we're not going to change the way that the majority of companies choose to build their professional ladder. But I think that within the community, we can arrive at definitions that work in order to describe methodologies and, uh, levels of education or teaching, you know, that it's just, but this goes back to my whole argument against cost from last week, right? If you change the definition of something to mean anything that you want it to mean, it becomes a useless word. And I, at that point, I'd rather not use it. And I think software engineering has a meaning. Yeah. 

DAN_SHAPPIR: But the reality, and I'll tell you what the main meaning is these days. If you're recruiting a software developer, then many organizations would just use the term software engineer and that's, 

AJ_ONEAL: which is not correct at all, 

DAN_SHAPPIR: but you know, again, that kind of goes with the fact that once enough people use a particular term in a particular way, then that effectively becomes a definition of the term. 

STEVE_EDWARDS: Literally. Yeah. I prefer to make it easy on people and just tell people that I'm a computer geek, and then that way it just, that throws all kinds of pictures at them, and I just let them figure out what I really do. 

AJ_ONEAL: That makes me want to ask you what TV I should buy, and...what kind of frame rates I can get on a PlayStation. And you say it that way. 

SHEM_MAGNEZI: And why my printer is stuck. Yeah. 

STEVE_EDWARDS: I say, I guess I should say software computer geek, not hardware. 

DAN_SHAPPIR: Yeah, but you were going back to something that I don't remember who mentioned it here, but the concept of ladder and progress. Let's say I joined a company, and this is maybe my first job, and I'm obviously a junior software engineer, we are an engineer in academic terms or not. And I want to, you know, progress. I want to have a career. First of all, how do I choose to become a senior software engineer? Why would I choose to be a software, a senior software engineer? And how do I get there? 

SHEM_MAGNEZI: Yes. I think this is the motivation for, for starting all this discussion, because if we like remove all titles and remove everything and we won't put labels on people, so it will be the easiest, right? Because everyone can do anything and everyone can impact the team and build its own tools and go its own path. But I think it's really important for people to understand where they can move forward, how they can move forward, how they can make more impact, make more money and advance in their career, right? I really think this is important for everyone in the company, no matter if they are engineers or software engineer or product or designers. I really think this is the main cause of all the discussion of senior came into conclusion. First, we need to understand that there are two types of advancement in the career of software people. There is the natural advancement that most of the of the companies and people have is to become someone's manager. Okay. And you manage people and you manage more people and you manage managers and et cetera. Okay. This is the classic pyramid that every department and not just computer have. Okay. 

DAN_SHAPPIR: It's always kind of amuses me this progression that a lot of developers choose because a lot of us got into software because in some way or another, we weren't so great with people. So why do we actually want to deal with people instead of dealing with software after investing so much time, you know, learning software and getting away from people? It amuses me kind of like the fact that all our social networks were designed by people who were totally asocial, at least in high school. 

STEVE_EDWARDS: I will clarify that Dan said not all of us there. Yeah, not all. Most.

DAN_SHAPPIR: But yeah, so I'm always kind of amused by that, but I totally appreciate it. I mean, you know, like you said, I want to move ahead. I want to have a greater sphere of influence. I want to have a great, uh, higher salary. I want to, uh, tell my, my parents that I'm advancing in my career and being a manager is understood by everybody, whether they're in the tech industry or not. 

SHEM_MAGNEZI: And there is a lot of value there because in the end of the day, you can do something. But you, this take you this far. As a company you need to move as a company, as a team. And if you want to move as a team, most of the time you need some kind of leader to move the team in the right direction or a direction as a team. So this is needed. But this is a very really other discussion than what we are doing now. As you said, a lot of people don't want to manage, including me. Like I've been a manager, it was nice. I didn't really feel satisfied and I really wasn't that good at it. So what are the alternatives? If I want to keep coding, I want to work with code, work on the technology. So what can I do now? Will I forever be a regular person inside a team and won't get advanced at all? That's why a lot of corporates, and it started with corporates, started to build some kind of professional ladder. So for individual contributors, and I really don't like the individual part, but this is how it's called, individual contributors can advance in their career. And same as you became a manager, you became a senior engineer. And same as manager became senior manager or group manager of something, you became a staff engineer and a principal, and etc. etc. 

 

Time is of the essence when identifying and resolving issues in your software, and our friends at Raygon are here to help. Their brand new alerting feature is now available for crash reporting and real user monitoring to make sure you're quickly notified of the errors, crashes, and front-end performance issues that matter most to you in your business. Set thresholds for your alert based on an increase in error count, a spike in load time,or new issues introduced in the latest deployment, along with custom filters that give you even greater control. Assign multiple users to ensure the right team members are notified with alerts linked directly to the issue in Raygon, taking you to the root cause faster. Never miss another mission critical issue in your software again. Try Raygon alerting today and create a world-class issue resolution workflow that gives you and your customer peace of mind. Visit raygon.com to learn more. Their simple usage plans start from as little as $4 per month with unlimited apps and users. That's raygon.com to start your free 14 day trial. 

 

DAN_SHAPPIR: Before we go more into detail about that, Ruth, I do want to say a few things about the managerial track because like you, I also got into that track and I went as far as to manage approximately 30 people and realized that I don't like it a whole lot. So I'm not totally adverse to any form of management, but being like a pure manager at least back then was not for me. I will say though that a lot of people kind of fall into the trap of management. What I'm saying is that, you know, you're a developer, you're pretty good at what you do, you have kind of a leadership, people perceive you as kind of having leadership skills so they advance you to a junior manager where you're still pretty hands-on. So you manage a few people, but you may also touch the code yourself. But then let's say you're also good at that and you get advancing to mid-level management or something like that and all of a sudden you definitely don't have time to look at the code anymore and all you do is just managing all the time. Now you might be pretty miserable about that because like you said you may have gotten into software because you actually enjoy doing software, but you don't want to go back in on in the advancement ladder. Like people see you in a certain way and you get a certain salary, a certain degree of respect, a certain position within the organization, again, even the way that your family perceives you, or you see yourself and you don't want to move backward. And what I've seen is kind of the Peter principle in effect, that you advance along the management ladder until the point where you're totally ineffective anymore, and that's the stage at which you get stuck. So you kind of get, so few people are actually really good at management. They really enjoyed the whole lot. They're, they're, they, you know, it comes naturally to them and they advance into upper management or become senior managers or maybe start their own company and become managers there. But a lot of people just kind of get stuck as mid level managers and people don't understand, don't appreciate that that's a really risky position because whenever there is downsizing whenever the industry takes a turn for the worst these are often the first people to go because you need your developers they're the ones that actually write the code and obviously the senior managers aren't going to fire themselves. So who are they going to get rid of? Well, they get rid of the mid managers. So instead of a mid manager managing five people well, we'll have mid managers managing ten people and we can get rid of half of them and finding jobs in that situation can be really challenging because if you've been away from the code for too long, it's really difficult to get back into that game. At the very least, you'll be seen as a junior again, which will be very problematic. So I've seen situations in which mid-level managers are the first ones to lose a job and then have a really hard time of finding their next position. So that's one thing to remember.

SHEM_MAGNEZI: Yeah. Yeah. My joke has always been that those who can do those who can't manage, but, uh, you know, I've seen those who just top manage 

DAN_SHAPPIR: and those who can't manage teach and those who can't teach consult. I, I'm trying to remember the whole progress of things. 

STEVE_EDWARDS: But you know, it's been interesting over probably the past year or two, I've seen various blog posts and discussions of people who are in that. They were so senior developer and it seemed like they're only their next step up was to be a manager, you know, tech commander, someone who's managing, and they've done it and realized, I don't want to do this. I want to do the actual, you know, boots on the ground, work coding, and so they'll step out of that role and take, I guess, what's considered demotion back down to a senior developer or something like that. So I agree, manager, you have to want to be a manager in order to be a good one. And not every developer, you know, has those skills, even though. A lot of times it seems like the natural progression is, okay, I'm a good developer, now I'm going to manage people. Well, not necessarily. And there's been a number of people, I know they've been managers, but they do everything they can to code as much as they can because that's where their true love is. 

SHEM_MAGNEZI: I will add to this that you always need to remember that this is a pyramid, right? In management, this is a pyramid. And you get to a specific point, a certain point, when you need someone to leave, to get fired or something like this. And until then, you're just stuck. And, and this is something that people understand only when it's too late. When you're a group manager and you say, okay, you certainly, you suddenly understand that you are stuck in this position for the next three years. 

AJ_ONEAL: So I, I want to take a step back, you know, back to the slide that I'm looking at here that I think is really relevant. I don't know what your axes are because it's just a curve and the curve starts off steep and then slows down. But you know, you could look at this as time and money. And I think one of the reasons that you would go into management is you kind of hit a glass ceiling as a developer. Either you have to go into consulting where a lot of what you're doing is managing expectations. So you're helping people to understand what their problem is because people come with kind of a vague idea of what they think they want, but they don't really understand the implementation implications or things like that. So you have to come on as a consultant and a lot of your role becomes helping define the work to be done. Or likewise, you have to go into management where a lot of your work is helping define work to be done and helping people work together. Because once you get past mid-level developer, you don't really get rewarded very much for being a senior in terms of compensation. And neither in terms of recognition, because there's very few people who can even know whether your ideas are better or worse anyway. 

SHEM_MAGNEZI: I agree. First, I love to look on the YSX as not money, but impact, because this is more aligned between companies and countries and cultures. So this is something that is slowly linear advancement instead of exponential advancement, specifically in the beginning. But yes, I agree because there are some teams that just don't need a very strong engineers. They don't have tons of problems or very hard problems, at least in the far future. And then you feel like you don't advance if you don't manage someone. And it's really similar to consulting if people are moving to consulting, because again, you know the technical bits and bytes, and then you tell others, okay, you need to hire this person, you need to pick this technology, you need to start with this POC, and I will code you something so you hit the ground and start running. And that's about it. But there are some companies and good managers that understand the value of senior engineers or senior engineer mindset. And those company, those manager will take these talents and will start give them the freedom to scout for problems inside the organization, to let them sit in product roadmap, let them sit and talk to it, the customer success. And they will just leave them alone with some kind of guidance, of course, to go and scout for problems. And this is very crucial for each individual to find those good mentors, managers, good culture inside the company. And there are very few. They're getting much more, but it's still very few. And in this graph, there is like a question mark there, right? How do you get there? Because me as someone that sits inside a team, I really don't know what to do. Like my scope is very limited I don't have all the context. I don't have the freedom to go out and ask. I don't know what the company is planned to build next year. So it's really confusing for me when I'm sitting inside the room of the company, of the team, right? 

DAN_SHAPPIR: I will say that the situation in this regard is much better than it used to be. But before I say that, we will obviously put a link to your presentation in the show notes. So folks, if you're wondering what graphs AJ and Shem are talking about, don't worry. You'll have the link in the show notes and you'll be able to see for yourself. But I think that the situation you're describing is much, much better than it used to be. I think that with so much demand in the tech industry and a growing understanding that the quality of the people that you're able to hire is going to have a dramatic impact on your ability to succeed. I think that a lot of companies are, these days, are starting to understand the value of senior engineers according to the way that you're defining them and to give them those capabilities and freedoms that you're describing. And if the company that you're working at doesn't give you that level, degree of trust and freedom, then I'm certain that you can find some other company that will. 

SHEM_MAGNEZI: The question is, how do you find them? especially from outside. How do you know there is someone there that will give you the freedom to do so and they have the leather and they have the career for you to support it. So I agree that there are more and more companies like this, specifically in Israel. In Israel, we are fairly new, especially in big companies and big corporates. We didn't have a lot of them five years ago. Now we have more than this. But yes, more and more engineers are exposed to those ideas, exposed to this kind of option for them to improve and advance in their career. And definitely in the past few years, there are much more options to advance in this path. 

DAN_SHAPPIR: I will give a few of my own recommendations about how to find positions like that, especially when switching companies. First of all, you can check the LinkedIn of people working at profiles of people working that company and, and see like positions that people hold. You might also want to see if you recognize some people from giving, from giving technical talks at conferences and stuff like that, because that's a good indication that those people are experts in their field and get are properly recognized by their company for that. I would also say that when you're interviewed, ask specifically about that. You know, obviously not everything that will be said and promised in an interview will actually hold up, but you can kind of gauge the response that you're getting. And also the compensation that you're offered will be a strong indicator of that. If the company is willing to give you a higher compensation, that's a at least some sort of an indication that they want, at least they want to make proper use of your capabilities because otherwise why is it worth it to them? Now obviously again, no guarantees, but if you join a company that doesn't work out, you can always leave and join some other company. 

SHEM_MAGNEZI: And I will also ask, like, what level am I interviewing for? And if it's like senior engineer, I would say, okay, what should I do to interview for a staff engineer? or a principal engineer. And if they have these kind of levels, if they have this kind of letter, they will say what you need to do, what kind of interviews you need to pass. And if they don't, so this is a big flag for you. 

DAN_SHAPPIR: I think we're close to wrapping up. Before we do, I want to ask you kind of a last question. Hopefully it's not too big. And it's okay. Let's say that I've decided to to pursue this career path, that's where I want to go. I want to evolve as an engineer, senior principal, et cetera. I think I know how to find companies that will enable me to achieve that, but what do I myself need to do in order to get there? 

SHEM_MAGNEZI: So I think you need to, we always talked about changing mindset. Instead of waiting for problems to come to your door, to your hands, you need to practice and scout for problems. It's not looking for problems because problems are not laying out there. You need to dig deeper. That's why you need to scout. You need to talk to your product manager. You need to talk with customer success. You need to talk to even the CEO. I'll give an example. I really think that examples are the best way to understand how the mindset is changed. Let's for example say you are working on a team, on the front-end team, you have a fairly big React app that is a client render, a single-page app, very, very regular, and there is nothing stopping you from implementing the next four months features. You are aware of the roadmap, you saw the roadmap kickoff in the beginning of the year,looks smoothly. And then somehow you came across a marketing roadmap and the planning how to get to the market in the next six months. And you discovered that you are going to some kind of product-led grow strategy and the marketing are assuming that your product will have some kind of It's really straightforward. But if you are in the room when they are deciding about this kind of strategy, and you already know the system and you have the technical mindset and you know how the system look and build, you understand that the verbiage will be broken just because it's a client-side application. And when people will share, they won't have any preview like SEO preview titles and images and stuff like this, because this is a client-side application and each page won't have a different title and different image tag and different description and et cetera. So by sitting in this room, by being aware to this kind of problem, being aware to this is the direction that the product goes to, you are the one that responsible to raise flag and say, maybe for this kind of strategy, we need to think about server-side rendering or something like this to tackle this problem. But if no one that know the system, that know React, that know JavaScript, that know the technical aspect, both the technical aspect and the product aspect, if no one was there, you will tackle this problem four months after, where it's where it will be too late, right? So that's why I'm saying you need to go and scout for problems. Problems that will be six months from now that your product manager won't be aware of. Your team lead won't be aware of. Your marketing people won't be aware of. And these kinds of problems are everywhere. 

AJ_ONEAL: But when you discover those problems, how do you convince other people that they are problems. 

DAN_SHAPPIR: That's where the fact that you're the senior engineer or the principal engineer comes in. You're supposed to be recognized by the organization as the senior technical person in the room. You might not be the manager. You might not be the final decision maker. You might not be the best one defining the user experience or the product features or whatnot. But in terms of the technological step, and at the end of the day, we are, this is a technological podcast, I assume that most of our listeners are people who are working in companies that deal with technology. There needs to be a technological expert in the room, and that should be you. 

AJ_ONEAL: Well, that makes it sound to me like the way to become a senior engineer, not just in your processes and your results, but in your recognition is maybe to switch jobs to get that, you know, because I mean, I guess you could, you could by long time demonstrate, Hey, I can't consistently have these good outputs. I consistently have good foresight, but it might take a lot longer to develop that within a company where you're at than just switching to another company and passing an interview that's testing for those sorts of decision-making skills or, or, you know, foresight.

SHEM_MAGNEZI: I agree, you need to somehow build this reputation within the organization and you need to start from somewhere. So there comes your communication skills and the mixing between product mindset and technical mindset and a little bit of project management mindset and above all of them communication mindset. Because you said or you heard about the planning to go this direction and your technical mindset came handy and say, okay, we're going to have a problem a couple of months from now. And then you need to go and convince people. Okay? You go and convince maybe your manager and then when he's convinced because he knows you and it makes sense what you say and you and they know that you are good and know the system and fairly familiar with JavaScript. And together, and after you convince him, you go and convince his team, his manager. Okay, there is a lot of groundwork to do and convincing to do and building a case and maybe writing a document and maybe send this document to 20 people that someone will be hooked. But yes, you need to build the resupply reputation together with your manager. Hopefully that he will help you to build a case But you do need to build a case and you need to build the case over and over and over Until you get this reputation 

DAN_SHAPPIR: and I would add to that that if you are defined as a let's say a principal engineer But you don't have the ability or the authority to walk into a VP's office and tell them, you know we've got a technical problem, technological problem with the way in which we're doing something or heading in a certain direction, then you're not really a principal issue. And I think that with that, we actually need to kind of wrap up and move into picks. 

 

Hey folks, this is Charles Max Wood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast, and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs why I changed it from DevChat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with DevChat.tv and I renamed it to Top End Devs because I want to give you the resources that are gonna help you to build the career that you want. So whether you wanna be an influencer in tech whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I wanna give you the resources that are gonna help you do that. We're gonna have career and leadership resources in there and we're gonna be giving you content on a regular basis to help you level up and max out your career. So go check it out at toppendevs.com. If you sign up before my birthday, that's December 14th, if you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com. 

 

DAN_SHAPPIR: So Steve, why don't you start with the picks? 

STEVE_EDWARDS: Oh, so we're gonna move early into the high point of the podcast. Okay, so for today, all I really have is a couple of my patented dad jokes called from the huge list of dad jokes out there. So years ago, before my wife and I got married, we were dating and I told her, you know what? There's no girl on planet earth I love more than you. And her next question, of course, was, what about the other planets? Where's my drum roll? 

DAN_SHAPPIR: You've had better Steve. 

STEVE_EDWARDS: Oh man, my drum roll's not working. I am seriously bumming here. 

AJ_ONEAL: Okay. I just, I think that one feels a little bit too far from reality. 

STEVE_EDWARDS: Which part? Me telling her that I loved her or her asking that question? 

AJ_ONEAL: There's your drum roll. 

STEVE_EDWARDS: And then second, second joke, last one for the day. So when my, my oldest son, he's 19. He's a very good athlete, really athletic. And when he was little, I used to play football with him quite a bit. Then my wife forced me to actually get a ball. 

AJ_ONEAL: Pfft. Ha ha ha ha ha. Ha ha ha ha. 

STEVE_EDWARDS: Dang it, my drum roll's not working and I'm seriously bummed. Anyway, those are my picks for the day. 

DAN_SHAPPIR: Okay then, moving along. AJ, what are your picks for us? 

AJ_ONEAL: All right, so first of all, let's see. Let me take a couple of just things from what came up during the show that actually didn't say either of these. So there's, uh, somebody created this, this little code snippet, junior programmer code, mid level code and senior code where it shows different ways of running a function, do something with a property object.bas. So just, you know, one of those little, but I thought it was hilarious and so on point. So I want to share that with you. I don't have a link to the image itself, but I have a link to the meetup where it's the banner for the, the meetup. So if you want to check that out and then there's a link to the original Twitter post, it's just not formatted quite as nicely. And then also I'm going to pick, uh, do my own creeds of craftsmanship.com because I think it's super relevant to what we're talking about here. If you are interested in becoming a software engineer, creeds of craftsmanship.com is a great place to go because it's where I am curating the talks and presentations and materials I find that are just of the utmost quality and not all of these people do I agree with 100% you know, crackford I'm, I'm pretty much 98 there. I would say probably the same true is true of Rob Pike and Dave Cheney and Matt Ryer, but there's also some, some of the people that I don't necessarily like or agree with, uh, have material that is defensible. And I think that's the number one, I don't know whether you say criteria or litmus test, but, but are you presenting an argument that's defensible, that's reasoned as for why you're constructing the processes and structures for your code that you're producing? And so I think that it's valuable to look at all of the well known and top philosophies about code to kind of get where these people choosing what their trade-offs are in their, their style and their processes, because you can learn a lot from that even if it's just, yeah, he's totally wrong. I don't want to do it that way. Then after that, I'm going to pick again, artings.com. I think it's supposed to be pronounced ratings.com, but it's just R and T and then INGS these guys just do a bang up job of doing testing on consumer electronics. This is basically a free and probably better version of consumerreports.com in terms of if you're going to buy something and you go into the store and you look on the back of the box, it's a complete crap shoot, both in terms of what the thing costs and in what features are listed on the box of whether or not it's any good, you know, when you're talking about TVs, headphones, whatever it might be and the people at our teams actually test the stuff and give you a objective metrics as to how things perform in terms of something like viewing angle or sharpness. They actually are using tools to test the brightness of a TV or the decibel output of headphones, et cetera, et cetera. And so you can kind of figure out, well, how do I spend a lot less and get something that is really, really good? Or how do I get something that's actually the best despite what's on the sticker. And my wife really wants me to get the projector out of the living room. She hates the projector screen. And I finally came around to my sensibilities and decided to get a TV instead. And so I used them to make my decision, which happened to be the Hisense U7G, which I think is just best bang for buck in terms of, I can't imagine spending $3,000 for a not cheapo TV, but you know, still I hate bad screens. I just hate them, especially when you're an apple snob and you're used to an apple screen going to something that is washed out color and dim and low contrast. You know, if you're an apple person, you know, if you're not an apple person, maybe you really don't care if there's a green tint to your screen and you don't notice, but anyway, I really appreciate that, that, that website, just because I've used them several times now when making purchases and I just feel better that, yeah, I'm really getting, it's an imperfect world, but I'm getting the best thing I can without being stupid about spending money. So that's what I got. 

DAN_SHAPPIR: Cool. Okay. So now it's my turn. My first pick actually has to do both of the topic of our show today and also something that you said in your picks, AJ, and it's actually going to be a tweet that you kind of recently tweeted out in which you said, and I quote, React has turned static landing pages into enterprise fizzbuzz. I can't even. And if I could have liked it 10 times instead of once, I would have. Because I'm talking about the roles of senior engineers and picking the correct technological stack and stuff like that. You know, you're a totally on point. I'm seeing so many websites, web pages out there implemented using React or some other frameworks where they should literally just be a static landing page, you know, and like you said, I can't even. And it's gotten to the point, by the way, that I sometimes think that the technological choices are being made based on how can we recruit engineers to work on that? Because we know we can't recruit engineers to work on WordPress, but we can recruit engineers to work on Next.js. So let's do it using Next.js.

AJ_ONEAL: I think that, well, that's, I kind of said that in pretty much those words several times on the show. 

DAN_SHAPPIR: Yeah. 

AJ_ONEAL: agree. 

DAN_SHAPPIR: Let's put it this way. React has a reason for existence. But if you're just building a simple landing page that's mostly static, that's not it. Anyway, that would be my first pick. My second pick is the TV show, The Wheel of Time. I recently actually subscribed to Amazon Prime because I don't know how they're priced in the States, but here in Israel, at least they're very cheap, relatively speaking. So I said, why not? And also they've got an evaluation period. And then I started watching the Wheel of Time. Now I actually had, interestingly, had high hopes for the series, not because I liked the books, but actually rather because I didn't like the books that much or more accurately, I enjoyed books number one through three or something like that. And then it went downhill very quickly for me and I basically gave up on it. And the reason was that on the one hand, the setting was very imaginative. The characters were interesting to begin with. And so was the story and the setting and whatnot. But then it got to be really repetitive for me. And it seems to just go on and on and on with no end in sight, especially when characters after they were killed were brought then brought back to life in the next book. So you say, hey, I thought we got rid of that bad guy, but there he is again. 

AJ_ONEAL: I haven't gone through it all yet. 

DAN_SHAPPIR: Okay. Anyway, so I was really hopeful that the TV series will tighten up the story, get rid of extraneous characters and move things more quickly along and not retell the same thing from three different viewpoints. And to an extent they did, but then they went ahead and kind of did it too much. So, uh, there's, there's a way in which you tighten up stories and you do that, not by trying to cram in everything, but then giving everything only like a minute, but by actually dropping things that are less important. So if you're going to leave a certain story detail, make, you know, if you just keep it there for a minute and then move right along, it becomes kind of jarring and disconcerting. And that's the problem that I'm currently having with the series, but hey, I just finished episode two. I think I'll give episode three a chance, but if it doesn't improve, that will likely be the last episode that I watch. 

AJ_ONEAL: It goes up and down. 

DAN_SHAPPIR: Also, you know I don't want to give any spoilers so I won't say anything else. My last pick is going to be a book series that I've started reading, which is called Old Man's War. It's not an excellent book series, but it's highly enjoyable. It's what's usually called hard sci-fi. It's kind of an inverse Star Trek. It's like you know, all the issues that you have in Star Trek where all the aliens kind of speak English and are exactly the same degree of technological development across the entire universe. So it kind of suffers from the same problem, but it kind of looks at it from an inverse perspective, whereas with Star Trek, everybody just wants to be friends. And if you know if there's conflict, it's mostly because it's a misunderstanding. And if we just trying to see everything from the other side's perspective, then everything will be fine, where this series kind of takes the opposite approach, where literally everybody's out to get you. It's a dog-eat-dog universe, and it's literally kill or be killed, and that's kind of the approach. Like I said, it's interesting, it's entertaining. If you're looking for light reading, then I definitely recommend it. And those would be my picks for today. And Shem, now it's your turn. 

SHEM_MAGNEZI: Actually, I didn't prepare anything, but I will shout out for a classic book that I'm currently reading. It's called Thinking Fast and Slow, a famous book from Daniel Kahneman. A lot about, it's talking a lot about how we are thinking as humans, what are all the pitfalls that we have, why we are all wrong when we are taking a lot of gut feelings. It's very interesting about how humans are thinking. 

DAN_SHAPPIR: Cool. And Shem, before we wrap up, if people want to get in touch with you and discuss either the topics that we talked about on the show or any other technical subject, what's the best way to find you? 

SHEM_MAGNEZI: Probably Twitter. We'll publish my handler on the podcast description, I guess. If not, it's Shemag8 with the digit 8. I'm mostly available there. And if not shem.dev. It's my blog. You can reach me out via email, comments, whatever there. 

DAN_SHAPPIR: Excellent. So, Shem, it was a pleasure having you on. I think this was a really important topic, and I think it was a really interesting conversation. So, thank you very much for joining us. And to all our listeners, thank you for listening to another episode of JavaScript Jabber. And bye-bye. 

STEVE_EDWARDS: Adios. 

AJ_ONEAL: Peace out. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit c-a-c-h-e-f-l-y dot com to learn more.