Career Development

I never liked being on-call (slight understatement) or asking others to shoulder some of the load. Sometimes it feels like it's a penalty for being more involved and knowledgeable about our code and infrastructure. And it definitely is a big distraction from core development and innovation. But there really is no way to avoid it once you have a live product or website with paying customers. Somebody needs to be available just in case something goes wrong. How on-call is done in your organization or by your prospective employer can make all the difference in your success (and sanity). Here are some approaches I’ve seen that can improve the on-call experience and overall productivity. Wake Up R&D! Being woken up in the middle of the night due to the NOC or support team opening a high severity ticket, only to find out that it was a relatively non-critical issue absolutely sucks. To solve this all too common scenario, one company I worked at came up with a simple solution. They replaced the “High Severity” designation with “Wake Up R&D.” By clearly outlining the result of opening a high severity ticket, they forced the opener to think twice (maybe even thrice) about whether the issue was really worth waking someone up in the middle of the night. Main Takeaway Make sure that you or your prospective employer has a good method for separating the signal from the noise. Junior and New Employees For junior or new employees who might be unfamiliar with all the intricacies of what constitutes a critical issue, how it should be handled, etc., it’s essential to have a runbook or some other documentation that outlines what issues warrant waking R&D up in the middle of the night. While this type of documentation goes a long way in describing various scenarios, their severity and how they should be handled, it takes a few months for someone to get a sense of the systems they’re working with, and be able to classify incidents accurately. Main Takeaway Make sure that you or your prospective employer invests the time and training for newbies to ease them through this learning process. The Fifth DORA Metric Well, it might be the sixth Dora metric as Google added a fifth already in 2021. Either way, hat tip to Charity Majors, CTO at Honeycomb who suggests in this excellent blog post that software engineering management should be evaluated not only by the four original DORA metrics but also by how often their “team is alerted outside of working hours.” This makes perfect sense to me. Management must do their utmost to ensure productivity. Why do I make this bold claim? Well I can only speak for myself but if I am feeling stressed about my upcoming on-call duties, I won't be focused on my work. If I’m tired the day after on-call, I won’t be sharp and creative. If I’m feeling overworked and underappreciated for my core contributions, I will be less motivated to give my utmost effort. Main Takeaway Make sure that you or your prospective employee respects employee overall well-being and understands that on-call duties can be very draining. The Fear Factor Earlier in my career, I’d go through many emotions during on-call incidents. How will I be judged if I don’t know how to handle the situation on my own? It’s 2 a.m. — what if I’m totally off, and this is not an issue at all? Do I want to risk the wrath of the senior expert I barely said two words to since I joined the company? These and many other thoughts would race through my head, and no matter the time of day or night, I was fortunate to have a close working relationship with my direct manager and would ping him whenever I was really unsure of what to do. As CTO at Kubiya.ai, I try to create a healthy balance. Waking a teammate in the middle of the night should obviously be avoided, but at the same time is totally fine provided we did everything we could to solve it on our own. And even if it turns out to be a false alarm or some easy fix, I say better safe than sorry. But this takes coaching and publicly stating to the team that this is our approach so everyone is on the same page and no one is terrified of making the call. Main Takeaway If you are building your on-call structure, clearly communicate that we must try and avoid waking colleagues, but at the same time, it’s perfectly acceptable if we need to (and even if we are wrong, it’s ok too). If you are evaluating a prospective employee, try and gauge what their culture is like and ask how they address this issue. Emotional Intelligence Technology teams are not known for their outstanding communication skills. And when you throw in a tense, sev 1 situation, I’ve seen people on-call think they have tracked feature ownership correctly and unfortunately when they reach out to the “owner” it comes across as super accusatory. They approach a developer with a buggy piece of code that seems to belong to them. They will be like “hey your code is causing the app to crash, blah blah,” and all of a sudden, the developer has an important meeting and cannot help — or worse, gets super defensive and mouths off. So it’s super important to avoid any accusatory or critical tones and/or wording when you think you’d found the issue and the person who can help. It’s really hard to know if it’s the specific code that is at fault. Maybe it was a change in firewall configuration, or perhaps it was a related but different component that is causing the issue. Refactoring code can also make it look like someone was the author even though they are not. Plus, if someone wrote something over a year ago and there were many iterations, it will take them some time to dig back in and understand. Main Takeaway Always be humble when raising an issue. Don’t jump to conclusions or blame anyone. Just ask for help, suggestions, and ideas from the people you think might be able to help. Let them know that while you are not sure they are the right address, you thought that perhaps, because they were involved at some point with the code, they could help. Who Should Be On-Call? This is really a tough question, but in my experience, operations teams should always have someone on-call. That said, if operationally things are very stable while applications are not so stable, developers might need to be the regular members of on-call rotation. In smaller companies, devs should probably have ops capabilities anyway, so they can cover all issues. Of course, during critical releases, particularly new features, devs should be on call. Main Takeaway Try and make sure that your teams are well-versed in all relevant areas to the extent possible, but obviously, this may not be realistic. So identify where the system is weakest and allocate on-call accordingly. If you are evaluating a prospective employer, try and see whether your role (dev or ops) would carry the brunt of on-call and make sure it’s reasonable and well compensated for. At the end of the day, on-call is the toll we techies must pay. But it’s worth it. Hang in there!

