16 ms·

An incomplete list of skills senior engineers need, beyond coding

• nicoburns 5y ago
  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.
• akarma 5y ago
  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 5y ago
  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.
• WalterBright 5y ago
  Major omission: learn basic accounting. Know what terms like equity, debit, margin, revenue, profit, liabilities, assets, etc., really mean.
  • b20000 5y ago
    i agree, very important
  • neilv 5y ago
    If anyone is learning accounting, and wants some open source software to play around with, there's: https://gnucash.org/ 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.
  • ghaff 5y ago
    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 5y ago
    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.
    • WalterBright 5y ago
      Even if it's not revenue-driving, somebody is budgeting and looking at the costs, and wondering if it is justified. To sell your project idea to management, it's far more effective to speak their language. It's career-limiting otherwise.
    • dwq65 5y ago
      We call those cost centers, which is another useful term to know for when you’re derisively called one. Also COGS/OCOGS and such, which is basically accountingspeak for “annoying overhead we wish we didn’t have to spend but nonetheless must,” and which occasionally shows up in department names to serve as a handy reminder of your corporate value. Without knowing how accounting works you’d sit there wondering “what the hell is that acronym in my department name in Outlook, anyway?” whereas once enlightened you understand how your team is evaluated at a higher level. It’s not just accounting, honestly, knowing how business works is advantageous for anyone. “What do you do here?” “Oh, I’m just a cost center.” is a pretty fun tack to take with leadership, often true, and likely to confuse the hell out of them in its simultaneous honesty and correctness.
  • halfmatthalfcat 5y ago
    While personally one should probably know what those mean, in the context of a Senior Engineer, I've never been in a position where I would have to know what those mean or have ever worked in a place where any engineer, let alone a Senior, needed to know what those mean.
• b20000 5y ago
  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 5y ago
    > the top skills engineers need The article is talking about senior engineers, not engineers in general.
    • b20000 5y ago
      sorry, i don’t see your point
  • b20000 5y ago
    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 5y ago
  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-commandments-for-scaling-startups 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 5y ago
    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.
  • godelski 5y ago
    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.
  • secondcoming 5y ago
    #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.
• Supermancho 5y ago
  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 5y ago
    I read this as “how to convince decision makers to promote someone.”
  • jedberg 5y ago
    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 5y ago
      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-anchor/ https://mekka-tech.com/posts/2018-08-09-the-difficulty-ancho...
• beyondsomething 5y ago
  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.)
• igetspam 5y ago
  > 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)".
• travisgriggs 5y ago
  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"?
  • sirmike_ 5y ago
    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.
    • sirmike_ 5y ago
      *sight
  • kec 5y ago
    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.
  • jpeloquin 5y ago
    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.
• MattGaiser 5y ago
  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.
  • suchire 5y ago
    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 5y ago
    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.
  • Traster 5y ago
    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 5y ago
      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 5y ago
        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.
• wanderer2323 5y ago
  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.
• telesilla 5y ago
  #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 5y ago
    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 5y ago
    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 5y ago
      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?"
• brianberns 5y ago
  A big one I'd add: Ability to gather requirements from a non-technical user, product owner, or subject-matter expert.
  • ipaddr 5y ago
    This is also a sign no one hired a technical analysis or business analysis.
    • jmchuster 5y ago
      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 5y ago
  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.
  • bilalel 5y ago
    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 5y ago
    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 5y ago
      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 5y ago
        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 5y ago
        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.
• deleted 5y ago
  [deleted]
• lolive 5y ago
  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 5y ago
    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?
    • DocTomoe 5y ago
      It is because the original article is not a personal bucket list, but an actionable todo for career advancement intended for the masses.
      • lolive 5y ago
        I probably should have read the article :) #myBad Did the author mention luck and treachery as most important skills for career advancement?
• clumsysmurf 5y ago
  What is a good resource to learn these points? Does the Manager's Path cover this material?
• jedberg 5y ago
  > 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 5y ago
    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 5y ago
      > 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 5y ago
        I would love to see a similar list for junior engineers.
        • pkdpic_y9k 5y ago
• yummybear 5y ago
  This combined with the list of skills for a fullstack developer, leaves Superman as the only qualified person for the job.
  • sombremesa 5y ago
    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 5y ago
      Alternatively, the list tells you what employers pay a premium for.
      • sombremesa 5y ago
        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... I should put in a caveat since this is hacker news - being actually good rather than having the appearance of being good is better for your career in startups, but the opposite is true for BigCos like FAANG. [0] https://i.redd.it/90avfvfjxj961.jpg https://i.redd.it/90avfvfjxj961.jpg
• akomtu 5y ago
  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 5y ago
    "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 5y ago
      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.
• deleted 5y ago
  [deleted]
