Many people questioned this decision, which is perfectly reasonable considering my short tenure. I myself still question it. Did I make the decision in haste? Will being out of work for several months drop an atomic bomb on my previously successful engineering career? Will the current economic situation effect my ability to re-enter the market when I am ready? What about my job gap? Will people think that I'm incapable, lazy, or entitled for taking this break when so many would do anything for the job that I threw away?

I've been working as a (self taught) web engineer for a little over 3 years. This is not a long time, although it's consisted almost entirely of fast paced work in small companies. Within the span of 3 years, I have worked full time for 4 companies. I was promoted to "mid-level" around the 2 year mark, and was in line to receive a promotion to "senior" towards the end of the 3rd (startups are a bit heavy handed with the "senior" role award, imo😅).

So, what went wrong? In short, I believe I burned out. On everything. Not just the act of writing code, but being a participant in corporate bureaucracy, late stage capitalism, SCRUM, deadlines, office politics, and the requirement to "always be learning". I began to hate every product I worked on. I was filled with a bitterness and exhaustion that did not fade even after my working day was over. In the morning I'd open my work laptop and cry out of frustration. Sunday nights were filled with dread.

While I am proud of my success, the pace at which I was advancing was unsustainable. I was constantly pushing myself to do more, and earn more. I accepted increased responsibilities when I knew that I could not manage them in a healthy way. I worked through holidays. I attended meetings on days that I had called in sick, and would participate in Slack correspondence from the beach during vacation with family. I was always thinking about work. In the shower, during dinner, before falling asleep, sometimes I'd encounter it in my dreams.

🔥 I once set an office microwave on fire after forgetting to add water to my instant mac and cheese, due to being so shrouded in my thoughts about a work task that I'd lost all sense of the present. Coworkers were not stoked about the smell.

I place the most blame for this experience on myself, I've been very lucky to have worked for companies that overall value WLB. I succumbed to the poison known as "hustle culture" when I could have done a better job establishing boundaries and realistic expectations. I'm exploring the reasons behind my inclination towards workaholism. I've so far boiled it down to a few possible culprits.

1. I'm self taught. I constantly feel that I need to prove that I am capable of doing the job.

2. I was recently diagnosed with OCD. I suspect that this has partly driven my tendency to overwork. It's not uncommon for me to review my own pull requests obsessively until I feel that they are perfect, which has led to exhaustion on more than one occasion.

3. I have fallen victim to consumerist habits, and a materialistic lifestyle. Lifestyle creep is a very real thing. I was once happy with less. I would thrift, buy store brand groceries, and eat out sparingly. Now, I live in a luxury apartment with an extra bathroom that I don't even use, buy my clothing new, and buy things when I'm unhappy and desire a dopamine boost (did I really need an embroidery machine?).

So… what now? I am still figuring things out. I am spending time practicing living more slowly, and living with less. Watching your savings drain slowly is an excellent way to introduce moderation back into your life. I'm slowly building up to coding for fun again (The "small web" has been super inspiring!). I'm reading for pleasure. I'm developing a more consistent exercise routine. I'm learning how to be content just existing. What is my purpose outside of writing software for SaaS companies? 🥴

What will make me happy? Is it working less? Working for ethical companies that produce ethical products? Non profits? How can I prepare myself to re-enter the market in a few months time truly refreshed and ready to set healthy boundaries? Is the software field where I'm supposed to be, or is there something else I'm destined for? I'm privileged enough to have a sizable chunk of time to strategize. And for that, I am thankful.

It wasn't until my adult life that I was able to look back on this experience and recognize it as the first manifestations of my Obsessive Compulsive Disorder.

For as long as I can remember, I've struggled with what I used to describe as "anxiety". People would ask me what I was so anxious about. Much of the time, I was unable to determine a direct cause. I was often plagued with intrusive thoughts, some so bizarre and distressing that I began to question my own character. They seemed to appear at random, and I developed several mental (and occasionally, physical) compulsions that I'd repeat until the darkness lifted.

