essay

under construction

On Square and web-foundations

Or how I have come to see my time there as DT 101

Note: This thought is under construction. It may or may not have been thoroughly proof-read.

My time at Square came to a close in late March as part of this mass layoff. I reflected a bit on the feelings of getting laid-off in this post . But here, I'd like to be a bit more positive and reflect a bit on what I learned at Square - at least in a technical, discipline-specific sense. (I unfortunately learned plenty about politics too, or rather what it is like when you refuse to play that game, but that's a different post entirely.) More specifically, I want to reflect a bit on my time at Square as soon of a Design Technology 101 in a sense - transforming me from someone who could build stuff into someone with a deep appreciation for what it means to build for the web.

I started at Square in July of '22 after almost 3 years at EvolveLAB . It was a different world at that time. People were still hiring; people were still getting interviews left and right. I got this job through an online application of all things. I'm not sure that would have been possible 6 months later, let alone now. I'm still not quite sure how my resume was picked but, hey, I was not, and am not, complaining. After years of AEC industry's long hours and low-ass pay, I had finally "made it." Perhaps at some point, I'll write a bit on this transition.

A web developer's journey

When I got to Square, I was more of a general purpose developer than someone who had a particular expertise in web development. At EvolveLAB, my first professional development projects were plugins to popular architecture and construction desktop applications. I worked mostly in Python and C#/.NET prior to (finally) taking on web applications and frontends. Because of this, I think it is fair to think of my time at Square as an education in what it means to be a developer when the web is your medium.

I think it is fair to say that I didn't know quite what I was getting into when I joined Square as a Design Technologist. I was expecting to learn what it meant to be a software engineer at a "big tech" company. My "Full-stack Developer" certificate from Udacity and plugin/app development background at EvolveLAB had me coming into role as someone, looking back on it now, with experience more akin to a backend or, perhaps, a back-of-the-frontend developer. I thought of web development as Javascript/Typescript-first discipline and was not particularly interested in the nuances of HTML or CSS. Hell, I wasn't even that embedded within the Javascript ecosystem having relied heavily on frameworks - it was Vue at EvolveLAB (I still remain thankful that we opted not to use React) - to get the apps working. I've seen this elaborated on in a couple different places but I definitely think that its true that, for a lot of developers, Javascipt (or, increasingly, Typescript) is the way and the other aspects of web development are not "real" code. HTML and CSS were meant to be learned but not deeply, just "well enough." I lived that world. It's one reasons that I was a Tailwind guy pre-Square. It felt more "real", in a sense, to the way that I conceived of software development.

I'm sure that there are people still coming to the web development field with the right mindset of learning the foundational structures first: putting in effort to master HTML, CSS, and vanilla JS before building with frameworks on top of that. But I also can't help but extrapolate from my own experiences where it is too easy, especially for those coming into the discipline from elsewhere, to fall into the trap of thinking of frameworks as everything. Learn React (or get or into the hot new framework). Use Tailwind because its the hot CSS "framework" that "fixes" the quirkiness of CSS. Build an SPA . Then, boom, you're a developer who can get a job making more money than you did in your previous, legacy industry that has more professional guardrails and old-heads keeping you down.

I don't want to begrudge this path or put down the people taking it. I did it after all. I think it is great that people can switch into this discipline and, at least in the past, get a job building some cool stuff. But I do want to call some attention to the fact that if you're not careful, or lucky, and fall into the right environment with the right people, you might get stuck into this Javascript-first, framework-first way of thinking without ever having that point of view challenged or, dare I say, corrected.

I think, in someways, I got just that lucky at Square.

An aside on on-boarding

Before diving further into this story though, and I promise I will, I want to take a moment to reflect a bit on my start at Square: the on-boarding process. I think if there's one low-key takeaway that I had from my time at Square, it's that the on-boarding experience really does set you up or hold you back from early success. My on-boarding at Square was, shall we say, "sub-par." The other design technologist on my team was a wonderful human-being but also, I think it is safe to say, a little checked-out on the job. Introductions to people and processes were not forthcoming and I was sort of left figure it out on my own a lot of the time. I did reach out to other DTs for help but, as with anything, it is hard to ask for help on things that you don't know exist or that you don't know to look out for. So, to anyone starting out in a new job out there, I would really recommend getting a great on-boarding experience lest you spend the first year or two of your job figuring out things that you really could have learned in your first couple months. Anyways, that aside, let's get on to the good stuff.

