loading...

The Art of Removing Obstacles

dannylee8 profile image Danny Lee ・6 min read

As much an art as it is a learned set of skills, the pursuit of being like Ganesha —the clearer of obstacles, is a valuable skillset for aspiring developers. Coding is hard. If it wasn’t everybody would be doing it. The demand for skilled coders, the high-paying salaries 💵 and most of all, the opportunity to have a stake in the next unicorn 🦄 make the idea of becoming a programmer very tempting to imagine, but actually following through can be more of an uphill climb 🏔 than people are willing to endure.

One skill that is incredible valuseful is obstaclearability— that is, being able to identify and clear obstacles. I believe it fits well into two of Larry Wall’s three virtues of a programmer.

The main impetus for learning how to identify and clear obstacles is not what you would expect…it’s laziness (𝕍irtue 1). What I’m talking about here is not lazy people who not want to do anything at all or get things done as quickly as possible, regardless of quality. What I’m talking about here is the sort of “balanced” laziness that haunts a person who knows that projects have to be completed on time, that quality matters and that a lot of energy is wasted doing repetitive, tedious tasks that could be done better. This kind of person wants to have less to do (lazy-time), but also wants everything to be completed at the same high level of quality and timeliness (smarts-time).

There is also a great deal of impatience (𝕍irtue 2) that leads to a righteous anger that builds up to the point that one must take action to identify and clear the obstacles holding you back. With every obstacle, no matter the size, there is a rabbit hole you have to dive down into, sometimes its shallow, sometimes its very deep, but to get to the next stage you need to remove that obstacle. Or perhaps, its a recurring obstacle or repetitive task, that consistently eats up your time and your brainpower in having to remember how to re-do something, or the idiosyncratic syntax that stumbles us all.

Whatever the impetus, the point is that there will always be more obstacles to identify and remove, tackling a problem today doesn’t mean tomorrow will be obstacle-free, it simply means there will be different obstacles. But, with an enthusiastic heart for service and a long-suffering gracefulness towards hardship and tedious labor, one can learn to enjoy being a clearer of obstacles. And who doesn’t love a clearer of obstacles?


I’m not qualified in any quantifiable way to explain how to identify and clear obstacles. I do know I have a passion for finding easier ways to do things, but at the same level of quality, as the original, longer way of doing things. If I can find a shortcut that lets me maintain the quality of my output, but reduces the amount of repetitive sequence of energy-wasting and brain-draining steps, I will INVEST the time to create a shortcut. Its not really much different than the idea of immediate gratification vs a longer-term greater reward (delayed gratification). Instead of wanting to get to work now, and feel that I am making progress on the immediate problem, I will set aside time to setup some framework or create some macros/scripts/automation to make future iterations of the same task slightly less cumbersome. And the hope is, over the long run, I will regain the time I am losing upfront, to create these things.


An Example: Building a Ruby on Rails backend with React Js Frontend.

T*he problem:* Create RoR API server for the backend and a React JS with create-react-app in the frontend. Put them in separate Github repositories. Repeat for each project.

So, I’ve currently reached mod(ule) 5 at the Flatiron School and I’ve been seeing a pattern of creating a Ruby on Rails API server backend and a React Javascript front end. And up to this point, I’ve been creating them as I needed them, but if this is going to be a recurring thing, why not setup a GitHub repository for each, get them to a base level of functionality and then leave them in that state for future projects. Of course, version changes for either, will render the original repositories outdated, but for the time being, all I have to do is git clone them, redirect them to a new origin/master and I’m set to build a new app.

T*he Solution:* Create and setup a backend and frontend, then just clone them and create new repositories for the projects.

Go to GitHub and create 2 new repositories, label one frontend, and label the other: backend.

  1. Backend setup: Copy your repo clone link, create a local backend directory, run the command below, add a CORS config, and git add/commit and push to the repo.

$ rails new backend --api -T --database=postgresql

3. The result looks like this: https://github.com/dannylee8/backend


  1. Frontend setup: Copy your repo clone link, create a local frontend directory, run:

$ npm install -g create-react-app$ create-react-app frontend

2. Then I changed the default PORT (3000) in package.json by changing:

“start”: “react-scripts start”,

to:

“start”: “PORT=3001 react-scripts start”,

3. Copied .gitignore for “Node” from https://github.com/github/gitignore

4. Then git add, commit and push.

5. The result is a Frontend: https://github.com/dannylee8/frontend


After this, all I have to do to setup a new project is:

  1. Create a pair of local directories.
  2. Create a pair of completely empty repos labeled project-frontend and project-backend. When you create these empty repos GitHub will show a list of commands you can use to copy a template-repo to your empty ones. Look for a set that says “…or push an existing repository from the command line
  3. Copy the Git clone links for the previously-setup backend and front ends, and clone them into your local directories.
  4. Redirect the remote origin from their original origins (the “template” repositories) to the new empty repos.
  5. You can use git remote -v to see where the remote links are set to.
  6. And git remote rm origin will remove the origin.
  7. The command to set your (local) cloned template repos to their new destination is something like:

git remote add origin git@github.com:/.git
git push -u origin master


Now, the question is, does this really save that much time? For me, it only saves me a couple of minutes, but once I get it scripted to build my empty repos and directories, something that took me 10–15 minutes will take 30 seconds. Step-by-step, clearing obstacles, automating repetitive tasks, making small gains and doing work daily on improving work flow pays dividends and is essential in any organization.

To read more on the idea of clearing obstacles to make way for others to be their very best, read Paul Lemley’s excellent article on the power of the humble clearers and path makers to enable others to reach the greatness they are destined to reach.

https://giphy.com/gifs/zwOgFlmzF98sM


[originally published 12/8/2019]

Posted on by:

dannylee8 profile

Danny Lee

@dannylee8

a nyc based programming enthusiast, who also loves handywork, propagating african violets, gardening, woodwork, welding, painting, and travelling to bali, to visit my future home.

Discussion

pic
Editor guide