I only recognize difference between junior/senior levels.
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.
Your list only handles how senior engineers solve problems.
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.
Let's be honest, this is requirements for a senior engineer, not a tech lead.
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.
This feels like the difference between someone who _needs_ mentoring and someone who does not. In other words, a senior engineer according to your definition can (mostly) "manage themselves". I do think that this is good in that it gets at the core of what makes a software engineer good (from the perspective of a good manager).
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)
I wish that the article mentioned the fourth level of seniority: graybeard. Bluntly, that's any developer over 40. But in terms of mindset, it's more like having multiple years of experience in a discipline spanning 2 or more eras so that you begin to see solutions outside of the immediate problem space in front of you.
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.
You're right-- nobody wants to hear about refactoring. Management instead hears "time sink and no additional revenue" (which isn't true, since too much technical debt reduces velocity-- but you're the engineering expert, not management. For a moment, let's forgive their naivete). So when you pick up tickets, build more time into your estimates. Adding 30% more time to your estimates isn't crazy, since estimates are often wrong, and people frequently go over them. This really is a communication issue with how you package up your discussion of time allocation to management. Before exiting industry, I would consider giving this strategy a try.
I’ve seen ex-engineers in management positions (one very well known and experienced engineer in particular) forget how important it is to offset technical debt. I think, more than naïveté, product managers just become consumed by feature-making and feel unproductive if there’s not a constant rush to hand new features off to engineering (which are then rushed to release).
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 think some part of this is that technical debt is invisible to the people that don't directly deal with it, so it's easy to underestimate how much of it there is.
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.
my charitable take is that they don't forget, but they have a hard time explaining to customers why the next release has fewer new features. "now with fewer crashes!" isn't really a good marketing pitch.
I always hear one of the two things when I say refactoring.
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.
Refactoring is (as Uncle Bob puts it) an implementation detail. That means management doesn't understand its value, so they should not be expected to take ownership over it.
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.
This is the approach I typically advocate. I actually like to think of quality, depending on the project of course, a bit like an LSM tree.. Well, in the sense that I expect new code and features to be a bit more loose and chaotic. Over time though, the chaos should be reduced and "compacted" if you will as code is revisited and patterns emerge(rule of three).
Of course a certain amount of developer continuity and familiarity with the code helps a lot with this approach.
Imo, this is silly and condescending. I've worked with plenty of team leads and PMs who understand the value of refactoring at some level.
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.
> "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..."
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.
I'm 36 now but didn't start my software career in earnest until 33. Prior to that I had a lot of leadership experience (as well as being a software hobbyist). What kind of beard will I be when I turn 40?
I think it depends on the culture and the relationship between engineering and management a lot. Good places I’ve been at management will create the buffer and time for engineers to refactor (within reason) instead of just patching things. Great places I’ve seen management isn’t even the gate keeper. They help set the objective and engineers decide how to execute. If that’s a quick patch then fine, if it’s spending more time to completely rewrite something then fine too, as long as the relevant impact is communicated.
I’m only 32 but I started with DOS and later desktop programming, moved on to LAMP in the 00’s, then SPA in the 10’s, and now going heavily to serverless+JAM.
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 ...
Well I think the whole pirate/ninja thing is a great metaphor for hackers, so technically you are a blackbeard. My friend and old business partner is 3 years older than me but still highly productive making games in Unity, so I think of him as a wizard or maybe a whitebeard. I'm just, haggard, so feel like a graybeard even though I can't grow one.
well, 40 is a hard cut off into gr(a|e)ybeard society. So, at the moment you are a "wannabe" ;)
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 :)
I don't know, but do you have a blog? I struggle from this too. Right now my solution is side projects, but I can only do this because I have very low expenses.
Many of the points made in the article seem pertinent to me, however I think thinking in terms of discrete levels of seniority is counterproductive. I also think that there isn't a single dimension of seniority that we should talk about.
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".
It’s also illustrating that we engineers love to nitpick over stuff that ultimately doesn’t matter all that much. You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.
You picked the easiest strawmen out of his examples to knock down in short funtions and DRY. The other examples were, no QA, no code reviews, which are things that I have seen first hand, combined with the other complains, to code that is always in a half broken state. The code is very difficult to change so you spend all of your time on support cases. Re-writes have their own pitfalls. Ultimately, developer retention and hiring suffer because no one wants to work on these products. The institutional knowledge leaves through attrition and it takes too long for new developers to learn to be productive in the code base. Eventually the quality of the product declines until customers leave. So, even highly profitable products die because of poor engineering practices. There are certainly engineers that get caught up in know-it-all platitudes, but I've personally seen more profitable products fail because of poor engineering practices than good engineering practices fail because of poor business sense. YMMV, but in my experience, good engineering is more rare than good business ideas.
> Ultimately, developer retention and hiring suffer because no one wants to work on these products.
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.
> would only give out knowledge in bits and pieces, enough for you to do your job, but not much more.
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...
> most junior (for lack of a better word) developers often don't read documentation anyways
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.
I have faced the same dilemma and don’t have a good solution either. An interesting twist is that people that ask basic questions that can be looked up then “DM” me on slack. My approach has been to ignore such questions; often I legitimately lose track of them anyways, but I don’t like the approach simply because it seems anti social. Then again I am only a human; it’s hard to provide one on one assistance to everyone that asks.
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.
Woah my experience is completely different. I've never seen a product fail because of poor engineering practices. And I've seen plenty fail because of business issues.
I've worked mostly on enterprise software, many of which had awful code bases but we're wildly profitable.
What kills those products is not the bad code itself, it's the side-effects piling up: added dev expanses, lagging behind the competition in adding new features, performance problems as app grows, etc. Badly written code is simply more expensive to maintain and improve. I guess it's less of an issue if you have a very profitable product and/or enterprise clients who are much more tolerable to things like the simplest customization taking weeks to finish, integrations that are complicated and cost thousands and thousands of dollars, etc. For startups and smaller businesses that are tight on dev budgets it's much bigger of an issue.
My best bosses and I think every mentor I've ever had (some were both) talked about what they value, where they want us to be, instead of micromanaging us on how to get there.
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 never seen a product fail because of poor engineering practices.
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.
Well engineers love to nitpick over stuff that we know will bite us in the ass in a few years. The most wonderfully architected set of business rules is of little help if it takes weeks to debug and it's impossible to refactor and add new features in future because no one knows how the code really works (and the guy who did it left long ago), it's untested and unreadable. Lots of great projects died slow deaths because of this.
Yeah those are all useful rules of thumb but I doubt anybody is gonna tell you that the point of those is that you should just not give a damn about anything besides whether your code can tick off the AC of a ticket.
My point is that a lot of engineers freak out about things they read a Facebook engineering blog post about, and are "engineering" a crazy complex system for months to handle non-facebook volumes of traffic. They then reassure themselves by valuing the ideological purity of their design over the months salary they wasted on building their Sistine chapel of REST. This is mid-level engineers all day, every day.
Yes, sure, that sucks, but you need some kind of balance, because sometimes you dig a hole that's so deep it's hard to get out of. Surely part of being "senior" is having some sense of what kind of abstractions and optimizations are worth making up-front and which can be saved for when they become necessary.
This deserves more upvotes. I have met so many engineers who do themselves a disservice by overvaluing the esoteric bits of code that nobody but their team will ever see. The business doesn't care as long as it works, and soon. Which isn't to say that you shouldn't sometimes sweat the small stuff, but you always have to remember that you're working for a business.
> You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.
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.
We discount logistics a lot when we have conversations like this.
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...
Only if you don't care about long-term.
Those things are not "platitudes", those are lessons learned from the experience keeping large systems maintainable.
(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)
I don't really have a term for this, but I kind of prefer the 'webtender' model of project management. It shows up in volunteer work quite a bit, but sadly not often in software.
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?"
The evidence you supplied suggests that "this kind of people" can tell what's really important from things that are not (either outright fads or not applicable for this particular business), and they have a track record to show for it.
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
My personal conclusion is that (unfortunately for people who care about quality and craftsmanship) in many industries it's enough for software to be "good enough". The rest can be covered with sales & marketing.
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.
>>>>their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff...
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.
> 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.
"They know how to give feedback without hurting anyone."
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 think the idea of having three (or four or five) buckets of seniority is not applicable for modern work any more. Leveling is too much about hierarchy and too less about the actual impact. Beyond leveling is something what doesn't need to be defined in a word, but is more about specific knowledge or competence that is needed to solve a problem.
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.
Impact based leveling is deeply flawed: it privileges those who are assigned to work on the best products with the most legible success metrics. That’s how you get the kernel hackers who keep the lights on perpetually at entry level, and the people who were told to scaffold CRUD apps in the right place at the right time treated like rockstars. (I am the latter by the way).
This is why I like small organizations where compensation can be tied to impact.
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.
I do wonder about the wisdom of this up or out (to some level usually) some times. For example, you can’t be SDE I at Amazon for 10 years. But why not? If I’m doing a good job as a SDE I, I’m happy with the job and pay and just want to keep doing it what’s the problem?
It's really expensive to hire at that level of seniority - even if the salary is the same once they start, it also takes a lot of time and money to get them to that point.
It’s hard to manage mediocre performers. Low performers you get rid of, and probably no one is too upset because even if they were well liked everyone recognizes that you can’t keep around low performers. High performers are obviously not an issue. But for mediocre performers, you risk the boiling frog where they slowly edge towards low performance but it’s hard to point to anything specific. And by sticking around forever they make a lot of allies and become increasingly hard to get rid of.
What about high performers that don't want to move up? I've known a few really good engineers that just don't want a lot of stress and don't care that much about the extra pay. They just want to do their work well at the level they are at and get paid.
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.
That’s definitely a downside to an up or out system. In other industries there’s a “mommy track” that allows for stepping back without stepping out but I don’t know of anything like that in tech.
For the military... not really. They have a concept called “high year of tenure” which limits how long a soldier can remain in a rank without being promoted. You are meant to advance and if you don’t advance you will be separated out.
For example if you join the Army as a specialist (E4) you have 8 years to get promoted or you’re essentially kicked out.
It would be the same thing if promotions weren’t so ludicrous. If you are an enlisted and want to get a promotion your best bet is to max your PT scores. It really has nothing to do with your ability to do a job at all.
Usually there’s a title standard at a particular band. A principal engineer is not just performing tasks for example, they are providing engineering/technical leadership.
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.
https://roadmap.sh/backend - I notice that this doesn't contain anything about understanding abstraction, abstraction barriers, managing complexity in problem v solution spaces, identifying "as simple as possible but not simpler", etc. I don't even mean design patterns or OOP, though those are nice applications. How things have changed. It's like how there was a time when physics was witnessable visual and tactile grappling with the world around us, and now it's become extreme math: the "programming" joy of yore has been replaced by webdev legoing.
Thank you for the feedback. It's still a work in progress. It was mainly moved from the repository[0] and needs to be updated. Plus it is lacking in a couple of other sections also which we plan on improving. Please feel free to leave your feedback and suggestions in the form of issues on the repository.
Senior level developers are usually people with excellent domain and business knowledge. How does one get a senior programming job without knowledge of the field?
I might consider myself a senior in my current job, but I wouldn’t necessarily call myself that when applying to a new field.
IME autonomy is the primary measure of seniority. If you need mentoring, or are completely uncomfortable being told "I don't know, can you figure it out please?" then you definitely have an opportunity to grow.
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.
> but the software is so huge and poorly documented
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).
You know how a lot of engineering comes down to making good choices about trade offs? Could be speed vs memory, could be which language or API to use, could be keeping it simple vs anticipating likely future needs. Same thing goes for working with an organization or codebase that has sub-optimal aspects. You think about and pick which, among many axes, is the most impactful thing to push on and you just do it. If the software is huge and poorly documented, write the docs you want to see for the parts you work on. If it’s a big tangled mess, pick somewhere to start unwinding and just find a way to make some sort of progress. If you do this, and you have a healthy org, it will become a natural reference point for others about how to do things well.
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).
A pattern I see over and over is good engineers doing exactly what you suggest, writing those docs, filling in the communication gaps, and then being told they’re not “technical” enough for their role, or a promotion, or a raise.
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.
Then throw your hands in the air and say that whatever business problem your company is trying to solve, well, they'll just have to deal with it?
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 idea that you can't be anonymous in such a situation is a "junior" attitude.
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.
Sounds very "no true Scotsman" and people are taking this way too senior vs junior.
If you are a junior wanting to become a senior or prove themselves as being more than junior, but find yourself in scenarios where management isn't actually asking for a senior but a rockstar, domain-expert medior going under the title of senior, what do you do? Continuously hop jobs until you get lucky? Wait until you finally rack in enough years so society deems you worthy of senior? Most situations I find myself in don't want to be fixed. Trying to take charge comes across as trying to tell the driver how to drive, or take the wheel myself, when its their car we're riding in. And using my own car is akin to starting my own company or going contracting.
>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.
The needs of a senior engineer vary by org and culture. It's only a "no true Scotsman" thing if we insist that there must be a single objective definition, but such a thing is a total myth. I've hired devs with the senior title that barely kept up with college interns. Similarly I've seen folks with 5+ years fail to meet expectations for baseline engineer with clear coaching and PIP over 6+ months, leave the company and land their first "senior engineer" a month after being fired. I've seen senior google engineers who failed to thrive in an open-source stack since they were used to being hand-held by Google's internal tooling and wealth of expertise they could turn to for any issue that was outside their immediate wheelhouse.
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.
“Either change your environment or change your environment”
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.
I think in that case it’s still a case where as a senior you should figure out how to be most effective in that situation, push for a change, take leadership and convince others.
>push for a change, take leadership and convince others
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.
This is also, in many companies, what the lead up to an internal blacklisting looks like, especially when said company has a dysfunctional technical management. Entrenched players (competent or not, mostly the latter) who may have been involved in the original iteration of a software project and/or architecture in many cases do not take too kindly to someone who is willing to rock-the-boat and challenge their authority.
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 avenue to address the same concern. Or you find better evidence to support your position. Or you mitigate against bad priorities and be patient until it's obvious that the bad decision isn't paying off. Or you talk to different people to see what you are missing.
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.
That is quite literally what senior developers need to do. Not only performing well, but convincing others of the soundness of the design. This may involve a mutiny.
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.
The code is the documentation. If you can run it through a debugger, you can figure out what it does. You may not know why it was written that way. But, someone in the organization knows.
You mean: Someone who used to be with the organization knows, but they were let go three generations ago when the management fired the developers to move development to India, then fired that outsourcing organization to move development to China, then fired the China team and brought you in as a temp.
Then you assume the source code is the spec. If you are brought on as a temp even better. You’re probably being paid either as a 1099 or W2 contractor and thus are billing by the hour. You get paid for trying to disentangle the mess.
This is a good read. Anyone have recommendations for reading on the next steps past 'senior'? This is called various things, like principal engineer, fellow, etc. at bigger organizations.
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.
At Microsoft, I'd say roughly senior is able to lead a project end to end. Principal is being able to represent a department and take responsibility for making sure multiple projects are run smoothly, developers are growing, outages are prevented. There's some overlap, and it's really just a matter of scale and trust. As you produce results, you get more trust and more responsibility for larger things. Progressing through principal is much more about paying attention to the bottom line. It's your responsibility to make sure the things you're doing are things that either customers are willing to pay for, or things that greatly reduce COGS. These are all achievable by mortals so long as you're hard working, determined, and focused on the right things.
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.
There are a bunch of great references for career ladders, broadly speaking, that discuss the rollout process and what each level means for that company. The best not only say something about the levels, but about how the levels are interpreted in line with that company's culture, whatever it means. It's very hard to get to levels beyond senior as a pure generalist: you're typically going to have to have worked on projects with significant, company-wide impact, and that usually means (a) doing something unique within a domain and (b) working with many others, in different types of roles, in your company, in order to have that impact.
Deliver industry-changing projects with proven results and know your industry/domain; this could also be projects that open up new markets for the org. While I think senior developer is achievable without domain knowledge of the industry, I fail to think of a single principal or fellow I've met who did not have deep understanding of the field they're in. Some had patents to their name, some didn't; all had 'proven' in some way that they're indispensable for their respective domain.
When a senior engineer sits on that role for too many years, the promotion is honorific (and jumps in salary band and benefits), or its a way to reward a very valuable senior engineer before he hop to another job. At least that's what I've seen in large organisations where senior has actually become a mid level engineer.
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.
My experience is that the fellow, principal, distinguished, etc, positions are almost always appointed positions. So there's little you can do, other than find opportunities for broad exposure, to land one.
Everyone's talking so positively about seniority but I've seen it backfire horribly.
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 know people who have raised multiple kids beyond the point of them graduating from college and themselves starting their own families who are still in this industry (by choice), and are still sharp as ever.
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.
That's weird. I find people with kids care more about personal and professional development, and are more diligent in their work.
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.
I’ve observed the same. Some of the most productive engineers are those with kids. Difference is they focus on getting their work done and doing it well (so they don’t get paged at night for instance) instead of chasing the new shiny, or being the hero.
At least one conclusion from this thread is that there are camps of people with different beliefs, and you're senior to one camp, but not another. A productive engineer, or not.
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.
I think the reality right now is people go to the "camp" where they fit more comfortably. Older engineers with kids that want to work their 9-5, get work done and go home gravitate towards companies that are friendly to it.
Might you be mistaking seniority with 'tenure' or years of experience?
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.
Yes I do think I mistook seniority with tenure but mostly because that is the culture I work in.
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.
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.
This may be also influenced by the selection criteria (or culture in other way). Basically, it's about those "who stay". The reasons to stay in a stagnating org could be diverse, but the attitude for change is often "lay low". Reasons to stay in "more with less" org are kind of a gamble, quite unsettling for anyone, let alone with kids.
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?
On the other hand, I work with some developers in their late 40's and 50's who are just as sharp as those far younger, not afraid to use new technologies (if they are a suitable solution to a given problem) and be awesome mentors.
Assuming that anyone over the age of 45 is "deadwood" is actively harmful.
I'm not really sure it has something to do with having children. I would say it's much simpler: either you care, or you don't, whatever is your current age. I'm pretty sure those 'senior' architects we already that reckless back in their twenties.
I think this is actually a reasonable point from a certain perspective. I know personally since having kids, I work like half the time that I used to before, and I'm far more out of touch with the latest and greatest technologies. I nailed the hype train on functional languages and NoSQL databases in the early 2010's, but docker, k8s, and such, anything 2013 or later I'm clueless.
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.
Before I had kids I'd regularly work 12+ hour days. Afterwards I am much better at time management. This has nothing to do with caring about my work (which I do to a fault). It's about realizing that raw hours do not necessarily make an engineer more effective, and achieving big things is a marathon not a sprint.
Attributing the perceived lacking performance of people to having kids is just another way for ageism.
> 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?"
I doubt it's stagnating, it's just they never were good to begin with. Personally I am not stagnating yet (mid 40s), but I have seen mediocre people getting promoted to architects and the only thing they can do are high level design presentations without any value.
They are most likely good speakers than have any technical skills.
It should be just the opposite. Now that I have more responsibility, I care more about staying marketable. I never want to be in the position where my livelihood is based on a job instead of having marketable skills and a strong network that will allow me to get a job quickly if I want/need to.
This article conflates personality traits and attitudes towards problem solving with seniority.
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.
What's not covered here is overlap between what an engineer knows and what the business needs; and especially knowledge of the business's existing codebase and architecture.
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.
I’ve seen this far too often. Theoretically, your pay should be a combination of what you could get for your same skill set on the open market plus getting paid over the market value based on what you bring to the company based on your domain knowledge and the relationships that you’ve built that allow you to be more efficient than someone off the streets.
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.
The real truth is that none of these titles mean anything outside of a given organizational context. Hilarious that the author felt the need to add "can give feedback without hurting people" to the senior engineer bullet list. So much wishful thinking here.
> Hilarious that the author felt the need to add "can give feedback without hurting people" to the senior engineer bullet list.
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.
There's some truth in your statement that most people do not wish to admit and are quick to dismiss as "rebellious, arrogant juniors".
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.
Really enjoyed your comment. Your comments about lack of innovation/interesting problems at most places are spot on. And "senior" developers being hung up on CRUD techniques is laughable to anyone who has solved truly difficult problems.
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.
English might not be his first language. Not mine either, so I did not notice the bad grammar!
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.
English is my first language and I didn’t notice any off putting grammar errors.
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.
This is a very good overview. One thing I would add for the junior and mid level developer is “attitude towards work in general”. One thing I see commonly in many junior and some mid level engineers is an inappropriate attitude towards work vs their career aspirations. For example, they will treat their job like an hourly employee with no skin in the game, and then complain about raises, promotions and bonuses. You don’t need the best development skills to show up on time, be diligent, work hard, and be a good teammate.
As somebody pretty firmly in the staff/principal firmament (when not in a management role), I absolutely, positively do not care in the slightest and at least low-key discourage people I mentor from having "skin in the game." Unless you have entire points in the company, "skin in the game" is a handle by which people can manipulate you to do things that are bad for you, your health, and your career. It's not that it should be an adversarial relationship, and one of the really nice things at my current job is that it it's the first I've ever been at that isn't (it's a genuinely good place to work, with empathic and decent upper management, and they get a lot more out of us for it)--but most are and it's not a line employee's fault and it's foolish to not recognize the game being played. Professionalism doesn't require emotional attachment and it shouldn't be expected or too generously given. Show up, do your job, do it well. But make sure you are building towards the next one and don't let the current one minimize your ability to get the next one.
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.)
I’ve been in this field a fair amount of time and my “skin in the game” is not to leave my coworkers hanging. But too often you hear employers talk about “we are family” and “the mission” to convince people to work 60+ hour weeks. I do the best work I can within a normal 40-45 hour week.
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)
[1] http://antirez.com/news/112
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.
https://news.ycombinator.com/item?id=22335738
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.
- [0] https://github.com/kamranahmedse/developer-roadmap
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.)