Senior engineers are living in the future | Hacker News Reader

Senior engineers are living in the future

zerobanana.com

324 pointspierreprinetti232 comments

Being 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.

> 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.

Staying mid level. Although the "senior" title of yesteryear is closer to the "staff" title of today, even at the top tech firms.

I'd say Amazon L6 is a good bar of what senior used to mean. Many newer (or older) companies lowered the bar to try and make people join them because dumb young people sometimes want the ego of a title rather than purely looking at the company's trajectory and compensation packages. In a way either intentionally or unintentionally there tends to be more tiers in the lower ranges of companies now, which can be a good thing for progress?

A lot of intermediates used to be stuck in this limbo zone, but some companies entry level "senior" now is basically what high-band intermediate used to mean. Worst case - paid the same, more ego. Best case - the pay band start to cross over to higher realms without going that far into the "hardcore senior" zone.

Being in the "optimal zone" I think. The best dollar-value-to-expectations is probably at the mid-level. Senior+ you take on a lot more responsibility, need to know a lot more, and you're not always compensated for all that knowledge. Having been at senior and above for a while now I can say that the juice isn't always worth the squeeze.

Nothing is wrong with optimizing for actual life things. It's hard to not be a company man when you reach the higher echelons. Generally, your real life suffers some. Especially since the invention of pagerduty.

strongly concur

This is extremely well put! As a youngster, I never understood why my father, who is an incredibly talented engineer and perhaps an even better organizer/leader, made no particular attempt to climb the management ladder (he, frankly, was tons more qualified to be an IT exec then any of the various folks he reported to through the years). However, the older I get and the more time I spend in my carrier, the more I realize that I love the "optimal zone"! I think where that zone is varies between persons, but, for most of us, there is absolutely a point where the expectations and responsibilities start to outweigh the benefits of the job (both the tangible and the intangible ones).

In my career, I quit my corporate job and I am now focusing on engaging myself with meaningful engineering work where I can collaborate with other passionate people to solve real problems. Just like my Dad, I could be making more money climbing the ladder, but I guess I learned from his example that there is a whole lot more to life then that....

Note that this can make employment in your 50's and 60's more difficult though, even if it shouldn't.

Also, I once worked for a military contractor and one of the lead engineers told me the company valued people who wanted to remain engineers instead of moving into management. It was the path he'd followed himself as one of the founders of the company. I believed him and avoided management, only to find eventually that there was no such path to becoming a senior engineer who did no management. So I quit, which caused me a lot of trouble, but it also denied the company the benefit of many years of my learning on the job (there are few ways to prepare for a career in top secret military contracting because you have to get a clearance first before you can start studying many of the things they work on, so a trained employee is much more valuable than in many other jobs.) The senior engineer had the right idea, but he'd never actually checked that his career path was viable for anyone who was not a founder. I think this is a mistake that many companies make, essentially forcing people into management. It is very similar to the idea behind the "Peter Principle", that people rise until they reach their level of incompetence and then remain there. Engineers rise until they are forced into management and have to stop doing what they do best.

Pretty much most big tech companies have levels Junior, Mid and Senior (and above). It gets confusing because many companies skip the mid level and call anyone with 1-2+ YoE Senior. However most often Senior eng at Big Tech is a bigger deal (think coordinating the delivery of complex systems involving more than 1 team). You could easily spend the rest of your career cranking up solid code as a mid level dev if you wished.

> 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.

One 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.

I 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.

I think one of the quickest ways to make life easier and less stressful is to try to ignore the ego as much as possible.

Easier 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

Sure, in the same way that "surviving to old age" is easier said than done. It's true, but what choice do you have?

Indeed. Parent post did mention “try… as much as possible” and that seems appropriate.

Show a person the bug, you’re on the hook forever. Teach them how to debug, you’re needed less and less.

Easier said than done, I've found. "Check the logs." is a statement I have to utter far too often.

Admittedly, when I started at the present company, I also remarked "this logging tool [Sumologic] is pretty difficult to use". The response from my senior engineer at the time was "it really isn't that hard." and then she didn't answer the question I had and made me figure it out on my own. It felt a bit brusque at the time, but it was very useful in the long run. I did end up figuring out how to query Sumo (I still maintain that its UI is gawd awful), and that's enabled so much debugging.

I think I also ended up authoring our internal documentation's page on how to effectively query in Sumo, which I feel has been read never.

Some people are lucky enough that the things they focused on early in life are things they were good at. Unfortunately, I think some subset of those people also develop an aversion to things that they don't appear to reach competence in as quickly as prior endeavors.

That's a shame, because often I think people that have competence in a subject come naturally to them end up at a disadvantage later, because their foundational knowledge is lacking (at least in cases where that's possible and learning was self driven).

One example of this is learning a programming language through doing compared to actual study and research. By "doing" I'm not referring to a project to cement details, but for example how most people know bash.

Another example would be spoken languages and some of my college professors. I'm not sure I ever heard anyone speak with as good of a vocabularity and diction as one of my CS professors that English wasn't his first language.

I find the opposite. If you know how it feels like to learn something you have a natural talent for, and you know what it feels like to be struggling, then you can choose to focus on the things that are most "efficient use of your time". Especially considering that life is short.

Of course, you can always choose to learn something you aren't best at, but at least you know the trade offs (i.e. needing to spend relatively more time to reach the same level of competence as more talented person).

I'm not convinced there is such a thing as natural talent. (there is such a thing as lack of talent) All the greats are just average people who focused until they became great.

You just have forgotten what it is like to be a child who knows nothing. I've been speaking English since I was a toddler, I'm learning Spanish now and I make tons of mistakes and often can't understand even a basic sentence - but in fact I'm a lot better at Spanish than I was at English when I had equivalent amounts of study into English.

Once you are a minimal level of competency it is a lot easier to study as well. So if you have only a tiny head start you will be top of your class, and that is always more enjoyable.

In my layman’s view it’s obviously a balance, like all things. Look at the top athletes - Michael Phelps has more upper body than he does lower. The best UFC fighters often have insane wingspan for their height (and therefore reach for punches). Usain Bolt is not a short man. Certain people are tuned for certain things. Then whether they combine that baseline with total obsession and hard work is up to them.

The mental sphere is where it becomes super vague for me. Did John Von Neumann just study really hard? The anecdotes told about Feigenbaum of Chaos Theory make him sound like a savant among savants. They just kept that childlike curiosity? Doesn’t make any sense to me. It seems they are tuned differently.

> I'm not convinced there is such a thing as natural talent. (there is such a thing as lack of talent)

....That doesn't track.

If there is such a thing as lack of talent, then "talent" is just "not lack of talent".

The concept of a thing called G factor shows there is such a thing as a natural innate talent.

Perhaps this is really stupid and juvenile, but the show Adventure Time had an episode where one of the characters said “sucking at something is the first step to being kind of god at something.” I think that’s an important lesson a lot of people should learn. Going out and sucking it up is awesome if it means you’re getting better at something.