Developing a good workflow can help you be more productive, organized, and efficient in your work. And can also help you keep track of your tasks and responsibilities. Therefore, productivity is essential for a good workflow. In order to help you work more efficiently, here are some of the most important tools I have listed for you. 10 Most Important Developer Tools to Boost Your Productivity 1. iHateRegex IHateRegex is a website and tool that allows users to easily create and test regular expressions (regex) without the need for coding or programming knowledge. It is intended to make it easier and more accessible for people to use regex to search and manipulate text or data. 2. Justgetflux f.lux is a computer program that adjusts the color temperature of a computer display according to the time of day. It makes the display easier on the eyes at night by making it warmer and less blue. It is available for various desktop and mobile operating systems, including Windows, Mac, Linux, iOS, and Android. The name "f.lux" is a play on the term "lux," which is a unit of measurement for light intensity. The program was developed by the company Justgetflux, which is based in New York City. 3. WakaTime WakaTime is a time-tracking tool that helps developers understand how they spend their time coding. It is a plugin that integrates with various code editors and tracks the amount of time spent on different projects and files. It also provides insights and analytics on coding habits and productivity. WakaTime is designed to help developers optimize their workflow and increase their efficiency. 4. KanBoard KanBoard is an open-source project management tool that utilizes the Kanban method for organizing and tracking tasks. It allows users to create a visual representation of their work, breaking it down into smaller tasks and moving them through various stages of completion. KanBoard also includes features such as task assignment, project collaboration, and reporting capabilities. It is often used by teams to improve productivity and streamline workflows. 5. Worldtimebuddy Worldtimebuddy is a website and tool that allows users to easily compare and convert time zones around the world. It allows users to input multiple locations and view the current time for each location, as well as schedule meetings and events across different time zones. It also offers a variety of customization options, such as the ability to add or remove locations from the comparison and change the display format of the times. 6. ILovePDF iLovePDF is a website that offers online tools for manipulating and editing PDF files. It allows users to perform tasks such as merging, splitting, compressing, and converting PDFs to other formats. It also has features for adding or removing password protection and adding text or images to PDF documents. iLovePDF is free to use, but some of its advanced features require a paid subscription. 7. Squoosh Squoosh is a web-based image compression tool developed by Google Chrome Labs that allows users to resize and optimize images for faster loading on websites and for easier storage and sharing. It supports a wide range of file formats, including JPG, PNG, GIF, and SVG. It offers a variety of advanced features, such as lossy and lossless compression, color adjustment, and image resizing. Squoosh is available for free and can be accessed through any web browser. 8. Monkeytype MonkeyType is a tool that helps developers test their code's typing speed and accuracy by simulating users typing the code into a console. It can be used to identify areas of the code that may be prone to errors or slow typing speeds, allowing developers to improve the usability and efficiency of their code. 9. Prestige An open-source, powerful, text-based HTTP client web developer tool, like Postman, works inside the browser. Write your HTTP/REST requests as text, execute them and view the response in the browser. 10. Screely Instantly turn your screenshot into a beautiful website mockup. Customize the browser mockup window, background, and much more. Screely is a website that allows users to easily create and share high-quality screenshots and screen recordings with a few clicks. It provides features such as annotation tools, image editing, and sharing options for social media platforms or via email. It is often used for creating visual instructions or tutorials, showcasing software or websites, or highlighting specific features or elements on a screen. Pro Tool: GitHub Copilot (Paid) Co-Pilot is an open-source project on GitHub that provides a framework for developing and deploying machine learning models for natural language processing (NLP) tasks. It includes tools and resources for training and evaluating models and a set of pre-trained models that can be used out-of-the-box for various NLP tasks such as language translation, text classification, and question answering. Co-Pilot is developed by the NLP team at OpenAI and is designed to be flexible and modular, allowing developers to easily build and customize their own NLP models. Prices are $10 per month for individuals and $19 per user per month for businesses. Wrap-Up Developer tools are an essential part of the software development process and are crucial for a number of reasons: Efficiency, productivity, quality, and collaboration. Overall, developer tools are an essential part of the software development process, and they play a key role in helping developers create high-quality software efficiently and effectively.

This article is a follow-up to the Engineering Manager: Resolving Conflict Situations, Part 1. In the previous article, we talked about intra-personal conflicts which are associated with people themselves. Today we will talk about interpersonal conflicts, common scenarios, and some tips on how to manage them in a professional environment. Interpersonal Interpersonal conflict is between two or more people that do not agree on topics such as what actions to take, what the priorities are, or how to resolve a situation. This kind of conflict is the most frequent and is usually the easiest to solve, but if poorly managed can generate an atmosphere of resentment between people. Roles Conflicts Conflicts between Product Managers, Engineering Managers, and Tech Leads are common for different reasons: Some roles have gray areas. Teams confuse the meaning of self-organization and sometimes confuse collaboration with the capacity to make decisions. Unclear performance targets for the product manager, engineering manager, or tech lead There is no clear definition or standardization of certain roles in the industry, so when people move from one company to another, sometimes the responsibilities for the same role are different. Collaboration means working together to achieve goals by providing support or feedback actively. It does not mean taking responsibility for the other unilaterally without the agreement of the team or the organization. Imagine a basketball team for which the coach hires a point guard and shooting guard to improve the offense. The club promotes collaboration and self-organization in the team so during the next season the point guard takes on the role of the shooter and the shooting guard has another contribution to the team. Point and shooting guards usually do not have the same responsibility and remuneration. The main performance indicator is the number of wins, but also the individual role performance that will be analyzed for each player. Unlike basketball games, engineering teams are not observed as they play the games, and this happens more in the back room. This type of situation happens on some occasions, must involve conscious decisions, and must be managed and evaluated by the organization to avoid complex conflicts to resolve. Performance reviews should be as fair as possible, and career development and compensation according to the value provided. Impact The impact is always the same in the mid and long-term: Toxic dynamic in the team The goals are not achieved. Roadmaps are not aligned with the organization's goal. High rotation in the team Tips There are always examples in the companies of self-organized and high-performance teams where there is a great collaboration between different roles. We would like to believe that we can achieve the same behavior from the beginning with all teams, but the reality is that this is not easy to achieve, and this kind of collaboration requires a lot of effort and maturity in terms of organization. There is no magic rule for success, but at least for me, this is a good starting point: Onboarding: The onboarding process should be a must not only for new people but also when we move people from one team to another. The onboarding has to include: A clear list of responsibilities and outputs by role/team A period of adaptation to the team to understand how they work and what is the best way to adapt to them Tighter definition to start: To achieve an efficient collaboration requires trust between all the members of the team. Trust requires time and people need to be comfortable with their tasks and responsibilities and not constantly be questioned. There is a slight difference between providing our experience and questioning decisions. This depends a lot on people's personalities. We can offer an opinion, but the other person can perceive this as us questioning their role or point of view continuously. Team Building: Team building activities are very important to increase team collaboration. There are many options such as playing games, trekking, or trust games. I really enjoy having lunch and drinks with the team in a relaxed environment that allows us to get to know each other better. Empathizing: It is important to understand what are the responsibilities of all team members, what are the objectives at the team level, and also at the role level. A team is about achieving objectives by helping each other. Different Personalities It may be obvious that teams are made up of people, but this is something that we sometimes forget. There are several personalities such as controllers, charismatic, helpful, perfectionists, or idealists. In addition to personalities, there are cultural factors between people from different countries. Many conflicts between people in the same team are because of personalities and cultural values. Impact This kind of conflict has an impact on people, and team dynamics and evolves into personal conflict if no one manages them. Tips However, they are the easiest conflicts to resolve in general: Identify personality: You have to understand people's personalities, and that there are people that can not work together for a long-time. They have opposite personalities and it takes a lot of effort for them to collaborate. Empathize: It is important to forget about concepts such as being right, justice, or blame. Each person sees reality in a subjective way. The first step in resolving a conflict between people is to understand how each of them feels. What they interpret from each other's actions and how it makes them feel. Time: Sometimes people need time to understand each other and need a mediator. These conflicts are usually solved but need time and continuous support from the engineering manager. Change team: Sometimes a person doesn't fit into a team however, the same person has outstanding performance in another team with people who you know will complement it. Mentoring: When the reasons are based on cultural values, having a mentor who has gone through a similar scenario is very helpful. Coaching: There are people that need to learn how to manage some conflict scenarios. In this case, a coach can help them apply techniques to manage it. A person can empathize with this other person, realize that they have good intentions, achieve all the goals, and even with all of the above have non-matching personalities. Unfortunately, they will not be able to collaborate for a long period of time. Performance In the context of this article, the performance of people is an indicator to evaluate the value provided by people to the organization's success. When we talk about performance reviews, we usually think about the organization's performance process led by the engineering managers. But in the organization, there are many performance reviews that sometimes are unofficial processes. Think about new teams or teams that a new member has joined recently. When a team is new or new people join a high-performance team, always there is an official/unofficial performance review made by the team members or even people with the same role in other teams. The comparisons are inevitable: The salary between new members and old members for the same role The quality of software or the number of unit testing The number of pull-request has been reviewed. The delivery vs the quality of features These comparisons usually are between people with the same salary, same role, or higher role: Same role but different salaries Same role but a different value provided Between a senior software engineer and a principal or between a junior and senior software engineer Impact When people believe that the value they deliver and the responsibility they have vs. their remuneration is not fair compared to other people in the same role: They may leave the company. Sometimes generate bad dynamics Demotivation implies a performance decrease. The impact is similar when you are a junior engineer and you believe that you are providing the same value as the senior engineer in your team. Tips Sometimes these scenarios are generated by the growth of the company, a bad hiring process, or not fit situations. Depending on the case we will have to apply one solution or another. Hiring process: Continuous improvement is important in the hiring process to be sure that the new people hired have the skills necessary and also align with the organization's culture. The target team needs to be involved, but it is important to remember that people move between teams over time. Some people do not fit in a team but fit in the organization. Onboarding process: In my opinion, the onboarding process should not be related to delivery, so things like deploying code in production on the first days are not a priority. The main goals are to know the company (cultural values, process, OKRs, etc.) and fit in with the team. One2One meetings with each member of the team. Join the team ceremonies as a spectator. Shadowing. Promote continuous feedback and continuous improvement culture. Transparency: Sometimes we need to grow the number of people in the team to face new challenges but there are huge opportunities in the technology environment. If we want to hire, we have to increase the salary range, but probably we can not increase the salary of the current team. In my opinion, we should be transparent with this kind of situation because: At the end of the day, people talk about salary ranks, and sometimes the salary is in the opportunity description. It is important that the teams know the reasons. This does not mean that all of them have to be aligned with the decision. We need to try to align all the salaries in a fair range. Not equals: People are not machines, so always there will be differences between people's skills even in the same role. Differences are good because they challenge us to think in a different way. Two senior software engineers can be different: sometimes one of them is more focused on the quality and another on the scalability of the applications. As managers, we need to understand this when there is a performance issue or a conflict based on software methodologies, soft skills, or culture. Mentoring: Every new person needs a reference during the first month, someone that supports them to understand the culture of the organization, promotes best practices, and answers any doubts about the role. One-to-one: It is a fundamental tool to identify these scenarios. When the one-to-one frequency is two weeks, I always set an informal meeting with several members of the team to ask about the onboarding. Informal communication is very helpful because it makes people feel they are in a trusting environment so they feel more comfortable talking about these topics. Team rotation: Everyone deserves a second chance, there are people that do to fit in a specific team but have a high performance in another. When there is a low-performance situation that we can not manage in the current team, we need to evaluate what are the reasons and also if these people can fit in another team. In another article, we will talk about how to manage people who are really underperforming, how to create a plan to help them improve, and how to manage situations where performance is not improving. The Frustration of Global Contributors The main tool of the global contributors is the influence over people through trust and respect that has been gained in the company. Many people think that when they become a manager of principal engineers they will have control of the initiative, architecture, or roadmap. The reality is that people have their own will, and it's not about giving orders, but about supporting and influencing people to achieve their goals. This is a topic that we will cover in another article, but forget any concept of control and think that people are not machines to which you throw a command and they always respond in a deterministic way. Conclusions Interpersonal conflicts are cases where the managers have more capacities to support the team to overcome and avoid toxic dynamics. I have seen many interpersonal conflicts during my professional career and most of them were avoidable. As managers, we should never look the other way thinking that problems will solve themselves. This does not mean that we need to take direct actions in all cases but should be a conscious decision based on the analysis of the conflict. We have to design a strategy to try to improve the situation and also determine which situation has no solution and we will have to make that complicated decision. We are not heroes and we are not alone in solving interpersonal conflicts. We can collaborate with other engineering managers, people departments, and team members. In the worst-case scenario, it is important not to look for blame, but to do a retrospective analysis to understand what we could have improved and what the causes were.

