SJ Homer, Code Wizard 🧙🏼‍️

How Post-secondary Changed Me

My time at college was a rewarding experience as it helped prepare me for my future as a self-driven learner, and respecting the consequences of failure.

What you’re not Taught, is the Lesson

My first lesson at college came early from the disconnect from what the curriculum offers, verse what the emerging treads on the Web were. In a field like web development, which changes on a dime, I got confused and questioned why a few courses I was studying were on legacy languages. While I wholeheartedly believe understanding where modern languages come from, it shouldn’t be at the expense of those becoming essential. PHP was beginning its meteoric rise in the web space as we were being forced to learn Perl, and other similar learnings away from where the Web was moving to.

I concluded that in the real world, no one is ever going to force me to learn what I needed to know. I would have to teach myself. That might seem cynical, but it’s quite the opposite, actually. I decided learning PHP was going to help place me in the field, so I took what teachings I could from my courses and apply it to the new tools myself. By the time I’d finished post-secondary, PHP had yet to be included in any of the course offerings. Yet, I had already built my graduation project in it, had a decent competency of it, and this helped me excel in the workplace.

A Pivotal Lesson in Failure

My biggest lesson during college, however, wasn't that I should teach myself things, and it was a lesson borne from one of my biggest failures. Thinking I could finish and enter the workforce earlier by going into my program nonstop, I did semesters back to back to back with no breaks. Classes went well my first three until I failed out of my forth when the pressure caught up to me. Almost being put on academic probation, I pleaded a strong case that I could prove I’d do better if given a second chance. They accepted, and I immediately began a new semester and aced all my classes! Afterwards, I finally took a break before continuing again at a reasonable pace through till graduation.

Had I not put myself through doing too much and failing, I may never of realized the resolve I can summon and foster. The experience helped transform my view of what it meant to be and act professionally, and I attribute this event to my dedication to endeavor to perform my best. It also allows me to recognize that when others make a mistake, even a substantial one, they can be the very best chances to learn and grow from.

Learning the Ropes

Putting some Notches on the Training Belt

Eager to learn and start leveraging by tapping into development skills, they onboarded me to aid in developing a back office ERP system with PHP/MySQL. It gave me the opportunity to learn the ins and outs of inventory management and supply chain.

Then came the opportunity to step into my first official Frontend development role in managing the company’s main website, marketing campaigns, emailers, and even some light ecommerce. All using ASP, and no, not the .Net framework, and even some Flash! Wild and crazy times when you’ve been in the field as long as I have. These were still valuable and prominent tools, and learning to develop good coding standards is never a waste.

Parallel to these efforts, as I advanced in my role, I had the opportunity as well to support some Windows Application development in ASP.Net, helping to build a modern installer suite.

Changing things up

The websites served their needs until through a merger with a parent company; we shifted gears and transitioned into the Magento framework, where I could move back into PHP development.

As mergers can go, however, not everything lands well for the smaller fish some times. As differences and struggles arose, preventing me from doing my best work, I sensed the need for a change. A door into a web agency opened up, and I continued my journey onward.

Cementing my Foundation

Why “done done” matters for UAT

Early on, still have little experience working directly with clients, with projects and requirements driven primarily by them, I came across another career defining failure. The first big project I produced was a complex Fintech website. Not having a well-rounded understanding of that field, and lacking guidelines and business requirements, I made some quick assumptions on presentation and UX by working fast, rather than smart. This cause features to have buggy result, and displaying poorly, without the perfect happy path use cases. As one can imagine, when I presented my updates before the winter holidays to the client, they were hoping to launch in the new year, and we were far from ready, much to their displeasure. Yet, from a spectacular failure was a great lesson to be learned that working fast never wins out. While I was still acting professionally, the calibre of my work was lacking.

I resolved to do my due diligence, validating requirements are clear before beginning, or pausing to gain clarity if blockers present themselves, finally triple check releases even when you think “things are good” to give clients the best possible results at all times. Least to say, while this specific client was immensely unhappy initially, they became quite fond of me. Through my dedication in supporting their services for my entire tenure at the firm, it saddened them to see me move on by the end.

Laying brick after brick

I helped to establish and mature the in-house CMS, crafted in PHP and MySQL, which we improved upon continuously as it served us well. We found an avenue to transition to working with WordPress, but only after it stabilized in later years.

WordPress, as with other early CMSs of the era, they were not the most dependable in of themselves, and why our in-house solution continued to be maintained and improved. I worked routinely to set and improve code standards and document patterns of using the system, improving aspects of the framework as new relevant libraries became available, around the JS layer with jQuery, extending to Less/Sass styling, and the importance of moving away from FTP to git management and version control on all things.