On the other hand, toxic positivity sounds exactly the same. So which is one and which is the other? What to do when you suck at something? Persevere or pivot? Both are praised in TED talks, but you just can't pursue them at the same time.

Sucking at something is the first step to being kind of good at something. It's impossible to not suck at something new, unless you are a prodigy. Whether or not you want to persevere in the face of prolonged sucking is a personal decision.

> Persevere or pivot? Both are praised in TED talks

For good reason. Wisdom is recognizing which is correct for the current situation. There is no rule that applies to every situation. You have to make a choice and stick with it. Sometimes that means you try something decide it isn't for you. Sometimes you try something and even though you hate it, someone needs to do it so you keep at it - of those sometimes you will turn out to love it in the long run sometimes it was just a job. (it seems to me the only people who actually hate it are justifying a mid-life crisis that turned them to something new - if the mid-life crisis hadn't worked out they would have returned and been happy)

There is a old prayer that goes something like:

May God grant me the courage to change things that I can, the patience to endure the things that I can't, and the wisdom to know the difference.

Even very senior engineers can make simple mistakes that can bruise their egos. Several years ago I was called into the office of the chief architect. I was also a senior engineer with a lot of experience, but he was quite famous (at the time) in the industry for his technical skill. He was convinced he had found a compiler bug. He had some c code that he had traced through the debugger at the assembly level. It was something like this:

if(/some really long boolean value with AND and OR clauses/); { /* some code to execute if TRUE */ }

He was sure that the if statement was FALSE some of the time, but the code inside the brackets would always execute. He spent more than an hour pouring over the code.

It took me a few minutes before I noticed the semicolon at the end of the if statement. I'm sure he felt stupid when I pointed it out.

> I'm sure he felt stupid when I pointed it out.

He certainly did. There is no amount of experience that makes people not feel stupid about those. What changes is that you learn to not be affected by it, because you know that it's not a personal flaw (at least not one specific to you), and while you can improve on it, you can't completely fix it.

But the alternating between feeling like the dumbest person on Earth and the smartest person on Earth never goes away.

You develop tunnel vision and, whether someone points it out to you or you look at it with fresh eyes in the morning, it's a head slap "Duh."

Yep. I've learned over time to just walk away from problems like this that make me go "that's not possible!" or "there must be a compiler bug!"

After at least a few hours away (ideally not coding) your fresh eyes will often spot it.

Similarly, demoing the bug to someone else is a good way, and often through the mere act of demoing it you'll find it yourself (also known as "rubber ducking" [1]).

[1] https://en.wikipedia.org/wiki/Rubber_duck_debugging

Or just better software development practices that can eliminate whole classes of bugs. If the developer was instead in the habit of not putting huge expressions inside if() statements, he might have caught it himself. Consider:

    bool condition = /some really long boolean value with AND and OR clauses/;
    if(condition); { /* some code to execute if TRUE */ }

Two advantages of doing it this way:

1. It's much easier to notice that incorrect semicolon

2. Even if you don't, you can stick a breakpoint (or log) between when condition is set and when it is evaluated, to convince yourself it works.

3. All modern compilers will produce the exact same code as they produce with it mashed into the if()

I agree. It also really helps when you want to negate something.

if(!condition) is a much better read and less prone to errors than trying to negate a long statement inside the if().

This pattern also eliminates duplication. I have fixed bugs in code where the same long if condition was duplicated several times within the same function (probably with cut and paste). This wastes cycles recalculating it each time and runs the risk of changing one of them without changing them all.

    bool subCondition1 = /* something kinda long */;
    bool subCondition2 = /* something also kinda long */;
    bool subCondition3 = /* something absurdly long */;
    bool condition = (subCondition1 && subCondition2) || subCondition3;

    if (condition) {
      /* do something */
    }

where, ideally, the sub conditions all have meaningful, relevant names that succinctly express what they were testing for.

Good point, code readability is often the best thing to optimize for.

Your change also got me thinking of unit tests: at some point it becomes worthwhile to have dedicated tests on that condition, and that's often easiest by putting it in a static method, and that also improves readability.

In those situations i do feel stupid but also feel relieved. Fixing a semi-colon is easier than fixing some major logic flaw that could have way deeper and worse ramifications.

I think it happened enough that some newer compilers actually post a warning message when it is encountered. Just like switch statements when you don't have a break; statement for every case: clause. In some cases you want the logic to fall through, but it can cause havoc when you didn't want that and you just forgot the break.

I find slow-walking someone through a problem can sometimes come off as condescending.

I take a different approach where I immediately point out the issue, and if they get discouraged about how fast I solved the problem, I remind them that I’ve spent hours banging my head against the same issue. They will probably run into this same issue again, and get stuck again, but next time they’ll figure it out faster, and the time after that a little faster, until it’s basically instantaneous. And then when they’re instantly able to solve a problem for a newb, they’ll have to give the same explanation as I’m giving now.

The circle of life!

Kill the ego. The less allowance we make for hurt feelings the more we can live in a world devoid of toxic ego-driven politics. We should all carry the expectation that professional criticism be received professionally.

Hm, that's an interesting way to look at it, though I don't like framing it as ego fragility as that seems unfairly negative.

I've reflected on this point quite a bit because I really struggled with it when I was teaching myself how to code. It's extremely demoralizing in the beginning, because of a couple of root causes (IMO).

1. We place a lot of cultural value around "genius", and we often ascribe that quality to programmers, mathematicians, etc. While some of them undoubtedly are, it's not clear what that genius actually is, and a great deal of people mistakenly believe that they don't have the "right brain" for it, or are not "smart enough", because they don't feel like geniuses. When you make several mistakes when learning a new activity, every mistake reinforces that perception.

2. There are two relationships you can have with technology - that of a consumer , and that of the provider. As a consumer of technology, your perspective is that "technology works", and if it doesn't work, then something went terribly wrong. But once you become a provider of technology, that perspective is flipped. Technology is broken, and if it works, then something went wonderfully right. It takes time to develop that perspective, and so young engineers will have their programs break constantly, not realizing that "broken" is the default state of the world, and in fact now their job is to make things work. Of course it's broken.

Part 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.

I put semicolons at the beginning of line.

Found the chaotic neutral DnD player

I find it really weird that this isn't a universal experience.

I've been coding for 15 years and could not imagine myself in your classmate's place - but I feel exactly the same while learning to draw.

I try to draw a somewhat straight line or something at least resembling a circle, fail, and feel like it's completely impossible to me, be close to tears, and everyone who can do it might as well be a wizard.

I think it is a universal experience. That's why you're (presumably) a programmer and not an illustrator.

Most people naturally choose to focus on things they are relatively good at, instead of keep banging their heads on something they struggle at.

GP's comment seems to imply it was a negative experience for the newbie, but in all probability given the daily frustrations and chaos of software development in the real world, switching majors might actually be the "right" decision for that person.