Sometimes among all the sprints, the pressure to ship faster, tools to measure lines of code written, it seems like we as an industry forget a simple fact: developers are knowledge workers, not robots. To remind us what it means to be a human, we invited some of the most empathetic engineering leaders we know to Interact and asked them to sit on a panel together. The conversation that followed is one of the most insightful and relevant conversations we've heard all year. Whether you are an IC, manager, or manager of managers, we promise this conversation will help you become a more empathetic leader and colleague. Today's episode of Dev Interrupted features Kelly Vaughn, Director of Engineering at Spot AI, Jean Hsu, VP of Engineering at Range, and Lena Reinhard, an engineering leadership coach. Episode Highlights (3:34) Hot take: no coding exercises in technical interviews (13:35) Why the panelists are so passionate about this topic (28:52) How to conduct a proper 1:1 (36:44) "BS metrics" (46:38) Burnout isn't the "24 hour flu" (53:41) Discussing burnout with your manager Episode Excerpt Conor: So, I wanna kick off this panel by doing something a little different. When we were talking before this conversation, a kind of a, maybe a hot take came up, when we were talking to Kelly. Kelly, you said that you question whether or not engineers should be required to code in an interview. What's your take? Kelly: Yeah, I love starting on a hot take, by the way. This is a great way to kick this off. Yeah, this is one of those hills I'll die on. I am very, I'm a strong proponent of not having a coding exercise in a technical interview, reason being, most of the time, we're hiring engineers who are not absolutely brand new, and they've been coding at other companies before, they have plenty of production building experience, and so I am not here to see exactly how you code, especially live. First off, we're not, you know, standing behind each other, watching each other code, so that's not a thing, and, second, when it comes to like take-home assignments, for example, they lean towards privileging those who have the time to put into doing the take-home assignment, and so, if you are looking for another job and you are still working full-time or working long hours, it's very tough to find the time to actually work on that, and so you might not be able to do your best work, so it's already putting you at a disadvantage. So, I like leaning more on system design interviews because I wanna know how you think, I wanna know how you problem-solve, I wanna know how you approach a problem, I wanna know just your entire thought flow, especially as you're working with one of our engineers and going back and forth, you know. No stupid questions in this technical interview. No, like, I want to hear whatever is on your mind, and I've found this works really well. I mean, I like to say, I like to think that I've hired some really great engineers in the past, so it's been working great so far. I will say the one caveat, though, is with junior engineers, I know you need to establish some level of baseline knowledge of where they're coming in, and so I'm okay with some like basic, how would you approach solving this specific coding problem, but I'm trying to make technical interviews less stressful for the candidates because they're already so incredibly stressful as it is. Conor: What about you, Jean, what do you think? Jean: I definitely tend toward the, like, let's simulate what it would actually be like to work with this person, and so things like, you know, having them describe something they did, which, you know, sometimes if it's a more senior engineer, we'll bring in some, you know, mid-level folks or junior folks and be like, okay, like this is kind of a situation where this person's describing something like, can you communicate with this person, right? Or have them work with a designer or PM and, you know, have a sort of like simulated kickoff meeting and see, like, hey, can this person help, you know, given these priorities, or will they ask for the priorities, and then how can they help scope or, you know, think about the timeline for this project that we just kind of threw in their laps, right? Like, this is for a more senior engineer, and that's really, I think, you know, going back to the topic of this talk, like what is it like to work with this person rather than like, what is the current technical ability that they have 'cause I'd much rather have someone who maybe doesn't know the language that we're coding in, but has a strong trajectory, has a strong career history of picking things up quickly, right? Like knows a few languages, they'll pick it up quickly. They've had that like, I guess, success in the past, and so, I think assessing what their current, like technical skills is not like super, is not super helpful. Lena: Yeah, yeah, I would so agree on that. Like I was, for a different project looking this up just last week, engineers, on average, spend about 11 hours per week in meetings, and even if, you know, in your organization, that's different, and I know meetings are a whole different hot topic, but I find that a really interesting way to illustrate, like the job is so much than put, so much more than putting out lines of code, and the job is so much more complex than that, but I still see so many organizations where the interview process for engineers is essentially a row of technical assessments that just focus on how do you produce code, but how, in the sense of essentially how much code do you produce, and where the complexities of it that are about collaboration, communication, building good relationships, being able to take ambiguous problems and turn them into solvable chunks of work, and all of those kinds of things that actually make up the majority of the work, or interacting with your team in one of these 10 hours of meetings, that's the role, that's the actual job, but I think so many companies, already in the hiring, basically pretend like it isn't. Jean: Also, the more senior folks get, I mean, especially if you're hiring someone who's sort of like a tech lead or engineering manager type, right? Like they likely haven't been coding, so you hear, you know, I have friends who are like, "Oh, I'm thinking about interviewing, but I need to spend like four months studying up on like LeetCode." I'm like, there's something so broken about the system if you're applying for the same role you have now, but you feel like you need like, full-time, to study for four months, like that's just ridiculous. Conor: Yeah, to all of your points, what I'm hearing is this recognition that software engineering today is a team sport, and we're often taught, I think, as folks are moving into the ranks of becoming a developer, that it's more of an individual thing. You go in and you like knock out all this code and you solve this problem, and that's part of it, but you also are functioning within a larger organization within a team, you're working with product to make sure you're aligning on the right features, you're working with the rest of your team to make sure you're working on the right pieces, you're probably doing PRs, and I kind of hear that recognition from all of you, which is important that we consider the job as more than just pushing code out. Lena: I think there is an added complexity in that team element, like so many companies essentially when they hire engineers, assess them at an individual level, and there's no doubt that that needs to be done, but the much bigger question that ultimately arises once they join is are they going to be able to perform effectively as part of a team? Because we all know that like adding one engineer to a team won't mean that the output of the team is going to grow by one engineer exactly. You're also increasing the complexity of that team, but what happens is that engineers are basically assessed as sort of standalone entities, and I think a lot of that still comes from this really pervasive hero culture that we still have in our industry, of sort of the lonely coder, maybe they're wearing a hoodie and they're probably also a man in that cliche, and they have the, you know, the stereotypical hacker, whatever, screen on that we all know from the movies, and they're doing it all by themselves, all by their lonesome, but that's not the reality, but at the same time is this question like, how will they contribute to the team? What value are they going to add? What impact can they bring, and how are they basically making the whole of this team better in terms of how they're working and what they're able to, has in terms of impacts, like that's the big question that I think is often really underestimated because we are so focused on these individuals. While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