While my OCD has roots that reach back into my childhood, it became a most powerful poison when I began my career in software. As an unassured young woman in my early twenties, I found the corporate world incredibly daunting. I wanted desperately to succeed, and allowed my "perfectionist" tendencies to take the helm. I'd obsess over every line of code, every story requirement, every social interaction with my colleagues. I'd review my own pull requests until my eyes were sore. My morning showers were spent mentally replaying my actions from the day before, and I'd hit myself if I recalled anything unsatisfactory.

Unsurprisingly, these patterns led to severe burnout after a few years in the field. Defeated and exhausted, I finally turned to a psychiatrist to explore what might be wrong with me and how I might fix it. I was diagnosed with OCD, and prescribed an SSRI that "might help" with symptoms. Due to my fear of brain altering substances, I have yet to take this medication (more on this another day).

However, I have been working to overcome my destructive tendencies in the small natural ways that I can. Receiving a tangible diagnosis to what was once a mystery ailment has been instrumental in taking steps towards a healthier existence. There are a few fundamentals that I've been returning to during episodes.

1. Distressing mental experiences are intrusive thoughts. They are a symptom of my OCD and they are not an indication of some sort of evil lurking inside of me.

2. My intrusive thoughts are not random. If I concentrate, I can identify their trigger and work towards dispelling them in a healthy way. Example: If I'm having an intrusive thought about a sharp object lodging into my eye, it's likely due to catching a glimpse of something sharp lying around. I can locate that trigger, touch it, and remind myself that I am in control of it. Intrusive thoughts are merely thoughts, they cannot hurt me.

3. I can overcome regular obsessions by running towards them, rather than away. When I leave the house I almost always face the obsessive worry that I've left the stove on and my apartment will burn down. I allow the thought to occupy space in my brain, and I take a meditative moment to try to solve it logically. In the past, I've tried to fight that worry by attempting to push it out of my head - which only makes it stronger.

It is unfortunate that OCD is generally recognized as merely a boon for keeping a clean house, or organizing a sock drawer. When left unmanaged or unrecognized, OCD can have severe reprecussions on the human mind. I don't think that I will ever be able to completely erase my OCD. However, I'm learning how to put up a hell of a fight.

While I am delighted to see that accessibility has finally been invited to dinner at the table of design and development, I am concerned that there are groups using it as a device to gain approval from users for the purpose of profit.

Early in my career, I signed on as a developer for a small SaaS shop that was in the middle of overhauling their application to be WCAG 2.1 certified. Implementing the necessary fixes proved to be tedious work, but I was ecstatic to be a part of the push to make a small portion of the web accessible for all. I imagined myself as a blind user, would I be able to use the app to the same degree as I would sighted? Could I navigate this section of the application without a traditional mouse?

After the certification was secured, there was a company celebration. The CEO spoke to the team's accomplishments, and I was disheartened to hear the discourse sway in favor of how the achievement would present the company as more "ethical". Being fully accessible would help us gain an advantage on our competitors. It would siphon more money into the company accounts.

Unfortunately, this perspective on accessibility is growing increasingly common in the tech world. Accessibility advocates often feel that they must present their case for accessibility with a capitalistic flair. "It will be good for business", and "If we don't make the site accessible, we may be sued. Did you hear about the Domino's case?".

The result of a profit driven approach to accessibility is that the implementation is often superficial. Developers are allotted time towards feature development for the able. Accessibility is seen as a technical debt to be corrected when there is down time (the catch is that there will never be down time). It's "important enough to note", but clearly not important enough to be a feature requirement. Buggy third party accessibility widgets are copy pasted into the source code, some phrase about "striving for accessibility in all that we do" is added to the company mission to demonstrate virtue. But this is not good enough.

As developers, designers, product managers, and technology users in general - we must advocate for web accessibility because it is the right thing to do. When we hear profit based arguments, we must combat them. Have we no empathy for the disabled? The elderly? The cognitively impaired? The working mother with a baby in one arm? When we accept lazy attempts at inclusion for profit, we lose sight of what is most important: The web is for all.

