281–290 of 301 posts
Earlier quoted context omitted.
I very much believe in offensive passwords/passphrases (maybe not for wireless routers) specifically because: (a) You're not supposed to tell anybody what they are. (b) Offensive passphrases are easier to remember.
Also easier to crack if an attacker knows that detail.
Earlier quoted context omitted.
The first thing you should do is question why you're SSHing into a production server in 2019. But after that, usually you can do it by IP address or instance ID.
OP never mentioned it was a production server. Also, sometimes, things get stuck, or you haven’t set up a pipeline to gather X data but y has happened, or there’s a deadlock in your source control host, or you’ve accidentally deleted the backup and the live service is the only copy of the data... all awful reasons and yet I’m sure they happen every day to people.
> 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…
For some reason nobody liked my norse pantheon names. Teaching people to spell yggdrasil correctly in order to get a database connection is fun. For some values of fun.
Earlier quoted context omitted.
I have an admittedly crazy thing I do occasionally. I do 5 minute pomodoros. So it's 5 minutes of writing code followed by 1 minute of reflection. In that one minute, I'll write down what I did in the last 5 minutes (it takes about 10 seconds to write since it isn't much ;-). I'll also add a few TODOs that I'm hoping to do, or break down ones I've already got. Now, 5 minutes seems an impossibly small amount of time,…
If you're 2 or 3 times as productive for a couple of days then you can easily afford to take a day off. How much downtime do you need before you're able to repeat the pattern?
Earlier quoted context omitted.
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.
We do have a constants file which has all the messages but a PM does not access to code/commit and has to go via a Dev.
> 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…
> Good engineers themselves design systems that are more robust and easier to understand by others. This has a multiplier effect, letting their colleagues build upon their work much more quickly and reliably - How to Build Good Software The advice above is probably one of the things which would have the most impact across all your activities as a developer. When people talk about simplicity in software, they don’t ne…
by far. What's missing is:
> easier to understand by others.
And by yourself, 6 months later.
Anytime a "senior" dev complains to me about "junior" devs, I tell them to review their own code from 6 months ago.
> 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.)
We have one in our company named right now named Harbinger, neat name... but wtf is it? Boring names are boring, but they tell other people, and future you, what they are or do.
Earlier quoted context omitted.
I don't. I could never really pair programming, even in school. Interestingly, I can share my screen with people that have different tasks than mine. I just can't make it work when both people have the same state of mind.
pair programming is really a forced socializing in a field where a lot of people have trouble socializing, never really understood how it got as far as it did.
Bad definition (the one I encountered in school): two people of about the same skill level sitting at one computer and programming together. I hated it, akin to my hate of backseat drivers.
Good definition (the one I encountered at my workplace): as a junior engineer, I was tasked with implementing this tricky caching thing in one of our systems that I had zero previous experience with. One of our senior engineers was tasked with helping me with that. I would implement as much as I could myself, and when I get stuck, the senior would either give me hints on how to get unstuck or program some parts himself while explaining to me how and why he did things a certain way. This helped me out tremendously in my skill development and got me running confidently in our codebase really quickly.