Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Senior engineers are living in the future

zerobanana.com

Post reply on HN
Print view View original

181–190 of 241 posts

Re: Senior engineers are living in the future

#181

Post by bluGill »

hnfong wrote: post #162
kbenson wrote: post #42

Earlier quoted context omitted.

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 foun…

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 relativ…

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.

Re: Senior engineers are living in the future

#182

Post by groby_b »

bluGill wrote: post #179
setr wrote: post #172

Earlier quoted context omitted.

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 c…

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

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)

Re: Senior engineers are living in the future

#183

Post by 0x457 »

ASalazarMX wrote: post #55
trey-jones wrote: post #22

Earlier quoted context omitted.

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 loo…

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.

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

Re: Senior engineers are living in the future

#185

Post by kevinventullo »

adra wrote: post #133
kevinventullo wrote: post #121

Earlier quoted context omitted.

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

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

Re: Senior engineers are living in the future

#186

Post by bluGill »

soco wrote: post #98
zibby8 wrote: post #78

Earlier quoted context omitted.

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.

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

Re: Senior engineers are living in the future

#187

Post by 0x457 »

abhishekjha wrote: post #15
revskill wrote: post #12

Earlier quoted context omitted.

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.

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

Re: Senior engineers are living in the future

#188

Post by ryandrake »

gregmac wrote: post #148
ghaff wrote: post #140

Earlier quoted context omitted.

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

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()

Re: Senior engineers are living in the future

#189

Post by bluGill »

w10-1 wrote: post #169

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

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

Re: Senior engineers are living in the future

#190

Post by setr »

bluGill wrote: post #179
setr wrote: post #172

Earlier quoted context omitted.

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 c…

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

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

Post reply on HN