Levels of Seniority
roadmap.sh
roadmap.sh
My definition of senior developer:
- Senior will not be "stuck" with a problem. They recognize there is somebody to get help from and they will seek it. But they can also function when there is no person to get technical help from. They will dig, and dig, and dig, until they finally solve the problem.
- I can trust the solution to be usable even without supervision.
- They will have minimum standard they will enforce around them (ownership). Ownership for me means they will look for things that are not right and act on it, without being specifically instructed to.
- Is adult in behavior, can recognize and control their emotions, can work with other people, recognize and deal with communication problems.
From my perspective, people who have huge technical knowledge and experience but can't be trusted with tasks, can't be trusted to not get conflicted with the team on the first possible occasion, are not honest with their results (hide problems), will sacrifice good of the project because they just have to test that new tech -- all these people are junior devs for me.
IMO the most important qualities of a senior engineer pertain to knowing what problems to solve, and, at an even higher level of seniority, why those problems need solving.
For example, senior-level engineers will recognize when a problem is not worth solving at all. They might know that a solution is technically possible/feasible, but they will also understand that the engineering resources (i.e. their time) can, and in fact should, be better spent elsewhere -- fixing more egregious bugs, enhancing existing features and developing new ones.
To go back to what you said, being able to "dig, and dig, and dig" until they solve a problem is not what makes someone senior-level. Anyone with sufficiently high levels of dedication and stubbornness can go down rabbit hole after rabbit hole until they stumble upon something that resembles a solution. What distinguishes senior-level engineers is being able to step back and analyze the situation to determine if the rabbit holes are worth diving into.
It would, of course, be nice for a senior engineer to have perfect awareness but I think that is too much to ask to qualify to be called senior.
Have you watched Star Trek (DS9 for example) lately? You may have a bunch of senior officers but they still do not always understand why stuff needs to happen. They muddle through on principles until they succeed. Then it is always easy, retroactively, to say it was their idea all along.
At the same time, this is sort of an oversimplification the levels to senior engineers. I've seen a lot of people who have skills that really make them signficantly more effective than other people on the team (particularly me). Here are just some of the common differentiators:
- Getting tasks done [1]: As antirez says, I've noticed that some people just implement things quickly, while others take too much time. Even worse, many experienced engineers learn "too much" and make their code too "perfect" out of habit, even if they are aware of their perfectionism.
- Architecture ability: Some people simply come up with good designs more quickly. They know which data stores to use. Their predictions about scale turn out to be correct. Their designs are simple enough for other engineers to understand. Overall, their designs simply turn out to take a lot less time for the team to implement, test, and release to the customer (and not necessarily in that order).
- Expertise in CS fields: Hard problems do come up and block engineers. Good people can avoid/work around the unsolved ones and just implement that fancy downsampling or concurrency control technique when performance/correctness matters. (Ex: your shiny microservice mess is full of thorny networks/dist computing/database problems. I've seen multiple inter-service race conditions from people who don't know what a transaction is)
- Tooling experience: The person with experience with k8s will implement more quickly than the person who's never worked with a cluster manager. This is not that important, but more important than many more experienced engineers say it is. How long can you wait until your team is supposed to have a working system?
- Other qualities: product expertise, user design, interpersonal (some people singlehandedly make a team's culture good), ops skills, analytics skills, hiring (well now this is just more about what makes a general employee valuable)
So for example, a graybeard in the 1990s knew desktop development as well as the web. In the 2000s it was probably web and mobile dev, then NoSQL and reactive programming in the teens. Today it might be digging up old sysadmin knowledge for containerization, or applying functional programming to big data and machine learning problems. Maybe the definition gets fuzzier over time :-P
The problem with all of this is the danger of being put out to pasture. I hit an existential crisis last year where I stopped seeing things in code and started seeing everything like this big spreadsheet that I had to keep consistent. Satisfying multiple constraints in very large search spaces started giving me decision fatigue and I reached a point where my productivity fell below the junior developer level. Like, I'd be given a ticket to fix a bug in a view controller and discover that the problem was actually due to an incorrect relationship in the database schema from 10 years ago. After awhile, nobody wanted to hear about refactoring, they just wanted it to work, and we began the long death march of playing whack-a-mole with technical debt. It felt like there was nothing for me to contribute, and I burned out.
Now I don't know if I should continue programming, or try to transition to being a mentor in a management role, or get out of the industry altogether and move to something like renewable energy and build stuff in the real world. I'm still struggling, so any thoughts on this would be much appreciated.
The first is that some of these managers never really understood technical debt in the first place. They ascended to the position because they were willing to do "what it takes" to get the job done, with a "can do" attitude that often meant bowling over those who tried to keep sanity.
The second is the people who learned the right way, got into management, and then were crushed by the deadlines and expectations and the only thing they could figure out (while keeping their job) was to acquire more technical debt until it wasn't their problem anymore.
I see this across industries. It seems easy for former insiders to lose the ability to empathize with those in their former positions.
Another example: teachers who become principals.
We, collectively, need to get better at communicating the cost of the technical debt we face in each project. I stress that this is a two-part conversation: the engineers need to get better at explaining the amount of it in terms that matter to the end user, and management needs to learn to understand what the engineers are trying to say.
Let's also not forget that the engineers are the ones who produced the technical debt in the first place. The earlier it can be identified and weighed against other business desires, the better. Speak up about it not only once it sucks but also when it is created in little pieces.
1. We will see, if we have time.
2. Why is it not written better the first time?
The first option is mentioned by managers who have been developers before and understand stuff like this, but need to balance the delivery aspect.
The second option is said either by clueless managers and senior developers who think an all-encompassing upfront system architecture/design would have been the solution. I can talk to the senior developers about it but I don't know how to respond to the clueless managers yet.
Edit: s/hear two/hear one of the two
As engineers we need to just do it, and build it into our tasks.
A car mechanic doesn't ask the customer if its ok if he calibrates his widgetometer -- he just does it as part of the job. The customer has no idea what a "widgetometer" is (neither do I), so of course they will push back on paying for it to be fiddled with.
Of course a certain amount of developer continuity and familiarity with the code helps a lot with this approach.
In your analogy, I would say the implementation details would be things like which wrench is used, which hand turns the wrench, how many turns it takes to loosen/tighten something, exactly how you hold the bottle of widget fluid to pour it into the right widget fluid opening under the hood, etc.
The concept of which widgets are being fixed seems crucial to the full picture of understanding the state change of the system (car) before and after the work is done. The owner is paying for the state change in the system.
This is exactly why I don't work on web stuff anymore, front- or back-end. Working on products means that, for good or for ill, one _has_ to care about keeping technical debt down to a manageable level or the product collapses.
scnr
Hell I even had a tiny app make it into the official KDE distribution in high school. And I built my own templating language transpiler for a custom PHP framework ...
What does that make me? Whitebeard lol?
I think anyone who is pushing 2 decades ish or more of writing quite diverse software is likely a gr(e|a)ybeard. I started programming when I was 8, I'm now 48 and literally have a mostly a gr(a|e)y beard :)
To give a precise example, in my previous job we had very hierarchically senior people who understood the industry and the business side very well and of course knew the company's platform very well. Oh the other hand, strictly in terms of technical competence I think they lacked a lot of the basic mental framework. Their code was atrocious (core code in classes of 1000+ lines with no documentation or tests, lots of copy-paste), their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff, no code reviews, no QA etc.).
This kind of people in some ways would rank as competent architects and in some other ways as fitting the good old adage "20 years of experience - the same year repeated 20 times".
This was/is indeed the case for that organization.
> The institutional knowledge leaves through attrition
They have addressed this problem by simply silo-ing knowledge with a few key people who were very well compensated (think 10's of millions in stocks). These guys (the senior developers in my example) would only give out knowledge in bits and pieces, enough for you to do your job, but not much more.
> Eventually the quality of the product declines until customers leave.
I think more than the product becoming worse, it will simply be out-competed by better products. This will happen slowly though. By the time it does everybody who's anybody will have cashed in and moved on.
I'm curious as to how they would do this. I ask because I've seen both sides: as someone new to the company trying to understand the lay of the land and being frustrated at the lack of documentation, and on the other hand being asked for more documentation about things but not having the time to do it because of being pulled into doing other things and simply not having the time.
It also seems like most junior (for lack of a better word) developers often don't read documentation anyways, so it seems like a waste of time to go above and beyond to write docs.
HOWEVER. It is completely and totally inexcusable to build products without code review, regardless of how senior you might be. If its a spike or POC, fine. But if you're going to productionize it... you better have someone else review your code. I did see this happen and its a horrible problem: these "Senior" devs build totally unstable systems and offload them to another team to maintain; the poor team then spends most of its time putting out fires...
Though there are many other factors that contribute to excess reliance on tribal knowledge, I consider this a huge contributor to "bits and pieces" knowledge transfer. There are many people who ask others for help immediately upon encountering a problem, and they (as a group) reliably ask the same basic questions over and over. Many ask the same questions more than once, for years on end!
My honest answer to these questions is "fuck off, read the docs and don't just dump error strings into chat and rely on other people to do your job for you. Come back if you're still stuck after reading the docs with an explanation of what you tried." However, these questions are often asked in public fora, and I feel that I'll gain a reputation of being surly and not a team player if I respond earnestly: I'll give a "bits and pieces" response that probably answers the question without explaining my thought process or giving context with the aim of making the question asker go away as quickly as possible. I wish I knew how to effectively guide people into the habit of trying to find their own answers first without coming off like an asshole, but figuring that out is harder than just providing the answer.
There are, of course, plenty of things that /are/ poorly-documented. Giving bits and pieces answers for those /is/ harmful. But the same question pattern happens with public tools that are extensively documented (the Python standard library or Kubernetes, for example), and it's draining to babysit people that never learned how to, well, learn.
No documentation, testing or code reviews, selective knowledge sharing (only to some people at some times, the others might get yelled at), code that is not easy to understand on its own (not impossible of course, just hard enough that you won't bother understanding unless you really had to).
Big decisions were not really discussed with anybody except a select few. The regular developer would simply have things communicated to them e.g. from today we're using Git instead of Subversion, from next week we're doing weekly instead of monthly releases etc.
Of course, if you were persistent and really interested you would get to know more about the platform. It's just that things were made hard enough that most people wouldn't really want to do it.
I've worked mostly on enterprise software, many of which had awful code bases but we're wildly profitable.
Some business strategies are antagonistic to this sort of work, others are in effect the inverse (as in, doing the exact opposite).
I think the saddest 'joke' I tell is that I watched our industry, during the XP era, look at the numbers and decide that most of our problems come in during the requirements phase, and then instead of tackling that problem, we spent the next twenty years making sure our side of the house was in order (didn't work out that great, did it?).
Why did we do that? Did we think we were going to shame our business complements into doing better? Some of these positions actively seek out people who don't experience shame the way the rest of us do.
In theory, XP's theory in particular, fast iterations split up the business decisions over a long time, so the wreck happens in slow motion and more intervention, talking, and concrete examples are available to improve the quality of dialog.
Then Scrum gets co-opted by the business people, and now the business side does, indeed, have more time to think, and what have they done with that time? Found ways to give the developers less time to think. Oops.
Take PHP as an example. I'd say from a technical perspective not many people would go with it from a technical standpoint but we can't ignore that massive companies like FB for example were build on that (no matter if they grew out of it at a later date).
I've seen plenty of things fail due to extremely high costs to develop basic features with few enough bugs to satisfy customers. That is mostly the result of bad engineering practices, like choosing C++ instead of PHP for your web servers, or just plainly having bad engineers who don't know how to build a big project.
See also yagni, premature optimization, etc, etc
Short functions and DRY are a near universal component of fast delivery, but they are part of the set of practices that mostly enables faster delivery in the increments after the one they are applied in (though I've certainly had single sprints where my delivery time was better because I implemented a reusable abstraction early one that was used repeatedly in that task) so people focussed on fast delivery (as almost all are) who lack more than a myopic perspective tend to overlook them which has a compounding effect.
So, yes, your long lost of things (of which they are a part) matters more together than they do alone, though I'd say that your list is broad platitudes that almost no one forgets are necessary in the abstract, but where concrete details of the last—including fairly context-independent ones like DRY and short functions, as well as more context-dependent ones—frequently do get overlooked, especially when the return is not mainly immediate.
One speaker years back (possibly before Scrum darkened our doors) disagreed with the Tech Debt analogy and asserted that we're talking about wear and tear.
At the end of the day, making a change that doesn't cause any strong feelings is much cheaper than one that does. A lot of these supposedly aesthetic, nitpicking conversations are about not feeling a sense of dread when you have to look at a piece of code. I want to say that 'dread is the precursor to procrastination," but I think there are some psychologists who want to claim that procrastination is dread.
If you've ever seen anyone argue vehemently about how they can't do two 4 hour tasks in a day, it's probably because they know that one of those tasks is going to wipe them out and they'll spend the rest of the day recuperating, doing menial work or even goofing off.
If I get to control the narrative for a project, which isn't often, then eventually I will remember the roads that have always worked for my teams. That projects go better when we feel like we're incrementally getting more productive all the time, instead of slowly calcifying. That our tools require progressively less vigilance, our code becomes less scary and we become less afraid of it. We talk about what we can productively accomplish instead of what's theoretically possible to pull off. We leverage that to throw in cheap features people didn't even know they wanted, or solve problems they did not know they have (twenty minutes watching a user is more informative than days of interviews and a mountain of surveys).
That last bit may be more important than even I realize. How proud can you be of something you were ordered to do by someone you don't even interact with every day? I've never really thought of it that way before but I sure am now...
(that said, there are plenty of systems where long-term term does not really matter, as well as cases when good rules are taken to absurd levels)
Webtender tells you what you can make with the stuff you've already got. It tells you what you can make with just a few more easily acquired ingredients.
A lot of companies seem to get invested in the Realm of the Possible. Somewhere out there, all of the problems we want to solve have been solved, and we want to combine them together to solve all of our problems at once.
It's kind of cruel, if you think about it. You're asking your people to exhibit all of the absolute best qualities of the industry at the same time, and you often see bad managers ride their people into the ground if they don't manage it.
I've had a few rather memorable disagreements with people over the years about who we should fire and who we should keep. I don't care if you're the best programmer out there. I care if, within the tasks that need to get done, that there are enough tasks that I can trust you will do well and a few you can almost do well (growth opportunity) without monopolizing the work I want to assign to others.
I would much rather get rid of the people who are pretty good on the median, but when they fuck up, they aim for the stars. The former group knows their own strengths (or at least can be convinced of them, sometimes). They're a known quantity. No I won't promote them, but when they walk into my office looking like they're frustrated, my first thought isn't, "Oh shit, what did you do now?"
This was a great opportunity for you to re-examine your beliefs in, for example, necessity of QA [1], and learn when and how to save a lot of time by not writing tests yet achieve business goals for stability and continuity. Instead the lesson you took from it was "20 years of experience - the same year repeated 20 times".
[1] It's not too late though, the knowledge is out there
However I think you misrepresent my comment. I offered a comment pertaining especially to the idea of discrete levels of seniority and that of a single dimension of seniority. My examples with QA, Java 6 etc. were illustrations, not the main point.
Never look at what those guys in the banking industries are still using, you'll have a heart attack. I hear it is something ancient like Fortran and such!
>>no code reviews, no QA etc.
I find it hard to believe that something like this wouldn't collapse under its own weight fairly quickly.
At least in the case of that company the collapse will be a slow crumbling, not a big bang. What I expect will happen is that 5-10 yrs from now they will be out competed by nimbler new-comers. By then however all the important people will have executed their options, gotten their bonuses etc. and moved on. The rank and file will remain unhappy, there will be churn and nothing will change.
To me, whoever checks most of the boxes defined in this article and has a good mindset would make the cut.
Should instead be they use tact when giving constructive feedback. Too many people water feedback down--scared that they might "hurt" people--resulting in the value of the feedback being lost. We shouldn't be scared to be honest with people--even if it means they might be hurt by it. It'll be better for them in the long run to hear the truth now--even if it's tough to swallow. Giving this type of feedback needs to come from a place of love--a desire to truly help, and should never be done with the intention of hurting or trying to make them feel like they were "wrong".
It should also be added: "They can receive feedback without being hurt"
Pain is constructive in the right dose, and it's also risky since you can lose trust if delivered incorrectly. It requires maturity to give honest feedback and recognize that it might be biased since we have a lot of limitations on how we perceive others.
I formerly worked for a company that for a few years referred to all of the engineers as "rock stars" etc. As the company matured a bit, that was dropped from all of the top-down type communication.
The company didn't actually value the employees any less, and we were still praised appropriately for good work and / or solid efforts. The issue was that people simply had to acknowledge that no, not all of the engineers put in the same level of effort or had the same natural talents, and pay disparities couldn't make sense when "everyone is a rock star programmer".
Granted, by the time i had left, we only had 3 or 4 pay bands from most junior to highest job title that still programmed, but the company wasn't in the west coast and didn't pay west coast salary either, so the actual compensation gradient was narrower than what you might find at a FAANG company.
In large orgs, there are so many positions that are important but have unclear or many levels removed from impact (HR, audit, sanitation).
I've also encountered many people who aren't motivated by the mission, but rather have other motivating factors outside of work and still want to progress. I think having some systematic way to include and grow people who don't have natural motivation for impact is important, for large orgs.
That’s why in the regular army you don’t see 50 year old Captains.
I'm considered "senior" but the work in the last half of my career has certainly been more intense than the first half. Sometimes I think it'd be nice to go "back" a few steps to a job that I'm certainly very comfortable doing without too much effort and get paid decently well.
I worked at a place with long tenured people who stick around forever. Worked great and saved money, but when they retired the business was pretty screwed.
You always have to bet on management being long term dumb, so processes need to be setup to maximize short term risk for management. No modern manager gives a shit about a high impact risk 5 years from now; if you’re lucky they may care about next year.
For example if you join the Army as a specialist (E4) you have 8 years to get promoted or you’re essentially kicked out.
Though I would think for enlisted this happens much less than officers.
Junior/Normal/senior is a change in rank or function. It makes sense to provide salary steps with respect to tenure, but not changes in duties.
There's a third kind of learning in software. The first two are technical and domain, the third is abstract application and adaptability of your skills. That latter one only comes from experience. How do you efficiently learn both tech and domain? Can you identity waste (time and/or resources) early? Are you resourceful when seeking information? Are your questions and discussions phrased in ways that maintain direction and brevity? So on.
What if you're autonomous by heart, but the software is so huge and poorly documented, as well as having lots of bureaucratic rules and gripes, that you pretty much can't be autonomous? That's a reality for many developers, junior or senior.
This is the case in FANG companies. The expectation is that you figure out how to effectively find the info (whether by finding the key people, reading code, etc). Since finding info takes so much time, it's also expected that you make good judgement calls on what info you research (as you cannot be proficient in the entire codebase).
As for development - same thing goes. You find & form the right partnerships and have convincing enough arguments that people work with you on a project. Finding people that also benefit from your work is called "alignment" (of objectives).
If you are instead saying that you feel no hope that work will be valued or recognized, you need to decide either to do it anyway (because you are someone who’s going to think and do the right thing, ie, lead) given the imperfect reality we live in, or you can decide to find a healthier org to work in. By healthy, I just mean more functional and well organized, and thriving in a field of sufficient resources — similar to what you’d think of in a healthy biological organism.
So you might feel constrained by the existing language, build systems, release process, etc compared to working fully autonomously, on the other hand you can accept them as they are, gently advocate for ways they could be improved, but spend most of you energy on the things you can directly affect. It’s like gradient descent — push every axis towards improvement but push hardest on things you can improve the most. If you do this over time and don’t silo away too much, you will naturally gain more influence over time (again assuming a reasonably healthy org).
It sounds nice in practice, and I really wish it were advantageous in more places, but there’s a real risk. That assumption that you’re working in “a reasonably healthy org” is rarely safe to make.
I don't think a technical manager would ever make that statement, and I don't think a non-technical manager would care.
No. Autonomy here is figuring out what you can figure out. Figure out what you can't figure out. Use whatever resources (people, code, whatever) are available to you, and make the best decision for your company. It's not letting roadblocks get in the way. And if, after every avenue has been explored and there still is not an answer, then having the experience to produce an actual report demonstrating the code is too complex to reasonably make the required changes, present it to executives, and expect to be taken seriously. It will contain details of your investigations and alternatives to explore.
Autonomous here means you're not dead when something seems intractable. You keep pushing.
The "senior" attitude would be to find ways to achieve autonomy and improve the situation. They would either succeed or determine the company doesn't actually want a senior person in that role and move on.
In talking with senior people who have been in such situations, you hear stories about their valiant efforts with partial or full results. When I talk with junior people, you hear about complaints and wishes but little action beyond their own work.
>The "senior" attitude would be to find ways to achieve autonomy and improve the situation. How is this a "senior" attitude anyway? This should be the default attitude of any self-respecting employee, and I personally had this mindset from day 1 of my career. Who in their right mind wants to be either dependent or not make their life better? That's not junior, that's lazy.
Within a company it's possible to have some standard, and a lot of companies work very hard to make their levels as objective as possible, but even then it's incredibly difficult to reduce a large set of diverse individuals working on diverse projects with diverse skillsets down to a single number.
All that said though, it doesn't matter how good your technical skills are, if you can't unblock yourself with cross-functional efforts, or figure out a way to optimize a bad situation, you will not be considered for the fast-track in most large engineering orgs. If the situation you find yourself in is truly intractable as you suggest, then the senior mentality would be to cut your losses and find a new situation.
If you are truly a senior developer in any major metropolitan area in the US and kept up with the market, it shouldn’t take that long to find another job.
Oh yeah just stage a grassroots political takeover of the engineering team, no biggie, I'll get right on that. Doubt anyone will have any issues with that.
I'm a big believer in doing the right thing but all I say is tread carefully because you can and will get burned if you do not take into account the dynamics of a company's internal politics.
Or you find another problem or assignment without this category of problem.
If you tried all that and still aren't making an impact, go pitch that story as you apply for a position with more empowerment.
Some of the best changes I've seen took this path (client/server to web; prem hosted to cloud; n-tier to API) since the entrenched engineering team was not making appropriate design decisions.
Edit: corrected poor phrasing
…if you’re lucky.
You also have to develop your learning skills. How do you identify existing people with knowledge and be able to learn from them.
Some people's careers might take them to the point where they do not write much code, and act as a key interface between executives and programmers. If they aren't a manager and can still be on the IC track, where they provide technical leadership, coaching, vision, etc.
Beyond that, Distinguished Engineer I'd say is reserved for someone who works at a level beyond the most of us, whose work has produced multiple patents or been widely influential across the company or the industry at large. Fellow is someone who has done this continually throughout their career.
Two good intro readings on career ladders:
https://labs.spotify.com/2016/02/08/technical-career-path/ http://dresscode.renttherunway.com/blog/ladder
The tiers make me laugh sometimes, as the titled fellow, principal, distinguished, or evangelist are attributed to a few, sometimes even with the "senior" prefix added to those titles.
I am sure to catch backlash for this next statement but a lot of times it seems that people with kids stop caring. Which is only natural, understandable, because biologically something has arrived that takes all precedence.
But to me as an outside observer and co-worker I see a person stagnating.
I've had to teach senior architects not to send private ssh keys to each other and instead use public keys. How to do basic naming schemes for servers. And those are just two "timeless" examples. I won't even mention all the modern tech they ignore because they haven't cared about their profession for the last 15 years.
Edit: For context I am mid 30s and these people are late 40s or early 50s. I am not stupid enough to think I can avoid this in the future.
I've also worked with people who are 25 years old and who have clearly given up on life or anything more than turning the crank and getting their biweekly ration of pellets. They live in fear of being discovered or "found out" and turned out on the street to sell the Mercury News on the onramp to 101.
Age, experience, rigor, knowledge, energy level, mindset. Don't confuse one for any of the others. It's a multi-dimensional problem. Also, it isn't static.
I can probably give you an example of a coworker at any position in that n-way space just from my own experiences, and that's only with a 25 year career. I can only imagine what else I'll encounter next.
This might have to do with the environment I'm in (7,5 hour days with almost no overtime; recruiting motivated people).
I also personally feel I've become more responsible in all areas of my life after having kids.
Edit: I'm mid thirties too. I find the least responsible people to be those in their 50s with no kids. But I've only met a few who remained developers; most either have kids or switched to management.
Even if you take this feedback to heart, you have a limited sample set of signals. Do you average them out, or do you only care about what one particular camp said (the camp that signs your check, perhaps)? Which camps get weighted more heavily?
I don't think there are any real trends to observe yet. The field is too volatile with its labeling to really take seriously any kind of prescribed career plan to seniority that lasts beyond 3-5 years. It's also why we repeatedly test people in interviews.
In my company simply staying around long enough doesn't make you a senior. You need to demonstrate that you are working at the next level to get promoted, and the guidelines for each level are well defined.
We also have a development plan program to coach low performers into either improving, or leaving the company, so the chances of someone getting promoted and then doing bad work is diminished.
Or perhaps I misunderstood my corporate culture. Either way, I'm only pointing out another side of the story. And thanks for phrasing it better for me. English is not my native tongue, even if it might seem so.
Incompetent people stop caring once they're sure they won't be found out.
Kids have nothing to do with it.
Kids do tend to consume time which may have otherwise been used for work or work-related personal development.
Time is finite, it's not just a binary matter of caring vs. not caring, it's also higher priorities displacing lower ones.
Whether they use up your energy or they force you to reevaluate and drop unimportant things to focus on what matters, depends on your individual experience.
For myself, having a child made me extremely career focused.
In general, people would not care when they feel having no control over process and result. Just like when some other forces move them in whatever direction, like when riding downhill, why to spin the pedals?
Assuming that anyone over the age of 45 is "deadwood" is actively harmful.
But I'll put the counterpoint on it. I've become a lot more focused on getting the job done in the limited time available rather than going off on tangents and integrating each new thing I think of into the project. I also am more careful in my work, because I don't have the time or energy to deal with mistakes after work hours. And I try to figure out the best use of my time to the company. I've mostly back-burnered the idea of creating the "next big thing" and that allows me to focus on doing the thing in front of me and maximizing my utility there.
So, boring, yeah, but I think career wise it's helped me figure out how to maximize my contribution.
That said, the two anecdotes you describe sound more like a Peter Principle in action. They probably did the same thing before kids too, is my guess.
> I've had to teach senior architects not to send private ssh keys to each other and instead use public keys.
This has nothing to do with seniority, just ignorance. And ignorance knows no age.
> How to do basic naming schemes for servers.
Now this is something that I would understand why someone older would not care. You know why? Because these things are just fashions. You think they are stagnating? Truth is, they are probably just waiting until next week when some bright up-and-coming 30-something will show then another article they found online and will try to change ever-so-slightly something just so that they can feel they are making a difference. "Naming schemes for servers, really?"
They are most likely good speakers than have any technical skills.
It also speaks of overengineering, which is a highly ambiguous and subjective term that rarely leads to constructive feedback. It translates to "you are overdoing your job", rather than how you are overdoing your work. It is not actionable feedback.
Asking for help is not a trait of junior engineers. Asking for help in a non-structured way, without providing useful context or asking for help without making a reasonable attempt to understand the problem first is something that you would expect of a junior person. Not asking for help while being blocked for a long period of time is also a trait of a junior person. Being able to leverage expertise from team members is a trait of a senior person.
Now, about this:
> They have respect for the code that was written before them. They are generous when passing judgment on the architecture or the design decisions made in the codebase. They approach inheriting legacy code with an "opportunity mindset" rather than a complaining one.
No. Here the author is conflating seniority with blind personality cult loyalty. If something is suboptimal or wrong in a problematic way, then just go ahead and say it when the opportunity arises in the best way you can.
Even in the early days of software, people realized the importance of good engineering practices. If your legacy code doesn't reflect that mindset, it is not worth praising. The article author himself recognizes that dumping work on other people is a trait of junior engineers, but applies it inconsistently in this case. Senior maintainers may be able to identify legitimate tradeoffs, but when a code base is consistently bad, especially when it was already bad in its historical context, don't expect a lot of praise for the code or the authors.
If you know what exists and how it's put together (and this can come from tenure or experience in a vertical) you'll be far more productive. Tasks require less research and are implemented leveraging more of the existing design, possibly with a few tweaks in key locations, where an engineer with equivalent or even more talent may rewrite or reinvent a whole module owing to less deep understanding, and actually add less value.
This can lead to an engineer deserving to be senior in one company but not so senior in another. It's also a source of technical debt and risk when employees turn over. Knowledge is lost and merely hiring a replacement doesn't restore velocity. Sometimes modules need to be rewritten and replaced to get back to a good place.
If you’re not careful, your marketable skills will become out of date, but your salary keeps increasing because you’re very valuable to the company. Then when the company lets you go after a decade, you will be out there competing with people younger than you who have kept up to date and complaining about “ageism”. I’m 45 FWIW.
Over-engineering is a major problem, often leading to fragility and bugs.
When given a problem, they often try to fix just the current problem a.k.a. fixing the symptoms instead of fixing the root problem.
Why is that hilarious? Anyone can give feedback, maybe even correct feedback, but what is the point of feedback? It should be to help the person receiving the feedback improve. A senior engineer should be thinking about the team and not themselves. This includes their ego. If they are giving feedback to show off how smart they are in a way that hurts the team, that is not senior IMO.
I generally see two kind of seniors. The first group is senior in terms of experience and hard work. The second group got there only through obligation, working for years without growing a lot. Unfortunately, I see most management puts a hard cap on minimum experience before being a senior, so the former group and the latter group become indistinguishable. Other problems include Peter principle, where because someone got promoted to senior, he is now attributed as a good leader, despite having no experience leading as a junior before. Skills that are at best orthogonal are attributed to seniority, despite the fact many junior and medior people may be better at teaching, leading and mentoring others than their seniors. Nothing in the track guarantees a senior ever has to practice or show their excellence in these skills, either.
Furthermore, most people aren't doing interesting things. They get a revolutionizing experience at work maybe once a month at best, if not far longer. Couple that with an echo chamber and suddenly, they believe it is normal to take 3 to 10 years to become an expert on fairly trivial domain knowledge. We're not talking about top-of-the-line C++ programmers, ML experts, people driving innovation, veteran software architects or whatever. We're talking your average CRUD web programmer who did some backend, maybe some frontend. We're talking people who believe one can only be senior being able to deploy an application from scratch into a new environment, thinking this takes at minimum 3 years to learn when in reality, you could pick up a guide how to do this today. The only real thing you'll miss out are office politics and navigating in a group setting. The former is so volatile and context-dependent, you might as well learn it on the fly or wait until 15 years have passed by and pretty much any possible situation has come up. The latter is severely overstated in difficulty and most people will pick this up in no time, unless the team is dysfunctional to begin with.
Do you want to rise in the ranks? Learn to write well. Documentation, blogs, email memos, proposals, etc.—this is the evidence of accomplished seniority.
I have noticed in my own use of English language that after getting into a level where I get understood well enough in work situations and such, my language skills have started to stagnate. It does not help that even I use mostly English in my daily work, there are practically no native speakers around.
But I do agree communication skills being part of what is considered seniority. Also, being able to hold different viewpoints and communicate those to others could be considered part of being mature too.
This comment didn't make you look good. Not even a little.
That being said, especially for a non native speaker, I don’t judge their ability to communicate by their ability to write perfectly grammatically and idiomatically correct English. It’s whether they got their point across.
As your manager I might and generally do care about your personal growth, but it's not because it relates to your KPIs, it's because you're a person and I'm in a place to help you improve and I should do that because doing that is good. And, selfishly, I want to find and build great people to work with in the future. But at most places, me doing this is in tension with what my bosses would like me to do. Which is mold you into a better employee over the expected time horizon of your employee, irrespective of if that makes you a better developer or technologist. (I've learned that pushing people to be better technologists makes better employees too, but my experience is that most management doesn't get this and so we are mostly to be not trusted on that score.)