• fridif 5y ago
  Can anyone link to the technical version of this rather than the beyond coding version
• runawaybottle 5y ago
  tldr: how to be human
• g051051 5y ago
  Ugh. I'm an engineer, not a babysitter.
• varjag 5y ago
  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 5y ago
    Lists are easy to write and they get clicks.
    • lostlogin 5y ago
      As seen everyday in newspapers and particularly around Christmas. “Top 10 Christmas snack foods.” “14 dog collars your fur baby will bark for.”
• booleandilemma 5y ago
  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!
• lmilcin 5y ago
  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 5y ago
  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 5y ago
  > 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.
  • lostlogin 5y ago
    You’ve just ticked several several items on that list and asked for help understanding another (an act which also earns a tick).
  • alasdair_ 5y ago
    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 5y ago
    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.
• ablekh 5y ago
  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 5y ago
    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 5y ago
      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).
• Traster 5y ago
  >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 5y ago
    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. :)
    • 5y ago
• spicyramen 5y ago
  Really good write up. Definetly a guideline to get promoted too
• justbored123 5y ago
  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 fcking lap boy, you are an engineer, you solve the technical sht. 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 5y ago
    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.
    • ravenstine 5y ago
      Seems like a misunderstanding to me. Those tasks are on everyone's plate to varying extents, but I too have definitely witnessed the useless PM whose role seemed to be to force subordinates to effectively take on the executive portion of their role. Then everyone wonders why morale is so low.
      • astrange 5y ago
        I’m confused by this thread because a PM is not a manager. Their job is more like a cheerleader, where they don’t have any power and you don’t have to listen to them (unless your actual manager delegates to them). For some of them this does turn into just asking why you’re not done yet.
• reader_mode 5y ago
  Need for what ?
• timoth3y 5y ago
  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.
• wegwe33 5y ago
  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.
  • astrange 5y ago
    FAANGs/multinationals have offices in Europe. Even more rarely they have them in Asia/Oceania. Outside that, the happy developers I know are self employed as consultants or own app businesses. There’s also video game studios around the world in many places other software companies don’t exist. I think this is a very interesting trend but not sure if it pays well.
    • pavlov 5y ago
      Game development mostly pays quite poorly in comparison to other software eng, especially when considering the stress level of typical expected unpaid overtime. It’s a buyer’s market: companies have their pick because so many people are passionate about the field. (You could be a gaming millionaire by e.g. being a very early employee at a studio with a casual mobile gaming hit ten years ago, but those are definitely exceptions.)
• travisgriggs 5y ago
  _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 5y ago
    Nearly half the list: how to kiss ass
    • steve918 5y ago
      Or how to not be an asshole. YMMV.
    • khazhoux 5y ago
      I don't see a single item as ass-kissing. Do you want to call out a few that you think are particularly bad, and we can discuss?
• cperciva 5y ago
  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).
• drdeadringer 5y ago
  This reads like something from Robert A. Heinlein's Lazarus Long character. "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
  • H8crilA 5y ago
    I can assure you that the list is accurate (as in - that's all useful stuff) and not that hard to be at least decent at.
    • underdeserver 5y ago
      Plan invasions frequently, do you?
      • H8crilA 5y ago
        Look, in most corps you can shelter for a really long time at the lowest non up-or-out position. In fact to some degree that's the safest level to stay at, though the worst paid one. It's totally fine with everyone.
      • chaps 5y ago
        Become decent at an RTS and you can cross this one off the list pretty easily :)
        • ant6n 5y ago
          Or civilization (RTS? pshah).
  • Tomis02 5y ago
    Without specialization you sometimes end up reinventing the wheel, poorly. Like, a page of Python code instead of 5 lines of SQL.
• mybrid 5y ago
  Most senior engineers I know are key men. The have the corporation by the short curlies and, uhhh, dealing with the key men egos is something everyone has to put up with. Words like "senior" and "principle" engineer reflect more on company being hostage to coding expertise than reflect competence beyond coding. I'm trying to think of senior or principle engineer who gave two whits about "beyond coding". Coming up blank here. In large corporations pay is tied to title and often times titles are handed out simply to pay someone not to look elsewhere and it has nothing to do with anything else. YMMV
• deleted 5y ago
  [deleted]
• xwdv 5y ago
  My problem with this list is that a lot of these things are not really “skills” but rather seem to be a prelude to some new responsibility outside the job of engineering. Which is fine if you’re going to be compensated as such, but IMO the bump of 10-20% more salary for all this extra work and stress is not worth the hassle.
• deleted 5y ago
  [deleted]
• _carbyau_ 5y ago
  I'd add: How to speak up when your team working conditions is being abused by management. Honestly, doing this right-vs-wrong can be a career limiting move.
• deleted 5y ago
  [deleted]