Design Technology 101

I started at Square before the "modernization" of their web tech-stack. When I was asked to work on a page, component, design system, or etc... I was often required to do this via a CSS stylesheet, a Javascript snippet, or a "bundle" of both. There were a few times where a more complex design required a Svelte component. I was actually, despite the nominal complexity, more comfortable in this Svelte environment than outside of it. Solving problems without a framework was a mindset that I had to cultivate over the course of a few projects. I was not used to working with the fundamental parts of the web to such a great extent.

I'm very thankful for this experience though because it opened up my mind to the fact that frameworks are, indeed, not necessary - the web works quite well without them. It wasn't so much that the possibilities of CSS and built-in JS APIs were obscure solutions so much as I didn't know what I didn't know. I'd been brought up in a world where Javascript frameworks were "the future." At EvolveLAB, I picked Vue because it seemed more future-y than React. But once I knew what I was missing out on, that the foundational languages of the web are quite capable, I couldn't stop diving deeper. My fellow DTs at Square were instrumental as I could dig through their code to see what solutions they implemented. Seeing their solutions opened up other deep dives as I came across selectors and APIs that I did not know existed before - or at least had not see when unabstracted by a framework.

Now, don't get me wrong, I do appreciate Javascript frameworks (maybe not so much React but ¯_(ツ)_/¯ ) and understand the utility of Tailwind. I use Svelte and Astro all the time these days. I don't think I'd want to build one of my personal projects without one (or both). But, if you're not careful, it is easy to build without understanding the underlying mechanisms that these frameworks (or most libraries generally, really) are abstracting out for you. They can obscure the trade-offs, make you think that their implementation or solution is the best, or even necessary at all when something else like HTML or CSS could actually do job without any Javascript. (I've become quite interested in the moments when I can replace Javascript with CSS.) This is actually why I've come to like Astro so much: it pushes you away from unnecessary Javascript. Because, yeah, frameworks are great but I've also really come to see the value in the foundations of the web.

An aside on frameworks

While we're on the topic of frameworks, can I just say that I'm really happy that I started my frontend developer journey with Vue rather than React. And further, that I found a job at Square, totally by accident, that was using Svelte just after I had stumbled upon learning it myself. 
<br/>I think that the way that single file component frameworks like Vue and Svelte (and Astro) encourage you to think really is valuable. The way in which HTML, CSS, and JS are kept separate encourages you to consider the primacy of HTML and CSS rather than falsely assume JS is king. React is different. It is still a templating engine but JSX is weird in my opinion. The idea that "it's just Javascript" but also is everything(?) puts Javascript at the center of web development in a way that Vue and Svelte don't, at least not in inherently the same way. I'm going to credit those frameworks with, in a very small sense, sticking me on the right path. And helping to keep me open to the lessons I learned at Square.

An aside on craftsmanship

I also wonder if, and this is will probably have to be a longer post at some point, my education in Architecture has played a key role in shaping my education at Square. Architectural education really pushes this idea of "craftsmanship" and obsession with getting the details of a project right. This means everything from how design is drawn - are your lineweights right? - to how it is a building is built - is the flashing on your soffit considered both in how it looks and how it functions? Key to understanding your craft in this way is deeply understanding your medium.

Nowadays, my medium is the web. Honing my craft means deeply understanding the foundations of the web. It means understanding the tools available - HTML, CSS, JS but also, yes, React and Svelte and GSAP and etc... - and how and when to use them. I think, to a certain extent, everyone wants to be competent. Everyone wants to do a good job. And to that end, people are willing to work and learn and understand. But I also can't help but wonder if this obsession with craftsmanship, built from my architecture background, has pushed me a little further down some of these rabbit holes or made me a little more willing to cast off "modern" tools for more foundational, vanilla tools. Food for thought.

Conclusion

So, anyways, to come back to my time at Square, it was, in so many ways, a Design Technology 101. I don't say that because I didn't know anything coming in - I could build working stuff and had to pass a couple technical interviews to prove it - but because, like any good 101 class, my time at Square brought to my attention the greater world of web development. It showed me how much I didn't know that I didn't know. It showed me the capabilities inherent to the web without abstraction through frameworks. I'm so thankful to that because I now have a foundation that can, or already has, taken me so much further than dogmatically pursuing [insert x framework here] as the way.



Back to the garden