While it's true that the rules of web accessibility can be sometimes complex, there are a few simple things that you can keep in mind when developing static sites that will have a tremendous impact on those who wish to partake of your work.

1. Do not remove focus styling on interact-able elements.

   You can alter it to suit your site's aesthetic, but ensure that it remains clearly visible. Keyboard users must have a visible indication of the element they are focusing. Without this, the user will likely become lost attempting to navigate your website. You can test keyboard navigation on your website by pressing the "Tab" key to jump to the next focusable element, or "Shift + Tab" to jump to the previous.

   Example: A focused link from this website with a visible focus ring -

   

2. Use HTML semantically.

   This can become a rabbit hole with more complex markup, but there are a few common errors that can be easily demonstrated and corrected:

   📍 Do not use the "anchor" and "button" tags interchangeably. They are programmed to behave differently when accessed by a screen reader. Use an anchor tag when you want to navigate the user somewhere. For all other interaction, use a button.

   📍Avoid using "div" and "span" tags to hold meaningful content. These tags are primarily meant to be used as container elements, and they do not receive any contextual handling when accessed by a screen reader. There are many other semantic tags to use for your content instead. A common tag is the "paragraph" tag for any length of general text content.

   📍 Header tags on the page should follow a natural hierarchy (h1 > h2 > h3, etc.). Do not use "header" tags exclusively for their native font sizes. If you need that h1 to be smaller, target it with CSS instead of using a top level h3.

3. Provide image descriptions for low/no sight users with the "alt" attribute on "image" tags.

   The content of your alt tag should describe the image in detail. Use natural language and sentence structure, imagine that you are describing the photo for yourself if you were blind. Including words such as "image" or "photo" are redundant, as screen readers will first announce that the element is an image.

   Example:

   <img src="someSource.jpeg" alt="A stack of seven pancakes slathered in golden syrup and garnished with several blueberries and bananas."/>

4. Maintain readability by ensuring that text and background color contrast is high enough to discern between them both.

   For example, pink text on a slightly lighter pink background makes content difficult to read, particularly for those with low vision. This color contrast checker is an excellent tool for determining color contrast accessibility when you're unsure.

5. Avoid use of "autoplay" on media.

   This may come as a bit of a bummer, as it's normal to want to share your favorite song or video with site guests. However, when you autoplay media without consent it can present a confusing situation for those with cognitive disabilities - especially if the source of the sound is difficult to locate. Sound can also overpower screen reader output, making for a frustrating experience for those who depend upon this technology. Additionally, some videos may be dangerous for viewers with photosensitivity, and it is best to allow them to decide for themselves if the video is safe to play.

This is by no means an exhaustive list, but it covers a large chunk of common mistakes that lead to poor web accessibility. If you're unsure if your site is accessible, Wave is a wonderful tool that will conduct a "scan" of your page to determine baseline accessibility violations.

The small web is a wonderous thing, although it can be a bit of a "wild west" when it comes to accessibility. With these few tricks in mind, we can work together to make the small web more usable for all who wish to enjoy it. 💞

While I knew that I wouldn't be pleased with my discovery, I still wasn't prepared for the number reveal. I was averaging 6 hours of screen time a day, nearly 40% of my total waking hours. The remaining percentage of my conscious time was largely spent at work. I was living to work, sleep, and doom scroll. How could I have let this happen, and how could I fix it?

Almost all of my screen time was spent browsing the unholy duo of Instagram and Reddit, Instagram receiving the most of my attention. I had developed a near crippling addiction to Instagram Reels, an endless stream of short form video content that closely mirrors that of Tik Tok (In fact, many Reels are simply reposts of popular Tik Tok videos). I'd open up Instagram with the intention of browsing my curated personal feed of art, but had a difficult time resisting the "Explore" page button. With a single press, I was in the land of Reels - and my evening a thing of the past. At times, I would feel physically exhausted by my own addition. I wanted to stop scrolling, but breaking myself out of the stupor was challenging.

I decided to start exploring the causation for my social media addiction. While quitting cold turkey might help subdue my hunger for a time, I would likely relapse without an understanding of the root of my problem.

