DEV Community: Keenan Payne

Don't alter scrolling mechanics by scroll-jacking

Keenan Payne — Wed, 09 Mar 2022 00:00:00 +0000

Scrolling is how I use a computer. I also scroll a lot on my smartphone. I scroll elsewhere—through menus on video game consoles, books on my Kindle, apps on my Apple Watch…

You get the point. I scroll a lot.

Most people who use modern computing devices navigate them, in part, by scrolling. Of course, there are other ways to navigate devices. You might search and jump to a specific spot on your device or document. Keyboards and accessibility devices also help us navigate computers. However, such affordances aren't uniformly provided across devices, nor is such functionality as widely understood and adopted as scrolling.

You get the point. We scroll a lot.

My zeal for scrolling

I've spent 20+ years scrolling through interfaces on countless devices. Such incessant scrolling has informed a more-or-less "intuitive" understanding of how it should feel. I'm used to scrolling through websites and apps on my computer and iPhone.

If I could sum up my relationship with scrolling in three concise bullet points:

I know what to expect when scrolling
Scrolling reliably gets me from point A to point B
Scrolling isn't something I have to think about because it happens so naturally

This is why I'm such a stickler for how scrolling is implemented.

And why shouldn't I be?

Scrolling is one of my primary means for navigating a bevy of technological devices.

The current state of scrolling

In my experience, websites are the primary offender for altering scrolling mechanics for no good reason. There's nothing more jarring than loading a web page, beginning to scroll through it, and immediately recognizing how unnatural the scrolling feels.

💡 Note: Changing how default scrolling mechanics work in an application is commonly referred to as scroll-jacking.

What's worse is realizing that such a core mechanic was altered for no good reason.

I emphasize that scrolling mechanics are frequently changed for no good reason because of how mindlessly such changes are thrust upon us. If I don't understand why you've altered scrolling within the first 5 seconds, you've done it for no good reason.

This isn't to say there aren't well-intentioned web designers and developers behind the scenes making such decisions who surely mean no ill will to the rest of us. I've been there. But we can do better.

Deciding whether to alter scrolling mechanics

Anybody building websites or user interfaces should recognize the importance of consistency with the mechanics of human-computer interaction.

I never want core scrolling functionality to change. If I can't quickly jump down your page using the Space key or CMD + ⇩, you've fucked up.

You might be able to get away with altering the physics, but only if it's for a very good reason.

Spoiler alert: it probably isn't.

Furthermore, I don't want to notice or pay attention to scrolling when visiting your website. I like the action of scrolling to be as "invisible" as possible when navigating an interface so I can accomplish what I've set out to do.

The goal isn't to enjoy scrolling. The goal is to use scrolling to do something enjoyable.

Here are some very bad reasons for altering scrolling:

You think it adds to the "experience"
You think it feels "cool" or "fun"
You think it makes your website "dynamic"
You think it enhances the animations
You think I will enjoy it

Here are some very reasonable reasons for altering scrolling:

Scrolling is part of the mechanics for a game
You intentionally want to create something experimental and push the boundaries of human-computer interaction while acknowledging the downsides that such alterations incur

Here are some very good reasons for altering scrolling:

crickets chirping

Focus on what matters

If I could succinctly summarize my thoughts on altering scrolling mechanics for websites, it would be to do so sparingly and intentionally.

Don't do it if you aren't 100% confident that changing the scrolling mechanics is absolutely necessary for your goals. Just don't.

Focus your attention elsewhere—the content of your website, art direction, animations, accessibility, usability, etc.

Focus on what matters. Don't create new problems by solving a problem that doesn't exist.

Examples and resources

If you're interested in seeing the examples and resources I've gathered around scrolling and scroll-jacking, please view this post on my website.

Hello, scarcity mindset

Keenan Payne — Thu, 07 Oct 2021 17:53:49 +0000

The scarcity mindset frames our current circumstances as "not enough." It's feast or famine as a freelancer, so you better eat while you can. I fell victim to the scarcity mindset while freelancing, which caused me to accept more projects than I could personally handle. Doing so caused ripple effects throughout my entire life:

