[HN Gopher] Levels of Seniority
___________________________________________________________________
Levels of Seniority
Author : arbhassan
Score : 183 points
Date : 2020-02-22 13:30 UTC (9 hours ago)
(HTM) web link (roadmap.sh)
(TXT) w3m dump (roadmap.sh)
| camhart wrote:
| "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"
| tyurok wrote:
| Second that.
|
| 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.
| barrkel wrote:
| 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.
| scarface74 wrote:
| 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.
| arcanus wrote:
| 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.
| hirako2000 wrote:
| 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.
| [deleted]
| ath0 wrote:
| 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.
|
| Two good intro readings on career ladders:
|
| https://labs.spotify.com/2016/02/08/technical-career-path/
| http://dresscode.renttherunway.com/blog/ladder
| tyingq wrote:
| 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.
| alpha_squared wrote:
| 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.
| mberning wrote:
| 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.
| eropple wrote:
| 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.)
| scarface74 wrote:
| 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.
| leto_ii wrote:
| 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".
| 886 wrote:
| No one is perfect. No one can check all the boxes. Having the
| desire to try to check them all is the key. Quoting the last
| part of the article here.
|
| To me, whoever checks most of the boxes defined in this article
| and has a good mindset would make the cut.
| felipemnoa wrote:
| >>>>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.
| DenisM wrote:
| 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
| hinkley wrote:
| 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?"
| cle wrote:
| 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.
| hinkley wrote:
| 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...
| aero142 wrote:
| 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.
| JamesBarney wrote:
| 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.
| hinkley wrote:
| 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.
| ivanhoe wrote:
| 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.
| [deleted]
| Godel_unicode wrote:
| s/know/think
|
| See also yagni, premature optimization, etc, etc
| rootusrootus wrote:
| 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_.
| theamk wrote:
| 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)
| k33n wrote:
| 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.
| matwood wrote:
| > 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.
| BlargMcLarg wrote:
| 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.
| [deleted]
| tillmannhgl wrote:
| 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.
| prepend wrote:
| 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.
| Spooky23 wrote:
| Sure it is, you gate underperforming people at the low bands
| and attrit them out.
|
| That's why in the regular army you don't see 50 year old
| Captains.
| seanmcdirmid wrote:
| So promote until the Peter principle is activated?
| Spooky23 wrote:
| 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.
| hurricanetc wrote:
| 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.
| seanmcdirmid wrote:
| Isn't that the same thing? You eventually reach a level
| where you can't perform at the next and become classed as
| incompetent.
|
| Though I would think for enlisted this happens much less
| than officers.
| gowld wrote:
| No, you get promoted to level of competence, then fired
| after several years _instead of_ becoming incompetent.
| yibg wrote:
| 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?
| beefalo wrote:
| Because they want people who will grow that they can
| promote because it's really expensive to hire SDE III+
| yibg wrote:
| I don't think internally promoted SED III+ are any
| cheaper than externally hired ones. If they were they'd
| soon go else where anyways.
| cwp wrote:
| 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.
| bradleyjg wrote:
| 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.
| yibg wrote:
| 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.
| bradleyjg wrote:
| 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.
| closeparen wrote:
| 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).
| zdragnar wrote:
| It is an easy way to justify multiple pay bands.
|
| 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.
| psim1 wrote:
| This interesting essay is marred by bad grammar.
|
| 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.
| samiru wrote:
| 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.
| [deleted]
| sputr wrote:
| His name is Kamran Ahmed and he's from Dubai.
|
| This comment didn't make you look good. Not even a little.
| psim1 wrote:
| The point of discussion here is not to make oneself look
| good. Do you disagree with my statement?
| [deleted]
| scarface74 wrote:
| 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.
| kamranahmed_se wrote:
| I will go through it one more time, thank you! Feel free to
| submit a PR though. It's on GitHub
| https://github.com/kamranahmedse/roadmap.sh
| 29athrowaway wrote:
| 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.
| zackmorris wrote:
| 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.
| yibg wrote:
| 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.
| justanotherc wrote:
| 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.
| Swizec wrote:
| 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 ...
|
| What does that make me? Whitebeard lol?
| keithnz wrote:
| 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 :)
| zackmorris wrote:
| 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.
| ThrowawayR2 wrote:
| > " _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.
| IggleSniggle wrote:
| 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?
| dvdgsng wrote:
| neck...?
|
| scnr
| JMTQp8lwXL wrote:
| 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.
| jaredgorski wrote:
| 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
| naivete, 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).
| heymijo wrote:
| > _I've seen ex-engineers in management positions...forget
| how important it is to offset technical debt_
|
| 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.
| kqr wrote:
| 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.
| leetcrew wrote:
| 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.
| kqr wrote:
| It's a fantastic pitch to the existing customers who have
| suffered through those crashes.
| JamilD wrote:
| When OS X Snow Leopard was announced, this was the intro
| slide: http://2ig18m1zutag3bjpoclbo8am-wpengine.netdna-
| ssl.com/wp-c...
| animesh wrote:
| 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.
|
| Edit: s/hear two/hear one of the two
| invalidOrTaken wrote:
| 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.
| diN0bot wrote:
| 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.
| kamranahmedse wrote:
| 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.
|
| - [0] https://github.com/kamranahmedse/developer-roadmap
| top_kekeroni_m8 wrote:
| 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.
| [deleted]
| vjeux wrote:
| There's usually a "ramp up" period where you get to learn that
| knowledge. As you get more senior, that period gets longer.
|
| You also have to develop your learning skills. How do you
| identify existing people with knowledge and be able to learn
| from them.
| Jestar342 wrote:
| 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.
| BlargMcLarg wrote:
| >IME autonomy is the primary measure of seniority
|
| 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.
| jasonpeacock wrote:
| 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.
| scarface74 wrote:
| "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.
| BlargMcLarg wrote:
| 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.
| dasil003 wrote:
| 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.
| scarface74 wrote:
| 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.
|
| Edit: corrected poor phrasing
| chipuni wrote:
| 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.
| scarface74 wrote:
| 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.
| saagarjha wrote:
| > But, someone in the organization does.
|
| ...if you're lucky.
| Scene_Cast2 wrote:
| > 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).
| blevin wrote:
| 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).
| kaikai wrote:
| 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.
| darkerside wrote:
| This doesn't line up to me. We they told that by a
| technical manager, or non-technical manager?
|
| I don't think a technical manager would ever make that
| statement, and I don't think a non-technical manager
| would care.
| enra wrote:
| 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.
| Benjammer wrote:
| >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.
| jasonpeacock wrote:
| That's exactly what senior behavior looks like, and is
| what propels you to the next level.
| Qasaur wrote:
| 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.
| darkerside wrote:
| This is absolutely correct, and so is parent. Like any
| ambitious endeavor, done well it leads to success, and
| done poorly to disaster.
| prepend wrote:
| 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.
| [deleted]
| humanrebar wrote:
| 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.
| idoby wrote:
| The actual content of the roadmaps doesn't seem to be in the
| GitHub repo so I can't open PRs to correct typos.
| kamranahmedse wrote:
| Hey, everything is there at
| https://github.com/kamranahmedse/roadmap.sh/blob/master/cont...
| lmilcin wrote:
| 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.
| INTPenis wrote:
| 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.
| bpizzi wrote:
| 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.
| dancek wrote:
| 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.
| yibg wrote:
| 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.
| vsareto wrote:
| 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.
| yibg wrote:
| 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.
| free652 wrote:
| 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.
| angarg12 wrote:
| 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.
| dasil003 wrote:
| 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.
| inertiatic wrote:
| Competent people stop caring once they don't have anywhere to
| go, career-wise.
|
| Incompetent people stop caring once they're sure they won't be
| found out.
|
| Kids have nothing to do with it.
| pengaru wrote:
| > 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.
| inertiatic wrote:
| Kids change your life.
|
| 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.
| zoomablemind wrote:
| 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?
| rglullis wrote:
| 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?"
| scarface74 wrote:
| 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.
| rachelbythebay wrote:
| 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.
| philjohn wrote:
| 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.
___________________________________________________________________
(page generated 2020-02-22 23:00 UTC)