I've been battling major depressive disorder and OCD for the past decade, which together form a delightful little cocktail of madness. Over the years I've developed a tendency to distract myself from it. If I allow myself to exist in the present moment, I am often crushed by the weight of it all. To prevent this crushing, I must always be "doing" something. For a long while I threw myself into a vast expanse of ever changing hobbies. One week I'd be obsessively crocheting malformed teddy bears, the next I'd be 3D printing a row of rainbow colored frogs. This was a problem in itself, as I yearned for the ability to develop a mastery in a single hobby but never was able to cross the line from "amateur" to "pretty okay".

Somewhere along the way, I grew even less interested in my spice rack of hobbies and more interested in viewing the manifestation of other people's hobbies via social media. It started out as a means to seek inspiration, until eventually I became completely lost in a monstrous castle of "content".

The rise of the "For You" content algorithm on most popular social media platforms has segued us into an "attention economy" that can be difficult to eject from. Instagram is carefully engineered to keep you firmly planted on the couch, scrolling away with a reckless abandon. The more of it you consume, the more profit they reap. It's not only Instagram that flourishes, there's a piece of the pie for everyone! Feed the feeds, and you too can become a wealthy "influencer" who doesn't require a 9-5 to put food on the table.

Instagram Reels are designed to grab your attention, but only for a moment. They are a means of instant gratification. Wandering through a long, carefully plotted video of 12 minutes feels cumbersome when you can endlessly scroll through 6 second videos that stimulate your senses and trigger an instant dopamine hit. This infinite stimulant allowed me to distract myself from the discomforts of living in my own skin, with a required effort level of zero.

Over the years, I have felt my attention span shrinking. My willingness to toil over my own art has plummeted. At some point I stopped reading for pleasure, which was a sign that I'd truly lost the essence of myself. I would scroll through social media while eating breakfast, during my lunch break, during dull moments in remote meetings. Every night I'd lie awake in bed before finally exhausting myself to sleep, flicking my thumb across the small LCD screen that contained my entire world. If I could only regain the time I lost after putting my attention up for sale to the highest bidder.

I've come to the conclusion that I have an underlying dopamine addiction that's being fed most comfortably with predatory social media platforms. After mulling this conclusion over for a while, I decided to uninstall Instagram from my phone. My account still exists, but if I want to access it I must do so on my computer. Luckily, the Instagram web app is 24-karat garbage, and I have not been tempted to use it once. My screen time has been reduced drastically, although I still have some work to do when it comes to my morning routine of coffee and Reddit.

While I am beginning to feel myself return to the cusp of life, a problem still remains: my need for distraction. I've been attempting to fill the gaping hole that Instagram has left in its wake with other things. I've taken up crocheting again. I've crocheted a stuffed bumblebee that's quite embarrassingly crafted. Tomorrow I want to try an elephant. I'm nearly finished with "The Wise Man's Fear", a hefty fantasy tome that clocks in at 994 pages. I think these are good things. They require more brain power and deliberation. They force me to slow down, and not indulge my desire for an instant reward. But are they merely another means of diversion from my ever encroaching depressive tendencies?

I'll likely be nursing an "instant gratification" hangover for a long while. Every day I can feel the effects of its lingering poison - when I'm poised to drop crochet for embroidery, or in line to purchase another book that I don't actually need. What gives me hope is the fact that I've developed an awareness of my illness. Today I returned an arm full of assorted craft supplies to their respective locations in a Jo-Anne's. I didn't need them. I have enough yarn at home. Purchasing them would have given me the hit of pleasure I craved, but only for a moment. I would have regretted my purchase upon my arrival home.

So here's to me, and my long path to recovery from temporary satisfaction. May it be a worthwhile journey. 🥂

The company’s greatest interest is remaining profitable. Employee retention generally leads to more profit, as turnover is an expensive affair. I do not believe that the offering of perks is erroneous, but I am concerned about the commonality of their weaponization. Employees in these environments often develop a reverence for their employer. LinkedIn is overrun with office workers singing praises to their corporate overlords for their unbridled displays of ‘selflessness’. While I may come across as thankless, I find this sort of worship disturbing in an industry where a ten hour work day is both common and celebrated.

