Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tanishqkancharla.dev

Post reply on HN
Print view View original

41–50 of 199 posts

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

#41

Post by kasey_junk »

dom96 wrote: post #19
fake-name wrote: post #2

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

There are senior engineers out there that have <4 years professional experience. I myself went from IC3 (junior) to IC5 (senior) at FB in around 3 years and this is pretty common at FB from what I've seen.

I think the concern is that the industry, including Facebook, has decided that the designation “senior” is a thing you can get in But what if you were outside the industry and heard that term? A senior judge typically has decades under their belt. A senior chief petty officer is the second highest non-commissioned rank in the navy implying a whole career behind them. They might infer it only takes three years of experience to reach the near top of the software craft.

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

#42

Post by throwaway4233 »

lopkeny12ko wrote: post #31
fake-name wrote: post #2

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

Seniority is the fact or state of being older or higher in rank or status than someone else. Within an organisation, a senior engineer could be the engineer with the most experience with the codebase everyone else is working on.

I do agree that certain habits or experience from working for additional years might be missing, but as the first engineer of a codebase, IMO, there will always be something to learn from them. Which makes the article credible enough to warrant a read.

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

#43

Post by dataflow »

Just a note that functional programming here seems to be conflated with declarative programming. They do have some things in common ("no mutable state" being the main one I can recall), and technically I think FP is categorized as a subset of DP, but in reality a declarative program ends up looking quite different from a functional program, so it's with distinguishing the two.

To give a trivial example to illustrate the conceptual difference: a declarative program could say something like "the output is the solution to f(x) = 0", defining f explicitly and leaving it to the compiler/interpreter to supply the algorithm for figuring out an x that satisfies it. Note that, as long as x is unique, "try all legal values of x" works, so a viable fallback algorithm always exists; it's just inefficient. Whereas with FP you actually have to supply an explicit function to (hopefully efficiently) compute the output, i.e. you basically have to write f^-1 yourself, which typically results in a very different program - sometimes harder to read, sometimes easier.

Now, of course, you could do "FP" by writing f instead of f^-1 and then enumerating all possible inputs as with DP, just as you could write a DP to compute functions explicitly at every step, and you could write imperative programs for all these. But those would be unnatural, and would generally defeat the advantages of the paradigms.

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

#44

Post by yodsanklai »

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.

Generally, there's very little bikeshedding on code quality and that kind of things. People are pragmatic and wants to get the work done. It also means there are trade-offs regarding code quality (also dictated by management and pressure to deliver).

The challenges are elsewhere. Prioritising, communication, relationships with colleagues, setting up roadmaps and milestones, proposing designs, solving various challenges.

Generally, I found software engineering is less and less about writing code. I'm impressed how my colleagues are good at everything. Fluent in most programming paradigms, able to debug complex production issues, do low level performance analysis and so on...

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

#45

Post by mgkimsal »

thraxil wrote: post #38
samsquire wrote: post #27

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…

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; xinside 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(loop=0; loopThis concept from CC was at the back of my mind, but couldn't articulate it, or even remember where I'd first read about it, but it's been something I've worked at adopting and growing over the years. 6 line loops - x/i/j/k/etc are all valid and usable. In some ways, it's actually more helpful to me, because the longer names indicate something concrete/real, and the single letter names indicate local/throwaway values.

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

#46

Post by kasey_junk »

unwind wrote: post #8
BerislavLopac wrote: post #6

Earlier quoted context omitted.

I think a part of this issue is that there is nothing above senior. Additionally, "seniority" is relative and can vary between different technologies: for example, I have been working as a software engineer for 25+ years, and while I have worked with Java before I am no better at it than someone who just graduated. Similarly, even though I spent nearly a decade as a frontend dev, the last time I did that professional…

Sometimes I see the title "principal engineer" used, and my impression is that it trumps a mere senior. See [1] for an example. I'm not in the US though and also work as a contractor so it's hard to use titles like these in my daily work. [1]: https://about.gitlab.com/handbook/total-rewards/compensation...

You, accidentally, tripped a pet peeve of mine. Many people seem to think of writing software as a command and control function like some hypothetical military rank (and the leveling process engaged in by tech. companies reinforces this) where people higher up the ladder “trump” those lower.

But in software (and perhaps all knowledge work) many many times its the lowest ladder employees who are closest to the actual problem space. They are the ones dealing with the hacked up code base from 8 years ago, the indecipherable comments, the untested code that is critical to the business.

The job of the more senior people is not to command and control those employees, but to empower them. Bringing breadth of experience, or in depth expertise that is not specific to the problem at hand to help them make a decision.

Sorry, rant over.

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

#47

Post by samsquire »

mgkimsal wrote: post #45
thraxil wrote: 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…

For Java and Python for each loops I often use "current" or a singular name for the thing being iterated. If it's a nested loop then I use "other".

For C and JavaScript I use single letter indexes ijkl or "current".

I think it's a personal preference. I don't think there is a wrong way or a right way. Your team needs to agree though. I would be annoyed if I implemented a deep feature and the PR was blocked due to something as inane and useless as this.

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

#48

Post by pjmlp »

yodsanklai wrote: post #44

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.

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

#50

Post by goodpoint »

yodsanklai wrote: post #44

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…

Learning how to write good code is a topic for juniors. Any senior would already know how to that so we focus on other things.
Post reply on HN