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

221–230 of 392 posts

Re: New Grad vs. Senior Dev

#221

Post by gok »

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…

It's mostly a shibboleth to make sure you actually did the coursework on your resume.

Re: New Grad vs. Senior Dev

#222

Post by drewmol »

dmurray wrote: post #212
heymijo wrote: post #199

Earlier quoted context omitted.

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…

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.

> the answer is almost certainly that Python3 or some key libraries didn't exist.

This has not been my experience, even within the past few years on occasion.

Re: New Grad vs. Senior Dev

#223

Post by wmu »

Well, this is a nice example of lack of knowledge flow. The senior developer spent his time explaining things that should have been put in the procedure's comment. Yes, that's what comments are for.

Re: New Grad vs. Senior Dev

#224

Post by csours »

The only nested loop implementation I've ever changed for performance was due to the fact that there was a freakin' database call in the inner loop. All I did was refactor the data structure so that the db call was done outside the outer loop. Instant 20x improvement in performance.

Re: New Grad vs. Senior Dev

#225

Post by jniedrauer »

fjfaase wrote: post #79

Everyone who has done profiling knows that (almost always) the performance problem is in the part that you least expect it. But also that sometimes you wrestle to improve the performance of an algorithm hitting a hard wall and than someone comes up with an idea, often resulting from a fresh look on the problem, that results in an improvement of several orders. I guess that performance is at least as counter intuitive…

> I guess that performance is at least as counter intuitive as statistics.

I don't think this is really true. After you've optimized enough code over the years, you start to get a sense for bottlenecks, and your code is usually "fast enough" even on the first try. When it isn't, finding the problem with a profiler is usually pretty straightforward.

Re: New Grad vs. Senior Dev

#226

Post by burntoutfire »

Ididntdothis wrote: post #133
GordonS wrote: post #125

Earlier quoted context omitted.

I got the chance at work recently to work solo on a small, greenfield project, where I was fully in control of all the pieces and the problem space was small. I could do it any which way I wanted. Gods, it was wonderful! As I've moved up the ladder and worked on complex enterprise systems, with umpteen integrations, overly-strict SAST systems, enforced 90% test coverage and the like, I seldom feel the "joy of code".…

For a while I worked in video decoding/encoding. That was true engineering. I loved reading up about cache and assembly and then applying this knowledge to our code. It was ok to work on one function for weeks just to get 20% speed up. Now I do enterprise and it’s just horrible. Between dealing with stakeholders and 3rd party systems that barely work there is no room for systematic engineering.

May I ask why did you move from codecs into enterprise software?

Re: New Grad vs. Senior Dev

#227

Post by downerending »

pdubs1 wrote: post #116

I have no CS degree or STEM degree. Recently I worked on the same type of project as someone with 10 yrs of experience & a CS degree from Stanford. A few months later, I created a project, and had a manager with a CS degree. However, when I left, that manager was unable to pickup where I left off, and he ended up leaving soon after. I have less years of experience, but to me, what matters more is the time within that…

There are indeed many not-really-programmers with CS degrees.

On the other hand, sometimes I'm handed a program written by a new grad to maintain/fix/improve, and rapidly determine that it's less work to just chuck it in the bin and start over.

One of the major differentiators between a newbie and an old hand is knowing how to create a piece of software that those who work alongside you or come after you can understand, maintain, and improve.

Re: New Grad vs. Senior Dev

#228

Post by majormajor »

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.

That's a very "junior senior" type of developer. Rewrite from scratch needs external reasons to be a good idea, because you have a huge uncertainty risk of "i don't know enough about this system to rewrite it, and now i'm spending months hacking back in edge cases to the new no-longer-beautiful-design." Uncertainty risk doesn't mean never do it, but it means make sure you understand it and make sure it's gonna be worth it.

Re: New Grad vs. Senior Dev

#229

Post by heymijo »

dmurray wrote: post #212
heymijo wrote: post #199

Earlier quoted context omitted.

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…

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.

I think this seems like a good critique, but as you noticed this is a nascent concept for me. As I learn more, I'll have this critique in mind.

Re: New Grad vs. Senior Dev

#230

Post by downerending »

m3kw9 wrote: post #106

The senior dev knows the system, knows what they can get away with, and has choices to use those knowledge powers. A newbie will always follow the programming rules, like never going over the limit on a hwy. as they can’t take much calculated risks

A true master usually goes way under the limit.
Post reply on HN