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

31–40 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

#31

Post by paulsutter »

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…

Like the inevitable branch names. Main, Borg, Borgmain, etc... Or the purposes of the standard unix directories (lib, usr, opt, etc, ...)

Re: Things I Learnt from a Senior Software Engineer

#32

Post by teddyh »

stefs wrote: post #30
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.

Yes, this is more or less what RFC 1178 recommends:

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

Re: Things I Learnt from a Senior Software Engineer

#33

Post by Spooky23 »

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…

Naming standards are the ultimate bikeshedding event. Everyone has an opinion and camps develop for various schemes.

The last time this happened, I happened to be in a position of influence for the final decision for naming standards. We took an approach designed to piss off everyone... license plates. We used sequential numbers prepended by a pronounceable string, and random words, selected by a system, for internal services.

Overall, everyone is pretty happy with it. YMMV.

Re: Things I Learnt from a Senior Software Engineer

#34

Post by zrail »

stefs wrote: post #30
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.

I use Simpson’s bit characters. Never gonna run out of those.

Re: Things I Learnt from a Senior Software Engineer

#35

Post by heinrichhartman »

honkycat wrote: post #29
heinrichhartman wrote: post #24

Earlier quoted context omitted.

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 mo…

> Extremely high-performance database code is not what most of us are doing, however.

That's true. But look at the overall coding style in that file:

Code is structured into cohesive blocks, which are prefixed by a comment which explains in english language the intention, pitfalls, limitations of the following code.

I find this quite elegant and readable. An ideal to aspire to.

I am not advocating nonsensical JavaDoc:

    // Get's foo from bar
    private Foo get_foo(Bar bar);
If you are able to just use names and types to document your intentions, pitfalls etc ... then by all means, do just this. E.g.

     for( person in address_book ) {
          body = template.render( name => person.name, ... )
          mail = Mail.new(person.email, body)
          mailgun.queue(mail)
     }
However, if stuff get's more nuanced don't be afraid to use english language to explain what you are doing. You future self will thank you : )

Re: Things I Learnt from a Senior Software Engineer

#36

Post by jquery »

zrail wrote: post #34
stefs wrote: post #30

Earlier quoted context omitted.

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.

I use Simpson’s bit characters. Never gonna run out of those.

I use One Piece characters for the same reason. My most beefy PC is Monkey D. Luffy and so on. Like you, I like the whimsy in using names from a fictional world, and some worlds have more names to choose from than others.

Re: Things I Learnt from a Senior Software Engineer

#37

Post by contingencies »

The main value in software is not the code produced, but the knowledge accumulated by the people who produced it

Don't agree with this at all. If you're relying on people to maintain knowledge then you're doing it wrong and setting yourself up for failure. Document the why.

Re: Things I Learnt from a Senior Software Engineer

#38

Post by sergiotapia »

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.

We all "zed shaw" every once in a while

Re: Things I Learnt from a Senior Software Engineer

#39

Post by atoav »

contingencies wrote: post #37

The main value in software is not the code produced, but the knowledge accumulated by the people who produced it Don't agree with this at all. If you're relying on people to maintain knowledge then you're doing it wrong and setting yourself up for failure. Document the why.

accumulated doesn’t allow any qualitative judgement about the way they treat that knowledge. So we shouldn’t assume the worst.

I suggest the opposite: if they take their own words seriously and this knowledge is the main value than I’d assume they grow in great lenghts documenting that main value — because it would be (as you rightly noticed) lost.

Re: Things I Learnt from a Senior Software Engineer

#40

Post by yitchelle »

mtlynch wrote: post #10
Everlag wrote: post #4

The referenced idea of a 'human log' is great[0]. I started doing something similar 4 years ago and it eventually evolved from per-project notes into a full diary. Being able to search for 'August 24 2016' and know exactly what I did that day is quite powerful. I encourage anyone to take 10 minutes(or 30...) at the end of the day to write up what they've done. Just a text file with minimal formatting has scaled to 2.…

I do this on a weekly basis. I used to just do it in a Google Doc, but earlier this year, I wrote an app so I could share my log entries publicly. I've been publishing my weeks since March: https://whatgotdone.com/michael I tried for a few months to make a business out of it, but there wasn't much interest, so I'm planning to open source the code in the next couple weeks. A bit more about my motivation in creating th…

This is really good. It reminds me of a bullet journal. Well done!
Post reply on HN