I struggled to push myself outside of my comfort zone.
I became way too profit-driven.
Managing client projects became more complicated.
Hiring people required me to manage their work and increased my financial complexities.
I couldn't fully invest myself in a single project because I was spread too thin.

As a result of all of this, I got burnt out. This led to many bouts with anxiety; my body felt worse; and countless servings of stress, overwhelm, and unhappiness.

As a freelancer, if you're not working, you're not eating. Lacking a regular paycheck can make the future seem uncertain, especially for anyone who has been through a client drought.

Still, we should all be aware of the tendency to fall into a scarcity mindset. This awareness can help with mindful decision-making.

I'd be curious to know how I would feel if I were to do another year of freelancing and try keeping my scarcity mindset in check.

How would reducing the hustle and raising my investment in each project change how I feel?

Would I be more satisfied with what I've done and provide myself with room to grow?

Photo by Florian van Duyn on Unsplash

Introduction to Eleventy (11ty)

Keenan Payne — Mon, 04 Oct 2021 00:03:33 +0000

Eleventy (11ty) is a static site generator (SSG) built on top of Node.js that compiles static website assets (i.e., HTML files) using content inside of various "source" files (e.g., markdown, templates, JSON, etc.). Eleventy provides a platform that helps web developers create organized and DRY codebases through its support for templating languages, a robust templating engine, flexible data models, and plugins.

Eleventy is designed as a zero-configuration platform that provides as much or as little overhead as you would like. This preference for simplicity, combined with a philosophy of tooling agnosticism, offers a flexible and empowering developer experience.

Large websites won't only benefit from what Eleventy offers. Unless you are building the most straightforward low-maintenance websites, odds are that some aspect of Eleventy or another SSG will improve your workflow and codebase.

SSG Ecosystem

Eleventy exists in an expansive ecosystem of SSGs, alongside Next.js, Jekyll, Hugo, Gatsby, and so many others. In fact, Eleventy might seem like an underdog among these. However, its frequency of updates and thriving community provide me with confidence in using it for my projects.

I don’t plan on covering the similarities and differences between different SSGs in this article. Instead, here's a list of resources you can consult if you're evaluating this type of software.

My Take

I use Eleventy for a lot of projects

I've used different SSGs in the past, predominantly Jekyll and Hugo. While I enjoyed the ubiquity of Jekyll and the speed of Hugo, what keeps me coming back to Eleventy is its developer experience when used across a spectrum of web projects. About 90% of the projects I work on right now can be built with Eleventy, making it my go-to software for building websites of all shapes and sizes.

The most important advice I would give those choosing software for any project is to be mindful about what you’re choosing and why.

Understand what problems you’re solving, determine which of these are most important, then choose a piece of software that solves your most important problems in an ideal way.

If you're choosing the right tool for the job or at least trying to, that's what matters.

Don't buy into the hype of software X, paradigm Y, or language Z, and instead, focus on understanding your problem domain and using that as your north star.

Getting Started

I plan on writing more about how to use Eleventy for web development projects, but you needn't wait for me to shill my articles when there are so many excellent resources available.

Eleventy documentation

Documentation is always my first stop when learning new software. I start by seeing how the documentation advises I get started and then reach for external resources as needed.

Overall, I think the Eleventy documentation is great. The introductory "Getting Started" resource that I've included hits core concepts at a high level, making it suitable for folks who already have decent technical know-how with similar software.

Learn Eleventy From Scratch

This course—formerly paid but now free—is currently the best resource for learning how to use Eleventy from the ground up.

Taught by Andy Bell, this course teaches you the ins and outs of Eleventy without glossing over the more minor details.

Beginner's Guide to Eleventy

This tutorial, written by Tatiana Mac, is another excellent resource for anybody getting started with Eleventy. The first part of the series covers how Eleventy fits into the world of SSGs, while the second part goes incredibly deep on installing the software.

Naming typography patterns in CSS

Keenan Payne — Thu, 23 Jul 2020 19:28:10 +0000

Editors Note: I originally published this post last year while I was still working at Asana. I am no longer working at Asana, but I still wanted to share this content with the Dev community.

