Live data from Hacker News

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

tanishqkancharla.dev

151–160 of 199 posts

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

#151
If I may pick on one piece of advice here: intermediate variables. I think both the bad and good examples are both equally unreadable and feel the "good" version would introduce more confusion into a code base than the "bad" example.

For example, if I came across the example in code, I would begin to wonder why the `deltaX` variable exists at all if its only purpose is to be renamed `translateX` and spend some time tracing the code to see where the variable falls out of scope and to see if it's important. Then I might wonder whether it used for something else at some other point in time and trace the history of these lines (somewhat akin to nerd sniping).

Now I'm focusing on the variable as if it's important when really the important bit is the relationship of the current to the initial. The code is obscuring the fact that "delta" is `current - initial`. Look how many times the pattern is repeated! Perhaps we need an abstraction that can produce the delta for us. However, the data structure makes that a little bit tricky as scrollTop is held in an ad hoc manner, so maybe we should update the data structure so that we can eventually have an api like:

   type ScreenPoint = { x: number; y: number; scrollTop: number }

   type toDelta = (current: ScreenPoint, initial: ScreenPoint) => ScreenPoint

   // example implementation of toDelta using ramda for brevity
   const toDelta = R.mergeWith(R.subtract)

   const delta = toDelta(current, initial)
   shadow.style.transform = `translate(${delta.x}px, ${delta.y + delta.scrollTop}px)`
Intermediate variables can be tricky because you can't always trust that the name matches what's actually going on inside, so you have to read everything anyhow.

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

#152

If I may pick on one piece of advice here: intermediate variables. I think both the bad and good examples are both equally unreadable and feel the "good" version would introduce more confusion into a code base than the "bad" example. For example, if I came across the example in code, I would begin to wonder why the `deltaX` variable exists at all if its only purpose is to be renamed `translateX` and spend some time t…

> using ramda for brevity

please don't do that. Unless the article also uses Ramda (it doesn't) its not really appropriate for you to do so. If you want to use Ramda in your own, personal code, go ahead. But if you're posting a public example for other people to look at, including Ramda only makes sense if you're on a Ramda forum.

The whole point of this article is clarity in programming, you've reduced that with you decision to include some obscure package.

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

#153
post #38

Earlier quoted context omitted.

The recommendation I read back in the 90's in Code Complete that has served me well ever since was that variable name length should be roughly proportional to the variable span. "Variable span" being the distance between where the variable is first defined and its last use. Generally that means that a temp variable inside a short function can be a single letter since you can see the full context of its entire lifecyc…

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…

Sounds like your colleagues are cargo-culting rather than arguing from experience or knowledge.

My standard solution for this is to name the loop counter for the things being counted. So your example would be:

    for (horse=0;horse
or

    for (horse in horses) {
    }
or equivalent depending on whatever language you use.

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

#154

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

Much of the most widely used software in the world comes out of mid 20s so-called Senior Engineers in Silicon Valley (and other major US metros). Gatekeeping on the basis of years of experience is naive and unproductive.

IMO "senior" is a function of behavior not time. At FAANG, levels are formally defined by traits. For example, a senior engineer can plan and lead 6-12 month long projects, delegating some parts of the implementation to others where appropriate. I personally was fulfilling this definition at 25 and I know several dozen others in similar situations.

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

#155
Two of the points in the article are at cross purposes.

The author mentions doing Mindful Practice but later says to be Problem Oriented. The first one implies a background thread making judgments that is constantly running in the back of your mind. The second needs you to ignore everything but the problem at hand.

I’d go with the latter, esp if you’re new to the job. Let judgments accrue over time rather than go looking for them in the middle of a task at hand.

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

#156

Earlier quoted context omitted.

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.

If you're lucky enough to have someone buy into a centralized code/arch strategy then this is idea, the issues arrive when the code/arch strategy isn't a hard sell for the plow engineers.

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

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

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.

Sure, in the other extreme they never got shipped in first place, and that marvelous piece of art ended up in a museum.

It is a balance that needs to be learnt, and a trait of seniority.

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

#158

If I may pick on one piece of advice here: intermediate variables. I think both the bad and good examples are both equally unreadable and feel the "good" version would introduce more confusion into a code base than the "bad" example. For example, if I came across the example in code, I would begin to wonder why the `deltaX` variable exists at all if its only purpose is to be renamed `translateX` and spend some time t…

> using ramda for brevity please don't do that. Unless the article also uses Ramda (it doesn't) its not really appropriate for you to do so. If you want to use Ramda in your own, personal code, go ahead. But if you're posting a public example for other people to look at, including Ramda only makes sense if you're on a Ramda forum. The whole point of this article is clarity in programming, you've reduced that with you…

It was only intended to be illustrative of thinking about the operation as merging two identical data structures in a manner that produces the result. You could accomplish the it using any technique your codebase prefers be it FP, OOP, &c. (some languages might even handle such an operation natively).

In this case, I felt that it was sufficiently close to pseudo code “merge these objects by subtracting identical keys left to right,” but I understand your objection to obscurity. I actually feel that the implementation in this example is fairly unimportant.

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

#159

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

I'll play devil's advocate and argue that this could just be the code equivalent of privatizing the benefits while socializing the costs. You mention that your team writes code without explicit discussion of its quality. The benefits of that choice are front-loaded, while the costs of that choice won't be apparent until later. Furthermore, the team members who have to pay those costs may not even be the current team members - it may actually be those on the team months or years from now, after the original code authors have left for greener pastures.

So it may be too early to declare that your choice was a successful one. As the article mentions, code is read much more often than it's written.

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

#160

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.

HN maintainers should optimize page load time by just omitting the actual link to the article. The discussions would be pretty much the same.
Post reply on HN