> I think it is a universal experience. That's why you're (presumably) a programmer and not an illustrator.

> Most people naturally choose to focus on things they are relatively good at, instead of keep banging their heads on something they struggle at.

My parents told me I had to get a degree - they had very little appreciation for art, and some appreciation for engineering, but 0 understanding of computers. So I enrolled in CS so they would get off my back. Before college I had written maybe 50 lines of C.

I was never particularly good at CS - I just did OK enough under the pressure of having a clear goal (a degree) and there being no alternative to success (definitely not moving back in with my parents. I would have preferred joining the foreign legion).

Something I once heard that I think is kinda true:

When something goes wrong on the computer, there are two types of reactions: I am wrong, or the computer is wrong. The "I am wrong" person is discouraged and never gets very good at computes. The "computer is wrong" person persists until they bend the computer to their will.

Personally, I'd have picked it the other way. "I am wrong" tends to go "the computer did exactly what I told it to, so I must have told it to do the wrong thing", whereas "computer is wrong" tends to have less recourse about what to do next. I guess, in my mind, the framing is around the locus of control.

When I did a coding camp a while back it was the folks who could handle errors… and kept typing/ trying who did well.

Local football coach often says “failing is progress”:

https://youtu.be/0q3jiUrg7vY

Where 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.

The 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.

Don'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.

triyambakam 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.

Don'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.

Right. There’s always a bigger fish, so if you have imposter syndrome you’ll never be satisfied. Best to ignore those ideas.

I've kinda had the opposite experience. I started my SWE career in my early 30's. I feel like I've been treated as if I have more experience because of my age. And to some extent, rightly so. We have substantial work experience compared to a 21 year old. I did not start in a junior role.

Point being, don't blame your age. And don't underestimate yourself. And definitely don't compare yourself to others. If you are growing, then good fucking job. Keep doing that and maybe switch positions to somewhere more conducive to your growth if you feel like that's necessary.

Best time was 10 years ago, second best is now :)

In your next 1:1, ask him how he did it.

Ugh, one off data points are just as often wrong as they are right. What adage they give of their success could have just as aptly worked in reverse for you. Luck/timing (aka no strong correlation to actions) is a real thing, and are all too often ignored by the winners who always reward their achievements by "hard work" (clearly working hard is often needed as well to succeed).

If someone asked me "You seem pretty successful. How did you manage your career?" my story would be (other than some generalities) perhaps interesting but utterly unactionable for anyone else. And that's probably not unusual for anyone who hasn't followed a pretty conventional path.

Winners do this thing where they show the slightest interest in winning and a willingness to learn from more experienced people

> he's been able to climb up to a engineering manager in a shorter amount of time than I've been working as a SWE

If you want to be an IC, don't short change your accomplishments. Eng Mgr is not a promotion from IC, it's a career change.

The SWE career progression is much more established, and is often much more formal and understood than an Eng Mgmt track.

Your younger manager has recently gone through a significant career change that requires a significant amount of self-education to advance further. It's possible he'll advance opportunistically (if there's a vacancy) or by being clever or political, but his competency will not necessarily advance with him without him putting a significant amount of effort into learning this new career.

It's not uncommon for established SWEs to make more than engineering managers until the engineering manager has progressed to a level where they are dealing with levels of stress (business & social) that would make most people's hair fall out.

Even then many companies have career tracks that pay as well in the upper echelons for individual technical contributors as for high level eng mgrs. The one thing they have in common is that there are very few positions at the top of any career ladder. It gets competitive. Hopefully your aspirations match your talents so that you can compete for those fewer positions.

Thank you for the perspective, that's very helpful.

Hey, I'm right there with you. I think this industry is skewed young, but not as much as we might think. For me, the redeeming quality of my early 20's is that I matured dramatically. I'd encourage you to take a good, long (I mean months long) look at your motivations over the last decade and find a way to honor the part of you that was curious about agriculture & construction, and find a way to bring that part of you to life in the here and now. The word for releasing the tension between being and doing is "play".

Management is a different job.

I’ve been an engineering manager for over three years; and the skillset is completely different. So much so that I recently flubbed some easy LC questions.

Businesses may treat it as a promotion, but don’t make the mistake of thinking it really is one.

Do you want to be a manager? SWE -> engineering manager is not a natural and guaranteed progression. It is a shift from individual contributor path to a management path. A good company will allow you to become a more and more senior IC (senior -> staff -> principal -> distinguished) without a requirement to become a manager to increase your pay.

I feel you on that, but in these moments I remember a quote from Steve Jobs: "You can't connect the points forward, you can only connect them backwards".

Which for me means that you don't yet know what advantage these 'wasted' years could give you in the future. Just trust yourself to make the best decisions you can given the circumstances and you'll get to where you want in as little time as you can.

"The goal is not to be better than someone else; the goal is to be better than you were yesterday." (to paraphrase the Dalai Lama)

At one point I had a director of engineering who had something like 6 months of engineering experience; predictably … they weren't great at the engineering. I wouldn't put too much stock in it just because your manager is younger than you. Now, if they're climbing the ladder because they're actually amazing, by all means, try to learn from it, but I've seen people on runs of the ladder just inexplicably.

Engineering managers aren't necessarily better than you. It's not necessarily the next step up. I personally prefer to stay closer to code.

Often 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

Senior 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.

Can you give an example of a failure at step 2?

A 10 years Java/PHP developer doesn't know how to use Golang on the job in 3 days.

Well, golang is a tough language.

I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team. We are expected to deliver according to a plan while we keep hunting for relevant info.

I would say the second point is a lot more nuanced than stated.

Saw a company fail because all developers were expected to master k8/helm etc. A couple of us got the hang of it well enough to get by. But almost everyone failed too.

Even those of that had it working, it was a huge time sink.

In what way were the developers expected to "master" k8/helm? In the sense of actually making contributions to the k8/helm setup, or simply using an existing k8/helm setup to provide a development environment? Was there any "expert" person on the team that everyone could ask about k8, or was everyone simply supposed to pick things up on their own?

(asking because my own team is currently moving in this direction, and I'm curious about the pedagogical challenges we might face)

Anyone who is either insecure about their own skills, or so proud of their skills in their area that they can't face being a beginner in another area, will struggle and come up with reasons not to learn it. And they'll tell their nontechnical colleagues or managers that the idea is overengineered, or they'd add more value elsewhere, until it happens or they leave.

Ima be facetious here and suggest that the above is meant in the sense that K8 is the ultimate leaky abstraction and you have to "master" it first before even starting starting to achieve anything with it.

And Helm is just closing the cycle of Samsara - if you really want to base your operations on string templating, just use bash lol. Or hand-written forms on paper, still faster and you still get a better idea of what's going on.

There's also the problem of many developers nowadays just not having the hacker mindset/actual high-level abstract thinking/attention span, so instead of seeing the whole of K8S as the pointless kludge it is, they only see the interface - yay, YAML, I know that language! (usually they know it from everyone's favourite "dead" tool, docker-compose; which is a gem) - and they go on to fight with it tooth and nail, with corresponding feelings of "achievement" and "mastery".

I think the "10 years PHP/Java -> 3 days Go" thing from granduncle's cousin post is meant to point out this particular paradoxical situations.

But it could hurt people's feels to say it like that so let's just let Google do all our thinking for us instead. We truly live in a gilded age of computing.

That's why I'm a huge fan of server-less. Let Amazon or Google handle the tough parts until your company is big enough to have to optimize for server costs.

> Well, golang is a tough language.

This _could_ be true for some, but it directly conflicts with the stated goals of the language. Most people (that I've spoken to) would consider Go to be a simpler language, with fewer features, than other comparable languages.

The issue with Go is the implicit footguns you will inevitably hit. Starting out with Go sure feels like a super power because of the simplicity and productivity, until the code base has grown and you now meticulously inspect every single line to understand the entire context a change is bringing, because you do not trust it in isolation to be correct.

https://eng.uber.com/data-race-patterns-in-go/

You use Golang as a replacement for many Baah and Python programs, and never touch concurrency.

Concurrency is tricky, and that is true in every language, but less so in Go.

Python is also an easy to learn language, and you'll likely make correct programs quickly. Idiomatic Python, though, is a longer road. You won't feel confident to open source your code for months.

> I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team.

I can't speak for Helm, but working with Kubernetes in Go is almost uniquely difficult. Kubernetes modules are designed to be dynamic, and Go's type system doesn't make that easy, which leads to some cludge-y code out of necessity.

Plus the API is vast, and it's sometimes not clear what package you need for a particular use.

> Well, golang is a tough language.

golang is a language designed for fresh graduates to write fast code without much thinking. It isn't tough at all. For engineers that never worked with CSP paradigm, or rather for engineers who only ever work with Java style OOP and concurrency, it might be weird to adjust, and they will spend 3/4 of their time bitching about how much it is easier in language X.

Not everyone learns at the same pace, not everyone is great at bootstrapping.

Why is 3 days, likely with competing priorities, a reasonable timeframe to learn a new language well enough to contribute production code in your estimation?

The trick is that Go isn't a new language, it's an old language with a new coat of paint.

3 days to learn how to write syntactically-valid Go or 3 days to learn how to write idiomatic Go?

Idiomatic Go has some very large differences from idiomatic Java or PHP, including things like 1) the reliance on multiple return values and early exits for error handling 2) interfaces instead of inheritance 3) plain old data structures instead of everything-is-an-object 4) goroutines 5) table-driven testing 6) complete reliance on gofmt for formatting rather than doing it manually. And that's just the stuff that I'm aware of, as someone whose primary language is not Go but worked in it for about 3 months.

