51–60 of 301 posts
Earlier quoted context omitted.
.. Nopes, but it was the quickest reference I could find for the joke. I don't like to put quotes in without the source.
Hi Neil. The attribution is correctly given here: https://martinfowler.com/bliki/TwoHardThings.html (Hint... it's me.)
I've updated the website :)
> 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 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…
> 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 guess spelling wasn't one of them?
But other than that, it's a nice blog post. I like the "human log" suggestion - should really pick that one up. I've been doing that already, but only for my servers...
> Things I Learnt from a Senior Software Engineer I guess spelling wasn't one of them? But other than that, it's a nice blog post. I like the "human log" suggestion - should really pick that one up. I've been doing that already, but only for my servers...
> 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…
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.
> 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'm going to continue injecting some light humor into my code and it'll be fine (especially unit test code).
> 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.)
Just to toss in my two cents about testing: Unit tests are for refactoring and declaring behaviour. Additionally, a lot of people have made the same observation: Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function, think about how you can change your design to make testing easier. It will probably improve your code quality. Integration tests a…
Test as little as possible/responsible.
I think it was Kent Beck who first articulated that, though it was something many people converged on in the early 2000s in the XP world. Of course it doesn't mean test nothing, it's recognizing tests are liabilities (as all code is) and we need to make sure they are serving a purpose otherwise delete them / refactor them to get rid of duplication of testing and overly verbose long winded tests that keep repeating things over and over again and again, saying the same thing repeatedly, doubling up on testing :)