Live data from Hacker News

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

tanishqkancharla.dev

91–100 of 199 posts

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

#91

Earlier quoted context omitted.

Article start with variable names (which pertains to code quality) > Variable names are important because they communicate to the reader what’s happening. That’s their only job in code, so it’s important to name them well. Long verbose names don't cost anything:

Except in JavaScript ;)

And legacy c/opengl, where the variables names tell you the return type...

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

#92

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…

IMO too many coders can't write high quality code even if they tried. So when they write code that they feel is good enough, it rarely is good enough objectively.

What even is high quality code? I was on a project with a seasoned grey beard once and all he bitched about was dumb stuff like insisting NOT to prepend variable names with is and forcing a python project to have dependency injection. Sure, those things can make a high quality project but often misplaced and strangely opinionated.

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

#93
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?

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

#94

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.

Inside FAANG, it is literally a job title.

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

#96
post #48

Earlier quoted context omitted.

Make it work, then make it pretty. Undelivered pretty code doesn't deliver any business value. Same applies to 100% code coverage that isn't running on customers computers.

I don't care if it's pretty. Make it work and make it as straightforward as possible.

If by "straightforward" you mean "readable" I agree. If I can read it easily, it's pretty enough.

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

#97

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.

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.

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

#98

Hi! I’m the creator of the post. Thank you for all the comments on my post! I’m glad more people are getting to see it. Thanks for posting, @antidnan! Reading through, it looks like I have some rough edges of my website to clean up as well...

Congratulations on the post. One may agree or disagree with the content, but the text is clear, to the point, and generally very well written.

Good writing is, to me, the foundation of a good engineer. I know excellent engineers who are not great verbal communicators, but every excellent engineer I know writes like you do. I think it is the result of a structured thought process, that flows naturally into a structured clear text.

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

#99

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…

Sounds like a startup? Title inflation is pretty rampant at smaller newer companies. The expectation is definitely ship the product before all else. Obviously if you are an established company serving services to hundreds of thousands or millions of customers code quality and reliability becomes an order of magnitude more important.

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

#100
post #90

Earlier quoted context omitted.

You, accidentally, tripped a pet peeve of mine. Many people seem to think of writing software as a command and control function like some hypothetical military rank (and the leveling process engaged in by tech. companies reinforces this) where people higher up the ladder “trump” those lower. But in software (and perhaps all knowledge work) many many times its the lowest ladder employees who are closest to the actual…

What do you think should happen if a more senior person brings their breadth of experience or expertise and the junior engineer disagrees and does something else?

Obviously depends on the situation but almost always the person closest to the specific problem should make the call.

That’s why one of the most important differences between a more senior engineer and a more junior one is the ability to mentor.

Post reply on HN