Let’s pluck one of these perks off of the shelf for a closer inspection - “Unlimited PTO.” While some companies offer a set amount of paid time off, usually somewhere in the ballpark of fourteen days annually in the US, others claim that you can take as much as you want so long as it falls into the umbrella of “reasonable”. This sounds like an ideal set up, until you consider the manager in charge of determining what constitutes as reasonable. Most employees who are offered unlimited PTO take less time off than those who are allotted a set amount. Why?

These employees often worry about how their desire to take time off will reflect on them. They may study their colleagues, who are feeling the same discomfort, and decide to forgo vacation because everyone else has. Held captive to the grindstone by an endless showering of perks, they may wonder how cashing in on a vacation may affect their standing with such a wonderful company. They wouldn’t want to sour their reputation and have to return to a workplace where vacation is limited, so they inadvertently impose this limit on themselves. The downside is that unspent unlimited PTO is not reimbursed at the year’s end, nor does it carry over to the next. It can be quite cost effective for the company.

I recently worked for a startup whose culture revolved around “rockstar engineers”. A “rockstar” is a person who conducts entirely too much work for the pay they’re allotted. Tech companies seek out rockstars with baited breath, and perks are a means of luring them in. It was never enough to pursue the requirements of one’s current job title - giving “110%” was mandatory. “Professional Development” was a scheduled weekly requirement. Those who weren’t spending time coding up side projects in addition to their heaping basket of regular work were seen as lazy and ungrateful for the company’s “interest” in their development. I was mentally bankrupt from maintaining my regular workload, but felt that I could not speak up about these extra requirements without risking my rockstar reputation.

I spent over a year on this treadmill ever increasing the pace of my sprint. It led to a hearty promotion, and the endless praise of my superiors; until I all but flew off of the machine from exhaustion. I spent nearly eleven months without taking any vacation, a period in which I was encouraged to not take any of my “unlimited PTO” until the current project was released. The resulting burnout has led me to my current sabbatical.

Perks are not inherently bad, but they can be misused to create a feeling of guilt when employees entertain taking time off, or look for a new job. This showering of “exclusive bonuses” can entice the employee to work longer hours for no increase in pay. While these bonuses are becoming more common, they’re not necessarily standard. The threat of losing these perks can be a sort of ball and chain for employees who are unsatisfied with their jobs, but don’t want to lose offerings such as unlimited vacation. They have become a golden cage, much like the golden handcuffs of a high salary.

When job seeking, ask yourself if you’re interested in the work, or merely the perks. Perhaps the perks are truly just an icing on a delicious cake, or perhaps they’re a device to gain entry to your soul.

Both options mentioned are robust and perfectly capable, but were a bit bulky for my needs. Considering my current state of having too much time on my hands, I decided to jump on the chance to learn something new - I've never used or written a SSG before.

Javascript is the programming language that I'm most comfortable with, so I chose to write my SSG engine via Node.

This site houses a blog that's frequently updated, and I needed a way to generate HTML pages from markdown files to avoid laboring over hand-written HTML for each post. I decided to use Showdown to handle the parsing. It's intuitive, and requires just two lines of code to get the ball rolling.

Templating

To avoid copy pasting chunks of markup throughout my pages, I utilize a templating language for Node called Pug. Being a javascript junkie, I had initially accomplished this templating using JS template literals. While it served its purpose, long template literals can be cumbersome to manage, and I quickly acquired a headache updating them. Pug, looking a bit like a twisted love child of Python and HTML, offers a much cleaner solution. It also allows for inline JS execution, which is quite handy.

Chunks of Pug can be plugged into other Pug files for reuse via a system called "mixins". This feature is particularly useful for my Navbar, which renders on nearly every page of my site.

//nav.pug
mixin navWithHeader

h1 Sleepy dev 🌙