My definition of a senior dev would be someone who's aware that they can't just pick up a language in 3 days and write idiomatic good-quality code, but expects that they're going to have to keep learning for multiple years to really master a language. It's the metacognition of realizing how little you know and always continuing to learn.

"code quality" is not real, it's just something software engineers like to argue about like sports.

We like to talk about how code is written, because we look at code all day. The rest of the world only cares about what your code does once it's compiled.

Senior engineers solve problems. They're not overly concerned with ticking all the boxes just so they can get a "good code" sticker.

> "code quality" is not real, it's just something software engineers like to argue about like sports.

While I do agree that many developers sometimes like to argue about "code quality" too much (and I've probably been guilty of that at times), "code quality" is definitely a real thing. I have have interacted with code bases that were a joy to read/modify, and I've interacted with code bases that made you pull your hair out at every turn (and also many levels in-between the extremes). It is not always a case of just "arguing for the sake of arguing".

Probably I am being a bit hyperbolic. I could be more precise and say: code quality is a solution you should reach for if and only if you are running into real maintainability problems.

But I strongly disagree with the sentiment that someone should not write code in a certain language, or should not contribute to a project until they know how to write idiomatically according to all the "accepted" best practices. It's a pedantic and elitist attitude which has little to do with making good software, and runs counter to the practice of learning how to use a language, which is necessarily a process involving ignorance, trial and error.

By the time you have real maintainability problems, it's too late to improve code quality.

It's never too late. I've had to pick up development on orphan projects before, and some of them are real stinkers. You can always quarantine the bad bits and start to impose a proper separation of concerns.

I think somewhere in the middle is a good place to start. This can be managed by limiting the scope of code a "language newbie" writes (until they get reasonably up-to-speed) -- if/when that is possible. It also helps if you have someone experienced in the language who can help point them in the right direction when they need help. That can be a challenging thing to do well. Deciding where to provide direction, and where to just let them figure stuff out on their own can be difficult. You can come off as being too picky, or just being a jerk when you were just sincerely trying to help. I think to do it well you have to be vigilant about keeping your own ego in check. It has been my experience that most people who are fairly good at something (present company included) can slip into the state of "thinking more highly of themselves than they should". That's always counter-productive, and in my experience good "mentors" (or whatever you want to call them) are the one's who excel at avoiding it.

Code quality is very real, but the bounds you have to exceed before lack of quality start to bog down development are pretty large.

As a senior I can pretty quickly tell in the languages I write in often, when something is a smell, and if you keep repeating some code smells for a like a year you'll start seeing compounding effects on development speed. Understanding when to allow those with good reason and when to coach someone to stop doing those is an important skill for a senior imo.

But it's definitely not immediate, way more of a pernicious concern, the codebase will effectively rot until it's painful to make changes.

Eh, I've seen a number of startups sunk (as in went-out-of-business sunk) because of code quality issues. Eventually you hit a wall where every bug you fix introduces more bugs, and the product does not converge to a state where you can launch it. Then the VCs start getting impatient and you run out of money.

The point where this happens depends a lot on problem domain. If you're doing well-understood CRUD-screen database stuff but applying it to a novel business domain, you're probably not going to hit code quality issues. If you're doing heavy algorithmic, OS, financial, or networking stuff, though, where failures compound and any one bug might take the whole system down, you really want to pay up for experienced developers that have seen all the ways these systems can fail.

Oh sure, I didn't mean to suggest code quality can't kill a business. I however think like you said it's very domain dependent on how quickly that happens. I think taking on no debt wrt to code quality is impossible though and knowing how to take on that debt and pay it down to effectively meet the broader business goals without doing irreparable harm is something everyone has to contend with while being a dev.

That said, I can really only speak to web api dev, data engineering and search. I'd say out of all of those search was the tightest area with regards to quality and even then I was lucky to be working with another very talented dev. Him and I didn't run into very many issues we were unable to solve with scaling the technology even after hitting 100m pages or so and we could have kept going on scale but we were cost constrained, navigating the business side was far more challenging for us.

I'll admit as well I've been pretty lucky so far to work in situations where code quality is considered and managed and haven't yet worked somewhere where the concerns were entirely ignored or the team didn't care.

>The rest of the world only cares about what your code does once it's compiled.

People in your company (including non-engineers) definitely care, because code quality bears on how easy it is to debug problems and how easy it is to implement new features or fixes (or sometimes if a feature is even practicable).

Really all it is is "3 days to showcase you have a working compiler, ide, formatter, can run the tests, and are familiar with the CR tools".

The rest of it is learned (hopefully quickly) through the CRs, and any senior engineer should be comfortable making a few idiomatic mistakes in their CRs that they learn from.

None of that is "3days" . That's all the negative days before you start using the language.

I could do all those setup things in N days without ever learning any programming language.

I think you’ve misread / misunderstood the original post.

“3 days into the job”

That sounds like a description of the team onboarding process, not the engineer doing the onboarding.

Any engineer should be able to do this because the team has written good wikis and has working build tools, tests, etc

A person proficient in multiple programming languages absolutely knows all of the 6 concepts - it's just cases of 'aha, go allows me to do x,y,z and this is how things should be done'.

I basically learned ideomatic go in a week, by skimming over the "effective go" guide and cross referencing concepts to other languages I know -- there is really nothing inherently 'new' in Go that would require years. It's a deliberately simple language.

Just a JIRA task for next sprint with 2 points assigned !

I've had to jump into projects with unfamiliar setups and even unfamiliar languages more than a few times, and after a certain point it's all just problem solving. Like I had to fix critical bugs in an orphan rails project with next to no experience with Ruby and it worked somehow.

Are you going to write elegant, idiomatic code in the first week? Of course not. But give the task "make the system do X", 90% of coding is knowing how computers work, and the other 10% is knowing how to search on stack overflow to be able to translate what you want to do into the desired syntax.

Had a guy with 20 years experience at a top mail carrier come in for a senior position. We were very excited to interview him.

He had spent the 20 years copying the same html file and changing the text for whatever was needed.

Struggled heavily with the concept of a loop.

"He had spent the 20 years copying the same html file and changing the text for whatever was needed."

Dream job right there.

> copying the same html file and changing the text for whatever was neede

Can also describe a complex single-page web application :-)