I read a great article the other day by Dan Mall titled Typography in Design Systems. In it, Dan talks about how he approaches naming conventions for typography in design systems; specifically, some of the problems that he has encountered trying to scale common naming conventions. This is a topic that I've also been thinking about recently, having encountered similar issues as Dan in codebases that I work in. I’ve taken a different approach to address this problem, which is why I thought it would be useful to share my thoughts.

Clothing and naming

When working on web projects, abstracting user interface patterns such as typography into easily reusable pieces of code is common, and often desirable. Doing so promotes design consistency and can improve developer efficiency. However, the details of how patterns and abstractions get implemented into a codebase will inform how useful they become. Naming is one such implementation detail that, when overlooked or not sufficiently evaluated, can impede usability and clarity.

Many web developers are likely familiar with the clothing size metaphor when naming things in CSS. This naming convention can manifest in many ways, but one of the most common that I’ve encountered is for font-sizes. Here is a common way to create consistent font-sizes using Sass mixins:

@mixin fontSize-md() {
  font-size: 1rem;
}

@mixin fontSize-lg() {
  font-size: 1.5rem;
}

@mixin fontSize-xl() {
  font-size: 2.25rem;
  font-weight: 600;
}

See an example of this typographic scale in action at type-scale.com

It is common to use clothing sizes as a metaphor for naming font-sizes. Initially, this seems like a useful metaphor. It can feel intuitive to call our smaller font-sizes "small" and our larger font-sizes "large." This metaphor can work well for systems that have a limited typographic scale (e.g., xs, sm, md, lg, xl), but how does this metaphor scale when we work in a system with more expansive typographic needs? Using such a metaphor, we might resort to naming something fontSize-xxxxl. Such a convention can work depending on the context—be that the needs of the business, preferred design/development workflow, or the preference of the developer—but it can be problematic for all of the same reasons.

Naming is not one size fits all

I am part of a group of folks working on building the first brand design system at Asana. As a part of this effort, I have been taking preliminary steps to think about how we want to architect our codebase to accommodate the type of design system that we hope to build. This includes thinking about how the building blocks of our web pages are architected so that developer efficiency and designer flexibility are optimized. One such building block that needed re-evaluating is how typography is handled in our codebase.

We’ve run into issues with scaling the clothing size naming convention for typography in our codebase. Our designers prefer flexible, context-dependent styling for type, and the inherent limitations of scaling the clothing size metaphor make it difficult to achieve that. As a result, we have a growing list of font-size variables that is almost impossible to remember, which slows down development. Additionally, this naming convention adds overhead for designers who must name type styles in Sketch files so that there’s a one-to-one match with the variable names in our codebase.

Our design system should use conventions that designers and developers can understand, facilitates the development of new pages and components, and can scale as our needs grow over time. Our current solution for naming typography is not checking these boxes, which indicates that it’s time for re-evaluation.

Out of the metaphorical and into the literal

With this outcome in mind, my predominant thought around naming typography has been to move out of the metaphorical, and into the literal. Here’s an example of what this might look like:

@mixin fontSize-16() { 
  font-size: 1rem;
}

@mixin fontSize-24() { 
  font-size: 1.5rem;
}

@mixin fontSize-36() { 
  font-size: 2.25rem;
  font-weight: 600;
}

In this example, we scrap the clothing size metaphor and name our mixins after their pixel representation. When we want a sixteen-pixel font-size, we reference fontSize-16() in our codebase. This mixin can then convert our font-size into ems or rems if we wish, as well as provide accompanying font styles if necessary (e.g., font-weight, line-height).

A system like this could work well at Asana because our brand design team works with pixel font-sizes in their Sketch files. Translating a design into code could be made easier for developers, as there is a one-to-one match between our mixin names and the font-sizes that we see in design files. This means that we no longer have to continually cross-reference variable names with values to determine which to use. There’s also infinite room to scale our typography without impeding clarity; if we need a larger font-size, we can add a new mixin. Lastly, by removing the naming convention, we have reduced the work that designers have to do when building their files. Wins all around!