ul(id="nav")
    li
        a(href="index.html") 🏠 Home
    li
        a(href="about.html") 🧸 About
    li
        a(href="thoughts.html") 💭 Blog
    li
        a(href="microblog.html") 🐛 Microblog
    li
        a(href="misc.html") 🗃 Misc.
    li
        a(href="guestbook.html") 📓 Guestbook

Below is an example of a Pug file that I use to generate my thoughts.html page, which renders a list of all of my blog posts in reverse chronological order.

//thoughts.pug
include  nav.pug

doctype html
html(lang="en")
head
meta(charset='utf-8')
title="Sleepydev"
link(rel="stylesheet"  href="index.css"  type="text/css")
link(rel="icon"  type="image/x-icon"  href="assets/favicon.png")

body
+navWithHeader

- const  sortedPosts = postData.sort((x, y) =>  new  Date(y.pubDate) - new  Date(x.pubDate))
    ul
        each  post  in  sortedPosts
            li
                a(href=`posts/${encodeURIComponent(post.title)}.html`)= post.title

a(href="feed.xml"  target="_blank") 💥 Subscribe via RSS

The (relevant) file structure of my SSG looks something like this: src/ houses my generation logic and layout files, posts/ holds my blog post markdown files, and site/ is where the generated static site files live. site/ is what's uploaded to Neocities.

src/
├─ thoughts.pug
├─ postMetaData.json
├─ post.pug
├─ index.pug
├─ nav.pug
├─ index.js
├─ rss.js
posts/
├─ blogPost.md
site/
├─ assets/
├─ posts/
│  ├─blogPost.html
├─ index.html
├─ index.css
├─ feed.xml

Generating files

The following JS block loops over each markdown file I have in my /posts folder, converts each to a string of HTML , and passes that HTML chunk into a Pug render function to be consumed by a Pug template file that wraps the chunk in layout code. The final HTML string is written to a .html file in the /site folder.

const  converter = new  showdown.Converter();

fs.readdirSync("./posts/").forEach((filePath) => {
    const  postHtml = converter.makeHtml(fs.readFileSync(`./posts/${filePath}`, 'utf8'));
    const  pageHtml = pug.renderFile('src/post.pug', { postHtml:  postHtml });
    const  fileName = filePath.split('.')[0];
    fs.writeFileSync(`site/posts/${fileName}.html`, pageHtml);
});

Post "metadata" is generated automatically with each build. New articles are assigned a publication date of the current date. I could also assign a publication date to each article manually within the markdown, but this solution is working well enough for now.

postFilePaths.forEach((file) => {
    const  fileName = file.split('.')[0];
    const  postMetaDataExists = postMetaData.find((data) =>  data.title === fileName)
    if (!postMetaDataExists) {
        postMetaData.push({ title:  fileName, pubDate:  new  Date() });
    }
    fs.writeFileSync(`src/postData.json`, JSON.stringify(postMetaData));
});

My blog features an rss feed, which is generated with the help of an rss Node package. In hindsight, my feed is simple enough that I could forgo usage of this library; but it's working well and I haven't felt compelled to roll my own solution.

//rss.js
const  writeXMLFeed = () => {
    const  postMetaData = JSON.parse(fs.readFileSync('src/postMetaData.json'));
    const  converter = new  showdown.Converter();

    const  feed = new  RSS({
        title:  "SleepyDev's Blog",
        description:  'SleepyDev Blog Feed',
        feed_url:  'https://sleepydev.neocities.org/rss.xml',
        site_url:  'https://sleepydev.neocities.org',
        webMaster:  'SleepyDev',
        copyright:  '2023 SleepyDev',
        language:  'en',
        ttl:  '60',
    });

    postMetaData.forEach((post) => {
        const  postContent = fs.readFileSync(`posts/${post.title}.md`, 'utf8');
        const  contentHTML = converter.makeHtml(postContent);
        //strip out the header to avoid RSS readers repeating it
        const  contentWithoutHeader = contentHTML.split('</h2>')[1];

        feed.item({
            title:  post.title,
            description:  contentWithoutHeader,
            url:  `https://sleepydev.neocities.org/posts/${encodeURIComponent(post.title)}.html`,
            date:  post.pubDate,
        });
    });

    fs.writeFileSync(`site/feed.xml`, feed.xml());
};

