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

131–140 of 199 posts

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

#131

Post by mad_vill »

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…

This is touching on something I have been thinking a lot about as I progress in my career.

The thing good and bad code have in common is the fact that it needs to updated. Either for bugs or changing business need.

So focusing on the operational side becomes much more important. Code is the trivial part. Creating systems that can be modified reliably is the hard part.

I rather have ownership over a "poorly" coded service with proper ci/cd, integration tests, monitoring, and a team that reasons about and follows strong operational processes, rather than some beautiful code in a vacuum.

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

#133

Post by dchapp »

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?

I have. I prefer statically typed languages.

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

#134

Post by patrick451 »

nnnnico wrote: post #110
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…

>They absolutely do have a cost. what cost? aesthetics?

Long, verbose variables are hard too read (it literally takes more time to read more characters), cause excessive line breaks, are harder to remember, and in general hurt readability more than they help.

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

#135

Post by dchapp »

__Parfait__ wrote: post #83
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?

Readability. In particular, an increase in the rate at which long, verbose names which are mostly the same are confused with one another.

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

#136

Post by smrtinsert »

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…

Depends on the seniority imo. If you don't make code quality a thing with early in their career devs, you might open up a door to some bad habits to take hold.

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

#137

Post by mmmpop »

enraged_camel wrote: post #119
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…

In my experience it is useful to have such people on the team, but if they make up most of the team then the codebase becomes a gigantic mess over time, and it negatively impacts everyone else.

Perhaps but having "that programmer that management likes" is worth 10x more than whatever mess is generally being made.

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

#138

Post by alexashka »

dionidium wrote: post #101
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 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…

He is almost certainly way above a pretty good engineer.

Nobody can quantify 'good-enough code' but everyone can quantify meeting a deadline.

How much engineering is anyone really doing anyhow - or are we calling using React to build yet another set of forms users fill out with some error handling engineering nowadays? :)

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

#139

Post by silisili »

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 agree 1000%, but at my company and many I've looked into(not FAANG), it's the way they structure it. Senior is level II, one above Junior. Then all kind of inflated things above that like Lead, Principal, Architect, Principal Architect, Master. Just waiting for them to add Physician or something...it fits in line with our industry stealing other job titles to feel important.

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

#140

Post by skybrian »

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 the names in the article were pretty decent, but here is good article about common errors that result in unnecessarily long names:

https://journal.stuffwithstuff.com/2016/06/16/long-names-are...

Post reply on HN