I admit.. it’s been a while since the last blog post…
But I’m back again as I wanted to do a quick write up of my experience at this year’s CityJS Conference. Before you read any further, be sure to give me a few 👏🏻 at the end, if you enjoyed this blog post (Max amount is 50 so feel free to clap away as much as you want)!
As a little backstory to the event:
CityJS Conference is a JavaScript festival across London, a joint event from the London’s JavaScript meetups, including London JS Community, JS Monthly, Halfstack and Node User Group.
To put in short, it’s an annual event organised by developers who are extremely passionate about JavaScript and coding. This year is the 2nd year that the event has been organised and needless to say, it was just great.
With 10 incredibly knowledgeable speakers from all around the world, we were fortunate enough to spend the entire day with genius programmers who shared their expertise and tips/tricks.
Topics discussed:
- <feTurbulence> && !important (Chris Heilman)
- Machine Learning with JavaScript (Elle Haproff)
- It’s about time to embrace Streams (Luciano Mammino)
- The current state of the data sharing economy (Srushtika Neelakantam)
- Ada 99 — Rewriting the very first computer program. How does JavaScript stack up? (Marquis de Geek)
- The Oracle at Delphi Neither Speaks nor Conceals (Sam Galson)
- Syntactic sugar — Diabetes alert (Maya Shavin)
- Creating Your Own Image Format in the Browser (Trent Willis)
- A web of infinite possibilities (Ingrid Epure)
- BTR FSTR AWSMR SSR (Dylan Schiemann)
In this blog post, I won’t be explaining what each individual talk covered as it’d probably be too long of an article to read. Rather I wanted to revisit the one particular talk that stood out to me the most:
Chris Heilman’s speech on the Frontend Turbulence and the importance of focusing on what REALLY matters.
He mentioned the cruciality of building and maintaining high levels of accessibility, interoperability, performance and security when it comes to developing apps. But more importantly, he emphasised the frequency of how MVPs are usually built within a very short time-frame in order to generate revenue as soon as possible. Although this may be beneficial in a business sense, the speed in which MVPs are usually built, can, in turn, mean that the overall quality of the app will be decreased.
We often hear people say:
- Make it work
- Make it right
- Make it fast
But in reality, Heilman challenges us as developers to really put deeper thought into what reality portrays. He mentioned that often we build MVPs with the intention that they will be thrown away or replaced soon after delivery, with better products - which is very far from the truth.
From his consultancy experience, he shared that he often sees companies that stick to their original MVPs (that may be full of bugs and faults). Due to time constraints, initial MVPs might not incorporate good practices that encourage high levels of accessibility, interoperability, performance and security. Instead of ameliorating the MVPs with releases that actually add value to the overall product, developers tend to patch the faults with inutile add-ons or plug-ins that might not necessarily be the best option.
Nonetheless, he also explained how this could be due to a large variety of reasons - such as the influence of others within the business as well as shareholders.
Heilman urges us to reconsider the purpose of our code.
This really made me think twice. As a developer, we have a tendency to just code whatever’s being asked of us, without really questioning the real purpose behind a new release/function.
Will this new function really add value to the end-user? Or is this just a fancy add-on that shareholders want to see?
It is essential to reflect and fully understand the end goal of a product, in order to ensure that we are building an app in the best way possible. Only by understanding the true purpose and target audience of an app, can we then customise our code and make wise choices in the tools/frameworks we use, on a daily basis.
Another interesting point that Heilman raised, was that developers often look at the code that others have written and question the ability of other developers.
I mean… If you’re a soft dev, does the below sound anything familiar to you?
“Oh man - why did this developer choose to use this framework? And why did he/she/they write such an odd function? That’s so dumb.”
This mindset automatically causes a negative attitude and may even discourage the developer to work further on the app. In fact, even when we look at the code that we’ve written ourselves in the past, we often spot silly mistakes and areas that can be vastly improved.
Basically? Don’t be that person.
Context matters. Think in other’s point of view.
Given the time and circumstance of when the particular app was built, there might have been limited resources or tools available to the developer. Blame culture does not contribute to an efficient and effective work environment. As developers, we should always try to take a step back and look at the bigger picture before criticising the work of others.
To be honest with you, I’ve had a really incredible day at the CityJS Conference and I could probably go on and on about all the intriguing topics discussed. I’m always continuously looking for ways to improve as a dev, and if you have any feedback, I would love to hear them - so please comment down below. If you were at the CityJS Conference as well, let me know how you found it!
A big shoutout to Eddie Jaoude and Julia Biro for hooking me up with the tickets 🙌🏻, and to Shuen Yee for being the best conference buddy 🥺. I’m honestly so grateful for having such encouraging, supportive and positive tech buddies in my life. Can’t wait for next year’s conference! Though I hope next year it won’t clash with ️ReactJS Girls 😭…
Here are a few more snaps from the CityJS Conference. Enjoy!