While it's a little hacky (my speciality) and clearly not well optimized, the setup has been treating me well. This generation pattern also extends to my microblog, booklog, and short fiction journal. Knowing that this automation will take care of most of the heavy lifting for the content heavy sections of my site encourages me to spend more time focusing on writing and less time grinding out hardcoded markup. 💫

In addition to blocking release cycles, code review can prime one's system for scheduled anxiety attacks. Feedback is important for growth, but we are all human (for now), and it can be difficult to separate creation from creator when receiving criticism. Code is essentially an extension of the writer's brain, and there are ways to critique it without jeopardizing the mental health of the author.

In my eternal pilgrimage to de-cringify code review, I employ these foundational principles.

Pre-work: Establish reasonable and firm code style standards

One of the primary culprits for an exasperating code review is the lack of a "source of truth" for important code style standards. Reviewers are forced to labor over small, but important offenses that would have never seen the light if core principles were enforced with documentation and automated linting pipelines. As a bonus, this precedent will also help new engineers quickly onboard and adapt to your team's coding style.

1. Explain the "why" behind your change requests.

Few things are more harmful to a budding engineer than change requests with no explanation. Provide documentation and links to resources that explain your points if they are available. Your explanation does not need to rival the length of a novella, but it should provide the author with a foundation to understand your perspective and conduct their own research on the matter. This helps cut down on repeat offenses. It encourages the author to take the time to learn something new, rather than push up poorly understood changes for the sake of a quick merge.

2. Make your intent clear

It can be difficult to determine tone and intent in review comments. Does the comment denote a required change? Is it merely an observation, or personal opinion? Much time can be wasted on deciphering tone and following up with additional questions. An excellent, concise way to combat this ambiguity is to utilize a documented "emoji code" when leaving review comments.

Example:

👍 : Great work! (Positive reinforcement of things that the author should continue doing)

🔧 : This is a strong recommendation rooted in good practice and intention, but not a change requirement.

❗: This must change. Reserved for more serious offenses that would cause harm to the product or codebase.

💭 : This is an observation. I have thoughts, but no firm solution. (Great for encouraging discussion)

🙃 : Nitpick. A personal opinion on how something should be, but not a requirement or anything serious. (Use this sparingly).

3. Whenever possible, avoid nitpicking.

Nitpicking tends to take the passenger seat at code review when it barely deserves a pull out seat in the back. Newer developers tend to nitpick the most often - as it's easier to point out small "potential flaws" in code style than hone in on serious or complex architecture and performance issues.

Comments such as "You should use an implicit return here, it's shorter" are personal opinion, and a waste of effort for the author to digest, fix and await re-review. If your small grievance isn't in your team's style guide - ask yourself if it's important enough to become an addition. If it's not, your opinion will likely be better kept out of a code review.

4. Provide positive reinforcement often

Code reviews are primarily filled with acknowledgement of mistakes, and seldom filled with recognition for work done well. Imposter syndrome is a vicious beast that runs rampant in developers of any level, and I theorize that this is partly because praise is considered a precious resource to be hoarded rather than freely given. If you like the way that a developer solved a problem, say so! If you find a line of code beautiful, sing its praises. Thank your peers when they teach you something new.

As a younger, anxious developer in an underrepresented demographic, I grew the most when I joined a team that valued positive reinforcement. I began to feel comfortable sharing knowledge, writing documentation, and mentoring other engineers when I was finally given feedback that I was good at my job, and not on the verge of being fired like I so often assumed due to past environments avoiding praise.

5. Encourage discussion

When requesting changes, ensure that you keep the floor open for discussion and debate. Asking questions such as "What do you think of this?" when proposing alternative solutions can help the author feel comfortable voicing their concerns if they disagree or have other possibilities in mind. We all wield unique backgrounds and perspectives, and can learn from each other regardless of level or tenure.

6. Practice Empathy