When making a list of key skills for an engineer, developers and engineers likely focus heavily on technical proficiencies. Although technical knowledge is necessary to be an engineer, the ability to communicate effectively is too often overlooked. Why Do Engineers Need Communication Skills? The answer is simple: Today’s challenges are too big for one individual to tackle alone; they require collaboration across large teams of people with distinct skill sets. This is especially true in transformative projects involving advanced technologies such as artificial intelligence and machine learning. People from different backgrounds communicate in unique ways, and being aware of this can make us more efficient. Technology development requires contributions from engineers, researchers, program managers, ethics researchers, psychologists, businesspeople, and other stakeholders. It’s critical to effectively gather input and perspectives from all these contributors early to prevent duplicated or wasted work. This involves a few requirements, such as: Ensuring everyone is aligned with a shared goal, Communicating the vision of the deliverables and road map to get there, and Embracing uncertainty through constant testing throughout development. As you can see, technical knowledge isn’t even on the list of factors that make a great project. So, why is communication important in engineering? It’s because communication is at the foundation of teamwork and keeps everyone on the same page, working toward a unified goal. That makes it just one of the key skills for an engineer to learn, foster, and showcase when applying for jobs. Essential Engineer Skills and Qualities There are four basic engineering tiers, and where you rank depends solely on your skill set. Great engineers have a working knowledge of formulas and theory fundamentals. Those who can only work at the code level will only be able to work with existing implementations done by others. Creating new methods requires understanding what you’re doing on the math level; otherwise, you’ll always be following others. Top engineers also know what’s happening in both the business and the outside world. If you don’t keep up with what others are doing, you will eventually fall behind. This is true of every scientific field, and AI moves particularly fast. Integrating others’ ideas into your own work will turbocharge your results. Using a peer-reviewed digital repository prior to publication is beneficial. However, make sure you find good curation channels that work for you (e.g., conferences, subject matter experts on Twitter, etc.). Excellent engineers understand the full stack. Anyone can code Python these days, but very few people can go up and down the abstraction ladder. If you want to train a large AI model, you must understand what’s happening at a hardware level. As model sizes grow and accelerator architecture gets more exotic, this will only get harder. God-tier engineers know how to talk to people. Most assume people can read their minds, which leads to team friction and unnecessary overhead. Simplify what you’re saying, even if you’re talking to a fellow engineer. Draw a diagram, and then simplify it again. The difference between good and great work is how well it’s explained. This leaves three steps to improve your communications skills and level up your engineering prowess: 1. Learn to Listen to Others Understand that other people communicate differently than you. Next time you talk with someone difficult, try to be aware of how they process and view the world. Understand how you would communicate the same thing and make a mental note of the differences. Next time you interact with them, experiment with sharing your view of the world in “their language.” This technique is called mirroring and is an effective verbal and nonverbal communication method. 2. Start Talking More It sounds counterintuitive, but you need to talk more to get better at it. Present your work and thoughts in public as often as possible, whether it’s through a talk, video seminar, or simply speaking up in crowds. Each time you do it, reflect on what you did right and what could be better. Don’t worry about the outcome of the talk itself because you already succeeded by gathering data to further improve your communication skills. 3. Develop Genuine Empathy The hardest part is developing empathy. Assume people have good intentions, and if someone communicates something that ruins your day, consider the restraints they’re operating under. Think about how you would do it under the same circumstances and directly ask them, “Why was it necessary to do it this way?” Asking questions to understand somebody is one of the best engineering skills and qualities you can learn in your career. We often view technical proficiencies as the key skills for an engineer to develop. Certainly, being able to code is critical, but if you can’t succinctly communicate what it is you’re coding, you won’t get far. Communication is a vital skill for engineers to learn, as it can help you stand out from the pack as a next-level expert.

