Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
They don't understand that if they write good code covered with meaningful tests they don't do a favor to their employer. They do a favor for themselves. They learn, they practice how to craft good code. The become more employable.
This is what I tell all the time to some colleagues, that complain all the time because their job is boring, because the mostly copy-paste similar code from other parts of the application or add chunks of logic to other methods. You have to find joy in what you do. And one way is to care and take ownership.
Empower yourself. Not wait for anybody else doing it for you.
Absolutely love this article. could not agree more. Even though speaking of Refactoring might be a bit dangerous or misleading. I often met some of those bored employees embark in major refactorings that took ages and were not necessary at all.
But I am pretty sure with Refactoring in a pull request you mean small things, details that just improve the code you found or were working on.
The boy scout rule is a must for me (it could be fixing a typo, split a long method into smaller readables and unit testable ones etc) and adding a small unit test on everything I touch when bug fixing is another one.
Something else i dont understand when people say they are not allowed writing better code or unit test is, you estimated the feature, or you agreed with it. If reasonable code quality and unit test are not part of the estimated time for a feature, well probably you have to re-discuss your team´s "Definition of Done".
Indeed, I barely advocate for rewrite-refactorings. It's more the boy scout rule, just to clean up that area of code, that class if it's not too big.
The question of Definition of Done is really important. It's not enough to have it, but people should respect it. That's something I don't see every time. It becomes problematic when multiple teams are working on the same codebase, but not all the teams obey to the same rules...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is what I tell all the time to some colleagues, that complain all the time because their job is boring, because the mostly copy-paste similar code from other parts of the application or add chunks of logic to other methods.
You have to find joy in what you do. And one way is to care and take ownership.
Empower yourself. Not wait for anybody else doing it for you.
Absolutely love this article. could not agree more. Even though speaking of Refactoring might be a bit dangerous or misleading. I often met some of those bored employees embark in major refactorings that took ages and were not necessary at all.
But I am pretty sure with Refactoring in a pull request you mean small things, details that just improve the code you found or were working on.
The boy scout rule is a must for me (it could be fixing a typo, split a long method into smaller readables and unit testable ones etc) and adding a small unit test on everything I touch when bug fixing is another one.
Something else i dont understand when people say they are not allowed writing better code or unit test is, you estimated the feature, or you agreed with it. If reasonable code quality and unit test are not part of the estimated time for a feature, well probably you have to re-discuss your team´s "Definition of Done".
Thanks for your kind words, Davide!
Indeed, I barely advocate for rewrite-refactorings. It's more the boy scout rule, just to clean up that area of code, that class if it's not too big.
The question of Definition of Done is really important. It's not enough to have it, but people should respect it. That's something I don't see every time. It becomes problematic when multiple teams are working on the same codebase, but not all the teams obey to the same rules...