Architecture is contextual

Context is critical when making architectural decisions. What works under one set of circumstances may not work under another. In this instance, because web developers at Asana are building new pages and components from Sketch files, it’s important that developers can easily understand which class, mixin, or variable to use when translating designs into code. Because we have the additional requirement of wanting a flexible type system, it makes sense to use a naming convention that can easily scale as the needs of our designs change. These are all considerations that must be taken into account when making architectural decisions.

It is also important to acknowledge that architectural decisions are rarely made without any trade-offs. There is never a silver bullet solution that solves every problem without consequence. In this instance, we make trade-offs if we move forward with this new naming convention:

Difficult to remember: One of the efficiencies that is provided by using a metaphor for naming conventions is the reduced cognitive overhead for remembering names. For me, it’s easier to remember “extra-small” than it is to remember a string of numbers (e.g., 16, 24, 36, etc.)
Infinite font sizes: Using the clothing size metaphor, we were able to identify when typography styles started getting out of hand. Seeing something named “xxxxl” indicates that something needs re-evaluating: either the way that font-sizes are implemented in the codebase or the number of font-sizes that are used.

Trade-offs should be evaluated on a case-by-case basis. The circumstances and priorities under which decisions are made will directly inform the value of various trade-offs, and should hopefully guide you in making a decision.

Closing thoughts

Will we stick with this new naming convention for our font sizes? I’m not entirely sure at the moment. I think that this could be a decent solution for naming font-sizes, but more time must be spent evaluating our options and getting buy-in from teammates and stakeholders. Either way, it was fun to think outside of our existing paradigms and conventions and wonder how we can make improvements.

How would you have approached this problem? Have you had trouble scaling this clothing size metaphor with naming things well? Feel free to leave a comment below! I’d love to hear what you think.

Goodbye Asana, hello freelancing

Keenan Payne — Thu, 18 Jun 2020 14:52:08 +0000

It's seven, almost eight months past due, but there's no better time than the present to share some exciting news about my life. I have left Asana, and I'm now working full-time as a freelance web developer! I am a gun for hire, taking my decade of web development experience and applying it to new projects and clients that need someone with my expertise.

Because so much has changed in my life during the past year, I have done a decent amount of reflection, which I think would be useful to share with others. This post will just be a little overview of where I've been, where I'm at, and where I'm going. It will serve more as a personal reflection, but might provide some insight that could be applicable for others.

From Montana to San Francisco

Before joining Asana as their second web developer, I worked as a freelance web developer for several years in my home state of Montana. I started my career working part-time throughout high school and college, and upon graduating from college, I pursued freelancing full-time for two years. As I started looking to expand my horizons as a professional web developer, I found the options available to me in Montana somewhat limited. Working remotely for a company was a possibility, but even in early 2014, there were much fewer opportunities available to those seeking to full-time remote work (fortunately, remote work is much more pervasive now ¹).

Coupled with my desire to leave Montana to try living somewhere new, I embarked on a job hunt in employment-rich cities such as New York, Seattle, San Francisco, and even Amsterdam.
After hundreds of emails and applications (many of which were for jobs that I had no idea I was unqualified for ²) I ended up focusing on San Francisco, due to the large technology scene and plentiful job opportunities. Applying to Asana occurred to me by happenstance, as I was brainstorming companies to look into one afternoon. I remembered using Asana with a client of mine (shout-out to Glenn and Jamie) who used the product to organize the work that we were doing together. I looked at the job listings on Asana and voilà, a listing with "web developer" appeared. After countless rejections, I had gotten much better at matching job listings with my skillset, and the listing for Asana seemed like the perfect match. Well, needless to say, that it was as I ended up working at Asana for almost five years.

Overall, I had a wonderful experience working at Asana. I was fortunate to work at one of the prosperous startups in the city. This led to a lot of change during my five years working there. As a reflection on what changed from when I started to when I left, I wrote some highlights that come to mind:

