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

181–190 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

#181

Post by seren »

tehlike wrote: post #110
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.

You are thinking just the running system. The decisions behind why, the quirks of the software, how that all fits together, and the knowledge of why you should do certain things (like monitoring, experiments and whatnot) is important. Good luck documenting all that. Good luck making that document discoverable and readable.

Often you can deduce the "why" from the code because it makes some sense, but you can almost never find out is the "why not" .

Have they tried something else ? Was it the best solution chosen after a review or something quickly put together ? Likely you'll never know.

Re: Things I Learnt from a Senior Software Engineer

#182

Post by dagw »

bryanrasmussen wrote: post #153
Spooky23 wrote: post #33

Earlier quoted context omitted.

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…

I'm in Denmark, it has been my experience that the most common naming scheme (I would say omnipresent naming scheme almost) is to use the old Norse Pantheon for names.

Same experience in Norway and Sweden. Followed very closely by sci-fi/fantasy characters or authors.

Re: Things I Learnt from a Senior Software Engineer

#183

Post by gilesgate »

bryanrasmussen wrote: post #153
Spooky23 wrote: post #33

Earlier quoted context omitted.

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…

I'm in Denmark, it has been my experience that the most common naming scheme (I would say omnipresent naming scheme almost) is to use the old Norse Pantheon for names.

Similar in Greek academic networks, adapting to local mythology. The amount of routers and mail servers named 'Hermes' was ridiculous.

Different experience in English academia, where I encountered random names (e.g. 'mira' for a shell server and 'laplace' for a Physics Dept server). The acronyms could at times be interesting. Particular favourite was a 'central university network time' server. That was later renamed to ntp.*.ac.uk, after stern recommendations.

Re: Things I Learnt from a Senior Software Engineer

#184

Post by dotancohen »

afarrell wrote: post #169
rakamotog wrote: post #144

Earlier quoted context omitted.

The only time I (a PM) would do this is when you are working on validation messages / error messages / user facing text.

Error message phrasing is really very important, but it’s probably better to have that refined in code review or to have some explicit step for it.

Error message phrasing should not be in code. It should be in localization files, even for the default language, and not require a developer to modify.

Re: Things I Learnt from a Senior Software Engineer

#185

Post by dotancohen »

mikekchar wrote: post #114
ken wrote: 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.

You likely already have one.

The upper bezel of your monitor is likely shiny black. It makes a great mirror to know when someone behind you is taking interest in you. It is also completely inconspicuous and you do not need to move your head from your monitor to use it.

Re: Things I Learnt from a Senior Software Engineer

#186

Post by dotancohen »

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…

  > Nobody expects to learn much about a person by their name.
This is wrong. If I tell you that I just hired a mathematician, a farmhand, and a nurse, you could probably guess which person was which when I introduce you to Vladimir, Jebbediah, and Sofia.

Names are a reflection of culture, and certain cultures tend towards certain professions. No politically-correct dreams will change that unless we instill a universal monoculture throughout the world. I'm sure that Disney and Coca Cola would love that, but most people would probably prefer to protect their heritage and culture.

Re: Things I Learnt from a Senior Software Engineer

#187

Post by dotancohen »

Rediscover wrote: post #163
yen223 wrote: post #117

Earlier quoted context omitted.

ISO stands for the International Organization for Standardization, for largely the same reasons.

Maybe I got the wrong person (on the phone), but it was explained to me the name "ISO" was the Greek word for "sameness" and that Français and English just happened to form /meaningful/ representations for an acronym.

The Greek ισο "iso" does mean "equal". I do not know if that influenced the naming of the organization, though.

You see this word in many English roots, such as isotropic, isometric, isomer, etc.

Re: Things I Learnt from a Senior Software Engineer

#188

Post by dotancohen »

bitwize wrote: post #108
philwelch wrote: post #52

Earlier quoted context omitted.

If you designate your servers with numbers or meaningless identifiers instead of names, you also won't ever feel guilty about killing and replacing them. I believe this is (somewhat gruesomely) called the "pets vs. livestock" approach.

Every time someone trots out that old analogy, I think of my uncle who has a small dairy farm in the U.S. midwest with over 50 head of cattle. He gave each one a name, and when one is sick, he cares for it until it is better if possible.

I know of a man with over 50 children. I'm friendly with his neighbour, who has almost 40. 50 is a number that a human can still care for and love each one individually.

NB: Yes, I know that the Wikipedia list of "people with many children" makes 50 look like a record-breaking number. That list is Western-centric. Though 50 is a huge number of children even by Arab standards, it is not unheard of.

Re: Things I Learnt from a Senior Software Engineer

#189

Post by arkh »

rbavocadotree wrote: post #97
OJFord wrote: 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.

That's where pair programming can shine: when I see a junior who need help, I'll ask if they don't mind me coming around and helping. Just asking the right questions and guiding them to find a solution to their problem usually do the trick. And it helps me see the pain points of our code, documentation and specs.

Re: Things I Learnt from a Senior Software Engineer

#190

Post by heinrichhartman »

heinrichhartman wrote: post #35
honkycat wrote: post #29

Earlier quoted context omitted.

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…

> I would want that function to be multiple smaller functions with docstrings and such [...]

I have tried that style in the past, and have reverted to writing longer functions with intermittent comments. I now consider "single caller functions" a smell.

If logic is serial (do A, then B, then C) it's fine to have serial code:

   main() {
     ... A ...

     ... B ...

     ... C ...
   }
The issue with splitting out the intermediate steps into functions is, that the serial flow is broken. Instead of the logic now looks something like

    A(...){ ... }
    C(...){ ... }
    main() { 
       A(...)
       ... B ...
       C(...)
    }
Where B might have been a tiny task, that is not worth splitting out. In effect:

- The ordering of the logic is broken.

- Passing arguments can be a pain, if a lot of pieces are touched.

And what have you gained? Not sure there are many upsides besides debatable aesthetics of avoiding inline code comments.

Post reply on HN