Finally, it's important to incorporate empathy when reviewing code. Humans are creatures of soul and emotion. While it's important to ensure that code is up to snuff, it's also important to put ourselves in the author's shoes. Offer to pair with new developers on problems that are difficult to grasp when presenting change requests. Remember to provide positive reinforcement. Ensure a kind, professional tone when leaving comments - it goes a long way!

My productivity levels have been unstable. I teeter between “furiously productive” and “playing Guild Wars 2 for several consecutive hours”. Recently, I’ve been primarily occupied with the latter - and I’ve been consumed with guilt for failing to participate in activities of value. The guilt generally leads to self loathing, which begins a rapid spiral downwards into a pit of depression and lethargy. Once I’ve fallen into this hole, the climb upwards out and into the light feels impossible.

Rather than continue to berate myself for succumbing to “unfruitful activities”, I’d like to explore why I feel the incessant need to be “productive” during a self imposed break. After all, wasn’t rest what I wanted?

I’ve always had a difficult time rationalizing the allowance of rest. I have not indulged in a single hobby that I haven’t attempted to monetize to some capacity. Several Etsy shops later, I’ve managed to burn out on crafting endeavors that were originally supposed to bring me peace and joy. I’m brainstorming business ideas while churning the elliptical. I’m pillaging marketing sites for profit plundering gems when I have down time. I read fiction in hopes that it’ll make me a better writer, with hopes that it may lead to a life where my words sustain me.

I believe this plight is partly caused by my animosity towards working for other people. I’ve had dreams of sustaining myself independently since I was a teenager. I’ve secured small successes, but have never matched my corporate salary. Now that I have an abundance of free time, I’m crushed by the weight of my desires for “freedom”. I’ve pushed myself to produce these past few weeks, and the resulting harvest has been poor. I have produced little of value. My goal of unlocking independence feels as if it were planets away. I do have an exceptional opportunity to boost my productivity to levels unseen. But how can I do so effectively when my brain has become spaghetti?

Burnout can have a significant negative impact on the brain. It can cause memory impairment, cognitive impairment affecting problem solving and creativity, and can even lead to a weakened immune system. “Hustle culture” tells us to push through burnout, that if we power through our symptoms we will reap our rewards. But if we do not allow ourselves rest, will the fruits of our labor be of our best quality?

For me, the answer is no. I’ve allowed myself to unravel and have not yet stopped to sew things back up. My brain is begging for true rest.

This month, I am asking myself: How can I produce if I am in pieces?

I've always found the corporate way of life to be a tribulation, but the accelerated consumer viability of LLMs has transformed it into a kind of hell that I'm no longer certain I can tolerate. The startup space, of which I've been a part of for the past 5 years of my career, has been particularly devastated.

What Went Wrong?

The week of Christmas, I was handed a 50+ page Claude generated feature set proposal, teeming with invalid system assumptions and nonsensical mockups. I was tasked with providing implementation estimates on behalf of my team. This was the beginning of the end. Over the next several months, I became increasingly buried in an avalanche of drivel. Design drivel. Code drivel. Communication drivel. Bad ideas were given wings. "This is the way it is now". "If we don't increase our usage of these tools we will be left behind".

I did my best to lead by example. I continued to review code, designs, and proposals thoughtfully; despite knowing that they were not created with a comparable level of care. This asymmetry eventually started to chip away at me. I began to question why I cared so much about quality. After all, I'm paid the same regardless of my level of passion.

But, passion is what had originally made this career worthwhile to me. No matter how hard I try, I cannot seem to force myself to stop caring. I am not, apparently, able to "quiet quit". I am also not willing to offload my cognition to a language model. I will allow Copilot to complete thoughts already in motion, if I must, but I will not spend what remains of my short life babysitting "agents".

Towards the middle of the year, I resigned. I'm not sure that I'll return to software, and I'm not sure what I'll do next. The thought of a career change in my early 30s is harrowing, and I am bitter that I have expended so much time and energy aboard a sinking ship. But, I am adaptable and I will prevail. I know that I am not alone in this journey and I look forward to connecting with more people in the community who are facing similar trials.

Onwards 🚢