3 ms·

Are "Senior" titles meaningless in many companies? Absolutely. But they also matter in many others. It seems as though the author's "juniorness" is showing thr

Are "Senior" titles meaningless in many companies? Absolutely. But they also matter in many others. It seems as though the author's "juniorness" is showing through while writing this. In particular, the assertion that "programming skill is the most important skill for senior developer". I'm not sure that's true. You cannot write code in a vacuum; software development requires communication and understanding of the business to ensure you're solving the right problem. Doesn't matter how great your code is, if you write a solution to the wrong problem, you provide zero value. At companies where seniority is done well (FAANG, etc.) your performance is measured not just on the quality of your code, but the impact you provide to the business: this includes code quality, but also working on projects that matter to the bottom line of the business, enabling teammates to do their best work, bringing in new people, basically acting as a multiplier force.

cle 8y ago
Agree. I work at a large company with very specific role guidelines for "Sr. Engineer" vs. a regular engineer. The main differences are not "programming" skills, although a Sr. Engineer is expected to have solid programming abilities. This statements sticks out to me: > You can argue that being a “senior” is more than just being a good programmer, but if the “junior” developer is more productive and is trusted with tough problems, at the very least we should reconsider what a “senior developer” really is. Maybe the type of companies Eduardo has worked at, or the scope of his work, has left him thinking that the business solely values programming ability. But at my company, and at many other large companies, Sr. Engineers have a skillset that is nearly impossible for new graduates to have, because they aren't taught in college. In addition to technical prowess, these include: * Operational best practices (how to monitor, deploy, and maintain systems) * Project management (able to disambiguate a project and design it into achievable milestones with parallelizable work units) * Historical context...like it or not, this is very valuable * Knows how work happens across teams, such as best practices, pitfalls, technical strategies for minimizing coordination, etc. * Can work and communicate clearly with stakeholders, PMs, customers, etc. to make the right product tradeoffs * Know what matters and what doesn't when it comes to programming in a team setting, which is very different from solo programming Almost all companies will value these skills, even if they have dropped the ball and don't have them listed as competencies. > Yes, nobody wants to work with bad teammates, but refusing to acknowledge that there are great programmers who are also great teammates at the age of 22 is not the solution. More than likely, those great programmers are recognized with salary increases. If they can't perform the tasks I listed above, they can be the best programmer in the world, but they don't belong as a Sr. Engineer. Which is fine, many people are happy not having to deal with all that "soft" stuff.
chii 8y ago
> also working on projects that matter to the bottom line of the business this is my problem with this sort of assessment : as an engineer, you don't get to pick which projec to work on. The politics of the company may end up making you look like you're worthless even though you could've provided so much more value working on something else.
hardwaresofton 8y ago
I don't agree with the author's stance on everything but I do think that programming skill is the most important skill for a senior software engineer/developer, for a few reasons: - Code that is confusing/hard to approach for others (including future you) is bad code, so no "seniors" or "architects" that write crazy complex code aren't good at what they do -- true masters make complex things simple. - Identifying the right problem to solve is not the engineers job -- this is squarely in business planning/project management domain, which is rightfully a different specialization - Like the above, engineers shouldn't even be wasting time chasing down requirements, this is the job of project management, making people who have and specialized their craft over years spend time playing politics is wasteful. I do recognize the need for the other skills you noted in a modern business, but maybe we should be calling those skills + programming skill something different. As far as I can tell with your response and others, a non-exhaustive list non-code metrics for "senior"s are: - Business value understanding/delivery - Guiding junior engineers - Navigating politics Maybe we can call that "Senior Engineering Project Lead" instead and make the required skill sets more distinguishable. The fact is that if you start optimizing for some of these other skills you're going to take a hit on architectural/programming skill -- time and attention is limited. If what the position requires is someone who spent 60% of their time honing their craft, and 10% learning to navigate politics and 30% focusing on business-level understanding, then maybe we should signify that with a more descriptive title. I guess the crux of my argument is that "Senior Software Engineer" is a misleading title. As a side note, I think this is just yet another way for companies to extract more value from employees -- build in more and more requirements into an role denoted to be strictly for engineering, make another rung on the bullshit internal payment ladder to climb. I also would be more sympathetic to the "business impact" if more of the "business reward" was shared with those producing the value, and FAANG didn't actively collude in the last decade to reduce employee wages.
- dingaling 8y ago
  > identifying the right problem to solve is not the engineers job But the senior engineer has a vital role in advising which problems are solvable. Either in terms of technology, skill, time or budget. That input needs to start at the commencement of a project. Here's my rough delineation: a Senior knows why a particular requirement is in the Func Req Doc. A Junior doesn't. > [and if] FAANG didn't actively collude in the last decade to reduce employee wages I laughed at that. FAANG salaries are so out of context of most around the World that they are irrelevant. As a 15-year Senior in the UK I was earning $50,000 equivalent. And no stock options. I don't think FAANG salary ladders even start that low.