I would never fault someone for not being able to pick up a language and use it competently in 3 days. I understand why you use this as an example, with having samey syntax, but there is still nuance. I think the bigger indicator is you've been in the industry for 10 years and call yourself a PHP/Java dev. At this point you should have dabbled in probably 10-100 ways of solving problems depending on what your 9-5 looks like.

Who said you need competence, looks like that was your own insertion, haha. But seriously is it not unreasonable to be able to write some non-deep dive code in a new but similar language in just a few days? 3 days is a long time to read and ask questions.

What purpose does it serve though? I think being able to read and understand a Go program is a better example. That does seem like a reasonable and useful ask in 3 days for a veteran PHP/Java dev, and something that is more likely to come up in practice. What is the context of the former? "Welcome to our team. I know we didn't hire you as a Go dev. You have 3 days to "be able to write Go".

I have long subscribed to "A programmer is not language specific", and I don't hire based on the languages you know. But that first task is "Here is access to the repo. Read and understand what our code does today please. I'll answer questions within reason." Acquiring the new language happens as a side effect.

If you hire someone in a language they don’t know, you expect them to learn on the job. It’s reasonable by day 3 to expect them to show some code - even if terrible.

At some companies you’re still in onboarding hell on day 3.

I would say, most? Or maybe I have been really unlucky, lol! I don't think it is POSSIBLE for an employee at my current company to be productive before week 2.

Same. I've never seen anyone become proficient in a new language/platform in less than a year. Sure, you could learn Go's syntax, use it in the style of Java/PHP, and make it work, but that is not being proficient in Go and its idioms.

A year? That's a very long time for anyone who isn't a novice to learn a new language.

I would bet hard money that even an experienced developer wouldn't learn C in a year (e.g. avoid or recognize most UB and security issues) without prior exposure. I'll grant that C is pathological in that respect though.

Maybe we have different bars for what it means to learn something, but if I worked with an experienced dev who took a year to learn C (and there was an actual need for them to learn it) I'd question their claimed experience. It shouldn't take more than a few weeks to be capable of using C if you have a decent background with other procedural languages and already know the difference between heap and stack storage (so you don't make the mistake of a past colleague of trying to return data on the stack, he didn't claim to be experienced though).

Learning a language and mastery are separate things. An actual experienced dev should be able to hit "competent" in any new language within weeks so long as it's within the same family of languages they've used in the past. Procedural languages, like C, are pretty much squarely in the middle of what everyone has learned unless by some fluke they started and continued with Haskell and similar languages and never touched any of: Go, Rust, C#, Java, Javascript, Lua, Python, Perl, Ada, Pascal, Fortran, Matlab, BASIC (various forms), and a hundred other languages.

There's a lot of baggage that comes with each language. I could probably learn any language at that point, but it also takes time to learn whole ecosystem, mostly used libraries and tools. You typically can't do this in week or two, because you need to actually write something and see how it feels, if there are any surprises.

You would probably not want someone with little experience in given language, to touch production codebase without review, because there are always traps that you might've not encountered in other languages.

I typically don't touch low-level programming languages, but once I had to use C to write some small adapter to communicate with some Oracle product. I did it, it worked as expected, but I would not be able to use it efficiently for complex solutions without more experience with creating and managing solutions in C.

I can also write in Go with some basic proficiency, I felt confident at one point in my abilities, but when my code got reviewed by someone specialized in Go, he would propose several improvements that did not cross my mind, because I had less experience in Go.

> You would probably not want someone with little experience in given language, to touch production codebase without review, because there are always traps that you might've not encountered in other languages.

I never said otherwise. This is part of the distinction between competence and mastery. I would not expect most people to master a new language in just weeks, but a senior developer should be able to be competent within weeks. Now, would they have a product or substantive (non-trivial) change to show after those weeks? Maybe not, that might take a few more weeks, or longer if it's larger in scope.

> I can also write in Go with some basic proficiency, I felt confident at one point in my abilities, but when my code got reviewed by someone specialized in Go, he would propose several improvements that did not cross my mind, because I had less experience in Go.

That's part of learning, but it probably didn't take you a year to learn enough Go to get something in a reviewable (if not passing review) state.

> You would probably not want someone with little experience in given language, to touch production codebase without review

I wouldn't want anyone, in any language, with any level experience to touch production codebase without review.

Not even K&R themselves.

So that's a ridiculous straw man.

Yet it happens in many companies, when team is working on non-critical systems or in extreme cases, even on critical systems. I sometimes feel like some people in IT are detached from reality, not everything is mission critical system and not everything has high quality, because there's a lot of people in IT with all kind of background and there all kind of clients with different sets of requirements. It's business, not utopia.

I don't want your attitude at my business.

Everyone makes mistakes. And code review is also about knowledge sharing and avoiding single points of failure in staffing.

> Not even K&R themselves.