The Software Engineering job market is on fire! Especially if you have a couple of years of experience under your belt. And in the world of Software Engineering, if you are applying for a Senior Engineer / Lead / Architect / or a more senior role, System Design is the most sought-after skill and hence one of the most important rounds in the whole process. If you mess this up, nothing else would matter. If you get it right, though, you’re looking at a raise of at least tens of thousands of dollars annually. So how do you ace your system design round? Well, here’s what I did while preparing for my interviews with Facebook, Google, and Amazon, and it worked out rather well. I did end up creating a checklist for myself which got me through most of my rounds, so if you follow a similar path, you should be able to come up with something that works for you as well.Before we get into the details, what is a system design interview? What do the interviewers really expect from the candidates? Expectations: You should be able to design a system that satisfies the requirements given to you and scales well. Your design should be pluggable and not restrict the addition of new features. You should be able to compare various alternatives and choose the most optimal one. Things like which database is the most important, which protocol you should use, or what’s the best approach to scale a system, etc. You should know the basics that are relevant from a system design standpoint like: Load balancers APIs Caches Databases Network Protocols Message queues CDNs High-level details about ML and Big data CAP Theorem Monitoring and analytics In the past, I have shared the best system design courses like Grokking Modern System Design for Software Engineers & Managers and the best software design questions. In this article, I will share the step-by-step process to crack System design interviews, like concepts, common questions, and resources to master system design concepts. How to Prepare for System Design Interviews? Here’s how you can crack the System design round interview of any FAANG company (Facebook/META, Amazon, Apple, NetFlix, and Google) or get into FAANG There is a simple four-step process to ace any System Design round. Concepts Learn from the tech giants FAQs Practice 1. Learn System Design Concepts Any system design interview will definitely require you to come up with a basic high-level design for whatever system you are trying to build. There are some components that will be needed for sure. Make a note of these components. Here are a few: 1. 1 Load Balancer You cannot have a distributed system without a load balancer to distribute the incoming requests among various nodes. This ensures proper resource utilization and that there is no single point of failure in your system. Here’s how Nginx does it. 1.2 Cache Most systems have some read-heavy interactions, some information the user will access frequently but not update as much. It makes sense to cache this information in such a way that it can be easily fetched without the need for a DB lookup. Think low latency. Also, based on your use case, you might need to store more frequently accessed information or more recently accessed information. So, read up on various eviction policies. 1.3 Database Again, there can be no system without some form of data storage. Whether you want to store files, images, product information, financial transactions, or simply dump all the data from various user interactions to run analytics later. It all needs databases. So read up on it. Find out what matters when you are selecting a database, read about SQL/NoSQL, query patterns, and how the CAP theorem might come into play while making tradeoffs. 1.4 Message queues Sometimes our system needs to perform some tasks that need to be done but not necessarily immediately, or their outcome does not affect the user’s journey. In such cases, rather than making a service call and waiting for the response, it makes sense to just write the message to the queue so that it can be executed later. What if you need to insert information in your database, and bulk insert could be more efficient? It would make sense to just keep track of these inserts in a message queue and perform 1 bulk insert instead of hundreds of 1-to-1 inserts to optimize your resources. 1.5 CDN When your users are distributed geographically, getting your content to them in a reasonable amount of time becomes a real challenge. CDNs allow us to maintain a copy of our data in various data centers located closer to the users’ location to reduce the latency. Here is a short video about how Akamai does it. 1.6 Analytics and Monitoring This is something that is needed in every system you create. This is a hidden requirement, no one calls it out in the requirement gathering, but every interviewer wants this. User logs in or logs out? Wishlisted an item? Did payment fail? It is all the information for us! If anything of importance happens, fire an event and save it in your messaging queue. You can perform real-time analytics on data or just dump it in a Hadoop cluster to use later. Similarly, if an API call is regularly failing or if your servers are about to run out of resources, wouldn’t you like to know of it beforehand? 1.7 Network Protocols Based on your requirement, based on the type of content you are sharing, you might need to make a decision on which network protocol to use. Read up on various network protocols, and when they are relevant, what might be compromised you might need to make, etc. The first step is to know about all these concepts. And by knowing concepts, I don’t mean just some theoretical knowledge of what these are, but more practical hands-on experience about what should be used and when. You need to know things like: Which is the best alternative to choose from, given the use case? What are the tradeoffs that you need to consider while making these decisions? Best practices for certain use cases. To know most of these things, I’ll recommend going through this course on System Design by CodeKarle, which covers all of the above with concrete examples from the real world. 2. Learn from the Tech Giants (Read Their Engineering Blog) This is probably not going to help in the short term. But in the long term, to become an expert in System Design, it’s best to look at the Tech blogs of various tech companies and see how they are solving various technical problems. This would paint a clear picture of the real problems that they face and how innovatively they solve them. Understanding these things would help you become better at system design and also keep you up to date with the latest innovations in tech. Some of the best blogs to follow are: Facebook engineering blog Netflix tech blog Uber engineering blog 3. Solve Frequently asked System Design questions This is an obvious way to get started with your interview prep! Knowing the basics is definitely important, but it won’t be enough! The most basic way to get started with your practice is to look at some frequently asked questions and their solutions. Most system design interviews revolve around some five to six commonly asked System design questions, and if you know the solutions to those, you are more than likely to clear this interview. The most common questions are: Tinyurl System Design YouTube System Design Facebook System Design Whatsapp System Design Airbnb System Design Instagram System Design How to design Amazon Prime Video How to design Google Search How to design NetFlix How to Design a distributed Message Queue If you need resources to solve these questions, something which not only solves the question but also explains the underlying concepts and approach to solving system design questions, then this highly-rated course by CodeKarle discusses most of these case studies and some more problems, which has helped many people crack their interviews for companies like Google, Facebook, Microsoft, Amazon, etc 4. Solve System Design Problems Practice, practice, practice! Did I say practice? There are a lot of resources out there. I have shared a few that discuss some of the most popular system design problems in detail. Once you go through a few of them, you will start noticing a pattern and will soon be able to come up with solutions on your own. Get a better understanding of how your systems are designed in your organization. How are the other teams doing things? What factors do they take into consideration? The next best thing is to practice with a friend. Make sure you go through a few mock interviews before your actual interview to avoid some common but easily avoidable pitfalls. Some most common mistakes that I have seen people make are: Not driving the interview. Not asking questions. Not structuring the interview properly. Running out of time. Not considering the requirements. Not exploring all the alternate design options. All these mistakes can be easily avoided by having a few mock interviews with someone who knows System Design well. And time your interviews. The target must be to reach a solution within 40 minutes, including time for some discussion. That's all about how to prepare for System Design Interviews in 2023. We have discussed essential System Design Interview topics, concepts as well as popular System Design questions for practice. With this 4 step process, you’ll soon be ready to ace any of your system design interviews! Hopefully, this should be a good starting point for you. Happy learning! and all the best for your System design interview Thanks for reading this article so far. If you like this System design interview preparation article, then please share it with your friends and colleagues who are preparing for tech interviews. If you have any questions or feedback, then please drop a note. All the best with your interviews. And, here is the System Design Cheatsheet you can print and keep at your desk, thanks to Educative.

