opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues 1 Pull requests Projects 1 Releases Packages Wiki Activity Actions

Use environment-specific URLs instead of

Browse source 
...hard-coded ones
This commit is contained in:
Oliver Davies 2024-09-03 00:34:58 +01:00
parent 6ca5704c21
commit 1b05e63a20
76 changed files with 91 additions and 91 deletions
Download patch file Download diff file Expand all files Collapse all files

4
source/_daily_emails/2022-12-02.md
View file

@ -12,13 +12,13 @@ It doesn't need to be a whole feature. It could be a new class with its passing
It could be a small refactor - renaming a variable or class name that makes some code easier to read or removing some commented-out code that isn't doing anything other than adding visual clutter.
It could be updating some documentation or [writing a technical document](https://www.oliverdavies.uk/archive/2022/09/23/adrs-technical-design-documents); if you keep those in your version control repository, that would help you implement the following change or to make the documentation clearer for the next reader - whether that's you or someone else.
It could be updating some documentation or [writing a technical document]({{site.url}}/archive/2022/09/23/adrs-technical-design-documents); if you keep those in your version control repository, that would help you implement the following change or to make the documentation clearer for the next reader - whether that's you or someone else.
Committing something at least once a day creates a different mindset to "I'll write everything and push it when it's done".
It makes you break up large tasks into multiple smaller ones and set mini-deadlines for yourself. I used to do the same when I commuted to work on a train and had a task for a freelance project to complete before I arrived. I used to think, "What can I start, finish and commit before I get there?" instead of leaving something incomplete.
You don't need to push your change to mainline. If you use the ["Ship, Show, Ask" approach](https://www.oliverdavies.uk/archive/2022/11/30/ship-show-or-ask) then you could commit to a temporary branch that you either merge yourself once you know it passes the checks, or to show or get feedback from other team members.
You don't need to push your change to mainline. If you use the ["Ship, Show, Ask" approach]({{site.url}}/archive/2022/11/30/ship-show-or-ask) then you could commit to a temporary branch that you either merge yourself once you know it passes the checks, or to show or get feedback from other team members.
Practicing this becomes a habit, and if you're doing test-driven development and committing after every passing test or refactor, you'll find yourself pushing numerous changes a day.