2 minutes
The good kind of laziness
Imagine a scenario - a developer is working on some bash
script that is supposed to run on a remote test server.
This remote server doesn’t have a GUI, it doesn’t have copilot and doesn’t have our favorite IDE that makes our life sufferable.
So what does this lazy developer do?
He creates the script on his local IDE, CTRL-C
the code and CTRL-V
into the remote machine - thinking this is a small script that will be ready in no time.
Like usual, estimations are hard. Our developer is not special, and of course, multiple attempts are needed to get the desired result, sometimes dozens of attempts or more.
So each time this lazy developer copies, pastes the code and hopes that this time will be the last one.
This might be a simple task - copy and paste - but don’t underestimate it. This brings needless friction and another pain point to your constantly failing script.
You should always think - especially as a younger developer who is less experienced, how can I make my workflow easier, how can I be lazier? How can I [[Fail fast and fail hard]]?
There are multiple solutions to make this workflow more efficient, depending on the tasks and other factors.
- One solution might be to create a small script on the developer machine (which has the IDE) that will copy the developing script over to the remote test machine and execute it - all automatically. Meaning the developer will write code, and with 1 click run this script that will copy-paste-run and the developer will see the results as fast as possible.
- Another possible solution will be to install an IDE on the remote test machine or even work using
nano
orvim
. This should only be considered in very rare cases as it might lead to lost code that is not checked out to a SCM (Github/Bitbucket/etc). - If the development task is complicated and also has dependencies or a build stage (for example, building multiple Docker containers, removing the old ones, etc..), it is probably worth developing some pipeline such as GitHub Actions, Jenkins, or a bash script.