101–110 of 301 posts
> 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…
We have a similar culture on my team. When I was a junior engineer, being able to poke my head into any open office that sounded like it had an interesting conversation going on was really an invaluable way of learning.
Earlier quoted context omitted.
Isn't Cloud-Computing something that should make it unnecessary to name individual computers?
How do you make a service call or ssh into a machine without a name?
Ideally, none of our servers are special.
> 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…
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.
Of course, the other thing you can do is name server roles rather than specific hardware, so all of your servers are immortal, Ship-of-Theseus style.
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…
That's sort of the point. Step 1, your code should be self explanatory. When the natural interpretation a reasonable person would have from reading the code differs from reality: that's when you add Step 2: add comments to "fix" the gap between perception and reality. The less Step 2 is necessary the better.
> 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…
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.
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.
Good luck documenting all that. Good luck making that document discoverable and readable.