Live data from Hacker News

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

tanishqkancharla.dev

61–70 of 199 posts

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

#61

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…

At some point your craft is good (or good enough) that progressing further on it is not moving you forward as an engineer. It is often a difficult thing to notice and a trap one can easily fall into of over-focusing on craft and not realizing you’re plateauing your overall career or skill set.

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

#62

Earlier quoted context omitted.

I think a part of this issue is that there is nothing above senior. Additionally, "seniority" is relative and can vary between different technologies: for example, I have been working as a software engineer for 25+ years, and while I have worked with Java before I am no better at it than someone who just graduated. Similarly, even though I spent nearly a decade as a frontend dev, the last time I did that professional…

> there is nothing above senior. Only in industries where software development is not a primary business; beyond Senior there's titles like Lead, Staff, Principal, Distinguished and Fellow SWE, or branching off, things like architect. Anyway, senior engineer is less about what languages do you know and more about making informed technology decisions, maintaining quality, managing and training less experienced people,…

"Lead, Staff, Principal..." exist only in few companies, are even more vague that "senior" and don't even represent seniority but rather how long a person worked in the same company.

(And how lucky they are at getting promoted withing that company)

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

#63
post #4

> senior engineer > been a professional engineer for 6 years Man, the software world is just weird.

Is it really that weird? In the military 6 years is definitely considered senior and I’m sure that’s also the case in a lot of other fields.

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

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

#64
post #19

Earlier quoted context omitted.

There are senior engineers out there that have <4 years professional experience. I myself went from IC3 (junior) to IC5 (senior) at FB in around 3 years and this is pretty common at FB from what I've seen.

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.

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

#66

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.

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

#67

Earlier quoted context omitted.

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

I think it was Judd Apatow who said “You have to give yourself permission for the first draft to be shit.” The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.

Problem is the business will often never let you improve it.

So you better not tie your self worth to the quality of the things you produce.

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

#68

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

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

#69
post #48

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.

The counterpoint to this is "Rough Prototypes have a bad habit of being shipped out as End-Products". And technical debt 'does' kill products.

There's probably an optimum somewhere in the middle of each philosophy, but it's certainly not close to either extreme.

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

#70

Earlier quoted context omitted.

Thank you. I'd read CC ... 15+ years ago, but couldn't remember this specific step (but I know I've internalized it). I had criticism from folks a couple years back because I used "x" and "i" as variable names in loop counting - for (x=0; x inside a test file , and, at that time (8 months after launch), I was committing the first test to the project. It was blocked while I had to think of something better, like for(l…

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