codeburst

Bursts of code to power through your day. Web Development articles, tutorials, and news.

Follow publication

For The Love of Coding — Keeping It Real Through Passion & Profession

Joseph Matthias Goh
codeburst
Published in
7 min readJan 1, 2018

--

There was a time when coding was fun, when coding meant exchanging an all-nighter (willingly) for a piece of working-ish software, when coding meant entering a playground where what you could imagine, you could create. It was fun making things just well, work.

Then came the prized developer job, and things changed.

Design decisions needed documentation, code necessarily involved unit tests, even system and integration tests, style guides adhered to, and code reviews performed with another developer (ew, humans) before your code could be merged into the codebase. It takes out all the fun of, well, making something work.

So how does one balance between being professional, getting shit done, and maintaining one’s passion (aka being awesome)? Here’s some ways I’ve explored and found useful in my own personal development journey since the time I turned professional a year and a half back.

A nice summary venn diagram of the goal of this piece (credits to the onboarding material for GDS, where I’m at right now)

Experiment, often

Do things differently, and do it often. To engineer is to be human. And humans, unlike robots and artificial intelligences get bored easily.

“The definition of insanity is doing the same thing over and over again, but expecting different results.” — Albert Einstein

Spice things up by writing a block of code a little differently each time. Code is just an expression of human intent that a computer understands and the same intent can usually be expressed in many different ways.

Experiment with different architectures, different frameworks and design paradigms. About that for loop you got there, why not try out functional programming and make it stateless? Is the performance better? Is the code more readable?

Every experiment inevitably teaches us something, a failure means you’ll get it right the next time and a success means you’ve made the mistake enough times that you already have an intuition of what works — and intuition is the highest form of intelligence.

Designing your experiments properly has an added side effect of knowing how to measure things which is important for meaningful growth. How do we know we have improved over a period of time? When the rate of success of our hypotheses improve, you know you’re onto something.

You got to where you are by loving to solve problems, don’t let that fire die out. Keep experimenting and continue to…

Invest in your personal growth

Experimentation leads us to the bread and butter of engineers — learning. As engineers, we are paid to solve problems so that it’s “business as usual” — and a natural step towards being able to solve problems is to learn.

“If the mountain won’t come to Muhammad, then Muhammad must go to the mountain” — Turkish proverb

Staying nimble with the mind, as with any other body part, requires constant usage and training of it. Churning out documentations and tests in your nine to five does nothing in this regard, even risking regressions in large enough doses. Invest in your personal growth by taking part in workshops and attending conferences.

Hear about what other industry players are doing with their tech stacks, how they are solving problems unique to their business models. Engage with technical people on a hands-on level, learn new platforms and ways of doing things and see how they can be applied in your daily role as a developer to make things more efficient, more secure, more maintainable. Also, avoid learning things with a sole objective of overcoming a certain challenge at work.

Learning doesn’t necessarily need an objective. Cross-domain knowledge transfer can be extremely useful, allowing us to reframe an insidious problem into a more palatable one and possibly finding a more elegant solution. As engineers, we are paid to solve problems, and reframing a problem often leads to innovative ways to solve the same problem. Always remember the slow elevator and how mirrors, not faster elevators makes it better.

Crux of the link above. Credits: Thomas Wedell-Wedellsborg — from https://hbr.org/2017/01/are-you-solving-the-right-problems

Engage in personal projects

The most thrilling and fulfilling part about coding is creating things that work, not reducing the risk of things breaking. It’s the same difference between progress and fire-fighting. Many awesome developers stop working on personal projects upon going professional. “No time”, “tired after work” and “just wanna chill” are common excuses that will cause one’s passion to eventually fade away. Avoid this trap and continue working on creating your own working-ish software.

“The great dividing line between success and failure can be expressed in five words: ‘I did not have time.’”— Franklin Field

Engaging in personal projects allows you to make all the design decisions, forgo documentation, not be accountable to some ‘senior’ developer, to screw testing, and to cut to the chase – making something that works. Your needs, your objectives, your methodology, your product. There’s nothing better that keeps the flame alive than having fun in your own backyard based on your own needs.

Now that you’re professional, you’d have probably also learnt things which you wouldn’t have explored when you were an amateur. Things which separate hacks from products.

From version controlling to releasing, (sufficient) testing to writing more readable code with the goal of maintainability, and writing code in a way that others can contribute to, the quality of your working-ish software will improve as you bring professional elements in it. It might actually be *gasp* releasable as a product!

Coupled with experimentation, personal projects are a great way to keep learning – heard about a fancy new framework your company is never going to be receptive to? Try it! That ultra trendy but unproven platform as a service? Use it! You’ll get to see what works and what doesn’t, and when your organisation finally starts looking into it a few months later when the hype has reached management types, you’d be the person giving technical insights into why they should/shouldn’t consider it.

Things move really quick in software development, and consistent, fun learning in a low-risk environment is a neat way to both keep the passion alive — and maybe get that next promotion (;

Be good to yourself

To engineer is human — Henry Petroski

To engineer is to be human, and happy humans write happy code.

Being happy means being in a state of self-actualisation

Keep the human that’s attached to your mind satisfied. Stay healthy, your mind will thank you for it — eat smaller but more frequent meals, engage in aerobic exercise regularly, get enough sleep.

Have more tea breaks (within reasonable boundaries of course) and conversations with co-workers over what you’re/they’re doing — as an added benefit, vocalising what you are onto is a great way to get new perspectives while staying focused on your objective. After all, if you can’t explain it, you don’t understand it well enough.

Meet with close friends and family often, and share a good laugh with people who care about you often. Maintain both your physiological and mental health and you’ll be on your way to becoming great at what you do.

Competence precedes passion and loving to do something is a natural consequence of being good at something — passion isn’t serendipitous. Stay healthy, keep improving, keep learning, and eventually you’ll rock at what you do — making things work.

Share the love

Resonance happens when two waves with similar frequencies collide, increasing the waves’ amplitudes just by hitting it off. Same goes with your passions.

Share the love by attending and sharing at local community meetups or by writing articles on your experiences technical or otherwise. It’s a great way to meet like-minded people, bounce off ideas, share knowledge, gain new knowledge and perhaps even find a collaborator for your personal projects. Let your passion resonate with those around you. A flame dies easily by itself but together, they cause wildfires.

But wildfires don’t just decide to light up. Availability of oxygen and dry air are crucial to their beginnings and continuity. Likewise for us, we need to keep the opportunity open for our passions to be set fire upon. Meet people, get to know the community and who’s good at what, get the community to know you and what you’re good at and soon, you’ll be involved in affairs that can serve only to push you to greater heights in what you do.

While it’s statistically likely that you’re introverted,

Famous Last Words

Having a nine-to-five doesn’t mean you have to lose the excitement in writing code. Unless your organisation has draconian laws governing personal work and/or are naive enough to not be involved in upgrading their engineers, chances are, the opportunity is always there for you to take.

If you liked this piece/found it useful, it’d be nice of you to 👏🏽 a few times so that others like yourself may see it on their newsfeed! You can follow me too to get updates on my writings if you’re into reading articles related to leading life as a software engineer and technical musings in agile product development.

Till the next time! Keep coding, keep learning and keep trying to make the world a better place!

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Published in codeburst

Bursts of code to power through your day. Web Development articles, tutorials, and news.

Written by Joseph Matthias Goh

I write about my learnings in technology, software engineering, DevOoops [sic], growing people, and more recently Web3/DeFi

Responses (2)

Write a response