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

101–110 of 199 posts

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

#101

Post by dionidium »

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, strong intuition about how to architect greenfield projects, and the complete confidence of his bosses, with whom he very quickly earned a reputation as the person to go to when something absolutely needed to get done. He knew what to prioritize. He knew which parts of the code to plow through and which to take his time on. He knew exactly where in the code to start looking when a bug came in. And he knew which things were important to management and which weren't.

I learned way more from him than I ever have from the kind of peers who have opinions about how to structure every line of code.

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

#102

Post by vsareto »

karmicthreat wrote: post #53
pjmlp wrote: 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.

There are a ton of people at all levels that don't get this.

It's not a universal thing.

You can go into some interviews, say you write code just good enough to ship, and that will be a red flag to them.

You have to choose your tribe on this issue and be comfortable with the other tribe hating your style.

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

#103

Post by kasey_junk »

polio wrote: post #64
kasey_junk wrote: post #41

Earlier quoted context omitted.

I think the concern is that the industry, including Facebook, has decided that the designation “senior” is a thing you can get in But what if you were outside the industry and heard that term? A senior judge typically has decades under their belt. A senior chief petty officer is the second highest non-commissioned rank in the navy implying a whole career behind them. They might infer it only takes three years of expe…

It feels similar to the title bloat of Goldman Sachs, where a lot of people are Vice Presidents.

In certain regulated or audited environments you’ll see rules like “only a person at the VP level or higher can make decision xyz”.

It’s just as stupid but there is a different reason for it.

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

#104

Post by dionidium »

grayclhn wrote: post #94
jrockway wrote: post #85

Earlier quoted context omitted.

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.

"Senior engineer" is a job title at every place I've ever worked.

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

#105

Post by jimmaswell »

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.

It depends on the person and domain. I've been in the industry for 5 years, but I worked on a lot of projects and did a lot of self learning since high school through college. Now I've been promoted to a front end lead position and I'm fully comfortable with the "senior" in my job title.

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

#106

Post by antidnan »

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

Hope you didn't mind me posting it! I was reading through the parser you posted yesterday and stumbled onto your blog :)

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

#107

Post by treis »

zero_shift wrote: post #18
neilv wrote: post #16

Earlier quoted context omitted.

For software developers, I've thought 5 years of solid work and continuous learning is about the right time horizon for a senior title, in a typical contemporary software/internet company. (At least, 5 years of seeing the lifecycle through awhile -- not job-hopping repeatedly, before getting to see cause and effect together.) I could even see that going faster than 5 years, especially in a startup. For example, say o…

I absolutely cannot agree with this. It's true that after five years in a startup, you'll have seen lots of systems. But being a senior practitioner requires deep experience as well as breadth, and enough time in the industry to recognise larger trends. There is no magic mark for this, and it's quite possible to reach ten years and still be a weak practitioner, because you were exposed to a narrow range of problems a…

I don't think I've seen anyone provide a workable system where senior is reserved for people around 20 years of experience. What's that structure look like? Everyone from 1-20 years experience has the same title?

There's definitely inflection points at years of experience:

0: Good enough to be hired

1-3: Solid team contributor

3-5: Best IC on a team

5-8: Lead a project/team

8+: Lead multiple projects

Then from there it's increasing complexity of teachnical problems and project size.

If you're insisting that senior applies only to the last level what do you call all those steps between 0 and 8.

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

#108

Post by debacle »

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…

There are a few hard and fast rules around code quality (and every rule is meant to be broken), everything else is just preference.

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

#109

Post by ericmcer »

pjmlp wrote: post #48
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…

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.

It depends, if it has a bunch of nested loops and easily abstracted code but it works sure, who cares. If someone decides to store JSON as a string in the db that will work and deliver business value, but 8 months later when you want to query information in that JSON string you have a very difficult/dangerous migration due to someone just "making it work".

This philosophy less relevant in larger companies with more engineers also.

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

#110

Post by nnnnico »

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?

Post reply on HN