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

Things I Learnt from a Senior Software Engineer

neilkakkar.com

Post reply on HN
Print view View original

21–30 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

#21

Post by teddyh »

> Naming your clusters? Naming them after the service that runs on them is great, till the point you start running something else on them too. We ended up naming them with our team name.

This is covered by RFC 1178¹, Choosing a Name for Your Computer (from 1990):

Don't choose a name after a project unique to that machine.

A manufacturing project had named a machine "shop" since it was going to be used to control a number of machines on a shop floor. A while later, a new machine was acquired to help with some of the processing. Needless to say, it couldn't be called "shop" as well. Indeed, both machines ended up performing more specific tasks, allowing more precision in naming. A year later, five new machines were installed and the original one was moved to an unrelated project. It is simply impossible to choose generic names that remain appropriate for very long.

Of course, they could have called the second one "shop2" and so on. But then one is really only distinguishing machines by their number. You might as well just call them "1", "2", and "3". The only time this kind of naming scheme is appropriate is when you have a lot of machines and there are no reasons for any human to distinguish between them. For example, a master computer might be controlling an array of one hundred computers. In this case, it makes sense to refer to them with the array indices.

While computers aren't quite analogous to people, their names are. Nobody expects to learn much about a person by their name. Just because a person is named "Don" doesn't mean he is the ruler of the world (despite what the "Choosing a Name for your Baby" books say). In reality, names are just arbitrary tags. You cannot tell what a person does for a living, what their hobbies are, and so on.

1. https://tools.ietf.org/html/rfc1178#page-2

Re: Things I Learnt from a Senior Software Engineer

#22

Post by lazzlazzlazz »

adamnemecek wrote: post #14

These posts keep repeating the same things. "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. - Jeff Atwood" This is not novel, nor insightful. "Premature Optimization Is the Root of All Evil". I've reached a point where every time I hear someone say this, I legitimately ignore everything else they say.

You've become that unhelpful curmudgeon you used to dismiss.

Re: Things I Learnt from a Senior Software Engineer

#23

Post by grogenaut »

teddyh wrote: post #21

> Naming your clusters? Naming them after the service that runs on them is great, till the point you start running something else on them too. We ended up naming them with our team name. This is covered by RFC 1178¹, Choosing a Name for Your Computer (from 1990): Don't choose a name after a project unique to that machine. A manufacturing project had named a machine "shop" since it was going to be used to control a nu…

I find that team names change more frequently than responsibility in a large org. Also using a team name makes people assume ownership of decisions with that team. That's why I prefer service name. However I haven't thought much about shared use clusters.

Re: Things I Learnt from a Senior Software Engineer

#24

Post by heinrichhartman »

honkycat wrote: post #12

Just to toss in my two cents about testing: Unit tests are for refactoring and declaring behaviour. Additionally, a lot of people have made the same observation: Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function, think about how you can change your design to make testing easier. It will probably improve your code quality. Integration tests a…

I have heard this so many times:

> Comments: I find comments, outside of docstrings, a smell.

But is this really the case? I find comments like these invaluable:

     /*
      * Mark walreceiver as running in shared memory.
      *
      * Do this as early as possible, so that if we fail later on, we'll set
      * state to STOPPED. If we die before this, the startup process will keep
      * waiting for us to start up, until it times out.
      */
     SpinLockAcquire(&walrcv->mutex);
https://github.com/postgres/postgres/blob/master/src/backend...

Part of the job of a developer is to communicate

- domain model (Concepts, Relations between them)

- intention behind the code (Why is this code here?)

- possible pitfalls (I tried this, it does not work because ...)

- limitations (TODO: This special case does not really work, yet)

for your colleagues and future heirs.

How would you ever cramp information like this into variable names and types? (... without introducing so much abstractions that the code becomes unreadable).

Re: Things I Learnt from a Senior Software Engineer

#25

Post by honkycat »

neilkakkar wrote: post #15
honkycat wrote: post #12

Just to toss in my two cents about testing: Unit tests are for refactoring and declaring behaviour. Additionally, a lot of people have made the same observation: Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function, think about how you can change your design to make testing easier. It will probably improve your code quality. Integration tests a…

Interesting. I love the idea of generating documentation from code - it does a lot of things right: Single source of truth (right now we have 3), easier to update when changing code as it's right there. But I'm not sure everything fits in there. Where do you document processes like how to test stuff that isn't possible to test in a local-dev environment? Or .. what the IDs that have some business meaning, mean.