I was only the second web developer at Asana, alongside my co-worker Sarah. By the time I had left, we had a team of 9.
In 2014 the company was only 70–80 employees, and when I left in late 2019, the company was upwards of 600 employees.
I learned a lot while at Asana. Not only about web development, but coming from a purely freelancing background, I had a lot to learn about how to work within a larger organization. This deserves a post unto itself, but a not-so-shortlist includes:
- Collaborating with teammates
- Communicating with stakeholders
- Costing my work
- Understanding how to make trade-offs
- Framing my work within the broader context of an organization
- Handling interpersonal workplace relationships

Looking back, I am pleased with the time that I spent at Asana. There are things that I think could have gone better, but such is the case with most areas of our lives. I met a lot of great people, built a lot of great things, and learned a lot of great skills. That's not a bad takeaway from spending five years working somewhere.

My Asana office setup. Why is there a bunch of fake grass on my desk? That was a prank, and I kept it on there for almost two years.

Reflecting on areas of improvement

It may seem difficult from the outside looking in to understand why somebody would leave a high paying tech job with great benefits and security for self-employment, which offers no benefits, precarious security, and is sometimes high paying. Leaving Asana is not a decision I took lightly. I spent a lot of time reflecting on my needs and desires to understand which direction I wanted to take my life. After doing that, I decided that moving back into self-employment lined up most with my goals.

I thought it might be interesting to outline some of the biggest drivers that ultimately led me to move from Asana to freelancing.

Working Hours

I dislike having a prescribed structure thrust upon me by others. I don't necessarily know why, but it's something that I've been aware of for a long time. As a child, this manifested in disdain for attending things like school, football practice, or any other obligation for which I had little personal enthusiasm. As an adult, this has largely manifested in "working hours." That is, the hours under which humans are normally expected to work, which is generally viewed as 9am–5pm(ish). Fortunately for me, Asana was quite flexible in this regard. I could generally show up anytime between 9–11am, and no one would care (however, the implicit expectation, as set by everyone else showing up around 9am, did make my lackadaisical 11am start time feel a bit odd.) Even with this flexibility, I was still largely fitting my life into a general framework that I had very little control over. Ultimately, I ended up not liking the expectation to be somewhere at a specific time, even though admittedly, that rigidity was less rigid than what others generally experience day-to-day.

As a freelancer, I have the final say over what my schedule is. I get to take a look at the work that I need to do on a day-by-day basis and determine how much time is required to get that work done. I then get to fit this work into my day in a way that is more symbiotic with my other obligations and desires. If I feel more inclined to read and write in the morning or afternoon, I can do so, and give myself time to do client work afterward. This is the opposite of what the standard working paradigm is, and it works very well for me.

Commute

Not only did I have to be at a place at a certain time every single day, but in order to get to that place I had to commute. You know, I had a commute in Montana to and from my office in Missoula. That commute involved getting in my car, driving 1 mile east for 5 minutes, parking my car, and getting out of my car to walk up three flights of stairs to reach an office. This was a tolerable commute. Hell, I would have tolerated an extra 10 minutes on top of that so long as the weather wasn't terrible.

What did my commute look like in San Francisco? I'm glad you asked. I would hop on one bus that would show up whenever it felt like down the street from my house and take that to Van Ness street. This is already a rude awakening since Van Ness is where the downtown San Francisco techno-dystopian hellscape begins. I would then wait for another bus that shows up whenever it felt like and ride that until I got close to my office, where I would then walk the remaining distance. This whole process took anywhere between 35–60 minutes on average, depending on the inclination of the San Francisco Municipal Transportation Agency. I will note that this was when I lived 2.5 miles away from Asana. I decided to move further west in the city because my rent had increased, and I wanted to save money and get further away from the busyness of the city. This additional two miles added another 15 minutes on average to my commute time and put me on a bus that was, on average, packed with even more people trying to make their way downtown.

Needless to say, between having to be somewhere at a particular time and having my mechanism to get there be a (sometimes literal) shitstorm, the morning was not always my favorite time to be a human being. Enjoying my cup of coffee without somebody blasting a boombox and rolling a cigarette in the back of a bus is ideal for me.

Meetings

