A Guide to Being A Lazy Dev (By Using Scripts)

I'm a lazy dev -- and I like it.

Don't misunderstand me: I never said I wasn’t productive. In fact, I am -- very. Let me explain myself.

I hate doing repetitive tasks on a daily basis. I'm always looking for challenges; something that gets my brain going and brings out my best by forcing me to figure out creative solutions.

That's why I pushed myself through by automating repetitive tasks with scripts.

Scripts have helped me perform repetitive tasks and even increase my productivity, since I don't have to worry about spending a lot of time doing the same old thing, and instead can focus on what's worth my time (and brainpower).

It might be tough at the beginning, but if you want to become a lazy dev like me, let me give you some tips to keep in mind whenever you're writing a new script.

My Top 4 Tips For Writing Scripts

1. Use a common scripting language that your team knows well.

I prefer writing my scripts using bash. It's simple, easy to learn, and comes with all Unix based systems. Javascript can also be an option if your team is used to it.

(Personally, I've written most of my scripts in bash and a few others in python, when I’m feeling crazy.)

2. Keep your scripts short and clean

Please don't try to write a script to make everything; it's better to have several short, maintainable, and well-documented scripts than a big bunch of code that’s trying to control the world!

But, if that's what you want...consider writing a complete CLI program instead. (Though I wouldn't recommend it.)

3. Patterns make life easy

As a rule of thumb, try to keep patterns in your scripts. That will make it easy not only for you to start creating a new script, but also for your teammates to understand how the scripts work.

The pattern I like to follow is flag parameters -- when you pass them to the script as flags. This way, for example, if you want to pass an external file path you add a flag like -f (or --file if you prefer the full flag).

4. Document your scripts

The best way to document your scripts is a self-explained code but we usually just need a quick documentation of how to use it without need to check out the code. That's why I'd recommend you to always adda help -h|--help command.

Templates for the Lazy Devs!

Here are some templates you can use to start creating your scripts. Believe me when I say: these have helped me so much, both improving my performance and accelerating several tasks related to the projects I've worked on.

And on top of that, it makes my clients happy when I build tools to increase the development pace -- and it makes me happy to reduce the need to create and re-create those stressful repetitive tasks we've all grown tired of creating!

For those who reach the end I'll give you some templates you could use to start creating your scripts, and believe me this has helped me so much, improving my performance and accelerating several tasks in the projects I've worked on.

And for sure it makes my clients happier when I build tools to increase the development pace of those stressful repetitive tasks we've gone through.

Bash Template

#!/usr/bin/env bash -e

PARAMS=""

COMMANDS_FLAGS="
Help:
    In order to pass arguments use '--' after the command like: npm run script-name -- -f

  -f|--file:                    Pass file path
  -o|--output-file:             Sets the output file’s name
  -h|--help:                    Lists help options
"

# VARS
FILE=""

while (( "$#" )); do
  case "$1" in
    -f|--file)
      FILE=$2
      shift
      ;;
    -h|--help)
        echo "$COMMANDS_FLAGS"
        exit 0
      ;;
    -*|--*=) # unsupported flags
      echo "Error: Unsupported flag $1" >&2
      exit 1
      ;;
    *) # preserve positional arguments
      PARAMS="$PARAMS $1"
      shift
      ;;
  esac
done

# set positional arguments in their proper place
eval set -- "$PARAMS"

# execute your script
echo "Running script..."

if [ "$FILE" = "" ]; then
    echo "File not found."
else
    cat $FILE
fi

Explanation of the Template

Alright let's split the code: first we will need a variable to store the positional parameters $PARAMS, those are the ones its order is important.

COMMANDS_FLAGS is basically the documentation we're going to display when the --help flag is passed or if the passed params don’t supply the minimum requirement.

Always supply short and full flags in your scripts; believe me: users are going to love it.

Then, you'll want to define all the default values for the vars you're using, because next is where the magic happens. Here, we're parsing our flags and storing the right values in our variables depending on what needs to be done. You can add as many flags as you wish.

Just add a new case like this:

    -f|--flag)
      FILE=$2
      shift
      ;;

Remember the flag's value for non-boolean flags is going to be stored in $2 var.

And don't forget the last two conditions:

• -*|--*=) is meant to throw an error when a flag is not valid.
• *) is meant to concat the positional params.

while (( "$#" )); do
  case "$1" in
    -f|--file)
      FILE=$2
      shift
      ;;
    -h|--help)
        echo "$COMMANDS_FLAGS"
        exit 0
      ;;
    -*|--*=) # unsupported flags
      echo "Error: Unsupported flag $1" >&2
      exit 1
      ;;
    *) # preserve positional arguments
      PARAMS="$PARAMS $1"
      shift
      ;;
  esac
done

Also, after parsing your flags remember, to put back the positional params with: eval set -- "$PARAMS"

And that's it! Now you can start running your script based on the conditions set by the flags the user passes, or throw an error if the user passes exclusive flags; after that, it depends on how you define your script.

Bonus! (For the Laziest Devs Only)

If you'd like to add more life to your scripts -- like showing an error message in red or a piece of advice in yellow -- I suggest you to define your colors like this:

red=$'e[1;31m'
green=$'e[1;32m'
yellow=$'e[1;33m'
blue=$'e[1;34m'
magenta=$'e[1;35m'
cyan=$'e[1;36m'
purple=$'e[1;34m%-6se[m'
end=$'e[0m'

The end var is to define where to stop painting your text, and it's used like this:

printf '%s
' "${red}Error! There's nothing to be updated!.${end}"

And if that's not enough for you, you can also create helper functions to help you build better scripts, or even add some enhancements to your script like the power of logging the batch of commands to be run in case your script performs a sequence of commands.

That way, the user will be able to see what’s about to be executed before running the script. I've made that abstraction for you here; don't worry, I know you’re lazy -- just use it:

run_command() {
  if [ "$TEST_OUTPUT" = true ]; then
    echo "|$ $@"
  else
    printf "%s
" "${blue}running -> $ $@${end}"
    eval "$@"
  fi
}

This function, as you can read in the code, requires a variable called TEST_OUTPUT, so you can define the flag whatever you wish. I've done it here with the capital letter T -T|--test

If true, then echo the command will be run; if not, print the command and also execute it.

A simple use example would be if your script wants to run git status then check if there's any change which you'd run with the helper function: run_command "git status"


Get Lazy!

Well, that’s it, friends! Hope this could help you improve your productivity and find your way to being a truly lazy developer. If you follow these tips, my advice, and play with my templates, once you identify a task that can be automated by a script, you’ll be able to without much effort. And when you do, don't hesitate to get it written. Your team, your clients, and your lazy nature will thank you later!

--

If you want to stay up to date with all the new content we publish on our blog, share your email and hit the subscribe button.

Also, feel free to browse through the other sections of the blog where you can find many other amazing articles on: Programming, IT, Outsourcing, and even Management.