Delivery vs Growth: which to choose and when

How to strike a balance between speed and personal growth

For the past two years, I’ve been working in a start-up in Singapore as a full stack developer, engaging in different projects and building different modules for my mobile application.

We adopt an Agile methodology when building Minimum Viable Products (MVPs) to test demand, engaging in practices such as Scrum and Kanban because project requirements are always changing, there are always new features to develop and new projects to take on.

And as the name Agile suggests, speed to market is undoubtedly a competitive advantage, especially in start-ups I believe because everything has to move really fast when resources are tight and limited.

However, as a developer, it is a never-ending process to learning because technologies change fast, and it is important to keep up with the latest tools, languages and frameworks.

This can be dangerous; this is the path to stagnation. It can get pretty comfy knowing just “Joker” and living with those three chords. This is the same as looking through stackoverflow.com posts and copying/pasting in a rush just to get your task at hand finished. Or using “xyz” plugin to fix a problem without understanding how it works — Extract from How and Why Developers must always Evolve

So when speed is essential, how does one manage between writing good code and speed? With the pressure to ship your products faster, how do you find the time to learn or grow as a developer?

Here are some lessons I have learnt from my experience on how to strike a balance between personal learning/growth and the pressure to deliver fast:

TL;DR, Delivering fast does not mean to stagnate, nor does it === crappy code.

1. “IDWID”

“It’s done when it’s done” as quoted by some scrum master in the galaxy far far away…

When I just started development, I used to give myself a short amount of time to code out features, but I realise this has not only resulted in bugs in the code since it was not tested properly but also a poorly thought out end product.

Developers should learn to push back. When a tight deadline is in place, it induces fear and creates distraction that will inhibit creativity/next-level thinking. Give yourself more time. It is OK to compromise speed to make way for time to think critically, time to question, time to generate ideas, time to plan and time to experiment and grow.

2. Reduce, reuse & recycle

Says the government… and the developer you’ve always looked up to. Build your own templates or components to be re-used in different projects. It speeds up things by a lot. By building one component really well and reusing it, there’s no need to compromise on code quality to achieve speed!

We’re not designing pages, we’re designing systems of components. — Stephen Hay

Atomic design is the concept of breaking entire interfaces into fundamental building blocks and working up from there. You can divide your projects into different components and reuse them, which can result in clearer and more consistent code as well. As the name suggests, the gist of atomic design is that all matter is made of atoms. Those atomic units can combine to form molecules, which ultimately form more complex organisms that result in all matter in our universe.

I used to spend a lot of time validating different ideas in the past and for each idea, I would spend 2–3 days creating a simple landing page from scratch. So one day I’ve decided to build a landing page starter template for my own (https://github.com/stacygohyunsi/landing-starter) and I can reuse it over and over again. Similarly, you can build your own mini components and reuse them in different projects.

Read more here: Why use atomic design?

3. Curiosity saves the cat

Be an avid explorer. Dabble in new technologies and experiment with new frameworks and tools. Don’t be overly attached to one framework/technology. Invest some of your time learning new frameworks and it can save you a whole lot of time later on.

Just a couple of years ago, Angular was the ‘hot’ framework to be in — it seemed to dominate any framework discussion related to JavaScript and was the topic that developers wanted to write about. When Angular 2 came out, it seemed drastically different from the familiar Angular 1 and a new architecture all together. This was when I started to pay more attention to ReactJS and invested a fair bit of time learning ReactJS + Redux, which is quite a mindset shift from Angular 1. Now, it has become my go-to framework and even if Google does not plan to continue to support Angular 1, I was still able to continue to develop projects without a delay in speed.

Now before you start going on about the criticisms on hype driven development and frown upon this article, let me add a disclaimer to say that I would recommend using new technologies/frameworks only for side projects. Once you’ve played with that technology enough and is sure of the pros and cons to it, then you can consider suggesting it to your team.

If you are a Javascript fan (just like I am), here are some of the JS frameworks I’ve explored from my personal projects that have helped me build and deliver products with speed:

NextJS

• An easy to use boilerplate template which saves a lot of time setting up React applications. It comes with automatic transpilation and bundling (with webpack and babel), hot code reloading, easy routing of pages and file serving.

GatsbyJS

• Gatsbyjs is a React.js static site generator. It allows live reloading and is particularly useful to develop websites/blogs real quick.

RevealJS

• Excellent for creating slides, catalogues, training presentations, or a method to introduce a new product in a short period of time (packaged with animations out of the box!)

Read more here: Hype driven development

I like to discuss ideas and so if you have any thoughts/opinions in these areas, I would love to hear them.

Lastly, do follow me on @ https://github.com/stacygohyunsi if you would like to see what I’m up to next!