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

221–230 of 241 posts

Re: Senior engineers are living in the future

#221

Post by ASalazarMX »

idontpost wrote: post #208
Adiqq wrote: post #167

Earlier quoted context omitted.

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

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

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

Re: Senior engineers are living in the future

#222

Post by ASalazarMX »

Jtsummers wrote: post #59
ASalazarMX wrote: post #55

Earlier quoted context omitted.

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.

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.

Re: Senior engineers are living in the future

#223

Post by ajcp »

_ktx2 wrote: post #107

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

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

Re: Senior engineers are living in the future

#224

Post by aaronbrethorst »

ryandrake wrote: post #188
gregmac wrote: post #148

Earlier quoted context omitted.

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

    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.

Re: Senior engineers are living in the future

#225

Post by gregmac »

ryandrake wrote: post #188
gregmac wrote: post #148

Earlier quoted context omitted.

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

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.

Re: Senior engineers are living in the future

#227

Post by roflyear »

trey-jones wrote: post #214
roflyear wrote: post #207

Earlier quoted context omitted.

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

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.

Re: Senior engineers are living in the future

#228

Post by jlkuester7 »

Test0129 wrote: post #211
GolDDranks wrote: post #161

Earlier quoted context omitted.

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

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

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

Re: Senior engineers are living in the future

#229

Post by chrisdirkis »

tvanantwerp wrote: post #194
sp332 wrote: post #20

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.

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.

Re: Senior engineers are living in the future

#230

Post by uuidv4 »

yitianjian wrote: post #164
GolDDranks wrote: post #161

Earlier quoted context omitted.

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

Post reply on HN