Today, I’d like to recommend some helpful books for QA engineers. Grab a cup of coffee and jot down some notes and suggestions from these software testing books. 1. Testing Computer Software, by Cem Kaner, Hung Q. Nguyen, and Jack Falk This book is a real classic that should be read by specialists, starting at the junior level. It differs from other books for QA engineers primarily in its attachment to the conditions of the real world, using the example of well-known Silicon Valley development companies. The authors thoroughly consider a wide range of issues, from the organization of the quality assurance process to the actual testing of documentation, code, projects, etc. If you are new to software testing or have some experience but no formal training, this book will provide you with the right tools to approach software testing and will also give you insights that could take you years to learn on your own. This book does not discuss the testing techniques used in agile development approaches. Also, it may be difficult to focus on what the writers are attempting to express without being sidetracked or shut down by outmoded examples. But, putting that aside, it’s an excellent book for QA engineers. 2. Testing Computer Software, by Lee Copeland One of the greatest books for QA engineers that can be very useful for specialists at various levels. It only covers the design of tests and does not consider issues of planning and organization of the testing processes. However, in this book for QA engineers, you can find both new methods and in-depth descriptions of already-known ones. For example, Testing Computer Software describes seven approaches to testing using the “black box” method and several “white box” methods. There are nothing superfluous here, only useful and practical examples with tables and diagrams, a clear description of techniques, and additional tips. At the end of the book, there´s a section with conclusions and a list of other author's works on the topic that can also be useful. I recommend it if you want to prepare to obtain a professional certification. In my opinion, this book gives the best account of pairwise testing that I have found, with or without using orthogonal arrays. Besides being detailed, it includes examples to make it clear. The test coverage that can be achieved with well-chosen pairwise test cases seems too good to be true. According to the author, if necessary, some tester prudence should be used to supplement the technique 3. How Google Tests Software, by James Whittaker, Jason Arbon, and Jeff Carollo Oriented more toward senior engineers, this book will show how the best of the best QA specialists conduct their testing. The book gives an overview of the approach Google takes to testing software, followed by chapters dedicated to the two test engineering roles at Google, which are the Software Engineer in Test (SET) and Test Engineer (TE) roles. Throughout the book, there are sections and interviews with many other Google employees, with the final chapter being dedicated to some of the thoughts on the direction of testing at Google. Note that just because something works well at Google doesn’t necessarily mean that it will work well at some other company making some other type of product. Even Google could have made some different choices for some of their testing solutions and been equally successful. 4. Lessons Learned in Software Testing, by Cem Kaner, James Bach, and Bret Pettichord This is one of my favorite books for QA engineers. It’s a fabulous collection of tips, hints, and techniques for both the new and the experienced person working in a software test department. It covers obvious areas like testing techniques, automated testing (the material about what automated testing can’t do is very high-grade), documenting testing, and managing a test project. The book starts with the role of a tester. The next chapter relates to how to think as a tester and provides interesting references in completely different knowledge areas that may help testers improve. Another chapter covers different testing techniques and bugs in writing and test automation. There are also chapters that relate to working with others. 5 – Agile Testing: A Practical Guide for Testers and Agile Teams, by Lisa Crispin and Janet Gregory This book talks about using Agile testing quadrants to figure out what testing is required, who can perform the testing, and what tools can aid in it. Here are some key insights you could learn from this book for QA engineers: How to get testers engaged in agile development. Where do testers and QA managers fit on an agile team? What to look for when hiring an agile tester? How to transition from a traditional cycle to agile development. How to complete testing activities in short iterations. How to use tests to successfully guide development. How to overcome barriers to test automation. I hope you found these books for QA engineers helpful and that they will help you increase your knowledge in different areas to grow as a professional.

Top 20 TypeScript Interview Questions and Answers 1. Define TypeScript Answer: A compiler may accept TypeScript as a superset of JavaScript and create ordinary JavaScript from it since it is clearly typed. Dealing with JavaScript in a totally object-oriented context is made possible by TypeScript. Use classes and interfaces in this situation. It is also labeled, much like C# or Java. You'll need a TypeScript compiler to turn the code into a JavaScript file, which you can then utilize. The TypeScript compiler converts a TypeScript file with a.ts extension into a JavaScript file. Here, with a variety of editors, including VS Code, Sublime, etc., you may produce TypeScript. 2. What Are the Advantages of TypeScript? Answer: Advantages include: TypeScript is simple, quick, and straightforward to understand, and it can run everywhere JavaScript can. As a result, it ranks as one of the top frameworks for front-end programming for newcomers. JavaScript developers may switch to TypeScript since it is sufficiently comparable to JavaScript. The ability to write TypeScript using an IDE speeds up development and can result in more protected, resilient products. TypeScript code may be called from JavaScript code, providing compatibility for older JavaScript-based programmes. It includes ES6 and ES7 capabilities that may be used with JavaScript ES5 engines like Node.js. It complies with ECMAScript requirements. Your typescript code can be compiled to the ECMAScript targets of your choosing. This enables you to leverage ES2015's features and other features. Modules, lambda functions, restructuring, etc., are a few examples of these capabilities. It gives JavaScript-type support. Because an IDE can be used, TypeScript programming is a significantly superior experience to normal JavaScript development. If severe null checks are enabled using TypeScript, the TypeScript compiler will only allow you to write unknown to a variable if you have specifically specified it to be a nullable type. TypeScript is supported by Microsoft and is available under an Apache 2 license. Because TypeScript and JavaScript are interoperable, TypeScript can be used right away by developers who are already familiar with JavaScript. 3. What Drawbacks Does TypeScript Have? Answer: Here are some disadvantages. Because TypeScript code must be compiled, the implementation of TypeScript components might be slower than with JavaScript. Abstract classes are not supported by TypeScript. A TypeScript application will need an additional compilation step when running in a browser, which might have a negative impact on speed. It might not be easy to work with libraries from third parties. 4. What Are TypeScript's Component Elements? Answer: In TypeScript, there are three levels. The language consists of the following when installed normally: The language is often run using an IDE. A compiler that converted TypeScript to straightforward JavaScript code. The Language Service, which offers editor functions on TypeScript code that already exists. 5. What Do TypeScript Types Do? Answer: We'll start asking more technical questions now. The types of values we employ in our programmes are known as types in TypeScript. It supports a wide range of value types, including integers, texts, and Boolean values, in addition to other kinds like Enum, any, and never. Types should always be declared explicitly in TypeScript for a number of reasons. Types make code more readable and clear, and they can also help your compiler identify issues that result from improper type assignments. Additionally, Types provide an additional layer of documentation that might be useful when working in a team context. 6. What Kind of Data Are Primitive? Answer: These are the options: Number String Boolean BigInt Symbol Undefined Null 7. What Are TypeScript's Special Data Types? Answer: Any Void Never 8. What Scope Does TypeScript Offer? Answer: As far as variables are concerned, there are three scopes: Local Function Global Var is used to create both function and global variables, whereas const and let can be applied to either. 9. In TypeScript, What Are Interfaces? Answer: Which unique entity, a TypeScript Interface, enables us to build objects with specific properties? Let's go ahead and construct one. In order to establish a TypeScript Interface, for instance, we may start by entering the reserved term interface. 10. What Are the Various TypeScript Features? Answer: The following characteristics: It just contains JavaScript. It supports more JS libraries. It's transportable. 11. Does Method/Function Overloading Work With TypeScript? Answer: The answer is that function overloading is available in TypeScript. The name and number of arguments can be the same for several functions, but the return type and parameter types need to be distinct. The overloading of functions with the same name, various types, and varying numbers of parameters is not supported by TypeScript. 12. What Does the TypeScript Keyword Declare Do? Answer: The TypeScript keyword declares instructs the compiler not to trans-compile the code to JavaScript because it is present in external code. 13. A TypeScript Map File Is What? Answer: The Map TypeScript file converts trans-compiled JavaScript from an unreadable format to a format that is understandable by humans. Since the source Map will be utilized, this is beneficial if debugging needs to be done while in production. 14. In TypeScript, What Is Compiler Context? Answer: When TypeScript code is built, your compiler will inspect a collection of files and parse them to discover which code is acceptable and which is invalid. However, TypeScript also gives you the opportunity to modify compiler settings, and this is done using a tsconfig.json file. 15. What Are TypeScript's Access Modifiers? Answer: When interacting with class members, TypeScript makes use of a number of access modifiers. Public, private, and protected modifiers are those that are supported. These function as follows: Being public means that a class's instance, child classes, and all of its members can access it. Private denotes that a class's members are separated from one another. A class's instance cannot access a resource that all of its members, including those in its descendant classes, may access. It is considered that a class member is public if the access modifiers for that member are left unspecified. Wherever possible, you should explicitly specify access because this might present problems with compliance procedures. You should also be aware that after your TypeScript code has been built, class modifiers have absolutely no impact. These modifiers are not taken into account when the compiler generates the resulting JS. 16. Is JSX Compatible With TypeScript? Answer: It is possible. However, you must save your TypeScript file with an a.tsx extension. But when dealing with JSX and TypeScript, there are several crucial things to remember. JSX has to be compiled into valid JS since it is an embeddable XML-like syntax. This increases the number of compilation steps in your code, which may have an impact on performance. On the other side, TypeScript provides several strong tools for working with JSX, including type verification, embedding, and direct JSX compilation. 17. What Do TypeScript Triple-Slash Directives Do? Answer: In TypeScript, triple-slash directives and functions are similar to comments in that they both carry compiler instructions. They include single XML tags. Only when they are at the top of the contained file do the triple-slash directives function. However, if they come after any other kind of statement or declaration, your compiler will consider them as standard comments and ignore them. You can place comments before them, including additional triple-slash directives. 18. What JSX Modes Are TypeScript Compatible With? Answer: There are three JSX modes included with TypeScript by default. These respond, native, react, and preserved react. The JSX output of your code can be customized using these settings. The preserve mode's goal is to keep the JSX output within your compiled code so that another compiler can directly operate on it. The compiler will create a file with a .jsx file extension while this mode is active so that it can be further modified before usage. Similar functionality is provided by the react-native method. However, the output is given a .js file extension. React mode functions a little differently because it omits the React.createElement modifier, the result is devoid of raw JSX code. When utilizing this mode, the output file will have the .js file extension. 19. What Do TypeScript Decorators Do? Answer: We'll discuss some of TypeScript's more unique features in these final few questions. These features will be brought up frequently during interviews because knowing about them indicates that you have used them frequently. "Decorators" is the first of these features. A specific kind of declaration called a decorator is used to supplement existing code with annotations and metadata. They carry out declarative actions. You must enable the experimental Decorators compiler function in order to utilize them. 20) What Does TypeScript's Rest Parameter Mean? Answer: The Rest Parameter, a unique parameter that enables you to pass values to a function, is also a feature of TypeScript. By placing an ellipsis (...) before the parameter you're working with, you can call up this one. This makes it possible for functions to work with a variety of arguments, which is very helpful if you need to supply a function with an unknowable amount of parameters. However, there are a few things to keep in mind when using the Rest Parameter: For each function, only one rest parameter can be utilized. An array type must be explicitly defined. The parameter list should have it as the last argument.