This feels like a town cop enforcing strict speed limits in the couple of miles that fall in their jurisdiction. If K&R show up at your door and want to touch your production code, you just let them, bring them coffees, and ask for autographs. Even if it breaks, it would be an amazing story.

They might be able to get the compiler to accept their code, but that's not a good bar for competence in C. I personally wouldn't consider someone competent in it unless they're deeply familiar with UB and other language warts because it's too dangerous to do otherwise. UB can have nonlocal effects and "time travel" so any UB anywhere in the program legally invalidates the entire program, regardless of whether it would otherwise work. Most other languages have (wisely) decided not to carry that legacy forward.

As we all know, the subject of UB and the practical ramifications of particular instances is a topic few people could reasonably learn in weeks or even months.

A year is enough time so your new language stops teaching you new things every week. I agree that superficial knowledge can be attained quickly, but learning the idioms, tooling, libraries, gotchas, performance bottlenecks, warts, etc. takes months.

Maybe six months if you're very good, but I'd wait a year before assigning a big project to someone new in a language/framework. Still wouldn't consider them a master with just one year of experience, mastery of a modern language can take years, you can always go deeper.

Being proficient and using it are two different things. A year to learn? What are you talking about, in a year you can get someone who never used a computer beyond a browser to learn just about any commonly used programming language. Yes, they won't be level 99999 one-man-army ninja fullstack senior engineer, but they would be able to write code.

If you had 10 years of java, you can absolutely learn how to write Go in 3 days, unless your 10 years of java is "writing CRUD in Java 6 with libraries available in 2006".

I dunno. I haven't had much need to do a major project in another language other than Python for the last 10 years. Is that an issue?

I recognize the value of expertise in a language. I recognize that I have touched so many different languages that any "expertise" that I might have possessed at some point has probably passed as I've missed out on new features, etc. I guess I would just expect you to be really knowledgeable and efficient in python!

So I don't think it's an issue, if that's been your job. My job exposes me to a lot of different technologies: many programming languages and endless different software that might be supporting a web application (databases, webservers, firewalls, etc.). I consider my value to be looking at problem and being able to spot 10 different possible points of failure in a system in my mind and order them by priority based on likelihood and ease of troubleshooting. And this is something that I think is only gained through experience and that's what separates me from someone who just started.

Yeah. I wouldn't even say that I'm amazing at Python, not really! Much of my time these days isn't spent writing code. But, I can still get things done quickly. I wouldn't say I'm a superstar, though.

I learned it in 2 hours so you are pathetically junior compared to me.

The real 10x engineer right here!

I suspect he learned it in the future.

I can figure out its internal AST once I stare at the lang's codes. \s

In other words you're inventing some silly criteria that I'd guess you'd pass that others wouldn't. What I would say to that is that if you dismiss someone else's experience because they can't do some task you think they should be able to do rather than understanding that their experience probably brings something else to the team then that's your failing, not theirs.

For a little annecdata - I've been a dev for 25 years, with a senior level (and above) title for about 80% of that, and I reckon I'd take at least a couple of months to get to a point where I was happy with golang. I guess that makes me a junior in your opinion. However, instead of being able to get up to speed with a language quickly I bring a fantastic level of respect for users, a talent for technical writing, a belief that documentation is actually important, a sense of fun and joy in making high quality software, and a deep understanding of browser-based software. If I was looking for a new team member I'd seek out someone a bit like myself rather than someone who can learn a new language faster.

> a talent for technical writing, a belief that documentation is actually important

This is, IMO, a hallmark of "senior" engineers and above. Much more important than language adoption/choice.

Also importantly, it sounds like you would bring the understanding that surface level productivity is not the same thing as mastery.

Eh—I don't know. Code a test or two and something basic with just the lang? Sure.

The whole stack? Takes about a month to get productive and about three months to really internalize. Think interned strings in Python vs symbol exhaustion in Ruby. Or serializers in Django Rest Framework working as both input validators and output generators compared to stock Rails views.

Super similar languages with lots of similar frameworks and libraries, but they have these edge cases that still crop up.

A better example might be not learning from past mistakes, or asking the same question multiple times, even if framed in a different context.

For a bugfix or a whole new module ?

"Use" is pretty vague. Can run the process and make a small fix should be easy. Writing idiomatic code in a new language takes months.

I'd give them 1 week. And measure again at starting of week 3, if they are still struggle, that's very likely they suck at learning.

- Are you still struggle?!

- Y-yes...

- You are fire!

Note: Sorry for the cheap joke, I also make frequent grammatical errors in English.

Usually, they will appoint a cold room for 1-1 meeting to hear what's going on. And find out whether it's hiring process or teaching process that's the problem.

if they are still struggling on the same thing

You've spawned a silly thread, because mastering a language is a spectrum that takes years.

In 3 days someone should be able to fix a small business logic bug in a program in a new language, like copy-pasting a if-block to handle a new simple case, or improving an error message by grabbing a variable from context and for setting it for output, but not write a useful program.

My 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.

I think you can be senior without experience. To me, senior means "can handle ambiguous/incorrect/incomplete problem definitions."

This skill comes from experience. If you're talking about experience in a particular subdomain, then yes for sure.

The trick is, what people refer to "experience" in the workplace is very strictly defined as workplace experience in your role. But you can get experience from a wide variety of tasks, even ones that don't involve your current career. Working with vendors to organize a convention can prepare you for writing software. Or a volunteer/school software project could prepare you for a paid role, but nevertheless it is not counted.

No, you have you know the traps and specifically you have to know your own biases and this only comes with failure, thus experience.

Show me a mid-level engineer and I will show you someone busy walking straight into a trap.

When commercial hiring managers say "experience" though, they don't count school projects, volunteer (OSS) projects, or career-adjacent projects. That is the source of dissonance. You are right, it's just that you* vs. the managers have different definitions of the word.

* also me sometimes, but that's confusing since I just used the commercial definition of the word a few comments above.

I learned how to program starting on calculators in middle school and eventually moving up to games.

Looking back, I accidentally turned my first full time into a senior position almost immediately

A local company gave this self-taught developer a chance as a glorified intern, but a few weeks in and I reimplemented a project they had given to a contractor in a weekend after overhearing their back and forth.

We ended up shipping my MDM on hardware across the country that Christmas, less than 3 weeks after that weekend project, and I spent the next 2 years extending it as a platform: completely driving the functionality that sales would then go and sell new clients on, designing and implementing an autoscaling analytics backend and frontend, embedded V8 so that client's engineers could script the product without mucking in my codebase about with source access ;)

I remember I got a 25k pay raise at one point by simply saying "I was thinking I'd make more once we got past the evaluation period"

I had actually been trying to ask for us to set up a performance review, but in retrospect they were probably terrified of losing this guy they were paying half a senior dev's salary to do 2x the work, and were ok paying 2 thirds of a senior dev's salary instead...

