This past month I was fortunate enough to attend the Forward 4 Web Summit (also known as ForwardJS), which is single-day, multi-track conference hosted in San Francisco.
Although the official event is just one day, the rest of the week is stacked full with hands-on workshops taught by industry leaders. The conference speakers and attendees addressed a broad range of topics relevant to front-end developers.
While the event didn’t focus on any specific area of development, I noticed a few overarching themes emerge after reflecting back on my experience.
Despite the changes to the language and the community going forward, one can hope the culture of openness and knowledge sharing will continue into the next decade and beyond.
Use the Right Tool for the Right Job
During one of the panels, a debate arose over convention versus configuration. Is it better to rally behind a handful of well-built, well-tested, opinionated libraries and frameworks, or to create software architectures that play well with others and allow for more interoperability? Inundated with so many boilerplates, tools, and configurations to go with each, it is easy to feel overwhelmed by the amount of decisions to be made. This sentiment was shared across the board.
One of the panelists offered a practical solution to this dilemma: remember to use the appropriate tool on case-by-case basis, evaluate the requirements of the task at hand, and then determine what your technology stack will be. You may not need the shiny new thing on every project, and sometimes sticking to familiar foundations is the best thing to do.
Code for Humans, Not Machines
Out of all the topics discussed, the one that resonated with me the most was the importance of writing code for the people reading it, and not for the computer compiling it. Too often I find myself writing code in such a way that it is optimized for the engine that will run it (preferring for loops over forEach, for example), but not always for other developers who will inevitably interact with my code.
Code should be written in a way that is readable and accessible to developers of varying skill levels. Conventions used solely for the sake of convenience (i.e. short and undescriptive variable names) and other forms of “tribal knowledge” should be avoided. The use of comments in the code to explain why and how instead of what is also key to helping others understand your code.
These are just some of the important tips I took away from the conference, and I am looking forward to attending again next year.