cle 8y ago

Agree. I work at a large company with very specific role guidelines for "Sr. Engineer" vs. a regular engineer. The main differences are not "programming" skills, although a Sr. Engineer is expected to have solid programming abilities. This statements sticks out to me: > You can argue that being a “senior” is more than just being a good programmer, but if the “junior” developer is more productive and is trusted with tough problems, at the very least we should reconsider what a “senior developer” really is. Maybe the type of companies Eduardo has worked at, or the scope of his work, has left him thinking that the business solely values programming ability. But at my company, and at many other large companies, Sr. Engineers have a skillset that is nearly impossible for new graduates to have, because they aren't taught in college. In addition to technical prowess, these include: * Operational best practices (how to monitor, deploy, and maintain systems) * Project management (able to disambiguate a project and design it into achievable milestones with parallelizable work units) * Historical context...like it or not, this is very valuable * Knows how work happens across teams, such as best practices, pitfalls, technical strategies for minimizing coordination, etc. * Can work and communicate clearly with stakeholders, PMs, customers, etc. to make the right product tradeoffs * Know what matters and what doesn't when it comes to programming in a team setting, which is very different from solo programming Almost all companies will value these skills, even if they have dropped the ball and don't have them listed as competencies. > Yes, nobody wants to work with bad teammates, but refusing to acknowledge that there are great programmers who are also great teammates at the age of 22 is not the solution. More than likely, those great programmers are recognized with salary increases. If they can't perform the tasks I listed above, they can be the best programmer in the world, but they don't belong as a Sr. Engineer. Which is fine, many people are happy not having to deal with all that "soft" stuff.

chii 8y ago

> also working on projects that matter to the bottom line of the business this is my problem with this sort of assessment : as an engineer, you don't get to pick which projec to work on. The politics of the company may end up making you look like you're worthless even though you could've provided so much more value working on something else.

hardwaresofton 8y ago

I don't agree with the author's stance on everything but I do think that programming skill is the most important skill for a senior software engineer/developer, for a few reasons: - Code that is confusing/hard to approach for others (including future you) is bad code, so no "seniors" or "architects" that write crazy complex code aren't good at what they do -- true masters make complex things simple. - Identifying the right problem to solve is not the engineers job -- this is squarely in business planning/project management domain, which is rightfully a different specialization - Like the above, engineers shouldn't even be wasting time chasing down requirements, this is the job of project management, making people who have and specialized their craft over years spend time playing politics is wasteful. I do recognize the need for the other skills you noted in a modern business, but maybe we should be calling those skills + programming skill something different. As far as I can tell with your response and others, a non-exhaustive list non-code metrics for "senior"s are: - Business value understanding/delivery - Guiding junior engineers - Navigating politics Maybe we can call that "Senior Engineering Project Lead" instead and make the required skill sets more distinguishable. The fact is that if you start optimizing for some of these other skills you're going to take a hit on architectural/programming skill -- time and attention is limited. If what the position requires is someone who spent 60% of their time honing their craft, and 10% learning to navigate politics and 30% focusing on business-level understanding, then maybe we should signify that with a more descriptive title. I guess the crux of my argument is that "Senior Software Engineer" is a misleading title. As a side note, I think this is just yet another way for companies to extract more value from employees -- build in more and more requirements into an role denoted to be strictly for engineering, make another rung on the bullshit internal payment ladder to climb. I also would be more sympathetic to the "business impact" if more of the "business reward" was shared with those producing the value, and FAANG didn't actively collude in the last decade to reduce employee wages.

dingaling 8y ago
> identifying the right problem to solve is not the engineers job But the senior engineer has a vital role in advising which problems are solvable. Either in terms of technology, skill, time or budget. That input needs to start at the commencement of a project. Here's my rough delineation: a Senior knows why a particular requirement is in the Func Req Doc. A Junior doesn't. > [and if] FAANG didn't actively collude in the last decade to reduce employee wages I laughed at that. FAANG salaries are so out of context of most around the World that they are irrelevant. As a 15-year Senior in the UK I was earning $50,000 equivalent. And no stock options. I don't think FAANG salary ladders even start that low.