Live data from Hacker News

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

tanishqkancharla.dev

171–180 of 199 posts

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

#171

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 where you are. In the company I used to work at, code quality was a huge deal. I think, destructively so. Nevertheless, I exercise pretty extreme code quality in my work (see for yourself[0]). It's long reached the state of "muscle memory," and I work very quickly. As I am the person that most frequently has to go back and fix the code I write (I eat my own dog food), I write code that is what I want to se…

> I exercise pretty extreme code quality in my work

I'd say maintain good code quality on your own project is much easier than within a team. It's like living in a house with different people: not everybody has the same standard regarding keeping the place tidy and clean, and compromises have to be made.

This was one of the biggest pain point for me, moving from my own personal projects to working with other people.

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

#172

Earlier quoted context omitted.

Depends on where you are. In the company I used to work at, code quality was a huge deal. I think, destructively so. Nevertheless, I exercise pretty extreme code quality in my work (see for yourself[0]). It's long reached the state of "muscle memory," and I work very quickly. As I am the person that most frequently has to go back and fix the code I write (I eat my own dog food), I write code that is what I want to se…

> I exercise pretty extreme code quality in my work I'd say maintain good code quality on your own project is much easier than within a team. It's like living in a house with different people: not everybody has the same standard regarding keeping the place tidy and clean, and compromises have to be made. This was one of the biggest pain point for me, moving from my own personal projects to working with other people.

This is true. Many things suddenly become much more difficult, when even one other person is involved.

Managers often neglect to take team overhead seriously.

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

#173
post #117

Earlier quoted context omitted.

According to this[0] John carmack released 22 games before Doom all in the span of 5 years. Years of experience means nothing, working on real products that get shipped means a lot. I know plenty of programmers with 10+ years of experience that may never reach the level of expertise that Carmack reached in 5 years "professionally". [0]: https://en.m.wikipedia.org/wiki/John_Carmack

This has been my experience as well. I've worked with junior devs who understood their domain well and were very productive. I've worked with 20 year enterprise development veterans who are still doing the same basic Java work they have always done at large companies with questionable practices and literally haven't grown as a developer. Experience does matter, but what you've done with that experience is far more im…

Would you rather go to a mechanic that fixed only breaks in one car model for 10 years.

Or to a mechanic that fixed many things in many different cars over 10 years ?

Thats the difference between hoppers and “veteran corpo ppl”.

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

#174

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.

Being a senior is about how confident you are with your skill and your proven ability to deliver.

It has nothing to do with years or getting depth in projects. Most projects are just data pipes. Hard projects are rare.

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

#176

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…

yep.

A common refrain is that if you're not looking at code you wrote 6 months ago and thinking it's poor quality then you're not growing as a developer.

This is probably true for the first few years of a developers career, but there are only so many ways to build an authentication system (for example).

At some point your improvements are at the design and systems level. You start to develop a nose for what can be problematic and how to avoid it. Linus Torvalds referred to it as 'taste'.

And as you said, often times there are organizational and procedural challenges that have a much larger effect on the success of a project than purely code concerns. Not that code concerns are irrelevant, but good enough is good enough, there's generally an expectation that developers can read code. In the same way there's an expectation that readers of a novel are at the literacy level to understand novels. No one would blame James Clavell if a 5th grader couldn't understand Shogun, even though it's true that Shogun could certainly be improved from a prose perspective.

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

#177

Earlier quoted context omitted.

> Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. This approach probably works out because you have senior engineers laying out a lot of the core structure and architecture for how things built. There's a tendency for newer people to tacitly adopt patterns that already exist and replicate. However, this approach can be re…

Are you sure that the discussion should be around code quality but not architecture? I think they are quite different...

In addition, I think it's the fault of management if it's all young engineers.

I've often said the difference between a senior and a junior isn't writing software successfully, it's writing software that's maintainable 5 years down the road. The only way to learn that skill is to deal with a project over years and learn the pain points that aren't immediately obvious w/i the first 18 months.

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

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

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 e…

Do you know of any RDBMS's that can't take a text column and treat it as BSON?

I get your point, I just question the specific example.

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

#179
post #117
post #89

Earlier quoted context omitted.

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.

According to this[0] John carmack released 22 games before Doom all in the span of 5 years. Years of experience means nothing, working on real products that get shipped means a lot. I know plenty of programmers with 10+ years of experience that may never reach the level of expertise that Carmack reached in 5 years "professionally". [0]: https://en.m.wikipedia.org/wiki/John_Carmack

comparing to the top percentile is almost never a valid way to look at things.

14 year olds have competed in the olympics, I would never claim that should be the bar for considering health for 14 year olds.

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

#180
post #173

Earlier quoted context omitted.

This has been my experience as well. I've worked with junior devs who understood their domain well and were very productive. I've worked with 20 year enterprise development veterans who are still doing the same basic Java work they have always done at large companies with questionable practices and literally haven't grown as a developer. Experience does matter, but what you've done with that experience is far more im…

Would you rather go to a mechanic that fixed only breaks in one car model for 10 years. Or to a mechanic that fixed many things in many different cars over 10 years ? Thats the difference between hoppers and “veteran corpo ppl”.

1. That depends on how difficult the problem is. For some problems, you're better off with a specialist.

2. Do you want a whole car designed by someone who designed the hubcaps of a Ford Model, and the driver's side door handle for an Audi, and a dash switch for Toyota, and on through 10 other random parts? Or do you want someone who has been part of a team that designed a whole car before, from start to finish?

Post reply on HN