It's one of the rare fields where you get to be both creative and functional. Whatever you want to happen on the screen you can make it happen. You can really put yourself into whatever you are making. Maybe you can't do that and make a ton of money at work. Maybe you can't do that and release a product everyone will love. But you can do it. You can put power in people's hands. You can embed parts of yourself, your philosophy, your thoughts, your wishes, etc. into software and spread it all over the world very quickly. I like that about it

I know people have mixed feelings about Uncle Bob and I really never followed the guy at all, but back in college I found his book Clean Code on a shelf and read it cover to cover. A lot of it really stuck with me. In fact, I might dig it up again now that I'm thinking about it.

Favorite / most used systemd timers?

I recently wrote one to pull the location data of users for an app and make a heat map of sorts which updates every hour. Probably could make it run on a quicker timer but not many eyes on it at the moment.

All the stupid date functions where the days range from 1 to 31 but the months range from 0 to 11

I love the ansible documentation, so many examples which cover so many use cases and all the descriptions of all the possible arguments are very clear :)

React Native testing is hair pulling.

Every test needs to have 100 different mocks in place and there are: 3 different methods to mock a function (mock, mockImplementation, and fn), 3 different types of query methods to get elements (get, find, and query), and 5 different selectors to query on (accessibility label, testId, accessibility hint, accessibility value, etc.)

And after reading all this, being diligent and learning the difference between stupid, synonymously-named functions which have wildly different side effects like "getByA11yHint" and "findByA11yHint" (ugh...), after all that, you write out a test with all the appropriate mocks and you want to do something simple and it beats you up all over again.

Button enabled or button disabled. Simple right? Logically the former is "expect(elem).toBeEnabled()" and the latter is "expect(elem).not.toBeEnabled()", right?

Wrong! You're an imbecile. Your tests will fail and never tell you that ".not.toBeEnabled()" and ".toBeDisabled()" don't do the same thing even though they look and sound exactly the same. Only the latter will work. The former makes all your tests fail. Where is this written in the docs? Nowhere?! Great!

👌😄🔫

Love it when the maintainer of an open source project you contribute to runs a linter over the whole codebase and force pushes the changes to origin master so now all the Pull Requests in the queue have to be rewritten and have tons of merge conflicts to resolve. Awesome! 😠