• codeisawesome 5y ago
  This is an excellent list. I can think of so many experiences where I’d have fared better knowing/following this advice instead of my wrong instincts at the time.
• KingOfCoders 5y ago
  Understanding of the business. Software development is always a tradeoff, without a deeper understanding of the business it's hard to make the right tradeoffs.
• draw_down 5y ago
  Quite the list. But, you can get rich doing this so fair is fair. Keep your eye on the ball and make sure your employment is benefiting you, because you can be sure your employer is making it work for them. They like to expect a lot from you, make sure to return the favor.
• tastyminerals2 5y ago
  It’s weirdly saddening that these are the things ppl need to create a whole list for and keep being reminded of. Yet, it is very often is the case. The vast majority of engineers don’t even consider these to be of big importance. I wonder if this is something specific to our profession or people personalities that follow it.
  • faeyanpiraat 5y ago
    In my case growing up infront of the computer “helped” me avoiding all social situations. This made me a programmer, but oblivious to all sorts of things about how the world really works. I needed years of conscious effort to bring myself up to a basic level, which everyone around me seems to have mastered yeeears ago. But it’s well worth it, you just need self awareness, then realizing and admitting I’m not good at X, but will learn is the life long ultimate meta-skill.
  • ohdee2 5y ago
    In the past, for me, the word should was the blocker to improving on some of these. e.g. Senior manager X should know how this works. Programmer Y should be promoted. Technical debt Z should be paid down. I used to get stuck on this dismissive stance. It was the idealist in me saying we shouldn't have to waste energy on this stuff because it should be common sense. I was seriously lacking compassion for some situations. I think learning to synergise my empathetic side and my logical side has allowed me to step away from what 'should' be and what 'can' be.
• watwut 5y ago
  1.) We are industry in which you often become senior engineer after 2 years of experience, because basically you are confident a lot and can code. 2.) We are also industry that writes about senior engineers as if we were perfect zen masters, with no ego but great confidence and security, with infinite patience combined with effective asertivity, knew exactly what to say when socially and politically. And yet also willing to sacrifice self whenever self interest and project interest are in opposition. And also having perfect technical skills, both abstract thinking and attention to detail, and know all algorithms and also all optimizations and all technologies and generally being perfects perfections. 3.) Although the previous two points sounds to be contradictory, maybe it goes back to confidence and absurd expectations.
• dave1999x 5y ago
  > 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 > How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it Aren't these a bit condescending? Sure they're directed up, but it sounds "be nice when you're looking down on them". But worse, what if, as an engineer, you've just got a blindspot? What if the manager (or any person for that matter) has a brilliant idea that _you_ don't understand and therefore think it's stupid? My experiences with senior engineers is that they often need to learn to keep their biases in check.
  • mtberatwork 5y ago
    > Aren't these a bit condescending? Sure they're directed up, but it sounds "be nice when you're looking down on them". No, that's the point. It's how not to come across as condescending. > But worse, what if, as an engineer, you've just got a blindspot? What if the manager (or any person for that matter) has a brilliant idea that _you_ don't understand and therefore think it's stupid? I think that is covered here: "How to listen to other engineers’ ideas without feeling threatened". Just insert "manager" for "engineer". > My experiences with senior engineers is that they often need to learn to keep their biases in check. I'm sure there is context missing here but everyone has biases and this sounds a lot like someone feeling "threatened"...in which case, see the prior bullet point.
• flakiness 5y ago
  A recommended reading for folks who are interesting this kind of topic: https://staffeng.com/ https://staffeng.com/
• omk 5y ago
  I have been reading the "The Manager's Path" by the author of this post and for someone transitioning from a pure technical role to a semi-technical role I found it really insightful. For me, the human aspect of building tech solutions was always overshadowed by my passion for engineering. It seems that dealing with humans is indeed far more challenging and also far more rewarding. I recommend every engineer to dive into literature along these lines to get a fresh perspective. Seems like the most essential component for building successful tech teams.
• bryanrasmussen 5y ago
  some points on this list are somewhat disputable, for example >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 maybe not how, but when. I was on a project as a consultant that was basically ruined by management being technical but on very old or non-related technologies and they were indulged in spending hours of meetings some days to pontificate and worry about details that did not apply. Obviously this was not the only problem but I swear some times it would have been good to eye roll or otherwise shut down the questions rather than let them continue.
• AtNightWeCode 5y ago
  The running joke where I live is that junior developers work with coding, senior developers work with people.
• ClumsyPilot 5y ago
  A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyse a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. — Robert Heinlein, Time Enough for Love
• wiz21c 5y ago
  FTA : 4. 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 Skill learned : be able to not pay attention to a senior manager who wants to talk about technical stuff that they don’t really understand AND tells you that technical stuff is easy compared to management.
• arvinsim 5y ago
  > How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time Are there any templates for design docs?