Oh boy, let's talk about meetings. Over the course of my five years at Asana, the number of weekly meetings that I attended, and the duration of those meetings, increased year-over-year. In the beginning, there was a weekly team sync, as well as a one-on-one meeting with my manager. These were my standing meetings, and any other meetings, which occurred pretty infrequently, were to discuss project related or company-wide matters. I was very happy with the ratio of work to meetings in my first few years at Asana.

As the company grew larger and, specifically, the web development team grew larger, so too did the amount and duration of our meetings. In lieu of finding other processes by which to mitigate our meeting load (cough, the product we were building), the fallback had become more frequent and even longer meetings. If you've been following along, this falls under "being somewhere specific at a certain time." This is something that I do not enjoy, but its effect is even more pernicious, given the interruption that meetings cause during the day. Meetings force context switching, which, if you're unfamiliar, is horribly unproductive.

As a freelancer, I have, on average, 1–2 meetings every week, with no meeting lasting longer than one hour. Many weeks, I will only communicate asynchronously with clients and collaborators via Slack or Asana without the need for a proper meeting. Do you want to know something? All of the work that I need to do is still getting done, decisions are still being made, and everyone is up-to-date on project progress. In fact, and I have no hard numbers to back this up, but freelancing feels way more productive than working in-house ³. Fewer meetings play a large part in that, but they are only part of a higher order category under which productivity is achieved, which is minimizing context switching—more on that in one line break.

Context switching

Context switching is the act of moving from one context—that is, the conditions under which something occurs—to another context. This is normal and something that happens constantly throughout our daily lives. However, to achieve maximum productivity doing something, you need to be focused on that something. Focusing requires both deliberate effort and minimal distractions. I have the former in spades, but I had the latter in undesirable quantities while working in an office.

This isn't anything specific to Asana, but I believe it's mostly a result of the office environment in general. Asana is full of a lot of great people that I enjoyed being around and conversing with, and if you know me, you know that I love conversing. There is both good and bad to this. The good is that I have the privilege of being around a bunch of humans that I enjoy on a daily basis. The bad is that being around those humans created an amount of distraction that detracted from my day-to-day productivity. Whether it was so-called "water cooler talk," answering questions and helping co-workers, attending meetings, or any of the other number of things that can happen as a result of working with hundreds of other people, I was distracted. This had a negative impact on my ability to focus, which had a negative impact on my ability to do my job effectively.

I could take my laptop and work in more remote areas of the office to avoid other people. However, this came at the cost of sacrificing comfort for focus. I like working at my desk with my split keyboard, huge monitor, and a comfortable chair. I am generally more productive working at my desk than anywhere else, but I am also more productive when I'm not being distracted. Unfortunately, working in an office forced me to choose between one or the other, which ultimately led to dissatisfaction with my work environment.

