[HN Gopher] An incomplete list of skills senior engineers need, ...
___________________________________________________________________
An incomplete list of skills senior engineers need, beyond coding
Author : kungfudoi
Score : 284 points
Date : 2021-06-06 16:57 UTC (6 hours ago)
(HTM) web link (skamille.medium.com)
(TXT) w3m dump (skamille.medium.com)
| justbored123 wrote:
| Yea no, can we stop putting ALL of the weight on the technical
| people that already are MASSIVELY skilled on their field and are
| chronically overworked? The soft people skills responsibilities
| fall on the soft skills people i.e. management. That is THEIR
| job, not mine. They can't do shit else so they better do at least
| that.
|
| This is the fundamental problem with our profession, we are goal
| oriented and try to make things work at all cost, and we get
| taken advantage all the time even when we are holding all the
| cards (high demand for us, low supply).
|
| Stop making their work easy by making yours hard, you are not a f
| _cking lap boy, you are an engineer, you solve the technical sh_
| t. Make the "management and meetings" people earn their over
| inflated checks or simply move to the next job for an even better
| pay, simple as that.
|
| All my PM, TL, RRHH, QA, and the rest of the spreed sheet crowd
| have always been the same: Lest waste an hour every day in a
| pointless meeting to show them who is boss and pretend that we do
| something useful, then lets spend the rest of the day in Facebook
| and social media while I pest the nerds on chat every few hours
| asking "how is that going? do you have an estimate?". That is not
| working, that is been a parasite. Force them to earn their
| living.
| Der_Einzige wrote:
| Not sure why you're downvoted on this. Far too many managers
| try to also push their management work on the engineers
| themselves. I've seen this many times and it makes my blood
| boil. No random PM drone, it's not my job as an IC to do your
| sprint planning work for you.
| brianberns wrote:
| A big one I'd add: Ability to gather requirements from a non-
| technical user, product owner, or subject-matter expert.
| ipaddr wrote:
| This is also a sign no one hired a technical analysis or
| business analysis.
| jmchuster wrote:
| Well, you'd want both. You want someone dedicated to that
| role of business analyst, and then you also want your senior
| engineers to be able to do it, but just not focus their time
| on it. The understanding is key to improving their execution
| (unless you think BAs will provide you a 100% perfect and
| complete spec?) and helps with the turnaround time, so that
| not literally every ask to the business owner has to go
| through your BA. And maybe even most of the questions you'll
| be able to juts answer on your own, and then the turnaround
| time is literally zero.
| ericmcer wrote:
| I hate these lists because I don't think a senior engineer is a
| one size fits all skill set. You can be a mediocre coder but
| amazing at social aspects and mentorship. You can be an anxious
| wreck in social situations but have amazing engineering
| abilities.
| jmchuster wrote:
| There's nothing "wrong" if someone is an anxious wreck socially
| while being an amazing engineer. It just means that the company
| also needs to hire a good manager to take care of this
| brilliant individual. VS if they could hire someone who's maybe
| not as brilliant, but still sufficiently good to execute the
| engineering tasks that the company requires, but doesn't need a
| manager or anyone to tell them what to do, just does it and
| makes everything run smoothly. In fact, maybe even
| communicating with other teams and helping them run even
| smoother than before.
|
| Then you can see where in the first scenario you had to hire
| two people and only one in the second case, and in the second
| case you're getting even more additional value with your senior
| engineer doing partial manager-y things. So now the second
| individual is maybe 2x as valuable to the company as the first,
| and you can see it's a no-brainer for the company which to go
| with.
| bilalel wrote:
| One can also take one skill out of the list as goal to achieve.
| I don't think an engineer is able to be perfect in all skilset.
| This kind of list should be seen as an inspiration and
| challenge you in the skill we are lacking from.
| pc86 wrote:
| Both of these are true but I don't think either one could be a
| very good senior engineer (passable, maybe) and probably not
| even a passable principal/staff engineer.
| alisonkisk wrote:
| An engineer who can solve a hard problem is better for a
| project than a team of great people who just can't figure out
| how to do it.
|
| A senior doesn't have to be a leader.
| joshuamorton wrote:
| Yes but someone who can't effectively determine what
| problems need to be solved doesn't scale, not does this
| engineer scale to problems big/hard enough that they
| require more than one person
| jghn wrote:
| In most cases there becomes a point of diminishing returns
| in terms of pure engineering skill. At that point it is far
| more efficient to be able to improve over all output, not
| just your own. That's where these skills come in.
|
| Think of these as things which become critical _after_ the
| engineer has mastered the skill of solving a hard problem.
| nomdep wrote:
| This was written with the tunnel vision of a middle manager.
| Take it with a grain of salt
| qsort wrote:
| There is such a thing as a Mendoza line, though.
|
| Being mediocre at coding is fine if you can make up for it with
| other skills. Being downright bad is not.
|
| Same thing for running meetings, writing passable English,
| being able to explain technical concepts to laymen and so on.
| ipaddr wrote:
| If you are running meetings I'm not sure you are still in the
| senior developer category.
|
| These are more lead developer skills.
| walshemj wrote:
| I think the author means "senior" as a concept (For varying
| levels of seniority, from senior, to staff, and beyond.)
| and not just a point on a progression path.
|
| #1 Running meeting and knowing how they work is a really
| good skill for every one to have
| akomtu wrote:
| Realistically speaking, anyone who has all these skills can get a
| director level position with 150 reports. A realistic description
| of a senior engineer is an experienced coding monkey with
| passable social skills.
| alisonkisk wrote:
| "senior" can mean the level 3 years after college hire, all the
| way up to SVP-level Fellow, despite one of those levels having
| the specific name of "Senior Engineer" at many companies (often
| not the same level at different companies!)
| akomtu wrote:
| No way. There are 3 distinct groups of corp employees:
| workers or individual contributors (junior, middle, senior),
| managers (line manager, middle manager, director) and the
| "money managers" (vp, svp, c-suite). A senior engineer and an
| svp have nothing in common except the title prefix.
| beyondsomething wrote:
| This is a good list, and I'd add Nietzsche's classic aphorism to
| it, as these are also vital:
|
| _Ein Mensch mit Genie ist unausstehlich, wenn er nicht
| mindestens noch zweierlei dazu besitzt: Dankbarkeit und
| Reinlichkeit. (A man of genius is unbearable, unless he possess
| at least two things besides: gratitude and cleanliness.)_
| [deleted]
| wegwe33 wrote:
| Don't even bother with this list if you live in Europe. Even a
| waiting staff with zero education makes more money in Europe than
| a software developer. So if you lose your job, you will be glad
| making more money and have more fun contacting other people than
| sitting all day long at a desk for a penny.
| booleandilemma wrote:
| 24. How to write uncontroversial Medium articles filled with
| information people who have been in the industry more than a few
| years know and can kind of agree with in order to make yourself
| seem like some sort of guru.
|
| I scrolled to the bottom and sure enough:
|
| _Enjoy this post? You might like my book, The Manager's Path,
| available on Amazon and Safari Online!_
| WalterBright wrote:
| Major omission: learn basic accounting. Know what terms like
| equity, debit, margin, revenue, profit, liabilities, assets,
| etc., really mean.
| ghaff wrote:
| And when you learn that basic accounting, a couple of things.
| Cost accounting and financial accounting are related, but
| different. For financial accounting, there are often a number
| of different ways you _could_ account for something. The right
| answer may well not be something you can figure out from first
| principles. You do it the way FASB says to do it. This took me
| a bit to appreciate.
| alisonkisk wrote:
| That's important for a business lead of an engineering company,
| but huge swatches of engineering don't even work on revenue-
| driving projects at all.
| b20000 wrote:
| i agree, very important
| neilv wrote:
| If anyone is learning accounting, and wants some open source
| software to play around with, there's: https://gnucash.org/
|
| The data model is double-entry, transaction splits,
| hierarchical accounts, multiple currencies.
|
| There's also some tools support for invoicing, accounts
| receivable, taxes, budgeting, and various extensible reports.
| fridif wrote:
| Can anyone link to the technical version of this rather than the
| beyond coding version
| lmilcin wrote:
| A very good list. I agree wholeheartedly:
|
| Off the top of my head, in no particular order:
|
| * How to keep learning and acquiring new abilities.
|
| * How to recognize occasions to apply your development expertise
| to other types of problems (for example iteratively improve
| manual processes).
|
| * How to fail fast. How to validate your ideas and make mistakes
| without taking a lot of resources. How to rapidly prototype
| solutions.
|
| * How to divide and conquer complex problems. How to solve
| complex problems without knowing what you will arrive at at the
| end.
|
| * How to recognize superfluous code and design.
|
| * How to interview candidates and specifically leave your ego
| behind the door.
|
| * How to be patient and persevere to long term initiatives of
| yours.
|
| * How to recognize valid arguments and incorporate them in your
| solutions. How to change your mind.
|
| * How to credit people for their influence and cooperation in
| your successes.
|
| * How to be truly kind to other people.
|
| * How to build trust between you and your peers and you and your
| managers.
|
| * How to deal with difficult people.
|
| * How to recognize you need help and seek it before it becomes a
| (bigger) problem.
|
| * How to think big picture even in thick of things. How to deal
| with tactical without forgetting about strategy.
|
| * How to take and manage notes. Even, and especially, when there
| is no time for it.
| chiefalchemist wrote:
| Summing it up
|
| 1. Realize technology is the easy part, people are the hard part.
| E.g., that's managing leadership egos, and/or the egos of peers
| and subordinates.
|
| 2. In the context, communication is essential. Technology
| problems are solved with people and commms. Full stop.
|
| 3. Communication is not simply broadcasting, it includes
| listeningas as well. That said, sometimes (sadly?) "the whole
| truth" is better replaced with less than whole, or even silence.
|
| 4. Similarly, learn to "read the room." That could be the
| culture, the team, the project, the meeting, the individual, and
| so on.
| adverbly wrote:
| > How to write a design doc
|
| In over 5 years of dev, I've never been convinced in the value of
| design docs. I've bootstrapped several large components, I
| probably only kept up to date a document maybe once out of all
| those times, and I've never had any regret or paid a price for
| not having it. You can think up front, draw + share diagrams, get
| feedback, and have well documented source code without needing to
| introduce duplication and "englishification" of a system.
|
| I'd love to be convinced otherwise though! Always looking to
| learn! Anyone care to pitch them to me?
|
| Edit:
|
| After reading the rest of the points, I'm actually pretty
| convinced this is more of a "how to be <role that provides
| technical interface with leadership>" rather than "how to be a
| senior dev". It sounds to me like they're mixing
| roles/responsibilities here - there are certainly plenty of
| senior devs without these responsibilities/expectations.
| jmchuster wrote:
| "Plans Are Worthless, But Planning Is Everything"
|
| So i see the usefulness of design docs to be threefold:
|
| 1) Writing it all down in one place. You've got tons of
| whiteboard meetings, random discussions by the water cooler,
| random slack threads, ideas you think up in the middle of the
| night, different asks and different reqs coming in from
| different teams. It's useful to formally write it all down. And
| then once you see it all in one place, you can more easily see
| which parts of conversations you forgot, which decisions that
| you thought you all agreed on in the meeting but people
| actually thought you agreed on a different outcome. You can see
| if there are any contradictory points -- does one decision you
| agreed on in one discussion actually make it impossible to
| follow the decision you agreed on in another discussion. You've
| now got the big picture and see things now you're all zoomed
| out, that you couldn't see when each discussion was just
| drilled down into a single component or aspect.
|
| 2) Coordinate for review. So now it's all written down, and
| everyone can go through and see if there's anything that they
| missed. Are there actually any blockers in here? You can now
| send it out to all the concerned parties and they can make sure
| that you didn't miss anything, that all concerns and asks are
| being properly covered. Are all the original requirement
| actually being handled by this design? How long is this
| actually going to take now for all the involved teams and
| people to do. Much easier to do when you've got a complete list
| of everything you need to do.
|
| 3) Documents your original intent. So now you're off and
| implementing it all, and of course you end up building
| something completely different from the design doc. But it's
| still important to go back to it and be able to see, what were
| all of these original concerns and blockers and worries that we
| had? The design doc says we made this decision because of this
| showstopper, we ended up doing it a different way, but did we
| properly account for that in our final implementation. Why did
| we even want to design it this way in the first place, does
| that constraint still hold today, and will our end result fail
| because we ignored it.
| exacube wrote:
| Design docs are a _heavy-weight_ way to accomplish 3 major
| things, roughly in the order of importance:
|
| 1) Get feedback from your peers and other teams who need to
| interface with your design. Your design, or the problem you
| think you are tackling, could change based on their feedback.
|
| 2) Future readers can get a lot of context. Specifically, the
| design doc documents the trade-offs you considered and chose;
| this helps future engineers fully understand the problem space
| before second-guessing major decisions.
|
| 3) Leave some trace that you initiated/drove an effort of some
| design, for career/promotion purposes. You can demonstate how
| many stake holders/teams your work had to touch, and how
| difficult the problem & solution are based on various metrics
| in the design doc (# of ppl that participated in the review, #
| of services/components your design had to touch, etc).
| Personally this is my least favourite reason to write a design
| doc, mostly because I find people write heavy-weight design
| docs when it serves no other purpose than for perf, and design
| docs are often.. embelished when they dont need to be.
|
| Instead of a design doc, you can just file a bug, or shoot an
| email to a wider team, to accomplish the 3 things above.
| However, it becomes increasing inefficient to solely rely on
| bugs/email as the # of peers/stake holders increases, the
| scope/complexity of your project increase, or the communication
| overhead in your company increases.
|
| I think it really depends on how mature, how complex, how
| isolated, and how big your project/working group is.
|
| Where does your work fall, and what kind of process do you
| personally use to accomplish 1,2 & 3?
| lostlogin wrote:
| You've just ticked several several items on that list and asked
| for help understanding another (an act which also earns a
| tick).
| alasdair_ wrote:
| I write design docs frequently. They can be anything from two
| to about ten pages, outside of formal systems like aircraft.
| They need to be short to be readable.
|
| The point of a design doc is to get feedback on the design and
| to keep a record of decisions made and why they were made.
| That's it. It isn't supposed to stay up to date forever - your
| code should document that instead.
|
| Once you get feedback on the design, the doc has served its
| purpose - archive it and move on.
| villasv wrote:
| Did you receive many components bootstrapped by someone else?
|
| I've picked several projects along the way and just having one
| or two ADRs helped me so much. Sometimes a piece was not
| working so well, but without knowing why it was made that way
| made it really risky to just decide on a change.
|
| Like code comments and any documentation in general, design
| docs aren't best for telling what something is/does but why it
| exists, why alternatives were discarded, why apparently
| suboptimal behavior was chosen and so on.
| adverbly wrote:
| From my understanding, that is what architecture.md is for. 1
| doc to describe the current state and reasons for it, rather
| than 1 doc per change.
| igetspam wrote:
| > How to indulge a senior manager who wants to talk about
| technical stuff that they don't really understand, without
| rolling your eyes or making them feel stupid
|
| This I sometimes struggle with. It doesn't help that my recent
| efforts in this area have been with someone who also displays
| every bit of Dunning Kruger and beliefs in magic thinking like
| "the internet doesn't have problems and retries should never have
| to happen so we must have a bug!" or "everything can be solved
| with DNS (because they don't know how DNS works, what is is or
| how it can be used)".
| nicoburns wrote:
| This is a good list, and I'd also recommend the author's book
| "The Manager's Path". One of the few books in that genre that I
| felt contained genuinely useful advice.
| [deleted]
| travisgriggs wrote:
| I feel like a failure after reading this list.
|
| Is there a difference between a "senior engineer" and a "highly
| productive engineer with a long rap sheet of experience, that
| constantly feels like it's never enough"?
| kec wrote:
| Senior/Principle/Staff/etc titles are typically less about raw
| competence or tenure and more about leadership. A senior will
| typically spend most of their time working on high level design
| and overall strategy for a project, with execution left to more
| junior engineers.
|
| Seniors should be technical enough to jump in if necessary and
| they should guide junior engineers as needed but execution is
| not the main focus of the role.
| cdubzzz wrote:
| There is definitely a mix of product owner tasks in this list.
| I would say the following are either mixed responsibly or in
| some cases entirely on a PO:
|
| > How to influence another team to use your solution instead of
| writing their own
|
| > How to give up your baby, that project that you built into
| something great, so you can do something else
|
| > How to communicate project status to stakeholders
|
| > How to convince management that they need to invest in a non-
| trivial technical project
|
| > How to craft a project proposal, socialize it, and get buy-in
| to execute it
|
| > How to get information about what's really happening (how to
| gossip, how to network)
|
| There is also PM work in there but that I would say hits a
| little closer to the senior engineer.
| jpeloquin wrote:
| I think "senior engineer" is just a role with responsibilities
| that include the stuff in the posted article. There's no
| realistic expectation that someone can be successful at all of
| this all of the time, but the role requires making a credible
| effort. The work needs to get done and there are no candidates
| with perfect skills waiting in the wings.
| jghn wrote:
| Exactly. I've been kicking around for about 20 years or so.
| This list captures many things I've found set great
| developers apart from the pack. With few exceptions [0],
| people who only bring amazing engineering skills will be held
| back without some ability in these areas. That said, this
| isn't the sort of thing people should see as a checklist.
| Rather they're skills you should keep in mind and always seek
| to improve upon regardless of where you're at.
|
| [0] The exceptions are generally people with deep expertise
| in domains where that's a rare attribute
| throwawaaarrgh wrote:
| You could also see it as a Peter Principle checklist. If
| you do all of those things all the time, someone is going
| to think that you're _so great_ that they might promote you
| right out of software development and into management. So
| if you want to stay a developer, maybe try to leave a few
| boxes unchecked :-)
| bcrosby95 wrote:
| That should be covered under non-senior-engineer: learn
| how to say "no" ;)
| sirmike_ wrote:
| Feel it if you must but even this list is woefully incomplete
| if we are to strike the cynic's position! Not everyone is going
| to encounter all these in one role. Not even in a whole career.
|
| A lot of these are super redundant in my opinion.
|
| If you boil them down I bet a lot of these would be mirrored in
| one living ones life in general. Some of them can be taught but
| so much more is earned by grit and experience.
|
| I am not pooping on this site at all ... just remember
| everything in the modern world is made by a human hand. Frail
| and limited and built on billions of failed attempts. Life is
| iterative and unpredictable. It is a journey after all. Cruel
| and wide, with beauty written large everywhere in plain site.
| akarma wrote:
| This is great content, and much of it applies to other roles as
| well!
|
| I've been trying to summarize for my partner (a UX designer) what
| helps in doing a senior role well and gradually growing into
| leadership, and this says much of it better than I could have
| myself.
| macintux wrote:
| I had the pleasure of introducing Camille at RICON many years
| ago. She's quite good at bridging the management/engineering gap,
| a much-too-rare skill.
| travisgriggs wrote:
| _An incomplete list of skills people need, beyond just adulting_
|
| 1. How to run a meeting, and no, being the person who talks the
| most in the meeting is not the same thing as running it
|
| 2. How to propose a solution, take feedback, and drive it to
| resolution, in a reasonable period of time
|
| 3. How to mentor an early-career teammate, a teammate, a new
| manager who needs advice
|
| 4. How to indulge a superior who wants to talk about stuff that
| they don't really understand, without rolling your eyes or making
| them feel stupid
|
| 5. How to explain a concept behind closed doors to a person too
| embarrassed to openly admit that they don't understand it
|
| 6. How to influence others to use your solution instead of their
| own
|
| 7. How to get others to do something for you by asking for help
| in a way that makes them feel appreciated
|
| 8. How to lead when needed, even if you don't have direct
| authority
|
| 9. How to get others to listen to your ideas without making them
| feel threatened
|
| 10. How to listen to others' ideas without feeling threatened
|
| 11. How to give up your baby, that project that you built into
| something great, so you can do something else
|
| 12. How to teach others to care about the things you really care
| about
|
| 13. How to communicate with others that have shared vested
| interest
|
| 14. How to help superiors feel comfortable investing in long term
| goals
|
| 15. How to accomplish small things that lead to larger things
|
| 16. How to craft a proposal, socialize it, and get buy-in to
| execute it
|
| 17. How to repeat yourself enough that people start to listen
|
| 18. How to pick your battles
|
| 19. How to help someone get ahead in life
|
| 20. How to get information about what's really happening (how to
| gossip, how to network)
|
| 21. How to find interesting work on your own, instead of waiting
| for someone to bring it to you
|
| 22. How to tell someone they're wrong without making them feel
| ashamed
|
| 23. How to take negative feedback gracefully
|
| See what I did there?
|
| (edit: formatting)
| afterburner wrote:
| Nearly half the list: how to kiss ass
| reader_mode wrote:
| Need for what ?
| ablekh wrote:
| 1. I think that it is very important to distinguish between
| _seniority_ (formal, role- and capability-based) and
| _leadership_.
|
| 2. While the original post offers a nice list, my mental model on
| the topic is pretty simple: the higher the seniority, the more
| capable a person should be in _strategic thinking_ (both
| technical and business), ability to successfully apply it to
| correspondingly larger _scopes and impact_ (tasks - > features ->
| problems -> teams -> organization -> company -> industry ->
| economy), and _soft skills_.
| villasv wrote:
| I agree seniority is about scope, but also think that there's
| some isomorphic relationship in there.
|
| When you broaden the scope enough, leadership takes over as a
| crucial tool. Not necessarily leadership in terms of
| management, but at least in terms of leading by example,
| thought leadership etc.
|
| It's near impossible to have company-wide (say of >200 people)
| impact without any kind of leadership.
| ablekh wrote:
| I wholeheartedly agree. There is certainly a correlation
| between seniority / scope and leadership. And, as you allude
| to, it is a positive one. My point in #1 was that they are
| separate entities with their own unique characteristics and I
| just wanted to emphasize that (despite the fact that the
| author of the original post has included some relevant
| leadership expectations in the list).
| b20000 wrote:
| so is this person going to become another gayle mcdowell with a
| book that will be mandatory reading for engineers in a few years?
| the top skills engineers need to master is saying "no" and
| negotiating your compensation
| ratww wrote:
| _> the top skills engineers need_
|
| The article is talking about senior engineers, not engineers in
| general.
| b20000 wrote:
| sorry, i don't see your point
| b20000 wrote:
| funny how people vote this down - this illustrates the problem
| in our industry - engineers do not band together to counter
| more demands and expectations of a profession that is already
| extremely demanding compared to other roles in corporations
| romanhn wrote:
| A fantastic list. I find #11 to be especially critical to one's
| career growth:
|
| > How to give up your baby, that project that you built into
| something great, so you can do something else
|
| This is the only way to really scale oneself, while growing
| others in the process. Hanging on to a project indefinitely can
| rob you of an opportunity to tackle bigger, more challenging
| problems. It's so easy to get stuck on a comfortable track,
| feeling like (and probably being) an indispensable subject matter
| expert, while the bigger fish get away, often without being aware
| of them or having the necessary bandwidth to even consider their
| existence. This, in my mind, is one of the big differences
| between a senior and a staff engineer (where such distinctions
| exist).
|
| I highly recommend this article on "giving away your Legos":
| https://review.firstround.com/give-away-your-legos-and-other....
| Have shared it with many senior engineers that were looking to
| grow to the next level.
|
| Oh, and +1 to the author's book "The Manager's Path". Best one
| I've seen for anyone looking to go down that road.
| sopooneo wrote:
| Agree completely. I failed greatly at #11 at my last job. And
| payed for years. And absolutely second your endorsement of The
| Managers Path. If anyone here has ever read a "management" book
| and been baffled by how stupid it was, know that this book is
| very much a different breed.
| secondcoming wrote:
| #11 is probably true in the general case, but for me I am the
| only engineer in the company on a revenue-based bonus scheme
| due to my ownership of a pet project. It also doesn't stop me
| from working on other things. Obviously, if the company have
| the impression that 100% of your time needs to be on X then
| that's bad and they're probably getting that impression from
| you yourself.
| godelski wrote:
| This also seems to be one of the biggest things I've seen small
| but great open source projects mishandle. As the userbase
| becomes larger they need to hire more devs but that means not
| having as much control and others doing things that you did
| before. Learning to delegate (#3, #8, #9, #10, #12, #18, #20,
| #22) is a really difficult task (because it takes all those
| points). It is the transitioning from an mostly an engineer and
| partly a manager to mostly manager and maybe engineering that
| many engineers find difficult.
| lolive wrote:
| My own list is:
|
| - understand the query language of ES
|
| - do some Haskell
|
| - boost my Bash productivity scripts
|
| - swim 6 hours per week
|
| - dance again
|
| - repair my bike
|
| - help my kids become even better/happier than they already are
|
| - let the managers manage
| lolive wrote:
| I wonder why my very real todo list was so downscored...
|
| Is it because being a winner at work is completely no longer in
| my scope?
| clumsysmurf wrote:
| What is a good resource to learn these points? Does the Manager's
| Path cover this material?
| timoth3y wrote:
| Another way of thinking about it:
|
| I moved out of engineering year ago, but this is a great list of
| the skills senior _staff_ need beyond whatever their core
| competency is.
| jedberg wrote:
| > How to explain a technical concept behind closed doors to a
| senior person too embarrassed to openly admit that they don't
| understand it
|
| This list should also include: How to admit you don't know
| something as a senior engineer and learn from junior engineers
| who are closer to the new technologies.
|
| As a junior engineer I found that I respected senior engineers
| more when they asked me to teach them something they didn't know.
|
| As a senior engineer I feel like I get a lot more respect from
| the junior engineers when I just admit, "I don't know that can
| you teach me more or point me at some good resources?". For that
| matter, I get a lot more respect from other senior engineers when
| I give them exactly the same response.
| romanhn wrote:
| That's a great one. An observation that I've made over the
| years is that junior engineers tend to shy away from asking too
| many questions, afraid of appearing incompetent, whereas the
| most senior engineers asked the most questions. At a certain
| point asking questions becomes less about informing yourself,
| and more about informing the team (through context shared in
| meetings, chat). It can even take the form of the Socratic
| method, using questions to bring others to conclusions that may
| already appear obvious to you. Much better approach than
| pushing an idea directly onto others, and leaves plenty of room
| to change course as a result of the conversation.
| jedberg wrote:
| > junior engineers tend to shy away from asking too many
| questions, afraid of appearing incompetent
|
| Very true! And if they see senior engineers asking questions,
| they will hopefully feel more comfortable doing the same.
| DenverCode wrote:
| I would love to see a similar list for junior engineers.
| pkdpic_y9k wrote:
| Yes me too!
| duncan-donuts wrote:
| I'm pretty sure this extends into all roads of life. Being able
| to admit you don't know something instead of acting like you is
| a good trait. At the very least people won't look at you and
| assume you're completely full of shit.
| lostlogin wrote:
| I think that just about the whole list applies to people who
| are more senior in their roles - not just software
| engineering (of which I know little).
| LeonB wrote:
| > How to admit you don't know something as a senior engineer
| and learn from junior engineers who are closer to the new
| technologies.
|
| Definitely! This is something I do a lot and _love_ to do. I'm
| excited when i realise "oh, rather than reading and reading in
| this topic - I can ask (a person who happens to be junior) if
| they're not too busy".
|
| Everyone learns off everyone the whole time.
| ChrisMarshallNY wrote:
| Happens to me all the time.
|
| I have decades of experience, but there's often stuff I can
| learn.
|
| Here's an example: I have developed an SDK, with heavy
| documentation, but I have found that written docs aren't
| actually very useful, as no one reads stuff anymore.
|
| So a new engineer on my project showed me Postman. Before, I've
| used far humbler REST explorers. In turn, I showed him Charles
| Proxy.
|
| I've actually gone way beyond what he needed with it, because
| it's a great tool.
|
| It is not a 100% replacement for my docs, but it will help a
| lot.
|
| I can develop an architecture that is way beyond anything he
| can do, but it's worthless, if he can't write stuff that uses
| it.
| uyt wrote:
| It depends on what you're asking about. I remember an older
| engineer asking me what the term "amortized analysis" meant and
| that made me write him off as someone who doesn't know basic CS
| concepts (he was still a great product engineer, but I never
| once went to him for technical help afterwards).
|
| In hindsight, I guess it's sort of forgivable given his age.
| The topic probably wasn't even invented yet so he couldn't have
| learned about it in school.
| arghnoname wrote:
| Everyone has blind spots. I have a PhD in computer science. I
| wouldn't think any lesser of someone's technical chops if
| they weren't familiar with the term, so long as they quickly
| understood it when explained.
| bmitc wrote:
| Seems ignorant to me, but what do I know? I've never studied
| or used amortized analysis either.
| jedberg wrote:
| I'd never heard that term, so I looked it up. I was
| definitely familiar with the concept, but never heard that
| term for it before.
|
| Not everyone learns the same terms for the same concepts.
| Maybe you should be a little more accepting that not everyone
| had the same education you did.
| theshrike79 wrote:
| > How to admit you don't know something as a senior engineer
| and learn from junior engineers who are closer to the new
| technologies.
|
| (For reference: I've been paying my bills with code for a good
| 20 years now.)
|
| I've learned 80% of what I know about Javascript, Typescript
| and React from one dude on my team who was freshly out of
| university. The dude was (and still is) a damn genius at that
| stuff.
|
| If he doesn't burn out by overreaching, he'll be a legend by
| 2025 =)
| MattGaiser wrote:
| Senior engineers seem to need a lot more social skills than
| regular engineers. So much of that seems like managerial stuff
| that at least as a more junior developer I come nowhere close to
| touching.
| Traster wrote:
| As much as people laud 10x engineers, the reality is that if
| you can make the people around you 2-3x more effective you're
| likely adding the value of a 15-20x engineer without writing a
| line of code.
| romanhn wrote:
| I've never thought of 10x engineers as someone who can crank
| out 10x amount of code. Influencing others to accomplish
| larger goals is the best way to scale yourself reliably. And
| then there are the rare unicorns who can do both, e.g. John
| Carmack (having indirectly observed his leadership style at
| Facebook).
| nthj wrote:
| Yeah, the 10x debate always seems to be just a disagreement
| of terms. Are we talking about junior engineers shoving
| lines of code through the JIRA backlog with no negotiation
| over what the most effective things to be working on are?
| Probably not 10x variance, and if there is, maybe they're
| cutting corners on process.
|
| Are there people who say "I propose we subtly adjust the
| product in this way which saves us 7 person-months of
| development effort and 2 months in time to market while
| delivering 90% of the original proposal's value?" Yeah,
| there are, and I don't understand why we pretend that can't
| be a thing.
| secondcoming wrote:
| I consider myself a sociable person and that can have negatives
| if you're too pally with juniors. They may not take you
| seriously if they've seen you drunk on the thursday night work
| drinks. The more senior you go the more of a barrier there
| should be.
| alisonkisk wrote:
| Getting drunk has nothing to do with social skills, except as
| a poor way to deal with a lack thereof.
| suchire wrote:
| As people become more senior, the distinction in skills and
| responsibilities between managers and engineers starts to blur
| a lot. In fact, the best folks in both tracks have spend some
| time in the other track
| romanhn wrote:
| Don't worry, a lot of that is experience, though at a certain
| point you have to get intentional about your growth, as not
| everything comes naturally to most people. And senior engineers
| are regular engineers too. Well, most of them :) Senior
| engineers should be partners to managers and yes, there are
| overlapping skills for sure. That happens because building
| product is a lot less about raw coding as a less experienced
| engineer would expect. It's about people and teams and
| communication to a very degree, in fact. This too you will
| learn with time.
| runawaybottle wrote:
| tldr: how to be human
| g051051 wrote:
| Ugh. I'm an engineer, not a babysitter.
| cperciva wrote:
| Missing item: How to say no. Sometimes this is necessary because
| management literally wants the impossible (e.g. to solve the
| halting problem); other times it's necessary because management
| isn't aware of the tradeoffs (e.g. we _could_ release this game
| next week, but people will probably get annoyed when it crashes
| once a day; or we _could_ add the feature you 're asking for but
| it would take years of additional engineering time).
| Traster wrote:
| >How to influence another team to use your solution instead of
| writing their own
|
| Yeah I'd love to figure out how you do that. 99.9% of the time
| that is a cultural and political problem that you aren't going to
| solve by being some incredibly persuasive engineer. Oh and
| management won't care enough to intervene.
|
| I think one of the things that a lot of these articles lack is
| something along the lines "Be clear about what you can acheive
| and what you can't". It doesn't matter how good your solution is,
| if the guy writing the replacement isn't receptive to advice
| that's fine, you've got better things to do.
| Dove wrote:
| The ingredients to doing that, in my opinion, are:
|
| - Actually be right -- it really is to the other team's
| advantage to use your solution.
|
| - Find people on the other team receptive to the idea and talk
| to them. Informally, privately, in small meetings, and in large
| ones -- different settings will be appropriate in different
| social contexts.
|
| - Have a lot of social capital already. In this context, what
| this means is have a reputation for getting the other team
| recognition and making them successful, working with them when
| they want to do things their way, and going out of your way to
| help individuals with their own (unrelated) projects.
|
| - Put in all the work to make the advantage of your solution
| easy to see. Do the integration work for them, if you can. Set
| up a demo, if you can. Do the legwork, make the slides, do the
| research, solve their problems. Install it for them, if they'll
| let you!
|
| - Shut up about your part in their subsequent success. All you
| ever wanted was for them to succeed, and they made a smart
| call, and that's the important thing.
|
| At least that's the way I do it. :)
|
| I once saw an extreme master of the technique use it to
| convince an entire team of 50+ people including engineers and
| two layers of management to change an existing piece of
| infrastructure (our change control system) to something better.
| He did it by meeting privately with every individual touched by
| the process, explaining the advantages and the costs, getting
| individual buy-in from each one. He then put together a
| presentation outlining the change and held a big meeting to
| review the proposal -- with all the people he'd already talked
| to, who privately were behind the idea but thought nobody had
| the power to change it. Once everyone saw that everyone was in,
| it was a done deal. And that's how you solve impossible
| political problems. :)
| BeetleB wrote:
| > Yeah I'd love to figure out how you do that. 99.9% of the
| time that is a cultural and political problem that you aren't
| going to solve by being some incredibly persuasive engineer.
|
| You answered your own question: Get better in the
| social/political/psychological sphere. Handling/tackling
| cultural and political problems is sort of a prerequisite to
| being a senior engineer. :-) This is sort of "standard career
| advice".
|
| If you think going "political" is a betrayal of your values,
| then your thought process is part of the problem.
| yummybear wrote:
| This combined with the list of skills for a fullstack developer,
| leaves Superman as the only qualified person for the job.
| sombremesa wrote:
| To be fair, no one would hire you over superman. These lists
| are all great for employers - please provide as much value for
| as little expense as possible.
|
| As far as personal development goes, don't let anyone else
| dictate what's important for you.
| alisonkisk wrote:
| Alternatively, the list tells you what employers pay a
| premium for.
| sombremesa wrote:
| Nobody knows what you're capable of when you're being hired
| (unless you're well known - in which case you command a
| premium anyway), and once you're in the system it's highly
| unlikely you'll get paid more just for being a better
| employee. At the very least, you have to demand it.
|
| Your employer is usually perfectly happy getting more for
| less.
|
| Who is the target audience of TFA? Most likely, people who
| want to 'level up' in their career and still naively
| believe that skill (versus hustling or nepotism) is the
| main driver of such things. [0]
|
| Entire frameworks have been built just to afford the
| creators a career in consulting so they can 'level up'.
| Perhaps the less the average engineer thinks about such
| things, the better...
|
| [0] https://i.redd.it/90avfvfjxj961.jpg
| wanderer2323 wrote:
| The title says 'senior' so one would think Google Senior (L5),
| Amazon Senior SDE3, Microsoft 64 etc, but the sub-title indicates
| it is for 'all levels of seniority'.
|
| Well duh, ok, I would expect a Google Principal (L8) or Microsoft
| Partner (69) to be able to perform most of this list.
|
| The list for the exact Senior would look more like this:
|
| 1,2,3,4,5,11,15,16,21 -- L5+ senior engineer
|
| 6,8,12,13,14,19 -- manager (M1+) or L6+ engineer.
|
| 7,9,10,17,18,20,22,23 -- common "skills" that everyone executes
| up to their ability, but in general you would expect a
| corellation between the eng level and the ability in these.
| varjag wrote:
| I see this kind of arbitrary must have skills lists quite
| frequently lately. Is it something they hand out as home
| assignments in bootcamps nowadays?
| booleandilemma wrote:
| Lists are easy to write and they get clicks.
| lostlogin wrote:
| As seen everyday in newspapers and particularly around
| Christmas. "Top 10 Christmas snack foods." "14 dog collars
| your fur baby will bark for."
| telesilla wrote:
| #22 is one I'm struggling with at the moment with a colleague:
| _How to tell someone they're wrong without making them feel
| ashamed_. I 'm very tactful except when it comes to asking other
| people to be tactful. Any suggestions would be really appreciated
| here and make for an unexpected Sunday.
| romanhn wrote:
| I would approach this by bringing up (one on one) concrete
| examples of where this person displayed a lack of tact (without
| calling it as such). If the other party reacted strongly,
| analyze that and get this person to understand cause-and-
| effect, along with explaining that there are other ways of
| accomplishing their goals. Come with concrete ways of how you
| would have done it. If the other party reacted privately to
| you, instead talk about how you would feel, perhaps even ask
| them to imagine how they would feel if someone talked to them
| in a similar way. Don't make it personal at any point, your
| goal is to help them see that there are better ways of
| accomplishing their own goals. I find most folks are open to
| that kind of feedback. If the person is an incorrigible
| asshole, you may need to escalate.
| jseban wrote:
| This is something I test candidates on during interviews, I
| make a small mistake, or disagree with an opinion to play
| devils advocate, just to see how they will tell me. Are they
| going to be nice about it, or become nasty, and how will they
| resolve the situation of a disagreement.
|
| Me personally, I sometimes just ask to double check "are you
| sure?" even though I know a person is wrong, and say something
| like "I am very sure of this, let's double check" instead of
| saying "no, you are wrong".
| ghaff wrote:
| Yeah, I know someone who is otherwise pretty empathetic who
| has a tendency to lead with "No..." when there are better
| ways.
|
| This is one thing where not being in person often hurts--
| although even pre-pandemic that was often the case with me.
| If a reasonable well-aware person is reading a not to large
| room, they'll probably respond if someone suddenly gives a
| "Did I just hear what I thought I heard look?"
| spicyramen wrote:
| Really good write up. Definetly a guideline to get promoted too
| Supermancho wrote:
| From the article:
|
| > How to help someone get promoted
|
| Any strategic or tactical advice is particular to each company.
| This is not a skill. The other skills include mentoring, so this
| seems a little redundant.
| catlifeonmars wrote:
| I read this as "how to convince decision makers to promote
| someone."
| jedberg wrote:
| It's different from mentoring. It's being good at making sure
| management is aware of your coworker's accomplishments. It's a
| managing up skill instead of managing down skill.
|
| For example, when you as a senior engineer are in a meeting
| with management and without the junior engineers, it's
| important to call out "Jr. Eng X did this part of the project
| and did a great job".
|
| That's what that skill is about.
| vvanders wrote:
| Yeah, a lot of this is providing visibility to low visibility
| high impact work or Anchoring[1] work so people's impact is
| correctly reflected as a part of whatever review process an
| organization does.
|
| [1] https://mekka-tech.com/posts/2018-08-09-the-difficulty-
| ancho...
___________________________________________________________________
(page generated 2021-06-06 23:00 UTC)