In some ways I feel like the work I did there was more senior than the work I do now, at least in a technical sense. I think it's the soft skills that come from experience

The difference between 10 years of experience and 1 year of experience 10 times

I would reformulate #2 as learning to figure out things on your own, i.e. not to bail out as soon as something is outside of what you’re familiar with. The ability to go one level deeper to find out how things work under the hood. The ability and interest to extend your horizon, to pick out the learning material you need for familiarizing yourself with something new, without needing it to be served on a plate by someone else.

That is only half of #2. The other half is knowing when to bail early.

More than once I've proven my value as a senior engineer by refusing to do work that should be left to someone else. Sure I could figure it, but it would be a waste of time when someone else can. Sometimes because it is obviously an easy task, and thus good for a junior engineer to learn to figure things out on. Sometimes because it is something I'll never need again and I know we can hire a contractor who already knows how to do it.

I would put “knowing when to bail early” on the “experience” side, so #1.

The 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.

> 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.

Perhaps 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.

Oh 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.

The 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.

The 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

As opposed to execs getting rewarded no matter what so they can be open about their failures that they won’t resolve.

There is a point to not executing people for failures so that information isn’t hidden but when “not getting paid massive amounts of compensation” is equivalent to execution I think you’re going to have the same bad behaviors.

Uh... Fulfilling expectations has nothing to do with making decisions on your own.

I can guarantee you that no matter how good or bad their manager, if you don't meet their expectations, you are in trouble. By all means, own your local decisions, be proactive, keep your manager in the loop - AND MAKE SURE THEIR EXPECTATIONS AND YOUR WORK MATCH. That doesn't mean waiting for requirements, but that means your manager knows what you do and agrees, at least in broad strokes.

Surprising your manager unpleasantly never leads to good outcomes for you. There's only one person holding power in that relationship. (Positive surprises do work, but they usually take the form of "I did what you expected, AND".)

Totally agreed that the 1-2 days in the future thing is wrong. As a senior you should be at least a couple of weeks in the future, better if it's months. At the staff level, 6-12 months. At the principal level, 2-5 years.

If it's just a few days between each level, a) somebody is failing at their job, and b) yes, information will be outdated by the time it reaches you.

> Surprising your manager unpleasantly never leads to good outcomes for you...

Not quite 'my' manager directly, but a client's PM. They had a ... PM/PO type person who was quite insistent that we had to have feature X by date Y. Slightly aggressive, but... sure. Between that insistence (over weeks) and the date Y... that person left and a new person started.