Most developers nowadays take a lot of modern dev practices for granted, having not worked through and surpassed the legacy processes that many firms once used routinely. As I saw tools and tech to reduce our risk, add stability, and improve our overall development workflows, I jumped at any chance I could to raise the bar on how we could operate more dependably.

During my growth, I led some projects, supported other developers through code reviews, began supporting the RPF process, defining estimations on projects/bids to quantify the efforts, and defining tasks needed to execute our solutions successfully.

Looking to the Future

After the advent release of Meteor JS, the future of the Web being JavaScript crystallized in my mind. The possibilities with real time delivery, hot reloading on local dev, and socket connections blew my mind. I didn't get the chance to leverage my growing JS capabilities through work at the time as must as would've liked. Still, I began introducing better tooling and code generation to improve our development experience.

We began seeking more managed services to help unburden the DevOps of running direct hosting and problems that could ensue to reduce efforts. And, the growing complexity and maintenance of the in-house CMS was becoming more apparent. Thankfully, with the improved stability around WordPress, it became attractive along with easier ways to run the CMS via SaaS provides. Transitioning towards this meant the team could focus more on doing good work and less time managing deployments, which was a win for everyone.

Because of my continued self-directed learning and growing competences, it once again opened the door for my advancement to another agency. They were seeking a talented JS developer in an early decoupled solution, and I was ready.

Honing my Craft and Leading

Node, the Crazy but Fun Wild West

The early days of NPM were not for the faint of heart. While, arguably, it can be a source of frustration from time to time even today, newer developers won’t appreciate the monumental advancements and stability the ecosystem has evolved too. And while decoupled solutions may be the norm now as well, these solutions were still up and coming a decade ago.

Being Senior Development then, I took these challenges head on when jumping into things are full speed at my new agency. I found my stride on my first decoupled project supporting an ecommerce ticket purchasing system. We were leveraging Angular JS on the front and a NodeJs/MongoDB backend, while integrating to a custom REST API which the client team was developing to manged accounts and order data. We tied this finally into Stripe for payment handling. Phew! It was a giant leap forward from my former development. Also, moving from “take your time” cart based ecomm to expiring carts with finite quantities without back-orders… it was quite a mountain to conquer. But of course, we prevailed in the end.

Blessed with an incredibly talented and patient mentor who was a DevOps wizard, he helped me to improve, and to respect the importance of foundational data architecture. Knowing all the data points, how each layer and endpoints of the system communicate and validate that data so things run smoothly was immensely enlightening. Without a CMS monolithic structure, we could do things with more dynamic data layering, and every piece of the pie could do something unique to support the overall solution.

Following the project launch, the next would give us a spin on the fringes of the earlier days of static site frameworks. We had a project which began blending an early era static site generator to support a series of sites with a shared theme leveraging DocPad based in CoffeeScript/NodeJs, while connecting to a Drupal CMS backend. As their content didn't change that often, only at set intervals, coupled with their concerns from previous experiences with CMSs being flaky at keeping their sites online, a static generated site was ideal. With the team having a strong background in Drupal, foreign to me then, I realized it really stood out with its integrations for this solution in the CMS space, even to this day.

CoffeeScript, well, that was a wild ride for sure. With its harsh opinionated syntax enforced, coupled with its complicated templating of DocPad, but hey, at least we have arrow functions in JS now! Leveraging a NodeJs server as a middleman to connect to Drupal, it fed data to DocPad and, through our data architecture, dynamically generate components. We were doing headless CMS here before it was common practice, and this too was before “componentize all the things” became the norm, so, it took some real magic to get the stars to align around these technologies. And just like modern static site frameworks, unsurprisingly, build times and hiccups needed to be surpassed to find a reasonably happy path. The sites could generate and build their specific content and themes, deploy to separate servers, all while utilizing shared components and assets across the sub-brands allowed for a more maintainable solution.

Durpalizing the Componentizing

Between the former project and those that came next, I was extremely fortunate to have a couple months of R&D focused research. It was the dawn of the Web Component spec, and components were becoming more and more the norm as a way of development for more reusable frontend elements. I was exploring NodeJs tooling and how to generate components of different base types, naming and file structure, as well as assisting in how our DevOps could consider leveraging Docker (up and coming at the time) into a new ecosystem for building our websites.

