Live data from Hacker News

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

tanishqkancharla.dev

51–60 of 199 posts

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

#51
post #38

Clean code is code you and others can understand and everybody seems to have a different idea of that. Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete. I don't think I would enjoy working on this codebase.

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…

Kudos to Code Complete, specially l the tips regarding "safe" C code and parameter validation, based on Microsoft learnings in failure to do so.

One anecdote I remember from the book, is how for a while Excel allowed for dual colored cells based on a parsing error due to trying to be too clever.

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

#52

Earlier quoted context omitted.

I know the EE & ME worlds, senior generally implies at least two decades of experience. I'm pretty sure the same is also true for civil engineering, and most of the other "hard" engineering practices. It seems like (at least outside of the military) the duration to being senior and the importance of things not going wrong are correlated.

The meaning is different. In software industry, senior means "doesn't need handholding", not "super-super-long experience" as in other more traditional fields.

I expect more than that, a senior should be in the position of accomplishing a task based on a ruff abstract, they should also be able to mentor juniors and jump into meetings with the customer, supporting architects and sales, if needed.

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

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

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

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

#54
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 good introductions to functional can you people point me to?

When people hear "functional programming" many of them will immediately point you to Haskell (and totally forget to mention The Haskell Pyramid [1]). I'd advise you to stay away from it until you _want_ to go deeper down the rabbit hole.

Play with Elm and Erlang ("Programming Erlang" [2] and "Erlang Programming" [3] books are great) to un-learn imperative patterns, tinker with OCaml to learn a new way to modularize code.

[1] https://patrickmn.com/software/the-haskell-pyramid/

[2] https://www.amazon.com/dp/193778553X

[3] https://www.amazon.com/dp/0596518188

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

#55

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…

It depends what is understood as code quality. After a while, writing code that is not verbose, fairly maintainable, and readable, is a given. There is a minimum bar that each team set and it is gated by code reviews. The tradeoff start to happen after those minimums are reached.

I think quality in terms of correctness is always the target, and performance usually has a target SLA.

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

#56
post #39
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 part are you referring to? I don't see any FP stuff in that article... It's all imperative code? Anyway I would recommend learning Haskell. I like languages that allow different styles (like js does to a certain extent). But I think it's better to learn a modtly pure OO language like java and a pure FP language like Haskell to be able to make the right decisions in a language that supports both like JS.

The author refers to it as "declarative programming" when they talk about functional programming.

I would link to the section "Functional, declarative programming" but there are no anchors. The table of contents (which the author calls a "minimap") is not clickable either.

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

#57

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…

[deleted]

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

#58

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 wouldn't fully agree, because while senior engineers don't often discuss "code quality" syntax/aesthetic issues, it is quite common for people to discuss bugs/edge-cases that need fixes or to discuss simpler approaches to achieve business goals or getting rid of difficult to maintain logic/services.

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

#59

No content with Javascript disabled. Hardly unheard of among a technical audience.

Ah! That’s unfortunate . All that work of pre-rendering, and it won’t even work with javascript disabled. To be clear, I use a very very tiny bit of javascript only to animate the article elements after render.I guess when that fails, it just doesn’t animate the opacity to 1…hm...

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

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

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.

Post reply on HN