4 days before a walk through (where new items were demonstrated to stakeholders, and company owners), I sent the completed functionality over to the new PM (he'd been there a few weeks, but obviously still... new). "looks good" he replied. I checked that he'd at least watched the video I'd sent over.

Demo happens and I show the functionality, with the "this is vital to have" from the previous PM. Silence. Then "we didn't know that was being worked on". Behind the scenes I was somewhat thrown under the bus, even though I had jira tickets, paper trail, video evidence and assorted other info. "Lowercased is ... subverting the process" and I made a whole team look bad. Even though... they all had signed off on what I was delivering. But behind the scenes, new PM had told people "feature X won't happen" (i have no idea why that was said) but apparently I made a lot of people look bad, because I'd delivered something they said wasn't going to happen.

So so so weird...

Well, yes. Shitty management still exists. And the power imbalance is always there. I'm not saying not surprising your manager guarantees good outcomes, I'm just saying surprising them guarantees bad outcomes.

The lesson I've drawn for myself from similar incidents is "know all the stakeholders, and talk to them". Consulting/client work makes it extra hard, because stakeholders just keep coming out of the woodwork :(

The power imbalance fascinates me - why should it exist at all?

Do as I say or else? Why not, credible mission, great story telling, compelling vision, a well argued rationale.

I mean. If we paid everyone UBI, then every compmay would look a lot like the Linux Kernel (insert preferred less shouty FOSS project here)

Because communication is inefficient.

If you have to produce a well-reasoned argument, and successfully convince all peers that your argument is in fact well-reasoned, and comprehensive, and handles all concerns of all involved or potentially involved, and that all opposing arguments do not meet these criteria… it will take ages to get all stakeholders in agreement, and even when you do, you get a horse designed by committee (a camel).

Projects with no owner consistently end up in the same rut — always planning but never doing. Bikeshedding.

So you need the owner. But for someone to own the project/task, he needs to be in charge of it — he needs power. For what is power if not the ability to make a decision and have others follow through on it?

In arenas without defined power relationships, but manage to produce useful work, it’s usually the case that the power relationships still exist; they’ve just been made implicit. You see this in geopolitics, in your high school group projects, in Valve, etc. Determined not by corporate hierarchy, but instead charisma, money, social networks, physical/military strength, etc. Most of which is reflected by the corporate hierarchy anyways.

Businesses just make it explicit, and consider it valuable enough to attach higher pay. You might make the argument that managers don’t deserve higher pay than an individual contributor, but it’s clear enough that a manager has much higher potential impact than an IC — if you manage 100 resources, making them 10% more efficient than otherwise, you’re doing the effective work of 10 ICs. But in my head, a resource-managers role is primarily to make his team more efficient — by optimizing processes, clearing blockers, umbrella’ing against shit from on high, reporting upwards, to guide the overall direction of all involved — not to dictate the every individual activities of his underlings.

Also the Linux Kernel clearly has a power hierarchy, and while that power hierarchy doesn’t dictate what you work on, it does dictate whether your work can hold any value (by getting included into mainline). The difference just ends up being in the fact that it really doesn’t cost anyone anything for you to continuously do work that’s ultimately rejected every time, whereas for a business it obviously does (in the format of your salary). Obviously you can fork if you want and make it perhaps valuable… but you can exit the hierarchy just as well in business by quitting.

> You might make the argument that managers don’t deserve higher pay than an individual contributor, but it’s clear enough that a manager has much higher potential impact than an IC — if you manage 100 resources, making them 10% more efficient than otherwise, you’re doing the effective work of 10 ICs

Maybe. Supply and demand is always at play. If any manager can make 100 developers more 10% more efficient, but only a few people who have any ability to be a developer at all, then the developers are worth more. Numbers are relative to supply - my company has discovered we have to get ICs better raises than their manager at the lower levels as our great developers were becoming managers. We can get managers from lots of different entry level areas, but not enough engineers.

I mean... if you get your managers "from lots of different entry level areas", then you get exactly what you paid for.

Any tech manager even remotely worth their salt should be able to function as a senior+ IC if necessary. If that skillset is lacking.. maybe you want to rethink your hiring. You'll likely never see the effect of a good manager if you don't.

As for your argument that developer scarcity somehow makes managing worth less - the opposite. If you can hire a single person that can effectively give you 10+ devs without having to hire those 10+ devs, you want to hire that person.

And for the "ICs need better raises, or they turn managers" - uh, no. But you do need to offer parallel development tracks, with comparable advancement opportunities. (In reality, IC & mgr raises should be roughly similar in terms of percentages. If you value managers, at least)

Management is not related at all to tech ability and there is no reason for a manager to have tech knowledge. Tech knowledge avoids some of the worst things i've had managers do, but my best managers have been completely non technical.

> If any manager can make 100 developers more 10% more efficient, but only a few people who have any ability to be a developer at all, then the developers are worth more.

Then you'd expect fewer developers, and fewer managers overall. Unless you hit some really low threshold (e.g. 5 developers, so the same manager is only worth 50% an IC) where the cost of manager doesn't "pay back" in developer-headcount-reduction, it'd still follow the same strategy.

And of course, the amount of "pay-back" you get from a manager would naturally be how one derives their value, and thus their paycheck.

But IC --> Manager as the only promotion track is completely unnecessary, and generally a mistake. That's just intentionally driving into the peter principle (promoted to the level of their incompetence), because you've simply left no other way to go. Usually you have the alternate track for IC's expanding into larger/more abstract/more important domains, but not head-count; technical/solution architects and what-not.

But the story hasn't changed -- if you assume the role of the manager is to make their resources more efficient, then a manager's value scales with the number of resources under him; an IC does not. It will always eventually make sense for a manager to be more valuable than an IC, and this only holds false at low headcounts.

I'm not sure how much more I could have communicated. "Feature X is done and i'm going to show it on thursday". "OK looks good".

Behind the scenes, without telling me, telling other stakeholders "feature X is not being done".

Demo feature X.

"Whoah, you really blindsided us and made people look like they don't know what they're doing".

Had this been, say, 5 weeks ahead of time, yeah, maybe. This was ... 3 days? Monday afternoon to Thursday afternoon - maybe you could count that as 4.

This had grown to the point where I wasn't allowed to directly talk to the major stakeholders. This demo meeting was the time to talk to them, for a dog and pony show only. 18 months earlier we had more regular (still in a group) communication, but it was possible to talk directly. As this grew, my own ability to talk directly to people was layered with middlemen, which exacerbated this sort of problem (had happened before, but never for something this 'important').

What's... funny about all this is that the earlier PM had made this feature of paramount important, but it turns out ... no one is using it.

EDIT: both at the time, and now, I looked at it as "mistake". we're human and things happen. but it was framed as "lowercased was hiding information, working in secret". this was not the case.

> The US military tries hard to put decision making at the front line where it is most up to date.

Business leaders love to imitate the military, but isnt it ironic they are emulating the institution that has the most government involvement and central planning?

On the surface level it should make sense bc in war stakes are high so you’d think “survival of the fittest” would apply. In reality I’d say it’s far from being the case but it makes suits feel more important so here we go again

In terms of how it’s supposed to be structured the military is heavily centralized but that model has broken down considerably as the US has had to face far more dynamic adversaries than before. It’s a popular perception but most groups in the military branches operate a lot closer to Silicon Valley in many respects than people give them credit for.

> 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.

As a senior engineer that is what my manager expects me to do. In fact I'm often expected to define the requirements before working on them. Often when I get the requirements refined enough I hand them off to other engineers.

Of course there is personality involved here. I pass things off before I don't enjoy the boring grunt work of putting the final polish on, but I work with people who prefer to put the polish on an already solved problem. This is a win-win as both of us avoid things we don't like. (note, putting polish on is at least 90% of the work, so I can't completely get out of that, and junior engineers never can). There are other problems that other senior engineers work on that I never touch - they are the experts not me

>"Ensure that you are fulfilling the expectations of your manager"

"Just tell me what to do" is like the anti-senior developer philosophy, particularly if you report to someone who is non-tech.

If you're senior you should be the one setting the expectations and lay out a (working) plan to fulfill them.

Edit on the above: I am coming across way more negative than I planned. I just want to counter-balance the underlying assumptions that a workplace is somehow fair, or has your interests at heart. They are collectively controlling ~50% of GDP resource allocation, they are effective dictatorships for the executive "class" and perfect competition that would keep them in line is rare in most industries.

Perhaps I am saying that changing the game is better for everyone than learning to play the current one well.

Not 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.

> 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

"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.

No 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.

That hasn't been my experience. I've even had managers pit devs against each other.

Those sound like bad managers :/

I guess so. I haven't had a truly good one out of the 19 or so that I've had in 10 years.

If your manager is churning every six months, they are either bad managers or in a failing organization.

Yet somehow they go on to manage other teams and thr company manages trillions in assets.

a 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.

> 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.

Especially in the last 5 years. 2-5% bumps for 10-20% inflation… gotta love math.

We 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.

If 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.

There may be some of that but that hasn’t been my experience. Most of the time it’s because of comp or as another poster reminded me, bad manager. If people are leaving because they coded themselves into a corner, the code review process where you are is broken.

Another common reason is when you get new manager(s) and they don't respect the insight which "All the superstars at my current company have been here for a while" have.

Often the superstars are just normal people who really knows the business well and therefore what makes sense to implement and what should be skipped.

When you earn enough money for a decent lifestyle, then I think this becomes the major reason for a lot of people to jump ship: you join a company but leave a manager. https://getlighthouse.com/blog/people-leave-managers-not-com...

I totally forgot about bad managers. Thanks for reminding me. I’ve only left two jobs in my career due to bad management.

While I agree with the reasons you outlined, my experience so far shows that number one reason is being the impostor. Most people I've had displeasure to work with job hopped because they got the job through lies, which showed when faced with bearing responsibility and having to finish the project, I've seen many just jump the boat.

That hasn’t been my case at all. If you have that, maybe your interview process is broken.

>All the superstars at my current company have been here for a while.

Exactly. And isn't that memorisation by repetition? If you will come across something often you take a good guess on how it works.

Quoting Groundhog Day: “Maybe God isn't omnipotent. Maybe he's just been around so long, he knows everything.”

Senior 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).

HN headline tomorrow: Senior engineers are literally gods

Except that's not at all what the article is suggesting. Quite the opposite.

> it is literally effortless to accidentally cultivate the impression of being some kind of wizard

My 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.

> just

Exactly, but also that it's quite often experience you had this morning, not e.g. over the last 5 years, that makes the difference.

A 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?

Relevant KRAZAM: https://www.youtube.com/watch?v=eSqexFg74F8&ab_channel=KRAZA...

Senior engineers are worms. Bow before the principal engineer.

Wait until you hear about Staff engineers.

> 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.

I'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.

Seniors are overrated. Principles is where it's at now.

The 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.

> 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.

As 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.

It'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.

It'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 ¯\_(ツ)_/¯

This explains why I'm so tired.

I 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.

Get 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.

Based 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.

Weird how they used as an example debugging character encoding bugs instead of solving real problems as the typical thing software engineers do.

Senior Engineers can also give the impression of wizardry by writing shitty code that only they understand.

I’ve heard that the literal translation for Sensei is “the one that was here before” or something like that.

Reply on news.ycombinator.com