What Is the Difference Between Contributor Individual, Staff Engineer, and Leadership Technical? Individual Contributors, ICs, are professionals who work with a team or an organization but do not work in management. That is it; they influence a group and an organization; however, they do not have “official responsibility for this. This contributor performs a great integration and cross-time communication activity and is not isolated, as the name suggests. The term “technical leadership” has been used to reduce this misunderstanding. The idea is to clarify that this contributor does not work alone; this person has strategic responsibilities, and communication is part of his role. Staff Engineer is the term created to deal with technical leadership in the software engineering career. Staff Plus refers to all positions after Staff; however, the meaning does not change. In addition to the specialized knowledge, the engineer will also work with communication and influence, impacting teams and organizations. I Want To Know More About the Topic; Where Is the Get Started? A good start is to read the two books published so far on the subject: Staff Engineer: Leadership beyond the management track: The first is the most famous. Will Larson held several conversations on his podcast and, based on that, consolidated a fascinating book. This would be an excellent first book to understand the why of Staff beyond its initial concepts. The Staff Engineer’s Path: The most recent book in the field written by Tanya Reilly and endorsed by Camille Fournier, author of The Manager’s Path, and Will Larson, previously mentioned. It brings a greater focus on how to act in this new position. Technical Leadership: Does This Mean I Have a Team? Generally, a technical leader works in a team but is not responsible. This means that defining a salary increase, dismissal, or some structural change is not within your responsibility's scope. However, it has the role of influencing people with such decisions. What Is the Importance of Mentoring Other People Within My Team? As a leader, it is essential to always think about succession. For example, if I take on the role of Principal, who would replace me as a Staff Engineer? Another point is the multiplication of knowledge beyond the technical level of the team. Holding 1:1 meetings to help technical evolution, points to improve, literature tips and points to be improved based on a code review, among others, makes the mentored person evolve much faster than if had alone. A tip is to hold such conversations with the team on a fortnightly or monthly basis for thirty minutes. Bringing previous notes with points in addition to hints asynchronously tends to make these encounters even more impactful. What Is the Importance of English for Staff Plus Engineers? In technology, English has become the official communication for news and trends in the area. It may even be possible to live without it for a while; however, this language becomes increasingly necessary for more significant flights in your career. English is not just a reading tool but an interaction tool. It is natural for your networking to grow and for you to meet and deal with people from other countries/cultures, and English will also help you in this regard. Lots of news pops up on Twitter, LinkedIn, and GitHub. And these will be the most common places to ask questions, contribute to open-source projects, and share experiences. As a bonus, we just talked about the importance of social networks in the workplace. Learning and taking advantage of them for your professional growth is possible. Which Literature Is Indicated To Learn More About the Topic? At this point, I will break it down into two categories: Technical Books In addition to your area of expertise, it's natural that you need to communicate with peers, so focusing on software architecture and basic concepts will help you speak "engineeringsh" Good books to start with are, for example: Fundamentals of Software Architecture: An Engineering Approach Software Architecture: The Hard Parts: Modern Trade-Off Analyzes for Distributed Architectures Building Evolutionary Architectures: Support Constant Change The Philosophy of Software Design The C4 model for visualizing software architecture Trying to limit myself to just five, these would be good reading recommendations in addition to the classics you've probably already read and are familiar with, like Domain-Driven Design (DDD), Clean Code, Clean Architecture, San Newman's microservices books, plus Martin Fowler's Refectory. It is worth mentioning that this does not eliminate the need to use blogs and portals to keep up with news in the area. Miscellaneous Books As mentioned, the technical part is one of many expected points and/or skills. Knowledge to carry out storytelling and good communication are also expected. Good books to start with are, for example: Storytelling with Data: A Data Visualization Guide for Business Professionals Start with Why: How Great Leaders Inspire Everyone to Take Action Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs Team Topologies: Organizing Business and Technology Teams for Fast Flow The art of knowing how to communicate, structure ideas and plans, and even a little bit of management and how a team works are significant. Will I Walk Away From the Code? The answer is no; you won't need to step away from the code, but, as you progress in technical leadership, it is also essential to look at the team as a whole, focusing on mentoring, improving code quality, and technology strategies. Sometimes, it will be necessary to code less to guide more. Give space and multiply. In other words, study and constant technical evolution are necessary; nonetheless, you will only be coding part of the time. It will take time to do other activities. How Do I Keep Up to Date? As mentioned earlier, Staff Plus Engineer coding activities tend to decrease. However, technical activities are critical and staying close and in constant evolution is crucial. An excellent way to be close is to perform code reviews, PoC, or even participate in open-source projects. However, something that does not impact the team. What Is the Enormous Difference Between Staff, Principal, and Distinguished? In short: Staff: Focuses on tactics; however, understands and seeks a more robust strategic understanding of the company. His focus is to impact some teams around him. Principal: It is the link between the tactical and strategic. Its impact targets an area or a product; generally, its visibility goes to the entire company. Distinguished: Your focus is on the strategy and impacting the company/organization. It is usually known by an entire community and the company for its technical notoriety. Who Is Responsible for Making Decisions Where Technical Opinions Do Not Converge? Technical Leadership or Management? In the ideal world, there is a consensus between technical leadership and management. However, this joint agreement only sometimes happens. It is always essential to make clear the difference between “I don't understand”, and “I disagree”. When the two sides try their best to converge without success, the final word rests with management. Remembering that this resource should be an exception; after all, having an expert and not listening to him is a management failure as much as the expert not understanding the business context. That is, synchronization between the areas is crucial. Conclusion As this is a very new area, it is natural that several doubts arise. Therefore, this article aimed to answer the most common questions about Staff Plus Engineer. In addition to technical knowledge, this type of professional needs to understand that software is from person to person and has people throughout the process. Thus, communication skills are also required. So, do you have any other questions? So comment here with your questions about Staff Plus Engineer!

