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

New Grad vs. Senior Dev

ericlippert.com

Post reply on HN
Print view View original

351–360 of 392 posts

Re: New Grad vs. Senior Dev

#351

Post by Aeolun »

ljm wrote: post #299
maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

I'm a senior dev/tech lead and I empower my junior team mates/reports to do what they think is right. As such, I get shot down just as much as I shoot them down. I learn a lot from them, because I'm asking them to do a lot, and they also learn from me when I review the code or advise them on an alternative. They push back a lot and that's what I want. I want my reports to prove me wrong and show me better. This appro…

I’m trying to get to that point. It’s interesting to see that any new member that joins the team has a sort of adjustment period where the still come to ask everything, but eventually realize that “do what you think is best” is going to be the answer to any technical question regardless, and they realize it’s ok to have (and fix!) their own problems with the code.

Re: New Grad vs. Senior Dev

#352

Post by Aeolun »

wolco wrote: post #305
maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

In the end the junior spent a month working on this. Now you are on the latest python. How does this benefit the user again? Could the junior have been working on that spa for marketing? That's one months salary..

One months salary for a rewrite to python 3 is a good deal for pretty much any project.

Re: New Grad vs. Senior Dev

#353

Post by celeritascelery »

SaxonRobber wrote: post #198
lonelappde wrote: post #83

Earlier quoted context omitted.

In Python performance is your last consideration, and that's OK. Most things computers do don't need to be fast. Only the innermost loops run the most do.

This is the philosophy that has led to our software becoming slower despite improvements in hardware. Performance is always important. Especially for consumer applications, where your software will probably need to run alongside many other processes each competing for resources.

> This is the philosophy that has led to our software becoming slower despite improvements in hardware.

I disagree. Software has gotten slower over time because we are adding more fluff to it (SDK’s, libraries, electron, GUI animations, web interactions, frameworks, etc). Not because the developers are failing to focus on code optimizations.

Re: New Grad vs. Senior Dev

#354

Post by maliker »

ergocoder wrote: post #315
maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

Here's a tricky one that I encountered a year ago. A junior tried to advocate for browser test. Senior from the developer productivity team said browser test couldn't possibly be made non-flaky. I didn't know how to advice the junior because I agreed with them. Saying "something is infeasible/costly" is like a blanket statement. There was no way to quantify that. On a flip side, we couldn't justify the impact of brow…

My team went through the browser testing issue as well and agree they're hard tests to write. We ended up writing a few using selenium, but we don't have as much coverage as we'd like. Luckily, unlike an interpreter upgrade, we can add them incrementally.

Re: New Grad vs. Senior Dev

#355

Post by maliker »

nine_k wrote: post #318
maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

That is, the fact that Python 2 is not officially supported any more, and at maximum you'll see some fixes for most egregious security holes, is not something you considered back then?

I knew about the security risk, but I wasn't aware of how many quality of life and performance improvements we could use in the new version. And I also learned that some people enjoy researching/debugging the interpreter, whereas I originally thought the refactor would be a chore that hurt morale.

Re: New Grad vs. Senior Dev

#356

Post by sweeneyrod »

wolco wrote: post #305
maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

In the end the junior spent a month working on this. Now you are on the latest python. How does this benefit the user again? Could the junior have been working on that spa for marketing? That's one months salary..

Will it save a person-month in future work? If there's 10 devs working on this project and it will be around for at least another year, then that requires less than a 1% increase in average efficiency.

Re: New Grad vs. Senior Dev

#357

Post by maliker »

wolco wrote: post #305
maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

In the end the junior spent a month working on this. Now you are on the latest python. How does this benefit the user again? Could the junior have been working on that spa for marketing? That's one months salary..

Wins for the user were performance improvements and security. The dev quality of life features (better type checking, f-strings, nicer pathing syntax), as someone else mentioned, will improve our development velocity in the future, which gets back to the users as new features faster.

Re: New Grad vs. Senior Dev

#358

Post by maliker »

sweeneyrod wrote: post #356
wolco wrote: post #305

Earlier quoted context omitted.

In the end the junior spent a month working on this. Now you are on the latest python. How does this benefit the user again? Could the junior have been working on that spa for marketing? That's one months salary..

Will it save a person-month in future work? If there's 10 devs working on this project and it will be around for at least another year, then that requires less than a 1% increase in average efficiency.

We'll be at 12 devs this year with a 3 year runway. Thanks, we didn't think to put a precise number on the efficiency improvement!

Re: New Grad vs. Senior Dev

#359

Post by bitwize »

erik_seaberg wrote: post #191
bitwize wrote: post #180

New Grad: I'd use a linked list here because insertion into the middle is O(1) rather than O(n). Senior Dev: Linked lists have very many more cache misses than do vectors, and the difference between hitting cache and hitting main memory is such a huge constant factor that for most reasonable list sizes it never makes sense to use a linked list. Use a vector. Checkmate, smug Lisp weenies.

Yeah, the Lisp world figured out cdr-coding in the 1970s and had moved on to chains of vectors by 1985 according to https://cpsc.yale.edu/sites/default/files/files/tr362.pdf . Fortunately they avoided changing the API to make this tradeoff.

Afaik the only modern Lisp implementation that actually uses these techniques is Clojure.

Re: New Grad vs. Senior Dev

#360

Post by habosa »

Seems like the original developer should have left a comment about why their nested for loop was the right implementation (if they knew it was). Would have saved everyone a lot of time.
Post reply on HN