Since I started freelancing, I have primarily been working from home in a desk setup that I configured after leaving Asana (and realizing that my Ikea desk and chair were going to be the death of my back if I didn't upgrade). Now, I have the best of both worlds: I have a desk configuration that is perfectly situated for how I enjoy working, and I have an environment that is conducive to focusing. The only thing I'm missing is face-to-face contact with the people that I enjoyed seeing every day at Asana. I've mitigated this feeling by being proactive in scheduling time to see my closest friends regularly so that I am not lacking in human contact.

My current home office setup. I will share a post about how I decided on my equipment in the future.

Professional agency

Lastly, and perhaps most importantly, was the distinct lack of agency that I felt over the work that I was doing at Asana. I take an immense amount of pride in the work that I do, and I always strive to do the best work that I can given the circumstances. The problem, however, was the circumstances under which I was continually doing work at Asana. As a fast growing startup, everyone is expected to move quickly to help keep the company growing, so that we can continue meeting our goals, so that we can eventually capture the market, so that we can be a sustainable company… so on and so forth.

This is all fine and good, but it came with one problem: we were usually in a state of reactivity instead of proactivity. "How quickly can we build this landing page for a new product" was my life for years at Asana, instead of "how can we design and implement a system that facilitates building landing pages quickly." Instead of reflecting on how we could make improvements to allow for better work in the future, we consistently looked towards the next project that the marketing or sales team needed to meet their goals. This led to building on top of systems that were not designed for the size and scale of work that we were doing, which led to lower quality code, which led to sub-par design implementations, which led to personal dissatisfaction. Additionally, I was usually at the tail-end of a waterfall planning process that usually happened with little or no input from me. As a result, project deadlines would be determined by the time that it was my turn for development, which offered little room for me to organize the work in an ideal way ⁴.

As a freelancer, a large part of my job is planning and organizing how the work should be done for a project, alongside doing the work. I learned after leaving Asana that I need to create the circumstances under which I create high-quality work, not expect those circumstances to arise from external forces. As a result, I am growing comfortable telling clients that I will be organizing and orchestrating the entire development-side of a project while allowing other stakeholders to organize and orchestrate the areas where they are responsible. This enables me to build web projects that I am more proud of, set reasonable deadlines for work that needs to be done, and build confidence in my clients that I can be trusted to run a web project from start to finish. I am the expert, after all, and this is what people are paying me to do.

Side note

I will note, perhaps unnecessarily, that I am not trying to rag on Asana in any way. The issues that I experienced during my time working there are not uncommon to others who work in an office setting, specifically one that is in a metropolitan area. Even still, in order to create positive change for myself, I need to clearly understand what areas needed changing. My needs and desires might be different than yours, and that's okay. We all have things that we prioritize, and the trade-offs and decisions that we make are going to be a result of that prioritization.

Upward and onward

This was a pretty long-winded post, but there was (and still is) a lot for me to unpack. I also realize that there are more things that I touched on that might be suitable for their own more comprehensive post in the future. Even still, I appreciate you sticking with me throughout all of this; including those of you reading this blog post who don't know me at all, and those of you reading this who do know me and have given me unconditional support throughout all of these years. I appreciate each and every one of you.

As for me, well, I'm now a freelancing web developer once again (well, I have been for almost eight months, but I already went over that). If you are interested in hiring me for a web project, you should get in touch and we can talk more about it. I'm a systems focused front-end developer, which I enjoy working on projects where I can help architect and implement solutions that solve problems, big and small, in an intelligent and scalable way.

If you are reading this and find what I have to say compelling or interesting, I encourage you to sign up for my newsletter. Writing is something that I have wanted to do more regularly for years, but I have not made the time to do it until recently. I plan on writing about my experience as a freelancer, which will include sharing my thoughts and ideas, which you might be able to use for your own career. I will also be occasionally sharing web development tutorials, tips, and musings if that is up your alley.

And of course, if you feel so inclined, leave a comment down below and tell me what your thoughts are. Have you had similar experiences working in an office environment, or is the office environment more conducive to productive working for you? Either way, I would love to hear your thoughts and opinions.

Of course, I expected the transition to remote-friendly work to grow steadily over time, but the unfortunate spread of Covid-19 seems to have kicked a foot into the back of companies' asses who were resistant to setting up an infrastructure that allowed for remote-friendly work. ↩
Growing up with a completely informal education as a web developer ended up creating some confusion when I tried taking the skills that I had and match them to job listings I found online. I had no idea what I was; was I a web developer, web designer, front-end developer, software engineer, blah blah blah. Anyone who has applied for a technology job before probably knows how horrible job listings are. That, combined with my lack of understanding about what exactly I was as a professional, led me to a bunch of awkward phone calls where both parties fully understood that I had no idea what I was talking about for a job to which I had applied. Oops. ↩
I may not have hard numbers to back it up, but the number of projects that I have been able to complete during my first six months freelancing dwarfs what I was doing at Asana. Sure, this is anecdotal and there are plenty of caveats I could make, but I'm listening to my gut on this one: I'm much more productive right now than I ever have been. ↩
I will note that the process for organizing and executing web projects got much better during the last year that I worked at Asana. After years of being at the tail-end of waterfall planning, I was finally having more of a say in the planning process, which allowed for more flexible deadlines and better project planning. However, we still acted as a mostly reactive team, and rarely created time for ourselves to improve our processes and infrastructure. ↩