As things progressed with later projects, I moved into the more traditional Drupal theming space, and pushed the boundaries into what it could do in the vein of componentization. Studying designs and similarities from page to page, I recognized if things were just data, many UI elements are just the same component with unique styling or variations. It wasn't too long before I helped define and build, with a talented partner, an internal component system for Drupal. It’s stood the test of time as its still being using successfully today. Based on PatternLab and Atomic Design, it was born from Main Spring and an earlier iteration of Emulsify. We put own spin and standards to streamline what worked best for our team, added tooling, and a micro JS framework to pair component behaviours alongside Drupal with ease.

Stepping up to the TA Plate

As things progressed, my aptitude for architecting and senses in breaking down components and aspects of good product design or UX continued to expand. It was natural I transitioned then to a Technical Architect role. Supporting developers while still primarily developing myself, I moving again to manage code reviews, helping define and flush out data and component architecture, and distilling these into technical tasks for the team beyond user stories.

From this, I became involved once more in project planning and estimations from the RFP stage, albeit at a higher level than at my former firm. It was now my responsibility to formulate to the best of my ability with what research and known variable options were available, forming an ideal approach for solutions. I had to know the scope of all the technical aspects and risks to help flesh out those elements for the bid. Advancing to this role, I became more prominent with clients. Helping deliver and clarify technical proposals, I had to instill confidence in our understanding of their problems we’d planned to solve.

The Shifting Frontend Landscape

Before long, we would once again took a step forward in the JS space with newer approaches to websites. Through my continued expanding expertises in JS, it allowed me to advance to my role as the Frontend Development Lead. In this role, I would take on the responsibility to help guide, lead, and mentor the frontend efforts across the company.

Frontend had began to encompass so many elements. Long gone were the days of just using a bit of HTML, CSS, and JS on pages. Now we had Frontend UI components to design and craft, UX and State management flows to plan and implement, “Backend” Frontend through Integration or serverless to support interactions with APIs and resiliency, and Frontend DevOps with the growing complexity of CI/CD services and tools. The field has expanded incredibly in recent years, and still has no signs of slowing down.

As we moved into headless Jamstack space, we settled on the pair of Gatsby and React as our primary frameworks, with their possibilities of data from any source being astounding. From my exploration, however, I was admittedly considering we’d move towards Vuejs 2.x, with its separation of concerns that I felt React lacked at the time… until React 16.8 dropped, that is! With its functional components, hook architecture, and component level state (for when you shouldn’t be using heavier libraries), it was a game changer. It helped point us into a direction that the broader community has continued to embrace around React’s success and growth, and it was soon clear that we made the right choice.

It was kind of funny too, that while JS classes improvements in ES2015 release were a huge step forward (no more ‘this’ madness), they lacked a finesse that frontend components required to be maintainable and reusable patterns. That, coupled with the lacking potential of easily component level shared state, which React’s release ushered in.

With a new and shine static site generator tool like Gatsby, old became new again, which reinvigorated the essence of why static sites were a critical concept that needed a comeback. Our first enterprise Gatsby site launched just before the pandemic, and proved the right choice. While our client’s competitors sites got hammered and run down from SSR traffic, out right breaking some of their services, our clients site was online and running without a blip. That’s the beauty of these solutions, having at most a degradation of isolated services should issues occur when you build smartly in Jamstack. It gives end users a peace of mind while doing most of their needed operations practically always.

Leading a Team Successfully

Continuing to respect the efforts in leading, I learned it takes more than assigning tickets or reviewing Pull Requests to mentor and inspire team members. Often project timelines and budget are limited, and while we always strive to do our very best, we also don’t have the luxury to take our time and build whatever we desire. Finding the balance of simplicity and maintainability instead is what I strive to lead the team towards, through constructive feedback and compassion so they know they’re safe to learn from their mistakes. I’m just a part of their journey through the field, and do everything within my power to guard them so they can stay focused and be productive. And of course, learning to challenging them so they can move deeper into the areas that interest them.

A key lesson I’ve learned about fostering good developers is that they should not need to know everything. The better they can unpack knowledge and jump back into library/frameworks API docs when they need to use again, means they can always solve problems without a lead looking over their shoulder. I urge my team to keep a site like DevDocs pinned at all times to look up how to reuse methods and refresh core concepts as a healthy practice. And, not only to they write better code for it, they continue learning about extra flags/options or other tidbits they may have missed previously when they review it. This helps them to keep expanding their knowledge and improve. It’s truly a marvelous thing.

That’s a wrap, for now.

If you made it this far, I’m eternally grateful, and hope my path had some worthwhile insights. I could talk endlessly about topics around development from my journey, or where I hope to keep moving in the future, but, everything must come to an end. So until next time, cheers!