A coder talking about code
Tom here writing, passionate developer for all things web and native. Many moons have passed by since I first started writing a few lines of code. A glorious “Hello World”-moment is was, and since then I’ve written many more lines of much more code, spanning from real-time alert systems, medical applications supporting doctors in their everyday tasks to multi-platform meeting-&-scheduling-management software. I’ve learned some things along the way, too, and today I want to share one aspect of coding that may not always gain that much focus, especially during mid-project heavy times. Let’s talk about a coder’s responsibility, or, to be precise, a coder’s code legacy.
The Pyramids of Javascript
An architect’s job is not only to define the fundamental layout of a new building, the shapes of walls, windows and doors or the house’s alignment proportional to the sun at noon. Among all those things, the architect knows that the building has to endure for years to come, that it has to withstand a brutal nature of strong winds, heavy rains, chilling winters and hot summers. The ultimate goal of the architect’s job is to make sure that the people living in the building have a safe home. It’s all about the longevity of his or her work. It’s all about its legacy.
In software development, things tend to move at a very fast pace, especially when working at startups. It’s important to quickly ship new features, gain traction in the market and keep the users engaging. The focus during development tends to be limited to the current sprint or implementing that one high-priority feature asap.
Yet when I’m coding, it shouldn’t be restricted to the tests to light up all green or just the deadline to be reached. Once out in the wild, applications get used by humans that may rely on them for their daily working routine. The program I’m building today is the legacy I’m leaving behind tomorrow.
Let’s take the web as an example: it’s never been easier to find components that provide the functionality I’m looking for right now through NPM. They’re quickly installed and hooked up to the rest of the codebase. But when it comes to the longevity of my application, 3rd party dependencies may halt the whole update-process, b/c updating that one dependency stops another one from working. It’s a balancing act deciding between what to implement by my own, fork or install directly from a package manager.
However, code from 3rd party providers can just be fine. It’s important to check for some factors before using the library or framework: how good was maintenance in the past, how many active contributions are there now, is a roadmap available outlining future changes or improvements, is the package completely community-managed or backed by sponsors to help with its development?
Moving forward from external code to my own codebase, one thing I constantly have to remind myself is to not cut corners during development for reaching a goal faster. As tempting as it might be in the short run, badly planned code will take revenge and bite back. Thinking about code more than writing it helps mitigate many problems. A key factor for sure here is experience, yet junior devs too should understand the importance of maintainable code from the start. What leads to bugs now may never be fixed due to project timelines and only be solved through workarounds, leading either to messy code, bad user experience or both.
Mentality of the machinist
One other aspect of thoughtful coding I want to write about is an application’s target audience, the user. As I’m sitting 9 to 5 in front of my electric slide rulers’ screen, plowing through lines of code and focusing on the issue I’m assigned to, it sure is hard to keep in mind that all my work, eventually, has to be used by someone who uses it partially or completely during the daily job. And it doesn’t really matter if I’m building an app for non-technical people or APIs for other devs - the stuff I build has to be ergonomic in its usage.
I know from first hand experience that users might interact with your app in strange and mostly inexplicable ways. I as the creator tend to reject “unintended” behavior of my service, even more so if I’ve already invested a lot of time and energy into it. Yet keeping a calm mind when receiving feedback and, if necessary, forcing myself to listen to it, plays a key role in understanding the audience’s actual, real usage behavior.
We as developers live in a world of order and uniformity when coding, where a special kind of physics and gravitation apply and where we know all the rules. It’s a world to embrace and fully immerse ourselves into it, as we’re its creators and inhabitants. But facing feedback i.e. criticism from outside this world usually leads to its rejection by developers. Handling user reports and options has to be learned and valued as relevant input for the development. It’s a lesson I learned, and it vastly helps at every stage of the project to be open for changes and feedback.
process.exit();
To summarize, think not only about the code you’re writing today but the one that people will use in the years to come. Make thoughtful decisions regarding the usage of external code packages as well as the project’s structure and implementations, such that the final product can be used ergonomically and efficiently, reflecting the target audience’s actual demand. Understanding feedback is key and greatly helps delivering a quality product one can be proud of.
- Tom
