Live data from Hacker News

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

tanishqkancharla.dev

141–150 of 199 posts

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

#141

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.

Yes, very good point. I added a little edit to clarify that.

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

#142

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…

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

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

#144

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.

Yep I tend to be more on the spectrum of focusing on code & architecture quality over raw productivity, and I find the "plow through it and get it done" engineer to be the perfect foil to have on my team.

Ultimately it gets done faster than it would if the whole team was my personality, but with higher quality than if the whole team was their personality.

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

#145
I don't think 'type unsafe' is the only way to enable decoupling. For adding new commands, it can be done in a pretty type safe way. The problem is that the `ICommandHandler` may be used in a lot of places expecting different parameters, so they try to simplify the interface by using `any` as the parameter type.

> Static typing is really a form of testing

No! Static typing is not a form of testing. Static typing or static analysis, is an approximation of you program behavior, because it is undecidable in general. Depending on the properties of the type system, you can guarantee that you program doesn't go wrong if it is well-typed, where the definition of 'go wrong' depends on the type system. On the contrary, testing can check the behavior of your program with respect to a set of inputs, and it doesn't guarantee anything outside that set of input. You are doing state partitioning by doing a static analysis over your code to determine what tests you may need, and test some of them.

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

#146

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

My experience is that “good” code enables all of that — CI/CD, meaningful testing, monitoring/logging, operational tooling, etc.

Making any of that work for spaghetti is rough, since it lacks the boundaries and entry points those things rely on. And even if you ostensibly have it for “bad” code, it tends to be fragile and unreliable. (As my many, many overnight pages have shown.)

Of course, that may be different perceptions of “good”.

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

#147

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…

Fixing bad code is easier than fixing bad architecture. And if your architecture is modular and cleanly decoupled, then the bad code’s impact can be contained.

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

#148
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…

Modelling in the type system has a cost too. You have to digest a lot of text (wrapping & unwrapping, etc.) just to understand that you're passing a length. Comparatively some extra characters in an identifier are basically free and can tossed in anywhere.

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

#149
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

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 important than how long it is in absolute terms.

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

#150

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.

33rd Degree Revered Imperial Grand Master of the Ancient and Sacred Order of the Freecoders
Post reply on HN