Live data from Hacker News

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

tanishqkancharla.dev

121–130 of 199 posts

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

#121

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 :)

All good, I’m glad you liked it! I’ve already posted it once, but it had no traction last time for some reason.

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

#122

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 really problematic when you have a team that's primarily newer engineers. I've seen it multiple times and it's always the same result - productivity almost grinds to a halt over time because there are so many problems in the code base. The worst example I saw was switching teams and seeing the team velocity. We measured all the work in story points and used the exact same task as a baseline story point. The previous team with mostly senior engineers, a point took .5 days. With the new team that was started by all fresh grad engineers, a story point took a minimum of 3 days and usually bumped up to 4 days. This velocity lasted multiple years, even when the team had a much more balanced spread of senior, mid-level, and fresh grad engineers.

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

#123
post #97

Earlier quoted context omitted.

Im not sure if there’s a good way to use css to animate an arbitrary number of children with a delay, while retaining clean markup. I did this before: .article-child { animation-delay: var(—index)*0.025s; } and while rendering, set style tags on each element style=“—index:5”, etc. That works, but it was annoying to maintain, and every single element has these style tags. So I just use Motion One (WAAPI) now.

Drop the animation and just let the browser render the elements and css position/style them. Most 'animations' on otherwise textual articles are merely eye-candy fluff that is totally unnecessary. PS: Viewing with JS on -- yes, totally unnecessary eye-candy fluff in that animation.

But that’s my vibe!

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

#124
post #34

I have never given much attention to functional programming just out of prejudice. Now I read this blog and my head just exploded in the functional part. It's beautiful. What good introductions to functional can you people point me to? Also, good code is like prose. You write to other to read, and you need to guide their minds. Of course you can write in dense, truncated and clever ways, but your audience will be sma…

I’m glad it left that impression! My thoughts have clarified a bit since I read that post, and I think what I describe is more declarative, like React. But the best places to read about it (for web devs) are in Elm!

There is also this new thing I found that seems to really lean into the core of what being functional means here: https://github.com/jorgebucaran/hyperapp

After a while, you see that basically all systems can be modeled as event-driven, functional systems. It’s a flexible model, and fits beautiful into web dev where the semantics are very clear: the system is the web app and events are clicks, keyboard events, asynchronous calls...

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

#125

Earlier quoted context omitted.

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

Cognitive overload. Storing 3-4 succinct variable names in your head takes the same energy as storing 1-2 verbose variable names in your head.

Cognitive overload.. Perhaps it'd be best to provide and example of a "verbose" variable name as compared to a "succinct"

Personally I'm thinking more along the lines of

Succinct ->KEY

Verbose -> MAIL_SERVICE_API_KEY

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

#126

Earlier quoted context omitted.

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

Cognitive overload. Storing 3-4 succinct variable names in your head takes the same energy as storing 1-2 verbose variable names in your head.

I think there's some nuance though. If I'm the one writing the code, sure I can keep 3-4+ succint names of things I came up with in my head.

But then somebody else needs to look at this code in the future, and they're scratching their head as to what these names represent. Or somebody didn't really put enough thought into what the variables are, or gave them a name that only half represents what they actually mean.

I basically threw away all care for how long a variable name is long ago and have never had a problem. I just name it with enough words it needs to describe what it represents and don't fuss with making it smaller. With a decent IDE you don't even have to remember the whole name for things half the time, only parts of it.

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

#127
post #34

I have never given much attention to functional programming just out of prejudice. Now I read this blog and my head just exploded in the functional part. It's beautiful. What good introductions to functional can you people point me to? Also, good code is like prose. You write to other to read, and you need to guide their minds. Of course you can write in dense, truncated and clever ways, but your audience will be sma…

What tech stacks are you currently comfortable with? If you have significant .NET experience f# can be a great entry point as you can reuse a lot of the same tools (VS/VSCode/Rider + Nuget or Paket if you wanna go full f#), and sites like https://fsharpforfunandprofit.com/ go pretty deep into why f#/functional etc.

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

#128

Earlier quoted context omitted.

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.

Surely, I have given up to the pretty tribe on a couple of pull requests, as I have better things to do with my time, and it is easier to make their wishes come true than endless arguing.

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

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

One of the traits of seniority is to understand what that "it depends" means in reality.

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

#130

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

Yeah, I stopped reading after this line. Sorry, but if you call yourself "senior" with 6 years of experience you've lost all credibility in my book.

I wouldn't instantly go that far. There are people who can be senior in 6 years. People truly that good are the exception, not the rule though.
Post reply on HN