It’s a familiar situation at work where code ‘works on my machine’… but when another developer… or a staging deploy.. or a production deploy happens, it doesn’t work on that machine. There are many practices to address this – virtual machines, docker, automated tests, etc, etc.
There is a similar situation in learning new technology skills: The same “I did it once, on my machine and it worked, but when I tried later to do it, it didn’t work. I don’t remember exactly how I did it before and this time I encounter unexpected problems I didn’t experience before.
This leads to a number of issues:
- I typed something once. I’m unlike to remember that in a week
- At some point I’ll try and use a different machine
- Dependency hell – stuff seems to be ok but then on machine X it isn’t
- I didn’t encounter any problems so didn’t learn how to get around them
To address this, I use a practice of switching machines 2-3 times a day.
This approach developed naturally over time to match my daily schedule, i.e. by working from home on a desktop, working from a cafe on a laptop and then working from home on the desktop again. As with other coding activities I am addressing the pain point by doing the activity more often, not less. This invokes the lazy programmer in me that will then address ephemeral issues such as local setup and get the experience I need to be able to walk into other situations and make progress having encountered and conquered many different setup issues while learning. It also ups the amount of source code management that I do through git which is always good practice. I recently stopping coding within a Dropbox directory ‘cos I need to exclude
node_modules/and dropbox doesn’t allow that (you’d have to selective sync for every node projects
node/modules directory which is waaaay too much config management for me.