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

81–90 of 199 posts

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

#81

Post by ebiester »

samsquire wrote: post #27

Clean code is code you and others can understand and everybody seems to have a different idea of that. Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete. I don't think I would enjoy working on this codebase.

I think I get frustrated here because "Clean Code" is talking about a very specific style of coding popularized by Robert Martin in the book with the same name. It is not a synonym for Good Code.

Longer variable names are certainly a facet of Clean Code. It's in chapter 2, and Chapter 1 is an introduction.

That said, I strongly suggest Arlo Belshee's series https://www.digdeeproots.com/articles/naming-as-a-process/ - this gets to the heart of how to have both descriptive and not-sentence-long.

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

#82

Post by dchapp »

> 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 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.

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

#83

Post by __Parfait__ »

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…

What's the cost?

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

#84

Post by tanishqkanc »

ChadNauseam wrote: post #73
tanishqkanc wrote: post #59

Earlier quoted context omitted.

Ah! That’s unfortunate . All that work of pre-rendering, and it won’t even work with javascript disabled. To be clear, I use a very very tiny bit of javascript only to animate the article elements after render.I guess when that fails, it just doesn’t animate the opacity to 1…hm...

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.

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

#85

Post by jrockway »

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.

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

#86

Post by scary-size »

tanishqkanc wrote: post #65

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...

I enjoyed reading your blog post. It was very well written. Most of your points resonate with me.

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

#87

Post by samsquire »

DanHulton wrote: post #70
samsquire wrote: post #47

Earlier quoted context omitted.

For Java and Python for each loops I often use "current" or a singular name for the thing being iterated. If it's a nested loop then I use "other". For C and JavaScript I use single letter indexes ijkl or "current". I think it's a personal preference. I don't think there is a wrong way or a right way. Your team needs to agree though. I would be annoyed if I implemented a deep feature and the PR was blocked due to som…

I don't mind "i", but if there's an inner loop with "j" as well, you are BEGGING for confusion.

I got down to "k" too. What about "x" and "y"? One important consideration of nested loops is row major access pattern rather than column major pattern, so access array[i][j] rather than array[j][i] due to the data locality of each. You shall get a performance boost by accessing them in that order.

I worked on parallelizing nested loops across OS threads and load balancing between outer loops for different progressions through the loop. I also wrote some code to reverse the loop direction to avoid a cache miss when the indexes go back to 0.

https://github.com/samsquire/multiversion-concurrency-contro...

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

#88

Post by johnthuss »

yodsanklai wrote: post #71
tom-thistime wrote: post #68

Earlier quoted context omitted.

For benefit of a friend new to HN (and anyone else who might be new here): Yes, the comments and the articles are almost separate, parallel discussions. The articles can be interesting in themselves, but for purposes of reading the comments, the articles are often just kind of inspirations or writing prompts. So, yeah, the OP doesn't even mention code quality. The comments do. That's ok. It's just how the site works.

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 ;)

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

#89

Post by rr808 »

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.

Yeah its pretty scary, 6 years mean you've either only understood on one or two big systems, or you've job hopped more projects and never understood them in depth.

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

#90

Post by treis »

kasey_junk wrote: post #46
unwind wrote: post #8

Earlier quoted context omitted.

Sometimes I see the title "principal engineer" used, and my impression is that it trumps a mere senior. See [1] for an example. I'm not in the US though and also work as a contractor so it's hard to use titles like these in my daily work. [1]: https://about.gitlab.com/handbook/total-rewards/compensation...

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?
Post reply on HN