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

What I learned working with a senior engineer as a new grad

tanishqkancharla.dev

Post reply on HN
Print view View original

161–170 of 199 posts

Re: What I learned working with a senior engineer as a new grad

#161

Post by twic »

jrockway wrote: post #85
yotamoron wrote: post #72

6 years of experience does not make one a senior engineer. I`ll be polite and say that most engineers with 6 years of experience I know are not seniors.

I think there's a split in the industry; outside of FAANG senior means "certain amount of time spent in front of the computer getting paid", inside FAANG, it's a set of behaviors encapsulated in a particular mid-career job title.

Outside of FAANG, senior means "we can't pay as much as FAANG but we will call you senior when you have two years of experience and no idea what you're doing".

Re: What I learned working with a senior engineer as a new grad

#162

Post by battery_glasses »

yodsanklai wrote: post #44

I've noticed many of these articles about what it takes to be a good software engineer talk about code quality. I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. G…

I used to feel this way until I started working with a very senior engineer (20+ years) who writes some of the worst code I have ever had to work with.

Functions are regularly 50+ lines with 10+ logical expressions. Most features are written as single classes with 3k-5k lines. Everything is written imperatively (that 50 line function declares a variable at the top and mutates it 10 times as it works through the control flow.) The same magic values are redeclared multiple times through the codebase instead of using a shared constant. His PRs are usually 3k-5k lines and take hours to work through. etc. etc

His code takes way more effort to understand and takes orders of magnitudes longer to change than it reasonably should.

Also his code works. It generally does what its supposed to do, covers edge cases, and is reliable. He also delivers with decent speed, but all that saved time is being pushed on the poor sap who has to work with the code next.

Re: What I learned working with a senior engineer as a new grad

#163

Post by dchapp »

edflsafoiewq wrote: post #148
dchapp wrote: post #82

> Long verbose names don't cost anything They absolutely do have a cost. The question is whether the benefit they bring in implicit documentation is worth their cost. > Even beyond the DX of readable names, it also acts like a type-checker. By reading the code, you can verify at least the semantics make sense. I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is…

Modelling in the type system has a cost too. You have to digest a lot of text (wrapping & unwrapping, etc.) just to understand that you're passing a length. Comparatively some extra characters in an identifier are basically free and can tossed in anywhere.

That may be a fair criticism in some cases.

For my toy example I don't think it is because it's generally easy (in the languages I work in) to overload arithmetic operators on types that are basically constrained scalars so there's no explicit wrapping/unwrapping to do when you want to operate on them as if they were plain scalars.

Maybe you could give me an example of the kind of pathological situation you're alluding to?

Re: What I learned working with a senior engineer as a new grad

#164

Post by ChadNauseam »

pwg wrote: post #97
tanishqkanc wrote: post #84

Earlier quoted context omitted.

Im not sure if there’s a good way to use css to animate an arbitrary number of children with a delay, while retaining clean markup. I did this before: .article-child { animation-delay: var(—index)*0.025s; } and while rendering, set style tags on each element style=“—index:5”, etc. That works, but it was annoying to maintain, and every single element has these style tags. So I just use Motion One (WAAPI) now.

Drop the animation and just let the browser render the elements and css position/style them. Most 'animations' on otherwise textual articles are merely eye-candy fluff that is totally unnecessary. PS: Viewing with JS on -- yes, totally unnecessary eye-candy fluff in that animation.

I wouldn't want to live on an internet without a hint of personalization or eye-candy fluff :P

Re: What I learned working with a senior engineer as a new grad

#165

Post by plonk »

shepherdjerred wrote: post #93
dchapp wrote: post #82

> Long verbose names don't cost anything They absolutely do have a cost. The question is whether the benefit they bring in implicit documentation is worth their cost. > Even beyond the DX of readable names, it also acts like a type-checker. By reading the code, you can verify at least the semantics make sense. I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is…

> I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name. Have you never worked in a dynamically typed language?

Python is only palatable with strict type checking everywhere. I don't see how unchecked dynamic typing can bring anything else than chaos in a large project.

Re: What I learned working with a senior engineer as a new grad

#166

Post by ChadNauseam »

tanishqkanc wrote: post #84
ChadNauseam wrote: post #73

Earlier quoted context omitted.

Haha, same thing was pointed out to me when my site was posted to HN. My advice: use a css transition instead of js

Im not sure if there’s a good way to use css to animate an arbitrary number of children with a delay, while retaining clean markup. I did this before: .article-child { animation-delay: var(—index)*0.025s; } and while rendering, set style tags on each element style=“—index:5”, etc. That works, but it was annoying to maintain, and every single element has these style tags. So I just use Motion One (WAAPI) now.

If you're willing to do some heavy copy-paste, there's always:

    @keyframes fdsseq { 
    100% { opacity: 1; }
    }

    #fds p {
    animation: fdsseq .5s forwards;
    }
    #fds p:nth-child(1) {
    animation-delay: .5s;
    }
    #fds p:nth-child(2) {
    animation-delay: 1s;
    }
    #fds p:nth-child(3) {
    animation-delay: 1.5s;
    }

Re: What I learned working with a senior engineer as a new grad

#167

Post by yodsanklai »

cpeterso wrote: post #147
dionidium wrote: post #101

Earlier quoted context omitted.

I used to work with a guy who took "gets shit done" to a level I'd never seen before. It changed the way I look at programming. He was actually a pretty good engineer. Wrote good-enough code. But he wasn't precious about anything and he didn't care all that much about finding the 100%-guaranteed-socially-approved-correct way to do things. What he had was an incredible ability to diagnose and fix problems quickly, str…

Fixing bad code is easier than fixing bad architecture. And if your architecture is modular and cleanly decoupled, then the bad code’s impact can be contained.

This is a good point. Modularity is the key to managing complexity. Unfortunately, I think writing a good architecture is harder than writing good code at the local level (because most developers have less experience at writing code in the large). And projects with a good initial architecture tend to diverge as developers add new features and introduce new dependencies. They often don't understand the original design and want/need to get things done quickly.

Re: What I learned working with a senior engineer as a new grad

#168

Post by goodpoint »

foobarian wrote: post #80
goodpoint wrote: post #63

Earlier quoted context omitted.

In most engineering it takes 15 if not 20 years. Otherwise the term "senior" gets completely watered down.

Many software companies have official ranks where "senior" is a step up after "junior," to be followed by "principal," "senior principal," and/or "staff." "Staff engineer" may not sound as impressive as "senior" to a layperson, but at say Google those people are like minor deities.

"principal" and "staff" are even more vague than "senior" and exist only in few companies. More importantly, they almost never refer to total experience and instead refer to being promoted within a given company.

Re: What I learned working with a senior engineer as a new grad

#169

Post by nine_k »

yodsanklai wrote: post #44

I've noticed many of these articles about what it takes to be a good software engineer talk about code quality. I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. G…

For me, code quality boils down to two aspects: (1) current operation cost and (2) future maintenance / alteration cost.

You can cut a lot of corners, as long as you don't paint yourself into a corner. OTOH an extra hour not spent today on doing the right thing may and will result in extra weeks and extra thousands of dollars spent in a few months.

Re: What I learned working with a senior engineer as a new grad

#170

Post by yodsanklai »

toomanyrichies wrote: post #159
yodsanklai wrote: post #44

I've noticed many of these articles about what it takes to be a good software engineer talk about code quality. I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. G…

> I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. I'll play devil's advocate and argue that this could just be the code equivalent of privatizing the benefits wh…

I'm not saying that my team writes unmaintainable code, but rather that because they're all strong and experienced, writing decent code is a given and the focus is on other, more challenging, problems. That being said, our code is definitely not as readable as it could be, but I understand it's a trade-off and there are more important things to do than refactoring code, unless it really gets in the way.
Post reply on HN