[iLoveOncall]

I've read the free preview on the different meanings of what is a senior engineer, and I have to say I'm not convinced.

"Years of experience" VS "Technical ability" is at best reductive, at worst completely wrong.

I encourage you to look at large companies and how the levels are defined (https://www.levels.fyi/blog/amazon-leveling-progress.html here for example, for Amazon) and the nuance that there is.

The different parts you cover are commendable ("How to build trust and work with your manager", "How to ask better questions", etc.), but they are bare minimum requirements for an engineer that has a couple of years of experience, they're not what is needed to reach the senior software engineer level.

Junior to not Junior anymore? Sure. Junior to Senior? I don't see it.

[dandigangi]

Agreed. I've found some value in years of XP but its very contextual. It feels like its used as gating many times vs depth of experience. Have come across and promoted many seniors with lesser years that have the experience and talent to put their money where their mouth is. And... plenty of 20-30 year veterans that are not good at all.

One framing I like to use when asked about junior and upwards is at the junior level you are focused on self success which is learning skills, building knowledge on how to develop software, the SDLC processes, estimation, and consistency. The higher you go the responsibility set grows to impact other developers on the team and products to a higher degree. Further is expanding horizontal and depth impact where you impact other teams and larger parts of the organization.

Last is that you don't have to be a senior to act senior but for them it is explicit responsibilities.

[ravenstine]

> "Years of experience" VS "Technical ability" is at best reductive, at worst completely wrong.

I'm not sure it's a completely useless model, but it's problematic. One problem that comes to mind is that a certain number of seniors are going to settle into their role and are going to be driven by different things than a young kid at his first junior dev job. The junior may be more driven because there's more at stake and may come with a fresh perspective since they're actively learning.

> they are bare minimum requirements for an engineer that has a couple of years of experience, they're not what is needed to reach the senior software engineer level.

Depends on who defines "senior". You're correct in terms of what it is to be a senior engineer. To get the title of senior engineer is more a function of time and social skills.

[dglass]

Thanks for the feedback. Holloway's platform makes it easy to make revisions, and I plan on updating the content periodically based on feedback like this. Comments from readers in the book itself also help as well to adjust the content over time.

I had a feeling this topic would be a bit controversial on HN :) I tried to address this in the book in the first section of "What Makes You a Senior Engineer?" by talking about the different meanings, and how the software industry doesn't have a standard definition of what a senior engineer role entails. Everyone will have a different opinion on what makes a senior engineer, so I'll try to add more info about the nuances involved in the senior title in future revisions.

[benrow]

If I may suggest some further feedback, I think mentoring is very important at a senior level. Perhaps this could be covered in a chapter in the existing communication section, unless of course I missed something!

I think learning to identify how engineers could improve, and being able to successfully help them, is a big level-up. Departments will want to trust their seniors to do this proactively - rather than say, just when questions come up - as this helps foster a healthy team with everyone growing.

One other point comes to mind on impact - as this is often seen as a key differentiator for senior engineers. It's good to see the section on improving processes in your book, as this is a nice way to add a lot of value. Another way to make an impact is keeping a close eye on product delivery and cycle time, and identifying any problems. For example, is work getting released often, or is it getting stuck in 'nearly done'? Are there frequent blockers to builds or deployments? How is cycle time looking recently, and are there any lurking issues where work is getting blocked frequently? How do we work around this current setback - is there a short term solution to keep things moving while we work on a proper fix? Are we currently on track for delivery?

Managing complexity is another area which can be tough to navigate as a new senior.

Just some thoughts which came to mind, as we all see things from a different perspective.

Overall, I really like the focus of the book. We need more of this stuff and this will help a lot of people, so kudos on the release!

[dglass]

That's some great feedback, thank you! I'll add these to my notes for the upcoming revisions.

There's a section about having a "team-first approach," but I agree with your comment that mentorship is another trait that could even deserve it's own section.

[rmbyrro]

From his LinkedIn profile, the author doesn't seem to have experience in the likes of Amazon.

"Senior" will vary depending on the size of company and the scale of problems it deals with.

[metabagel]

I don't think someone should have to work for Amazon in order to write a book about how to become a senior developer.

>> "Senior" will vary depending on the size of company and the scale of problems it deals with.

No matter what company you work for, your role is in a specific context, typically within a group or working on a project. And it's not the scale of problems the company deals with which makes you a senior developer. It's the scope of your assignments and the breadth of knowledge and experience which it takes for you to be able to tackle them.

[rmbyrro]

I did not say it's a requirement, just highlighting what type of experience the author has.

[iLoveOncall]

In terms of pure job title I agree, but it's not the way it is presented here.

This book claims to give you the keys to unlock the skills you need to reach the "Senior software engineer" level.

It doesn't tell you it's not for large companies and it doesn't tell you that the "Senior software engineer" level he is talking about may meet the expectations of one class of company but not the other.

The target is specifically "ambitious" software engineers. I'm fairly certain that ambitious software engineers are many to have FAANGs as a target.

[rmbyrro]

That's why I found useful to mention here the type of experience the author had in his career.

Prospective readers can judge the likelihood for the book to be useful for them based on this additional data point.

[mooreds]

I wrote a blog post in 2018 about the different dimensions of being a senior engineer and have to say it is a complext and deep topic.

I counted 10+ different aspects: https://www.mooreds.com/wordpress/archives/2812

[metabagel]

"they're not what is needed to reach the senior software engineer level"

I don't really follow your train of thought. It might help if you could list one or two additional things, beyond what appears to be in the book, which someone should have in their toolbox in order to become a senior developer.