Motivated by some recent M&A news and general productivity pressures in time of tight budgets, we present some anti-patterns to the use of engineering metrics and give an overview of how to use metrics for productivity insights instead. First, let us first start with what to avoid: Anti-Pattern to Engineering Metrics Lines of code written: While lines of code can be a proxy metric for how much code you have to maintain (and therefore costs to incur), it has been proven to be a terrible metric for productivity. This shouldn’t need much explanation, but: Output does not necessarily equate to the outcome. Different programming languages have different verbosity, and e.g., just including some open-source packages or pasting in some code from Stack Overflow does not make you more productive. And, of course, solving hard problems often does not require a lot of code but a lot of thinking, exploration, and collaboration. Complexity or salience of code: Complex code is not good code. Someone else has to read, understand, and maintain it. Salient code (let’s interpret this as “most notable”) can be worth noting, but that does not make you a good team player or show any consistency. One key point here: Software development is a team sport. However, every company has some rock stars who are able to do things that others cannot, but that does not mean you only want rock stars who cannot work with others. This is especially true if you have more than on star with similar traits. Number of PRs/Reviews: Now, this is a bit more on the grey side. Of course, if you can churn out a lot of pull requests (PRs), this typically means it is work associated with some feature spec (at least one would hope so). This means it is at least going in the direction that is perceived as customer value. But on their own, PRs are again a proxy of the amount of work that requires maintenance and a metric that is prone to gaming. Sure, you can do a lot of small PRs and “clog up” the review and merge pipeline, or do a lot of cursory reviews (LGTM), or worth add confusing and useless comments. So, adding value to some customer features is good, but for the sake of showing activity, it is not. Bug fixes: Someone fixes a zillion bugs? This can be great, but two questions come to mind: Why are there so many bugs in the first place? And: do all of these “bugs” need fixing? The unfortunate truth is that no software is perfect, and there is always way more to do than that there is time for. Number of hours worked: This shouldn’t need much explanation either, but hours do not equate to time well spent. Sure, if you only work 1h a day, you must be really exceptional (and not hardcore) to produce continuously high value. But if you work 14h, it does not mean you are at your most productive. Especially running out of steam/coffee. All good things need the right effort without going to extremes. Sometimes this might be more coding, and sometimes more exploration/thinking/discussing. The Value of Data-Driven Engineering Now, we are the last ones not to promote some metrics (ahem ….), but metrics are not the goal; insights into what is going on in the organization and continuous improvement loops are. Firstly, metrics are almost always poor to manage individuals. If you need metrics to understand if an employee gives you the value you are expecting, then you are already in trouble. We understand that large organizations need some sense of objectivity, but using any of the above is probably poor. Also, metrics in themselves do not solve principal issues. This brings us to the next point: Metrics are of value to highlight trends, anomalies, imbalances, and bottlenecks. This is, in particular, true for processes, workflows, and team/group aggregates. It would be unthinkable to run your ops without watching some numbers, and the same for sales or marketing. But it is always intended to improve and streamline processes and create less disruption. As such, metrics can provide great signals to manage organizational engineering productivity and remove friction in the system. For development teams, it makes sense to measure some numbers and trends. For instance: Where in the development process do we get stuck or waste time? Does our build system hold us back? Are we overloaded with reviews? Do we have QA issue? Do our sprints get re-scoped all the time in mid-air? Are there too many context switches? All these things are essential, especially for good managers to assist their teams. Managers should remove roadblocks and distractions, not micromanage lines of code. As for trends, there are some indicators of whether teams are “in the flow” or not. How are the features/PRs tracking over time? How much work do we usually get done (feature tickets, even PRs as a proxy)? Do we follow the process (reviews and approve those)? Do our security checks run? How does our build reliability perform? The question then is: Do we see spikes, anomalies, or unhealthy trends? These indicate issues with infrastructure, processes, and team health. Those warrant fixing and, in turn, create happier and more productive teams. Ensuring a smooth flow in software delivery. Reducing Friction, Not Micro-Managing The key to using metrics is to gain insights and confidence into processes, teams, and workflows that are otherwise hard to obtain. The engineering productivity objective should be to minimize any friction in the software delivery pipeline. This means the steps from planning a feature to delivering it to the customer and the reaction time to customer feedback/requests should be quick, smooth, and reliable. Any process or principle bottlenecks significantly outweigh a single contributor's shortcomings and should therefore be the major focus. Modern engineering leaders focus on the 4 Key Metrics to structure their engineering measurements to get better visibility into their teams and delivery processes. These metrics are: Velocity of delivery (how fast) Throughput of delivery (how much) Quality of delivery (how good) Impediments to delivery (how risky) Recently, a new wave of engineering intelligence platforms supports teams and their engineering managers to get the required visibility and insights to create such healthy and productive organizations. By shifting the focus away from individual performance metrics to reducing friction towards productivity goals, companies have achieved double-digit percentages of cost savings after a short period of time. We will dive deeper into this in a future article.