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

191–200 of 241 posts

Re: Senior engineers are living in the future

#191

Post by bluGill »

layer8 wrote: post #134
revskill wrote: post #8

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.

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

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.

Re: Senior engineers are living in the future

#192

Post by 8note »

yazaddaruvala wrote: post #80
nostrademons wrote: post #44

Earlier quoted context omitted.

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…

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.

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

Re: Senior engineers are living in the future

#193

Post by [deleted] »

ironmagma wrote: post #51
revskill wrote: post #8

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.

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

[deleted]

Re: Senior engineers are living in the future

#194

Post by tvanantwerp »

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.

Re: Senior engineers are living in the future

#195

Post by layer8 »

bluGill wrote: post #191
layer8 wrote: post #134

Earlier quoted context omitted.

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

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…

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

Re: Senior engineers are living in the future

#196

Post by Jtsummers »

Adiqq wrote: post #167
Jtsummers wrote: post #127

Earlier quoted context omitted.

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…

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

Re: Senior engineers are living in the future

#197

Post by AlotOfReading »

Jtsummers wrote: post #127
AlotOfReading wrote: post #90

Earlier quoted context omitted.

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…

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.

Re: Senior engineers are living in the future

#198

Post by didgetmaster »

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…

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.

Re: Senior engineers are living in the future

#199

Post by deathanatos »

Swizec wrote: post #39
wccrawford wrote: post #27

Earlier quoted context omitted.

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

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.

Re: Senior engineers are living in the future

#200

Post by deathanatos »

triyambakam wrote: post #81

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

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.
Post reply on HN