71–80 of 301 posts
> 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.)
I for one appreciate good humour in a codebase.
Earlier quoted context omitted.
I think it's okay to be funny in test cases. For instance, my test data has included the user-agent string, "The Thrilla In Mozilla".
As long as you don't go into potentially offensive humor
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.
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 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.)
I enjoy seeing a bit like of humor in the code, especially silly-but-clear comments and names less important parts of code. For a one shot task, why name it ScheduledObjectStorageDownloader when you can name it AutoCloudStorageFileYoinker?!
> 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…
The thing is: 1. Some people balk at you making lots of small PRs, because it feels like noise to them. 2. Some people/organizations make you do a lot of work on a separate branch and then want you to PR just once for the final feature you're implementing.
2. That's fine, your branch has the series of small PRs that people can review.
> 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.)
I enjoy seeing a bit like of humor in the code, especially silly-but-clear comments and names less important parts of code. For a one shot task, why name it ScheduledObjectStorageDownloader when you can name it AutoCloudStorageFileYoinker?!
> 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…
Pets Service Model
In the pets service model, each pet server is given a loving names like zeus, ares, hades, poseidon, and athena. They are “unique, lovingly hand-raised, and cared for, and when they get sick, you nurse them back to health”. You scale these up by making them bigger, and when they are unavailable, everyone notices.
Examples of pet servers include mainframes, solitary servers, load balancers and firewalls, database systems, and so on. Cattle Service Model
In the cattle service model, the servers are given identification numbers like web-01, web-02, web-03, web-04, and web-05, much the same way cattle are given numbers tagged to their ear. Each server is “almost identical to each other” and “when one gets sick, you replace it with another one”. You scale these by creating more of them, and when one is unavailable, no one notices.
Examples of cattle servers include web server arrays, no-sql clusters, queuing cluster, search cluster, caching reverse proxy cluster, multi-master datastores like Cassandra, big-data cluster solutions, and so on.
[1] https://medium.com/@Joachim8675309/devops-concepts-pets-vs-c...
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.…
And what does one do when one is struggling with burnout/depression/insomnia and the only legitimate thing to write down is "Not a whole lot really." for days in a row? (A problem a um, ... friend has, of course.) Risky habit to have under those circumstances.
I believe everyone has times of marginal productivity in their lives, maybe some more than others. But if you can average out ahead of the curve, what does it matter? Showing the fact that you've had a slow week but finished the month on a high note seems like a great capability.
And if an employer doesn't recognize this and can't measure your net output, then hopefully another employer can.