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

311–320 of 392 posts

Re: New Grad vs. Senior Dev

#311

Post by skunkworker »

heymijo wrote: post #199
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…

This sounds like the phenomenon dubbed Chesterton's Fence [0]. A core component of making great decisions is understanding the rationale behind previous decisions. If we don’t understand how we got “here,” we run the risk of making things much worse. So you helped the new dev understand the current lay of the land. They listened, then suggested an improvement based on their new understanding. You agreed and together…

I recently started a new job and whenever I can I try to document the code I contribute with the "whys" instead of documenting self-explanatory parts. I've extended this to parts of the code that I now maintain but did not initially write as this helps me mentally map out the rationale.

Re: New Grad vs. Senior Dev

#312

Post by jSully24 »

bogdanu wrote: post #145
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…

The reverse of this also happens: new team manager joins a team of 4-5 dev and goes "eww... a monolith, we'll write an MVP in 3 weeks with microservices, CQRS and all". Long story short, one year and a half passes and the mvp is still not finished, the architect leaves the company and some poor guys (from an outsourcing company) are still going at it with the same architecture.

Never hire anyone who’s top priority is not to first understand the whys of the current situation and understands how to move forward from there.

If they have “the answer” but don’t understand the “why we are here today” their decisions should be, at the very least, suspect.

Re: New Grad vs. Senior Dev

#313

Post by lucio »

DonHopkins wrote: post #131
lonelappde wrote: post #88

Earlier quoted context omitted.

New hires showing up at work and doing the one thing they were tested on in the interview. How strange of them!

I like to ask interviewees to imitate the sound a computer would make over an AM radio while executing different algorithms. Nested for loops go brrrrrrrrrrrr, munching squares go bweep bweep bwweeeep bwweeeep bwweeeep bwweeeep bwwwweeeeeeep bwwwweeeeeeep bwwwweeeeeeep bwwwweeeeeeep bweep bweep bweep bweep... https://www.youtube.com/watch?v=V4oRHv-Svwc Life goes shlup shlup shlup shlup shlup... https://www.youtube.co…

beautiful analog phosphorus naturally fading

Re: New Grad vs. Senior Dev

#314

Post by mister_hn »

burpsnard wrote: post #247
mister_hn wrote: post #156

Earlier quoted context omitted.

Not everyone is accepting suggestions like you. I am a senior dev and I always try to push new ideas to my team lead (senior dev and older than me), but all I get is blatant criticism because he says "I've tested it and didn't like it). A clear example: refusing to move to Spring Boot and still staying on the dead horse JavaEE, which got more complicated and fragmented than ever since Java 9

one client of mine has stuck to java8, way ahead of your curve there ;)

Just imagine that allof it is called JakartaEE and yes, you have an artifact for interface and one for implementation and they are not even compatible with jpackage (Java 14)

Re: New Grad vs. Senior Dev

#315

Post by ergocoder »

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 browser test either. But I felt, at the time, we should've been biased to implement every type of tests (than not) since there are only 3 types: backend, JS, and browser.

Akin to your example, it was the same argument "X is costly/infeasible". Your example doesn't have any issue because everyone probably agrees with it. But being infeasible to setup browser test sounds strange.

Also, if we don't plant the tree now, then when?

Re: New Grad vs. Senior Dev

#316

Post by Zarel »

dimtion wrote: post #7

I find that the biggest misunderstanding happens because "new grads" (and I happen to be one) confuse _asymptotic complexity_ with actual complexity. I'm not sure sure why, but CS courses and interview questions mostly focus on _asymptotic complexity_ and usually forget to take into consideration the complexity for "little values of n". And funnily enough, in real life n never goes to infinity! In a strict sense big…

After a few years working on real-world code, I understood that faster asymptotic complexity was often slower on average.

After a few more years working on real-world code, I understood that it's usually better to choose the algorithm with better asymptotic complexity, anyway.

Like, sure, my O(n) algorithm will be 10x slower than your O(n^2) algorithm for small n. But users aren't going to notice a few microseconds. Users ARE going to notice my O(n) algorithm being 100000x faster for large n, when it's the difference between milliseconds and minutes.

Re: New Grad vs. Senior Dev

#317

Post by koreth1 »

herbstein wrote: post #210
TheOtherHobbes wrote: post #205

Earlier quoted context omitted.

I sometimes wonder if CS should be renamed Computer Pseudo-Science. I blame Knuth and (mostly) Dijkstra for propagating the falsehood that you can estimate the performance of real code on real hardware with a some elegant academic blackboard math which gives you the wrong answer for many practical applications. It's not that Big O isn't useful - it's that it's taught as a set of "proofs" which somehow make it appear…

But Big O was a lot more directly correlated when the CPU wasn't doing "magic" optimizations on its own. It was still estimations with an invisible constant factor, of course,

This is a key point. The gargantuan performance difference between main memory and the CPU cache (or indeed, the existence of significant CPU caches at all) happened well after big-O was firmly established in the CS curriculum.

Re: New Grad vs. Senior Dev

#318

Post by nine_k »

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?

Re: New Grad vs. Senior Dev

#319

Post by nine_k »

joshwa wrote: post #292
dmurray wrote: post #212

Earlier quoted context omitted.

This isn't really Chesterton's Fence. It doesn't take any soul searching or insight to answer "why was this not written in Python3 in the first place" - the answer is almost certainly that Python3 or some key libraries didn't exist. It's a pure cost/benefit analysis question. Switching has some cost, and some benefits, and you have to decide which are likely greater.

Knowing how so many devs are hungry to move to the new shiny thing, the question is often more like "why hasn't this been rewritten in Python3 already? ". Possible answers: • Legit technical or cost/benefit reasons • Probably a good idea but no budget/time for the effort • Somebody already tried and it was a disaster • No manager has been stupid enough to humor the devs

Most reasonable devs are not jackdaws and do not want a "new and shiny" thing for its shine.

Mostly devs want to go away from the old and increasingly creaky thing. And when the cost / benefit ration is finally right (that is, it's creaking loud enough and slows things down much enough), the move hopefully happens.

Re: New Grad vs. Senior Dev

#320

Post by rkagerer »

ericlippert wrote: post #144
rkagerer wrote: post #119

Shockingly, InStr( , "docum") = 0 I'm a dev with some grey hair who feels it would have been useful for all that fantastic domain knowledge from Paterson to get documented in a code comment. I'd love to hear if either of them ever went back and did that?

In this case I think not. However I strongly agree with your position and have tried hard to ensure that my code is commented such that it explains why the code works as it does. See https://ericlippert.com/2014/09/08/comment-commentary/ for more thoughts on this subject.

Hey Eric thanks for responding here!

Love that article, it was interesting to read your dissection of code comments.

For anyone else reading it, here's an updated link to the CS file referenced in his blog post (the original moved): https://github.com/dotnet/roslyn/blob/master/src/Compilers/C...

Post reply on HN