45 ms·
Senior engineers are living in the future
- draw_down 4y ago
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- Invictus0 4y agoHN headline tomorrow: Senior engineers are literally gods
- smrtinsert 4y agoRelevant KRAZAM: https://www.youtube.com/watch?v=eSqexFg74F8&ab_channel=KRAZAM https://www.youtube.com/watch?v=eSqexFg74F8&ab_channel=KRAZA...
- Spooky23 4y agoSenior engineers are worms. Bow before the principal engineer.
- jasonlotito 4y agoExcept that's not at all what the article is suggesting. Quite the opposite.
- Invictus0 4y ago> it is literally effortless to accidentally cultivate the impression of being some kind of wizard
- atomicnumber3 4y agoMy impression of that bit was that the author was saying it may look like a senior engineer is a wizard, but actually it's just experience and it's not magic.
- olddustytrail 4y agoA quote which shows you were wrong and the person you were responding to was right. You do know what is meant by "impression" in that sentence?
- decebalus1 4y agoWait until you hear about Staff engineers.
- strikelaserclaw 4y agoa great article, we software engineers are impatient and we tend to job hop often. Being an effective engineer is about more than knowing how to build systems and code, it also requires deep domain knowledge into your company's business and existing systems and this knowledge takes years to cultivate at the same company. All the superstars at my current company have been here for a while.
- dominotw 4y ago> we software engineers are impatient and we tend to job hop often. This has been the only way to increase our pay beyond measly 2-5% growth if you stay at the same company. I would love to not jobhop and become a 'superstar' but making half the pay of your peers is really intolerable.
- gabereiser 4y agoEspecially in the last 5 years. 2-5% bumps for 10-20% inflation… gotta love math.
- gabereiser 4y agoWe job hop for a number of reasons. The primary one being compensation when their current job isn’t keeping up with inflation. Another is lack of promotion when you went above and beyond (as you were coached to by your manager, for that promotion). Another reason (which is why I do) is that life for some of us isn’t as stable. I move. I’m forced to sometimes because of rent. Sometimes that means having to find a new, cheaper, city to live in. Sometimes it’s to relocate for that new position. Next time you see someone who has worked at several companies over a decade, ask why and understand their reasoning. I would love to work at a company for 20+ years. I can’t stay put in the same position for that long.
- claytongulick 4y agoIf we're doing honest self-reflection as an industry, another reason I see programmers job-hop is because they don't want to sleep in the bed they made.
- onion2k 4y agoThis explains why I'm so tired.
- zackmorris 4y agoI was thinking the same thing, that as we gain experience, it can sometimes get harder to not see problems, which can lead to environmental depression. The flip side is that I used to suffer from agism-related depression, because I generally knew the answers but was powerless to sway anyone because they thought that I was too young to know what I was talking about. That didn't end until I hit middle age and realized that the problem wasn't so much about my performance, but my inability to communicate and set boundaries like older people do.
- revskill 4y agoSenior means two things: - Have experience - Self learning though above experience. I met many experienced developers, but most of them failed at step 2. To me, they're still junior.
- Existenceblinks 4y agoMy friends who won't step 2 mostly because they are limited by their circle's culture. There is this large enterprise corp network that can keep you stable forever, these guys never see outside world so global maxima is not a thing.
- roflyear 4y agoCan you give an example of a failure at step 2?
- sp332 4y agoOne of my classmates in college couldn't handle this. I'd glance at some awful Visual Studio compiler error and then point out a missing semicolon. He ended up feeling stupid, but I was trying to be encouraging because his code was pretty good aside from some missing punctuation, which will come with practice. He ended up switching majors.
- electrondood 4y agoPart of being a software engineer is constantly feeling stupid. Until you realize this is normal, you're going to feel bad and have imposter syndrome. If it were easy, everyone would do it and it wouldn't pay as much. It's supposed to be uncomfortable in the same way that exercising at the gym feels uncomfortable. Thinking is effort.
- wccrawford 4y agoI find that egos can be really fragile when people are just starting to learn things. Pointing out the mistakes so quickly can seem like a great help (and it is!) but some people react like they're staring at the sun. Instead, I find it better (except for how long it takes) to walk them through finding the problem as if it's really hard and just nudging them to the steps they'd need to take to find it themselves. They learn even more, and it doesn't immediately show the difference in skill between you and them. At the very beginning, even a small difference in skill can seem like a lot to the lower-skilled person.
- metadaemon 4y agoI think one of the quickest ways to make life easier and less stressful is to try to ignore the ego as much as possible.
- dieselgate 4y agoEasier said than done, no? I think one of the defining qualities of an ego is deceiving the individual into behavior - ymmv. But that’s why failure, psychedelic experiences, and more are important (imo) - for keeping the ego in check
- deleted 4y ago[deleted]
- giantg2 4y ago"The first—and most important—thing is to stop comparing yourself with others. Ensure that you are fulfilling the expectations of your manager and team for your development contributions." I have yet to see a manager or organization that doesn't compare on some level, even if it's just implicit biases.
- michaericalribo 4y agoNo doubt. But It’ll be a more favorable comparison to you if you are focused on achieving your manager’s expectations, and proactively contributing to the larger org — not comparing yourself to others as your personal performance metric. It’s obvious when someone is contributing to the organization in good faith / trying to do their job well, vs trying to edge out a colleague in specific eval criteria to look better. The second is not a good look, but I highly value (and reward) the first.
- giantg2 4y agoThat hasn't been my experience. I've even had managers pit devs against each other.
- michaericalribo 4y agoThose sound like bad managers :/
- kradeelav 4y agoNot an engineer, but I find this translates well over to design. Seniority in a lot of ways feels like the acknowledgement of being able to utilize people/soft skills in order to build things. I find at least 1/3 to 1/2 of my time, a roadblock in the project is caused by accidental miscommunication from top down, and the faster you can debug those, the happier everyone will be. Personally I rather enjoy that hybrid of people and "hard" design, but it's definitely not for everyone.
- michaericalribo 4y ago> utilize people/soft skills to build things I love this! It can feel frustrating to need to use these skills to exert influence: I sometimes feel disempowered by not having the full resources to throw around that I want. But that doesn’t really limit my ability to do the work. I’ve just had to cultivate a different skill set. Persuasion, not coercion
- drummer 4y agoSeniors are overrated. Principles is where it's at now.
- triyambakam 4y agoWhere I am often hung up in comparison is due to age. I dropped out of college and spent my early 20s learning agriculture and construction. Now I work in software engineering and my current manager is younger than me. Not only is he younger than me, but he's been able to climb up to an engineering manager in a shorter amount of time than I've been working as a SWE. So I feel really lame - wasted so much time early in my life and still seem to be wasting time.
- rambambram 4y agoDon't think like that. It might not have happened yet, but I'm sure in the future you'll be glad you can apply knowledge from agriculture and construction into your SWE role. And maybe not in your SWE role, but at least somewhere in your life.
- yourapostasy 4y agotriyambakam needs to take this advice to heart. Software engineering shares many troubleshooting patterns with agriculture and construction. While the cross-fertilization isn't 100% efficient, it doesn't need to be to be effective because the bar fortunately doesn't demand a global maxima only a local one: fix the current problem in a business-acceptable timeframe and cost, and you're adding value. Onto the next problem.
- michaericalribo 4y agoThe reason the author says it so many times is because it is so hard to do in practice :) You have an opportunity to distinguish yourself. You already stand out and break the mold as someone with a nonstandard background, and it will get noticed—and treated differently—if you excel.
- lupire 4y agoDon't compare yourself to others. Life is half chance. Find a good paying job and a good life. There is nothing special at the top of the ladder, just more money sometimes. Money isn't the only way to build a good life, and that's all money is good for.
- _ktx2 4y agoBeing a senior engineer is weird when looking retrospectively. I remember being a junior and experiencing what the author is talking about with respect to puzzlingly staring at my seniors when they could answer obscure questions. Now I do it and do the same things they did with me: facilitate my thought and troubleshooting process rather than give me answers. I think the people that are successful in Senior+ engineering are that way because of certain technical and character traits they've developed. One is a willingness to be right in the long run. When I was a young engineer I would make my cases hard with data. As a senior engineer I sit back and let the machine mull for a while because I know that's what the engineering machine will do regardless of how technically right I may be. Another is knowing that right isn't always right. Sometimes the right answer is technically wrong, or the learnings of wrong need to be made before we collectively can be right. Another is a lot of patience; patience for myself, patience for others. I recently admitted I was behind on work because my power was out for three straight days. Young me would've found a coffee shop and worked those days with a single monitor down to the bone. Senior me took my dog to the park. Not everyone makes it to senior, had I not forked my path in certain places I don't think I would have. My advice, relish your time as non-senior and ask lots of non-technical questions. The technical stuff comes over time and by necessity.
- ajcp 4y ago> Another is knowing that right isn't always right. Right isn't always correct. Being correct is being free of error. Being right is being free of blame. We should be correct in the technical, and right in the moral. If the problem involves both we should make it someone else's.
- GolDDranks 4y ago> Not everyone makes it to senior As a someone who isn't a junior, having two years of game development (in-house game engine dev) and five years of enterprise (mostly web-based internal tools & some data engineering with big data) development under my belt, but hardly a senior either, what do you think as the alternative to not "making it to senior"? Asking out of curiosity.
- 4y ago
- skrtskrt 4y agoOften as I've grown in engineering I've wished there was just a series of books that I could study backwards and forwards in order to just become a highly knowledgeable engineer. Instead it turns out that I'm just piling little pebbles of knowledge and experience on top of other ones, and I couldn't look back and design a book or a course or a curriculum to bring my old self to where I currently am. There are some pebbles just sitting on the side that haven't had an opportunity to be integrated into the pile yet, and some never will. It's all so... random
- manv1 4y agoSenior engineer = experience. For example, when building an HA system with embedded devices the devices shouldn't use the DNS cache and should ignore the TTL. They also shouldn't validate expiration dates on TLS certificates. Why not? Because stuff will fuck up if you don't do that. Also, you have to deal with the "regional power failure" situation, where every one of your devices will call home at the same time. Do devices need provisioning before they work? Because if they do, you need to handle that load fast. Do you believe a MAC address is unique and universal? It isn't as unique as you think, and not everything on the internet has a MAC address. Essentially, someone who's been around for a while realizes there's a difference between the spec (correctness) and what needs to happen to get shit to keep working (customers).
- lifeisstillgood 4y agoOh God. No. "Ensure that you are fulfilling the expectations of your manager" Please please do not assume your manager is any good at their job. Talk to your users. Find a way to identify them and get feedback from them. Keep your manager in the loop sure. But don't wait for requirements to come down from on high. "Every step up in job title is equivalent to living perhaps 1–2 days further into the future." No. If an organisation passes information down through the hierarchy then by the time it reaches you (it's more like 1-2 weeks if not months into the future) then it's already moved on. The US military tries hard to put decision making at the front line where it is most up to date. At the Battle of Jutland the British ships in the fleet had to radio its positions and sightings back to London, so London could update its "board" and radio to the Admiral in the fleet. This Admiral was this working on data that ships a mile or two away from him had had hours ago, but he was only just getting. This lead to an inconclusive battle. Anyway. Open information is way important.
- lovich 4y agoThe military also has a peculiar behavior of punishing leadership for failures instead of promoting them or giving them a golden parachute. Telling engineers to fulfill the expectations of their managers is more of survival advice. Granted this does not hold for 1) small startups where everyone has influence on the direction of the product and bureaucracy hasn't taken hold yet, and 2) FAANGS for the most part appear to operate under military like organization and allow for IC's to make decisions without 12 levels of approval.
- lifeisstillgood 4y agoThe US Army in WWII is known for moving and reassigning top ranking generals - failure was more a case of "you failed at amphibious landings in Pacific but now go do Air cover in Europe." But in general I feel if you want people to take risks for you, it's best that you pay them so much they stop having worries at home and just have worries at work. Executing people for failure looks like it gets results, but often it just gets results hidden
- 4y ago
- javier_e06 4y agoThe operative word is value: Many conventions and activities have value, some don't. I once met a senior developer who created in c++ the Class Byte for our codebase to tackle portability with it. I was a noob and I really thought that learning that had value. Years later I realized that there was really no value to the solution and it was more of a gold-plating activity. Yet, there was value on learning to recognize superfluous code. As a code developer their is that is that ironic and somewhat painful enlightenment along pacing along many dead end trails. What about those activities that truly not only do not have value but chip away the value of other valuable efforts. That is the time to dust off your resume.
- deleted 4y ago[deleted]
- w10-1 4y agoThe article's perspective is that the superiority of senior engineers lies mainly in the access they have to other people. I.e., they're not better, and it's not because of their experience; it's because of their position. I.e., the politics of resentment have reached even here. Do junior engineers prioritize avoiding embarrassment over learning? This is a really, really tough nut to crack. And let's not always hand-wave about safe cultures. When in senior roles, I try to model learning from failure and sharing everything, from short script tips and fantastic books to leads and gossip. Also sit together. But still: juniors have literally complained that it doesn't matter when I fail, because I'm already "made". Their sense that they have to prove themselves, and advance on some ladder, hangs over them always. Even, or especially, at leading companies, where everyone there is good. Part of it may be style: if after a while you drop all the "please" and "maybe", you risk people confusing assertiveness with authority (triggers). Feed them achievable projects where they can hide failures and show success. And give them their say. Doing this adds a new dimension of complexity to meetings and work factoring, but they eventually chill. If it's better to teach someone to fish, think of it as producing fishermen instead of fish.
- bluGill 4y ago> But still: juniors have literally complained that it doesn't matter when I fail, because I'm already "made". Their sense that they have to prove themselves, and advance on some ladder, hangs over them always. They are not wrong. I've been around long enough to earn some trust. I can (and have) made some major mistakes that would be reflected on a junior's raise, but I get by with it. I'm also working in places where those mistakes are more likely because we don't trust juniors in them. I like to think I make less mistakes than the juniors would, but I'm not sure... If you are a junior, just wait - your turn will come.
- mierz00 4y agoPerhaps this is just a reflection on the places I’ve worked. But I’ve never seen a junior get less of a raise because of a mistake they made.
- ChrisMarshallNY 4y ago> The first—and most important—thing is to stop comparing yourself with others. I'm "yes and no" on this. The reason is that I often look at the work/process/product of others, as inspiration. There's a lot of folks that are better than I am, and it is a good idea for me to keep an eye on what they do, and how they do it. What I don't do, is compete with others. I am not competitive, and I'm fine with that. Unfortunately, that seems to be a bit of an aberration. I am constantly having others take a competitive stance with me, and it can add a lot of friction; when they refuse to share information, make a point of being "snooty" with me, or assume that, when I talk about my work, I'm trying to cast their work in a negative light. That's not usually the case. I have very high standards, and I hold myself to them. If I will be incorporating the work of others, in mine, then I'll hold them to high standards. Otherwise, I've actually found a lot of gems in things like sloppy StackOverflow examples. Their lashup code may solve my problem, and I can take their solution, and refactor it into one that meets my own bar. I don't waste any time, thinking negatively about the other person. In fact, I'm usually fairly effusive, in my thanks. The person is often coming from an academic point of view, and are not concerned about the practicalities of shipping software. There's so damn much negativity, these days; often driven directly by competitiveness, that I feel I need to reduce my contribution to it.
- makz 4y agoI’ve heard that the literal translation for Sensei is “the one that was here before” or something like that.
- pojzon 4y agoBased on the job title only - Ive met seniors that would not be even called juniors in other companies. So yea.. it all depends where you stand. Ps. You dont have to compare yourself to others. Ppl will do it for you. During interviews or internal reviews. You wont run away from that.
- dbttdft 4y agoWeird how they used as an example debugging character encoding bugs instead of solving real problems as the typical thing software engineers do.
- lasermike026 4y agoGet your ego out of the game. Great teams work together, support each other, live and die with each other and share the victory. There are no straight paths. Just blood, sweat, tears and laughs. I've done too many startups. I should know.
- ZephyrBlu 4y ago> For those with the structural advantage of frontrunning the flow of information to the team, it is literally effortless to accidentally cultivate the impression of being some kind of wizard As someone more junior, I've already seen this and realized what was up and I absolutely hate it. In many cases there is literally no reason other than seniority that people can't do things. If you gave the same information access to a capable junior or mid level eng they would be able to solve these problems, write the document, etc but that doesn't happen because it's not explicitly part of your role.
- saagarjha 4y agoAs a junior engineer: ask for this kind of work! A good manager will be receptive to requests to work on things outside of the role you've been assigned, whether it's for career advancement/cross-functional knowledge/interest.
- ZephyrBlu 4y agoIt's not that easy. I can't ask for things I don't know about, and extremely often work is assigned far before I know anything about it. My manager also has to balance what work to give to which person. It's very unlikely he's going to give me the opportunity to do high level work like synthesizing information, writing a design doc, etc and even if he does I'm at a structural disadvantage compared to someone who has full access to information. I know from talking to the PM, more senior engineers on my team and sometimes my manager that this structural information advantage is real because they often talk about things I have never heard of, but they have been involved with for a long time.
- saagarjha 4y agoIt's not easy, but still something you can try to work on with your manager. It's possible that he's not doing this work himself, although he really probably should–in that case, you're going to have to pick up the slack. Part of management is being receptive to opportunities that allow your junior engineers to grow. Sure, it might take the senior two days while it takes you a month, but if he keeps assigning you simple tasks there's no room to let you actually advance to being a senior yourself. And that's just a bad way to run a team. The best way I have found to bridge the information gap is to actively bring it up during your 1:1s. Managers typically have an idea of what you "need to know" that is based on their idea of your current task. It's not always accurate and they may not always be able to see why from their vantage point. "I was working on project X and ended up being blindsided by changes from team Y, which blocked me for a week" is a really strong argument that you should perhaps be included in meetings with team Y. "I hear you and the team lead talking about our stack for Z a lot, I'm not really familiar with that. Can you tell me more about what's going on with it/can I get some time to work with it to get up to speed/where can I get information on it?" can help start a conversation on something you've just heard about. Keep abreast of "rumors" of where various teams are going and see if they have mailing lists or other places where they post general information for "stakeholders" (of which you are not, but often these are digests for people–often upper management–who are not fully familiar with the team, which would is useful for you too). Of course, this requires work from your side, probably on top of your existing duties. Ideally you have a manager who is sympathetic to such efforts for the reasons I outlined above. A two-way communications channel is key. It's always possible that he'll tell you to keep your head down and that this stuff is "above your paygrade" but there's really not much you can do about a manager who is bad at his job ¯\_(ツ)_/¯
- unconed 4y agoI've been told on one contract that my style was off-putting and making others on the team feel like nothing was ever good enough... at the _same time_ as a team on a second, parallel contract couldn't get enough of my time and thanked me profusely for helping them out of the hole they dug and teaching them to get better. It's all about attitude and egos. There are devs who call themselves senior who are theoretically proficient coders, but who lack the "street smarts" of how to develop a useful product, and how to architect it well. The person with 10y+ more experience is going to run circles around them. Not because they can crank out code faster, or with fewer bugs, but simply because they can do a lot more with a lot less, and they can contextualize what they code in terms of what the business is going to need 3-6-12 months down the line. As a junior you can either be resentful and try to compete from afar (job A), or you can realize you had access to a wealth of knowledge and experience that can give you a multi-year headstart on your peers (job B). Choose wisely.
- arwhatever 4y agoSenior Engineers can also give the impression of wizardry by writing shitty code that only they understand.