dherikb
Fun fact: on the same day I noticed and stopped taking it coffee, 5 days later I had terrible muscle pain in my lower back (I could hardly sleep). 2 days later I had no more pain. I researched later and saw that this type of pain could also be caused as an effect of caffeine withdrawal.
Like anyone else, when I joined the company, I had various questions: how to access certain systems, how to handle permissions, how to debug specific services, etc.
I compiled all these questions and answers as notes in a Git repository that my teammates could access. I wrote the notes using QOwnNotes, utilizing its Git integration. So, when someone had a question for which I already had the answer, I could simply share my notes, or create/update a node and share it.
The names of the notes were straightforward and easy to follow, such as:
- aws.md
- azure.md
- kubernetes.md
- staging.md
- production.md
- useful-commands.md (jq, sed, base64, etc)
My teammates used this resource frequently. As I was preparing to leave the company, I suggested them to fork my notes repository. I later heard that they continued to use it for many months afterward.
After read about the poor scenario where the Linux accessibility tools is today (https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-d...), I was wondering: if maybe the developers start to use these accessibility tools to improve their speed reading (and productivity as well), this could also helps to prioritize the accessibility features and bug fixes in Gnome, KDE, Qt, etc.
Different from when I'm on my smartphone, I do not feel any anxiety to check social networks using my computer. So I can focus more on learning some stuff, coding, organizing my personal data, checking my appointments, checking the tech news, or even playing some games (to have some fun).
The model is good to solve problems, but is very difficult to control the unnecessary changes that the model does in the rest of the code. Also it adds a lot of unnecessary comments, even when I explicitly say to not add.
For now Deepseek R1 and V3 it's working better to me, producing more predictable results and capturing better my intentions (not tried Claude yet).
I really have some concerns about this kind of opinion.
I know that we can't follow this rule (or smell) every time, but I already see this affirmation being used by very poor or inexperienced programmers to justify understandable gigantic and hard to test pieces of code.
This is the type of advice that just experienced programmers can understand what this means and know when is applied.
Most part of the time, it's easier to fix a cod
For Java services using MySQL, I was able to use just the H2 database (in-memory) many times. Does a decent job and it's very compatible with MySQL. If you try to avoid specific features from the databases, this in-memory database can do a decent (and fast) job running integration tests.
- 7-8 hours of sleep;
- Try to go to the bed at the same time everyday (for me around 22:00);
- Go to the gym (weightlifting) 4 times a week;
- Not have dinner after 19:30;
- Not drink anything with caffeine;
Also if the team is mature enough, the PR can be reviewed after the merge, so the necessary changes can be made with the current code already integrated and already running in production. The downside for this is that the team needs to have some discipline to review the already merged PRs and the developers needs to be disciplined to organize your time to make the fixes after the PR merged.