Live data from Hacker News

Things I Learnt from a Senior Software Engineer

neilkakkar.com

131–140 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

#131
post #61

Earlier quoted context omitted.

As long as you don't go into potentially offensive humor

why not? best kind of humor

I do work for a golf travel company. In my test code I have the fictional golf resort, "Fine UK Up-scale Resort", due to the way we sometimes abbreviate names. I was doing a presentation to management the other day, and which test data decided to pop up on my screen? I laughed, anyway... I don't think some other people were please ;-) Especially as a contractor, making sure management is pleased with you is normally job one...

Re: Things I Learnt from a Senior Software Engineer

#132
post #99

Earlier quoted context omitted.

I've read that in feng shui what you describe is called the "command position". I'm not able to work with my back to a crowd. That's a recipe for anxiety. I quit a company when they moved my desk so my back was to a hallway, and refused to compromise on this issue in any way.

If it happens again, I've been told that having a mirror on your desk so that you can see what's going on behind you can help a lot.

Or if putting a mirror on your desk is the best resolution your employer can offer, run away screaming...

Re: Things I Learnt from a Senior Software Engineer

#133
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…

The only machine we have that's not named poorly, is named DP2950. It was originally a Dell PowerEdge 2950, and we probably had more than one back then, so maybe it wasn't a great name. Everything else is named based on it's purpose. www, webapps, data, acccounting, mail, things like that. But, mail is actually named mailV3 (it's the third hardware the mail server has been on). Why it wasn't just named mail, and if t…

> Why it wasn't just named mail, and if the old one was kept around, it could be mail-old, I don't know.

Probably because mail system hostnames end up hardcoded in configuration files all over the place, and it's easier to add one and mirror onto it than to migrate the hardware while keeping the name.

Re: Things I Learnt from a Senior Software Engineer

#134

Earlier quoted context omitted.

If it happens again, I've been told that having a mirror on your desk so that you can see what's going on behind you can help a lot.

Wouldn't that cause even more distraction as you see all the people walking behind you?

Apparently (it's not something I suffer from), people who prefer to be facing the aisle tend to glance out at people from time to time, which makes them feel at ease. Having the people at their back makes them uncomfortable because they can't keep tabs on it. For some people, this is apparently so bad that even if they are in an individual office they need to have a window, or keep the door open.

Re: Things I Learnt from a Senior Software Engineer

#135

> I like a bit of humour in my code, and I wanted to name it GodComponent. No. Just no. Do not ever be funny in code. No one else likes your humor, and it's distracting. (Ignoring the other reasons "GodComponent" is a bad name.)

Yeah, seriously. People use the "it was just a joke" argument for so many stupid things. Realize that there are people here whose sense of humor is very different from yours and this inside joke is likely going to cause confusion or conflict.

Re: Things I Learnt from a Senior Software Engineer

#137

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

There are certain ways to organize large PRs to make them easier to review and deploy. Some examples:

- if a large refactor moves code around in addition to changing logic, omit the pure moves from the diff and provide a list of files moved in a description

- if a large refactor involves a lot of renaming, or other mechanical manipulation, in addition to a little bit of logic changes, split those apart. That way there will be one large mechanical diff, where you can state in the description, "Yes I changed 500 files and there are 20 pages of diffs but the nature of changes is the same as in the first file." This is vastly easier to review for your peers.

- A useful safe deployment trick, when feasible: guard new functionality with a kill switch, as well as some kind of sampling gate (e.g. use new logic only where customer id % 31 == 0). Then when proved remove old code in a followup.

Re: Things I Learnt from a Senior Software Engineer

#138

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.

My take on this point (and something I agree with) is that you shouldn't get too attached to a particular implementation. It can be useful to build a prototype and throw it away, then use that knowledge to build a better version, than to try to keep building on top of the prototype.

There's nothing in their point that refers to documentation.

Re: Things I Learnt from a Senior Software Engineer

#139
post #63

Earlier quoted context omitted.

I am not understanding why the machine name could not be changed when it's purpose changed? Is an immutable name unique to that environment?

Because you'd probably also change the SMB or DNS name for the machine when you rename it, and that opens a can of worms where you try to work out what's using that reference and change everything that matters. Now renaming the machine is a multi-day thing involving configuration changes (and that assumes it's not hard coded anywhere) to a whole bunch of software; inevitably you'll miss some and it'll break. Easier n…

If something else is still referencing the old machine, it means you aren't changing its purpose but only adding to it. I would imagine a change of purpose would normally be a reprov.

Re: Things I Learnt from a Senior Software Engineer

#140
post #81

> in my team culture it’s not frowned upon to “snoop behind” people writing code. Whenever I sensed something interesting going on, I’d roll around and watch what was happening. Agh, I'd hate that. In fact if anything interesting had been going on on my screen it would immediately stop, no way I could work with someone watching. I struggle enough at desks with my back to a door or where people walk by, just can't sto…

It's also strange in that I don't think I'd get very much out of simply watching anyone work, unless they were also giving live commentary or something.

There was an article posted on HN a while back that claimed that the best way for beginners to learn a new skill is to watch an expert just work, without any commentary or explanation. I tried finding a link, but couldn't come up with working search terms on DDG, Goog, or HN.
Post reply on HN