> But I'm not sure everything fits in there. Where do you document processes like how to test stuff that isn't possible to test in a local-dev environment?

I feel like that would go into the README or an attached wiki page.

It is funny, after writing my MILLIONTH validation library, I've been thinking OpenAPI or APIBlueprint driving my validation and parsing library at my web application boundaries is the way to go... which is kind of the opposite. Documentation driving my software xD

Re: Things I Learnt from a Senior Software Engineer

#26

Post by neilkakkar »

grogenaut wrote: post #23
teddyh wrote: post #21

> Naming your clusters? Naming them after the service that runs on them is great, till the point you start running something else on them too. We ended up naming them with our team name. This is covered by RFC 1178¹, Choosing a Name for Your Computer (from 1990): Don't choose a name after a project unique to that machine. A manufacturing project had named a machine "shop" since it was going to be used to control a nu…

I find that team names change more frequently than responsibility in a large org. Also using a team name makes people assume ownership of decisions with that team. That's why I prefer service name. However I haven't thought much about shared use clusters.

We've had the same name for the past 7 years, so going by the future estimates with no extra useful information, I expect us to have the same team name for 7 more years :P

Re: Things I Learnt from a Senior Software Engineer

#27

Post by neilkakkar »

teddyh wrote: post #21

> Naming your clusters? Naming them after the service that runs on them is great, till the point you start running something else on them too. We ended up naming them with our team name. This is covered by RFC 1178¹, Choosing a Name for Your Computer (from 1990): Don't choose a name after a project unique to that machine. A manufacturing project had named a machine "shop" since it was going to be used to control a nu…

Haha, I had no idea. Thank you!

Re: Things I Learnt from a Senior Software Engineer

#28

Post by heinrichhartman »

> When refactoring and preventing huge-ass PRs: “If I’d have changed all the tests first then I would have seen I had 52 files to change and that was obviously gonna be too big but I was messing with the code first and not the tests.” Is breaking it up worth it?

My 2 cents: There are two things to consider:

1. reviewability

2. deployment risk

If it takes a colleague 3 days to review your code, your PR is too big. If you panic, on the thought of deploying this ever, your PR is too big.

On the other side:

- Huge PRs that only change formatting are fine. Easy review. Low risk if properly automated/tested.

- Largs PRs that are feature neutral are acceptable as long as they are reviewable.

- PRs that refactor 2000LOC, fix 2 bugs and add 3 features are not a good idea.

Re: Things I Learnt from a Senior Software Engineer

#29

Post by honkycat »

heinrichhartman wrote: post #24
honkycat wrote: post #12

Just to toss in my two cents about testing: Unit tests are for refactoring and declaring behaviour. Additionally, a lot of people have made the same observation: Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function, think about how you can change your design to make testing easier. It will probably improve your code quality. Integration tests a…

I have heard this so many times: > Comments: I find comments, outside of docstrings, a smell. But is this really the case? I find comments like these invaluable: /* * Mark walreceiver as running in shared memory. * * Do this as early as possible, so that if we fail later on, we'll set * state to STOPPED. If we die before this, the startup process will keep * waiting for us to start up, until it times out. */ SpinLock…

This is EXACTLY where comments should be used, great example!

Extremely high-performance database code is not what most of us are doing, however. We are doing enterprise software development to send emails and scrape money out of people.

I would want that function to be multiple smaller functions with docstrings and such, but obviously, that would add stackframes to the call stack and be slower.

Additionally, many modern compilers have an easier time reasoning about and optimizing multiple smaller functions as opposed to huge functions with a ton of variables and logic. Plus large functions have an impact on garbage collection etc. etc.

Re: Things I Learnt from a Senior Software Engineer

#30

Post by stefs »

teddyh wrote: post #21

> Naming your clusters? Naming them after the service that runs on them is great, till the point you start running something else on them too. We ended up naming them with our team name. This is covered by RFC 1178¹, Choosing a Name for Your Computer (from 1990): Don't choose a name after a project unique to that machine. A manufacturing project had named a machine "shop" since it was going to be used to control a nu…

in my home network i name my computers after animals, whereby the power/size of the computer roughly resembles the size of the animal.

my beefy desktop may be the whale, the nas is the rhino, the notebooks are roughly dogs, the raspberry pis are small animals like mice, the chromecast is e coli.

plus good: i'm never going to run out of animal names.

Post reply on HN