DEV Community: Sylwia Vargas

Adding workflows to an Astro app with Inngest

Sylwia Vargas — Mon, 15 Jan 2024 14:24:39 +0000

Inngest has recently extended support for Astro!

If you’re familiar with both Astro and Inngest, you can read about how to set up the Inngest API in Astro or explore the Inngest and Astro 'Hello World' example.

If you’re new to either technology, read on to learn how Inngest can help Astro developers to build reliable workflows, background jobs, and long-running processes.

What’s so special about Astro?

Astro is a web framework specializing in content-driven websites. It has won the hearts of the dev community thanks to its excellent DX, thriving Discord server, or maybe it’s Houston, their lovely mascot? 💜 By reducing JavaScript overhead, Astro pages load fast while also scoring high on SEO and accessibility measures.

Astro’s most common use cases include blogs, marketing sites, and SaaS websites. To see what's possible, visit the rich collection of themes (templates) on their website.

Using API endpoints in Astro

Astro is perhaps best known for building blogs and marketing pages. Because of this, a common misconception about Astro is that it is primarily a static site generator. This, however, couldn’t be further from the truth.

Although Astro defaults to a static rendering mode, you can opt in to a server-rendered mode, or even a hybrid mode combining the two. Most Astro elements (pages, routes, and API endpoints) can be either pre-rendered at build time or rendered on the server at request time/on demand.

Astro also supports custom API endpoints, which become available as API routes under your site. You can use them for tasks like accessing a database, authentication, or supercharging your website with more a complex functionality.

Custom API Endpoint use cases

Static pages are specifically well-suited for sites where content changes infrequently. They can be generated and deployed quickly, such as simple blogs, portfolios, e-commerce landing pages, or documentation.

However, there are benefits to adding your API routes into your Astro codebase, such as:

It co-locates the frontend code with the serverless functions and processes, reducing context-switching.
The product team can manage the E2E experience instead of having to rely on cross-team collaboration.

Endpoints are an easy way to add synchronous backend functionality to your website, but what about asynchronous long-running processes and background jobs?

Adding long-running processes into an Astro app

In addition to building websites, product teams commonly own other customer touchpoints such as:

drip marketing campaigns,
email notifications systems,
payment workflows (processing payments, saving information, sending an email to the user, updating the stock, sending a shipment order)

Moreover, product engineers are often responsible for long-running tasks that may require scheduling, queuing, retries, and monitoring:

scheduling posts to be published,
chaining LLM interactions,
responding to a webhook from an external system when a new user signs up,
orchestrating backend tasks (for example, triggering a queue of tasks whenever a new user is created).

But imagine that an individual product engineer could own the user flow end to end, and implement the entire functionality as part of the same codebase. In most cases, this means a lot of communication between the frontend and backend components, which, in turn, translates into: “as an engineer, you will be endlessly context-switching between different codebases.”

This is where Inngest comes in handy. Inngest takes care of making complex workflows easy to build, manage, and scale.

What’s Inngest?

Inngest is the reliability layer for modern applications. Inngest combines durable execution, events, and queues into a zero-infra platform with built-in observability.

In other words, Inngest makes it easy to build, manage, and execute reliable workflows and background jobs. “Reliable” in this context means that if a task fails, it will not only automatically retry but also provide you with all the information you need to debug it safely on the Inngest platform

How to build complex workflows with Inngest in Astro

Imagine you’d like to send an email notification to users whenever a certain event happens. Without a tool like Inngest, you'd be responsible for task scheduling, execution, and handling retries when the task failed for whatever reason, likely requiring a team of specialists and significant resources.

Instead, a single engineer, product manager, or even indie hacker can use Inngest to handle the execution but also see the error logs, have the failed tasks be automatically retried, and obtain useful metadata.

All of this is done right from your own codebase — you own the code. Here’s how it’s done:

You implement the business logic in your Astro endpoint.
The endpoint is exposed to Inngest.
The Inngest platform will call the endpoint to execute the logic you defined at the right moments. In this case, Inngest will call your function which then sends the email from your server.
If for some reason the function fails, Inngest will retry as many times as you’ve specified.
The Inngest dashboard will provide you with helpful information and tools (such as logs and manual function retrying).

Adding background jobs to static Astro sites

But Inngest is not just for Astro developers. Sometimes, some of your business workflows might exist outside of your Astro codebase (sadly).

Being language and framework agnostic, Inngest works across your entire system. You can host different parts of your workflows in different codebases and they can still communicate and invoke with each other via Inngest, without the usual mess of distributed systems (service discoverability, orchestration, retries, monitoring).

You can also send an event from an Astro site that triggers an Inngest function in another codebase.

In other words, a function owned by the product team can live in the Astro site and other functions in your backend codebase. At the moment, Inngest has three SDKs available (TypeScript/JavaScript, Python, Go) but others are planned as well -- check Inngest roadmap.

Get started now

If you'd like to learn more about Inngest, head to our Quick Start Guide for a guided tour around the Inngest Dev Server.

Or, jump right in and explore the code yourself by starting a new Astro and Inngest starter project with a single command:

npm create astro@latest -- --template inngest/inngest-js/examples/framework-astro inngest-astro

Then, open the Astro development server at http://localhost:3000 in your browser and follow the instructions on the landing page 💜

Do you have any questions about Astro+Inngest? Or ideas for apps you wanna build? Join our Inngest community on Discord or reach out on Twitter.

Happy shipping!

Talk Notes: "Simple Made Easy" by Rich Hickey (2011)

Sylwia Vargas — Tue, 28 Mar 2023 18:11:00 +0000

✨ What is this post about: As a part of my professional growth, I make time to watch tech talks. Previously, I'd just watch them but now I take and publish notes for future reference.

✨ Talk: "Simple Made Easy" by Rich Hickey

✨ One-paragraph summary: Rich Hickey, the author of Clojure and designer of Datomic, is a software developer with over 30 years of experience in various domains. Rich has worked on scheduling systems, broadcast automation, audio analysis and fingerprinting, database design, yield management, exit poll systems, and machine listening, in a variety of languages. This keynote was given at Strange Loop 2011, and is perhaps the best known and most highly regarded of Rich's many excellent talks, ushering in a new way to think about the problems of software design and the constant fight against complexity.

✨ Impression: I loved this talk. Plenty of food for thought, both with regards to my engineering work and Developer Relations. Even though the talk was delivered over a decade ago, most points are still very much relevant - and many discussions are still ongoing. That is a testament to how well-planned this talk was, but also to that some themes in the tech community discourse are universal.

Introduction

"We need to build simple systems if we want to build good systems."
Word origins
- simple - roots are 'sim' and 'plex', which means 'one fold' or 'one braid'
- complex - at roots, it means 'braided together'
- easy - at roots, it means 'lie near' (adjacent)
- hard - at roots, means 'strong'

"Simple"

Simple things are like one fold: they have one role, one task, one objective, one concept; it is focused
There might be many instances of the same simple thing - and it remains simple as long as these instances are not mingled
The simplicity can be objectively stated
my side note: simple is a language of fairy tales

"Easy"

Easy things are near, at hand, easy to obtain, they are at reach; in software, that would be an easy reach like on our hard drive, tool set, IDE
Easy things are near to our understanding, our skillset, they are familiar
my side note: easy is Swedish because to me it looks like English and German
Easy things are near our capabilities
Easy is relative, it depends on the context an individual has

Construct vs Artifact

Construct: "We program with constructs. We have programming languages. We use particular libraries, and those things, in and of themselves, when we look at them, like when we look at the code we write, have certain characteristics in and of themselves."
Artifacts: "But we're in a business of artifacts. We don't ship source code, and the user doesn't look at our source code and say, "Ah, that's so pleasant." They run our software, and they run it for a long period of time. (...) All of that stuff, the running of it, the performance of it, the ability to change it all is an attribute of the artifact, not the original construct."
We focus too much on the construct (the programming languages)
- Even though the users are infatuated with the artifact (say, the UI), the developers focus on the construct (the library)
- Our employers are infatuated with the "easiness" of the contruct, too - it's "easy" to replace a programmer and this programmer will know how to move around the codebase and use the tools because they are "easy" - near their context and familiar (though it's not necessarily easy in the sense of whether the person has the capabilities to actually code in this codebase)
We should focus on the long-term results of the use of the artifact
- Does the software do what it's supposed to do?
- Is it of high quality?
- Can we rely on it doing what it's supposed to do?
- Can we fix problems when they arise?
- And if we're given a new requirement, can we change it?
Conclusion: We must assess constructs by their artifacts
- my side note: this is a really interesting framing; to me, it's really helpful because I have been thinking a lot about how much talk there is about some libraries (say, React) and so little talk about how inaccessible the resulting UI is

Working with limitations

Only the things we can understand we can make reliable
The more extensible, flexible, and dynamic stuff is, the more tradeoff there is in our ability to understand it
We can only consider a few things at a time; this is a limited number
- my side note: some research suggests that we can't focus on more than one thing at a time and other that we can keep track of limited number of things, like 2-4, at the same time
"If things are intertwined together, we lose the the ability to take them in isolation."
- Every intertwining is adding more burden - and the intertwining (braiding things together) is going to limit our ability to understand systems
Conclusion: complexity undermines understanding

Changing things

"What is the impact of this potential change?": if you're going to change software, you're going to need to analyze what it does and make decisions about what it ought to do
"And what parts of the software do I need to go to to effect the change?": if you can't reason about your program, you can't make these decisions without fear
Once we have software, we do two things: add capabilities, and debug what doesn't work
Good joke about debugging at 15:43 mark
- Tests are useless if we can't understand our program; they may eventually fail us
Another good joke, this time about agile, at 17:27, and I'm going to quote it here: > What kind of runner can run as fast as they possibly can from the very start of a race? Sprinter, only somebody who runs really short races, okay? But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint.
If you ignore the complexity, you will slow down over the long haul
if you focus on ease, you will be able to go as fast as possible from the beginning of the race but the complexity will eventually get you, and you will accomplish less with every next sprint, and you will end up redoing things you've already done, "and the net effect is you're not moving forward in any significant way."

Easy but complex

Some things that are easy are actually complex
- they are succinctly described
- they are familiar
- they are available
- easy to use
Users don't care about the underlying complexity, they care about what the program does
Is the outcome of your work drowning in complexity?
The benefits of simplicity:
- ease of understanding
- ease of change
- ease of debugging
- increased flexibility (change things around) - modularity
Is it easier to change a knitted castle or a LEGO castle?

Making Things Easy

Make it reachable - easy to install, easy to approve
Make it familiar - it's a learning exercise
Make it simple so it's easy to understand, we are limited in our ability to understand complexity
Good point about parens in Clojure: there are some things you can solve (get more familiar, start using the tool) and some that you cannot (the tool is complex)
Developers know the value of everything and the cost of nothing (rephrased from: "LISP programmers know the value of everything and the cost of nothing" from Alan Perlis) - we talk a lot about benefits but not the tradeoffs
Avoid complexity (don't complect/braid together)
Instead, compose (place together)
- composing simple components is the key to robust systems
- it's not only about modularization
State is never simple but it is easy (familiar, at hand)
You don't need all this complexity. You can make a sophisticated system with simple tools - you can focus on the system, what it's supposed to do, instead of the constructs.
If a decision needs to be made by a person who has better context, that system is not simple.

Main points of complexity

Construct	Complects
State	Everything that touches it
Objects	State, identity, value
Methods	Function and state, namespaces
Syntax	Meaning, order
Inheritance	Types
Switching/matching	Multiple who/what pairs
variables	value, time
Impreative loops	what/how
Actors	what/how
ORM	everything
Conditionals	why, structure of the program

These can be replaced with the following simpler stuff:

Construct	Get it via...
Values	final, persistent collections
Functions	stateless methods
Namespaces	language support
Data	JSON, maps, sets, arrays, xml
Polymorphism a la carte	Protocols, type classes
Managed refs	languages like Clojure
Set functions	libraries
Queues	libraries
Declarative data manipulation	SQL
Rules (declarative system of rules)	libraries
Consistency	Transactions, values

Data is actually really simple. There are not a tremendous number of variations in the essential nature of data: there are maps, there are sets, there are linear, sequential things. There are not a lot of other conceptual categories of data. We create hundreds of thousands of variations that have nothing to do with the essence of this stuff and make it hard to write programs that manipulate the essence of the stuff. We should just manipulate the essence of the stuff. It's not hard. It's simpler.

Abstraction for simplicity

abstract (meaning drawn away from its physical nature)
"abstraction" sometimes is used in a sense of hiding complexity but that's not what it is about
If you want to take stuff apart, look at a concept and ask who, what, when, where, why, how
What
- What is the operation? What is what we want to accomplish?
- If you separate "what" from "how", you can make "how" someone else's problem
Who
- Data or entities - these are the things that our abstractions are going to be connected to eventually depending on how your technology works.
- Pursue many subcomponents so you work with small interfaces
How
- How the work happens - the implementation logic
- connect to abstractions and entities via polymorphism
- prefer abstractions that don't dictate how (declarative are good)
When, where
- don't complect with design (if A causes B, you're complectin - use queues instead)
Why
- the policy and rules of the application
- often strewn everywhere

Information is simple

Don't ruin it
Simplify the problem space or some code that somebody else wrote by disentangling:
- identifying individual threads/roles/dimensions
- following through the user story
Simplicity is a choice - it's your fault if you don't have a simple system
You need vigilance, sensibilities, and care
Easy is not simple. Simple is something that's not entangled.

Simplicity made easy

Choose simple constructs over complexity-generating constructs
It's the artifacts, not's the authoring
Create simple abstractions
Simplify the problem space before you start
Simplifying means making more things, not fewer

What I'd like to see AI used for - women's month edition

Sylwia Vargas — Sat, 18 Mar 2023 01:24:55 +0000

(this blog post is a part of a DEV celebration of the annual #wecoded campaign - earlier known as #shecoded)

As I'm nearing my fourth year in tech, I see the same discussions happen over and over again around gender in tech - and I'm tired. In the past, I found that writing about these problems always left me exhausted and deflated for a few days so now I’ll try something different: I turned the reasons for my fatigue into ideas for your next-generation AI app ✨

Salary negotiation

Contrary to common belief, women are equally as good (or bad, actually) as men in salary negotiation - that is, when they actually negotiate. Sadly, a number of factors can impact a woman's willingness to negotiate an offer, including how the job description is written:

When jobs advertisements contained female-threatening language, women lowered their salary minimums compared to when jobs were described in a female-supportive way, whereas men were unaffected. (...) If women have lower aspirations, they may feel less motivation to negotiate and simply accept the first offer.

Consistent with my own experience, another study found that women are especially good at negotiation when advocating for the salary of others:

Our research suggests that (...) women perform better when negotiating on behalf of others than they do when negotiating for themselves; no such difference emerges among male negotiators. (...) Female executives negotiating as the mentor secured compensation that was 18 percent higher than the compensation female executives negotiated when they were playing the candidate. Meanwhile, male executives performed consistently across both roles, at the level of female executives negotiating as the candidate.
(...) It's not that our female participants felt less entitled to a good salary. (...) Nor were women more or less competent at the negotiation itself. Rather, it appears that the women executives were particularly energized when they felt a sense of responsibility to represent another person's interests.

⭐️ Here are some ideas for what AI could do:

a real-time salary negotiation assistant that will provide the applicant with the pep talk, sound bites, and arguments for a successful negotiation
estimating what folks at a given salary might be making (not only via Glassdoor or Blind) and what the candidate's skillset and experience is, and based on that, suggests acceptable salary ranges
(for HR) scanning job descriptions for gender triggers and suggesting alternatives
(for candidates) an extension that replaces gender triggers in job description with gender neutral language

At work

When it comes to gender issues at workplace, there’s probably enough to fill every letter of the alphabet - and perhaps write a whole encyclopedia. Well, let me just mention five things my friends and I noticed this past year:

I see a lot of my amazing female friends partake in glue work, either voluntarily or because they are expected to.
I have watched too many sessions where men talk a lot and engage in killgissa and mansplaining in 1:1 conversations with renown women or a non-binary folks who happen to be experts on the subject
I also have heard my share of "well, actually"s and seen loads of passive aggressive nit-picky PR reviews that my female friends share with me to ask for a sanity check.
I read a lot about that performance reviews for women focus mostly on their personality, and men on their work (the same study found that men are so much more likely to be called "genius" or "brilliant" and women to be called "overachievers")
I see so many people having no problem remembering names of obscure retro games, whole lineages of elves in some books, or the 80s niche bands but that amazing memory fails them in case of personal pronouns

⭐️ Here are some ideas for what AI could do:

a Notion/Confluence/Asana extension that shows stats for glue work for different team members
a Zoom app that measures air time, including air time spent on just taking space (EDIT: I heard that Vowel does that already! Awesome in case you don't want to reinvent the wheel.)
an extension that scans a performance review to show gendered biases
an app that scans all performance reviews from the company for a given year to make sure that the same metrics are used for all folks at given a level/role/team
grammarly but for correct pronouns
a Slack app that not only checks for exclusionary language but also reminds you to use the correct pronouns - before you even send the message! (even if you can't retain that knowledge, at least you don't create a situation that's awkward at best and damaging at worst)

Tech conferences, meetups, steams, events, twitter

Time and time again, we as a tech community learn about conferences offering unequal perks and payment for talks to different speakers.

We've also seen numerous conferences that completely forgot that there are plenty experts in tech who are women and non-binary people. To alleviate that, it happens frequently women (oftentimes experts themselves) are moderators in an all-male panel.

⭐️ Here are some ideas for what AI could do:

create a list of women and non-binary speakers, together with examples of most recent talks, and contact info
create a list of male experts to moderate panels featuring women and non-binary experts
fetch a list of male tech community leaders who could deliver talks on the value of empathy, collaboration, inclusivity, team culture
find out if a male speaker you're considering is known to talk about gender equality so you can ask him to mentor a first-time speaker who is a woman or a non-binary person
get a report on whether your tech event location might be dangerous for any minority, such as LGBTQIAP+ folks in UAE or trans folks in many states in the USA
(for male community tech leaders who state allyship with women and non-binary folks) checking stats on who you are retweeting, quote tweeting positively, and liking - it's really no longer enough to just say you support women, trans women and non-binary folks but in the times of wild twitter algorithms (for some, and life-threatening trans-hatred for others), you just gotta amplify their voices and recommend them as experts

Surveys

For at least as long as I have been in tech, the "State of JS" and "State of CSS" surveys have been not only doing a poor job when it comes to survey design, data collection, and analysis - they also have done a lot of damage for women in tech. For context, the survey consistently gets only around 5% of responses from women and non-binary folks, and year after year, there's some discussion around it.

There's a lot I could say about the survey given that I taught research methods for two years as a part of my PhD in Sociology program. For example, the presentation of the data on most popular community leaders does not factor the gender of the responders, resulting in an impression that that is the ultimate list of who's who in the JS ecosystem - and it features only four women. But not if you adjust the data for demographics - then you'd already see 10 women creators there. And if the survey actually collects more responses from women and non-binary respondents, the list will be only more diverse.

But the survey design flaws are less important than its outcomes. I don't think there's any data on the actual consequences so for now, three anecdotes from my experience need to suffice:

A male friend lamented how he can't get any women into the hiring pipeline "but then again, there are fewer than 10% of women in the web dev".
A conference organizer pondered if there's even any point in diversity efforts with regards to the lineup.
A few women streamers or community leaders were disheartened by not making it to the "Top 50" list of the survey.

The organizers say they sent dozens emails to women in tech organizations and heard almost no responses. This sounds almost incredible given how easy it is to get a response for a project like that. Was there a problem with how the emails were written? Maybe when they were sent? Why emails, anyway? Why not a DM on Twitter or an intro through a friend? Weirdly enough, none of my six community organizer friends received such an email, nor did I found one in my inbox - even though I have been a co-organizer of a React community for women and non-binary folks for the past four years, and even though I myself offered such help for example here on DEV. It's really odd because I have seen Sacha Greif, the main author of the survey, advocate vehemently for women, trans folks, and all other minorities - and I actually do trust that his intentions are good.

⭐️ Here are some ideas for AI to fix it:

following the advice from the Sociology handbooks and research findings, evaluate the survey before it is released from the perspective of research method design, with special emphasis on potential biases (not only gender)
- OR: being given the goals of the survey, design one in reference to the advice from the Sociology handbooks and research findings
given the scope of the survey (JavaScript ecosystem), define the representative sample, making sure it is statistically significant, as well as the sampling method
generate ideas for tweets, toots, blog posts, Discord and Slack messages that the organizers can post in various communities when asking for help
having received responses, assign a correct weight to respondents in representing the data
scan the final report for inaccuracies and include context information

Is a better world possible with AI?

As much as I'd love to believe the opposite was true, AI is just an extension of the biases of its creators.

For example, earlier in this post I mentioned performance reviews - in fact, ChatGPT writes longer and harsher performance reviews when it assumes that the employee is a woman. It views: nurse, receptionist, kindergarten teacher as women; mechanic as a man; banker and engineer as men or neutral. Here's also a tweet about ChatGPT recommendation letters:

male name reports "spotty attendance but very bright" -- with female name, we hear about their kindness & empathy and the children they tutored.

All the above app ideas could (and should) be done not by AI but by a human - if only the humans in questions cared more, were more self-aware, and possibly less exhausted (here I'm giving a benefit of a doubt to everyone who is well-meaning but has only so many spoons). For example, I spoke about better conference lineups - if you are curious about how to design one, read this great writeup about DevOps Days authored by Bridget Kromhout.

And before you actually go and design a next AI-driven app that will change the world - see if the change will be for better. AI has been designed with huge biases and it goes majorly unchallenged.

⭐️ If you'd like to learn more about the biases of AI, follow:

Timnit Gebru who runs Distributed AI Research Institute
Kestral Gaian who teaches ethics at London Interdisciplinary School
Safiya Umoja Noble who wrote "Algorithms of Oppression"

Cover photo was designed by DALLE with a prompt: "if gender equality was a kaleidoscope image"

What is pnpm? Is it really so fast and space-efficient?

Sylwia Vargas — Thu, 13 Oct 2022 12:57:41 +0000

We announced at ViteConf that our WebContainers now support pnpm. It was a major achievement in our commitment to support the Vite ecosystem as many projects running on Vite also use pnpm (examples include Vue, Astro, SvelteKit).

In this post, I’d like to talk about what sets pnpm apart from other package managers - and why we need package managers at all. As a person who best operates through analogy, I will also talk about: 🍣 sushi, 🪦 cemetery, 🎁 birthdays, and 🖼 memes.

What are package managers?

I've also written an “Explain like I’m 5” version of this section!

Let’s start with the terminology.

package, dependency, node module

A “package” (or “dependency”) is one or a few files bundled neatly together that can be downloaded from a package registry. Once it’s downloaded and installed, it resides in the node_modules folder in a project’s directory. In this post, I will use the words a Node module, a package, and a dependency interchangeably as many folks in the tech community do. That being said, the npm docs offer a differing opinion so check it out if you’re interested in trivia and precision. 🙂

package.json

Each package has a file called package.json which contains information on the package author, its version, its dependencies, and so on. A package can have many dependencies, which in turn can also have many dependencies (called "sub-dependencies"). This sounds like a lot of files, doesn’t it! It really is, especially if your project requires bigger packages.

In the olden times, you’d manually download, install, and configure the dependencies of your app. Keep in mind that most packages are frequently updated, which means that you’d have to always make sure that your project's dependencies (and their sub-dependencies!) are up to date - or that in a given project you use a correct version of a given package. This sounds not only stressful but also unnecessarily repetitive! This is where a package manager comes in.

package managers

A package manager is a tool that helps you keep track of all dependencies of your app in a consistent way. It automates the tasks of dependency installation, upgrading, configuration, and removal. It makes sure that all the packages that your app needs are installed, of the correct version, and up-to-date. This frees so much time for coding… and procrastination 🤪

The first package manager for the Node runtime was introduced only in 2010 and it was npm, (which, contrary to popular belief, doesn’t stand for “Node package manager” and, in fact, is an empty acronym). Twelve years later, npm is now managed by Microsoft and there are two other contenders to the iron throne of the package universe: yarn and pnpm.

What do package managers do?

A package manager grabs the published source files from the online registry and installs them into a directory (a folder) called node_modules. This is the folder where your app will look for the packages when you call the require() method.

You can think about the node_modules folder as a box with helpful tools that you can plug into your app so it works in a desired way. Except that all the tools are made of iron (or osmium!) and the box is massive. What I mean to say is that, sadly, prior to pnpm the node_modules folder would usually be bulky and take a lot of disk space. This resulted in a collection of memes such as:

Imagine that you have numerous projects on your local machine, and each project comes with its own node_modules folder. Most likely, many of these projects use a similar stack. In such a case, you end up with the same packages in numerous projects. Duplication and redundancy! Think about all those inspired side projects that never left the boilerplate stage, all the past attempts to check out all the hot new frameworks - all of them are chilling on your precious disk space.

Who cursed the `node_modules` folder?

To understand these jokes, we need to take a stroll down memory lane and look at how package management has traditionally been handled.

To the best of its intentions and abilities, npm handled the dependencies by splitting the installation (which is triggered by, for example, npm install ) process into three phases:

Resolving, when the package manager is checking all the project’s dependencies (and their sub-dependencies) listed in the package.json file, finds a version that satisfies the version specifier (for instance, ^1.0.0 would install any future minor/patch versions). Afterwards, it creates a file like package-lock.json for npm and pnpm-lock.yaml for pnpm. you can think about it like a project’s equivalent of a birthday gift wishlist.
Fetch, when the package manager takes the list of resolved dependencies and fetches all the packages from the package registry, which is an equivalent of the feverish shopping in a crowded mall two hours before the party for the gifts all of your friends will give to the birthday person.
Linking, when the package manager writes all the dependencies into the project’s node_modules folder, which, finally, is an equivalent of placing all the gifts in the corner of the party room for when they are needed.

In this scenario, each phase needs to end for the next one to begin. This means that if one dependency has twenty dependencies itself or if one package takes forever to be downloaded, you may have to wait for a long time. If we follow the birthday analogy, imagine that the wishlist included a new version of a popular phone and a box of chocolates. You end up queuing for a few days in front of the phone store to only then buy the chocolates. In such a system, you can’t “save” your spot in the queue, go buy the chocolates and join the party, even if that looked like a better use of your time. You see that t*he way npm manages its tasks is just not efficient.*

As we said earlier, it is also the matter of the disk space. You will end up with numerous duplications of the same packages. And even if there are different versions of the same package, it is rarely the case that all of the files have been changed from one version to another. You still end up with some number of copies. We can agree that the way npm manages the disc space is not efficient either.

How is pnpm a solution to all our worries and troubles?

On its docs page you can read that pnpm is a “fast, disk space efficient package manager.” It really is fast - locally, up to three times faster than the alternatives - and space-efficient. But - how?

pnpm is fast

Do you remember the birthday wishlist analogy? As a gofer, npm first collected all the wishes, then bought all the gifts, then placed them in the corner of the party room. Each phase needed to end for another to begin. This is how the npm gofer organizes its way through life.

Well, if pnpm were the gofer, they’d buy the gift as soon as they’ve read the wish, and designated the spot in the room as soon as they placed the order. They may not even have the physical gift yet to already be able to mark the space in the room where the gift will stand. This happens for each gift separately and independently from others. By design, pnpm doesn’t have the blocking stages of installation - the processes run for each of the packages independently.

pnpm is disc space efficient

Let’s talk about food. I love veggie sushi. I order a lot of veggie sushi. I also eat a lot of wasabi and I don’t like waste. Even though it would be fair to assume that such portions surely are to be shared, I usually order just for myself. My order always arrives with two pairs of chopsticks even though I say on the phone that I don’t need them - I have metal ones at home. I wouldn’t just throw unused chopsticks away and now I have a drawer full of them, and you can also see them laying around in the most surprising places in the kitchen. Similarly, I have my own wasabi tube but would I throw away those little sachets? Never. They chill on the shelf in my fridge in an ever-expanding fashion.

My chopsticks and wasabi could work as an analogy for how npm manages disc space. “Oh, you’ve already installed React two hundred times? I’m SURE you NEED the 201st copy!”

To my relief, pnpm checks what is already available on your disk and only adds what you additionally need for your project to run. All the dependencies are located in one global location (for instance, ~/.pnpm-store/ - you can check it by running pnpm store path in the terminal) called “a content-addressable store”. In your project’s node_modules folder there is a .pnpm file that contains the “virtual store” with many so-called “hard links”. it creates one hard link for each file of each package. I like this explanation that pnpm docs offer:

So, for example, if you have foo in your project as a dependency and it occupies 1MB of space, then it will look like it occupies 1MB of space in the project's node_modules folder and the same amount of space in the global store. However, that 1MB is the same space on the disk addressed from two different locations. So in total foo occupies 1MB, not 2MB.

This makes the node_modules folder more like a portal (like the wardrobe in Narnia) to files located in different nooks of the global store, and not like a bloated storage unit. This diagram illustrates the strategy employed by pnpm:

But, does pnpm “know” if there are duplicate files between two versions of the same package? Yes, because, just like git, it identifies the files by a hash id (called also “content integrity” or “checksum”) and not by the filename. This means that two same files will have identical hash id and pnpm will determine that there’s no reason for duplication.

pnpm has got your back

There are so many ways that pnpm looks out for you. One of them is that it is impossible to invite silly bugs by trying to use modules that are not directly specified in the project's package.json but, for instance, are required by your project’s dependencies. While it’s not the end of the world if everything works well, what happens if your project’s dependency no longer requires one of the packages and as a result it is no longer available in the the node_modules folder? Well, everything crashes and you don’t even know why.

Such bugs may happen in npm and Yarn Classic because of the flat node_modules directory because during installation, they hoist (elevate) all of the packages to the node_modules , regardless of whether they are directly required by your app or not. As a result, your project gets access to distant “relatives” of its dependencies.

…but what if my project doesn’t support symbolic links?

And even if your project presents an edge case and doesn’t work well with symbolic linking, worry not! You can still use pnpm but set it to an npm-like mode. While it will not be space-efficient, it will still be faster.

But… what about Yarn?

There are two editions of Yarn:

“Yarn Classic”, which comprises versions below v2 and is no longer maintained,
“Yarn Berry”, which is v2 and higher.

Yarn Classic operates similarly to npm with regards to managing the node_modules folder. Yarn Berry, on the other hand, offers three solutions:

the npm-like mode
the “Plug'n'Play” mode
the pnpm-like mode, which uses hard links to reduce the disc space (not available by default and not thoroughly documented)

The Plug’n’Play seems like an intriguing option but it has been met with the community’s apprehension as the .zip files are not so easily accessible during the dev workflow. The earlier-mentioned post by TakeShape explains some of the other challenges.

Closing remarks

Considering how space-efficient and fast pnpm is, it is not a surprise that more and more projects make a move towards it and that its popularity is rapidly growing. This year, the weekly download rate for pnpm was seven times as high as last year!

If you’re interested in learning about why projects choose to switch to pnpm, check out these posts by Gestalt and TakeShape.

Come work with us on package managers!

While you’re here, an announcement: we are looking for a new team member who will work on package managers including pnpm, npm, yarn, and our own Turbo. Interested? Apply today or reach out to me on Twitter!

Hacktoberfest: docs updates in three steps

Sylwia Vargas — Wed, 12 Oct 2022 14:57:36 +0000

Hacktoberfest is a celebration of Open Source contributions and new developers are eagerly encouraged to join in. However, many projects require so much setup, which not only stressed me out but also discouraged me from considering contributing.

Of course, there is the Markdown Preview on GitHub - however, it only changes Markdown to HTML and doesn't render the whole page. You can't see how the changes you're introducing will look on the page unless you close, install dependencies, start the dev server.

But what if updating docs wasn't this complicated? Well, good news is that it doesn't have to be!

Below, I'm offering a workflow that helps you focus on the content update or creation, without the hassle of the setup. If you prefer to watch a video instead, I got you covered as well - check the end of the post!

Content editing hack

Follow these three steps for a productivity hack:

In the docs repository, find the file you want to edit - can be markdown, can be anything, really. Click "edit" icon.

In the browser's address tab, add "pr.new" to the beginning of the URL address, press enter, and enjoy updating the content.

Once you're happy with the result, propose the changes and submit a PR!

What is this tool?

What you see above is a tool called Web Publisher. It is - and will remain - free for Open Source projects and for public repositories.

Web Publisher allows you to edit any file and see the changes rendered on the live preview. You don't have to do any special setup - you can even use it on your phone (on Chrome or Firefox). Now even the new developers can contribute their talents to Open Source by proofreading, translating, editing the text without the stress of the environment setup.

I have been using Web Publisher for weeks now and it really helped me a lot in my daily workflow. The other day I corrected a dead link on our page while waiting in line for an appointment 😂

Wanna try it out?

You can either edit a page of any of the public repos or... Add your name to this page!

See it in action

In case you'd like to see how I use the tool, see this video:

At StackBlitz, we love our community. Don't be a stranger - join our Discord or reach out to me on Twitter with your StackBlitz ideas, dreams, and wishes!

One-click treat for Open Source maintainers

Sylwia Vargas — Tue, 11 Oct 2022 18:18:21 +0000

It's October. For some, a month of beautiful foliage, Halloween, and pumpkin spice. Some Open Source maintainers live through their own version of Halloween - the stream of PRs coming their way to celebrate Hacktoberfest🎃

At ViteConf earlier today, StackBlitz has just unveiled Codeflow. It is a tool that I have been using for the past few weeks to build our docs site, to quickly fix typos, and to review PRs. Codeflow is and will be free for Open Source projects and for public repos, just like other StackBlitz tools.

So, what's the charm? One click and the entire IDE for the PR boots up inside your browser. No more cloning, committing, running dependencies, stashing your local changes.

If you prefer to watch people do things instead of reading about it, let me show you how I reviewed a PR from my colleague today:

One-click solution to PR reviews

CodeflowApp bot is a part of StackBlitz Codeflow. Once you install it on your account, organization, or a single repository, it will detect PRs (and issues containing bug reproductions in StackBlitz) and immediately spin up an entire IDE so you can explore and review it.

Don't believe it? See it yourself on this pull request I prepared for you.

NOTE: you need to have a StackBlitz account.

But what is Codeflow?

Codeflow is a one-click integration with GitHub for seamless coding workflows.

StackBlitz now helps you switch contexts seamlessly:

Codeflow IDE is a fully fledged desktop-grade dev environment capable of running your whole workflow - from production-level dev work to reviewing pull requests.
Web Publisher is a publishing tool that makes editing docs or blogs pleasant thanks to a realtime preview of the changes.
pr.new is a short URL that can be used on any repository to explore code, a branch or an issue, to review a PR, or even to edit a file, all in a live environment with a realtime preview.
CodeflowApp is a friendly bot, which provides a one-click link that spins up the whole environment for pull requests and issues. No more context-switching or branch-checkouts, just a new browser tab with a full IDE and a dev server running.

At StackBlitz, we love our community. Don't be a stranger - join our Discord or reach out to me on Twitter with your StackBlitz ideas, dreams, and wishes!

Explain like I’m five: package managers

Sylwia Vargas — Sun, 09 Oct 2022 17:01:44 +0000

For a long time, the subject of package managers was for me an intimidating one. As a bootcamp grad, I knew enough to build a website or set up a database but any configuration issues stressed me out. Every now and then, I'll encounter a discussion on which package manager is the superior one and I'd immediately feel humbled by all the things I still don't know about web dev.

Now that at StackBlitz we are about to make a big announcement regarding package managers, I thought I'd revisit this topic and take an “Explain like I’m five” route 💕

Let’s look into what a Node module, a package, and a package manager are.

Metaphor: LEGO sets

I have recently visited a friend who loves LEGO. His whole house looks like an exhibition hall with colorful sets displayed in the most surprising places. There’s a flower standing on a bathroom mirror shelf, a dragon guarding the stairs, a TV series set near the kitchen table, and a wizardry school near his TV stand. I’ve noticed that in most cases one big creation was, in fact, a collection of smaller sets.

Imagine that the massive wizardry school castle is your app and for it to be complete, you need to add a bunch of extras like a train station, a magic tree, or a phoenix. Each of them is a separate entity that you can move around as you wish.

Node modules and packages

If the wizardry school castle is your app, then each of the extras would be a Node module or a package.

So your castle needs a magic tree. You could design it yourself but it is way easier get the whole set designed and packaged together in a box with an instruction. A ready-made set in this analogy is a “package” and the instruction is the “package.json” file.

A Node module, or a package, is a piece of code that helps you add some functionality to your app. The package.json file tells us who created the package, when it was created, what other “dependencies” it needs to function, and so on.

To satisfy the folks who like to be very precise, please note that the npm docs page makes a distinction between "Node modules" and "packages. However, in most cases “Node module” and “package” are used interchangeably.

Package managers

Now, if you only have one or two LEGO sets in your home, managing an inventory of all the blocks, sets, and figurines you have would not be that difficult. But what if you are a lifelong collector, pieces break often, there are new sets constantly coming out, and the available color scheme changes faster than the company manages to announce it? Well, ideally you would find a system to keep track of all the pieces you own, need to replace, no longer need, and that that you need to buy?

This is why in software there is a need for the so-called “package managers”. A package manager is a tool that helps you keep track of all dependencies of your app in a consistent way. It automates the tasks of dependency installation, upgrading, configuration, and removal. It makes sure that all the packages that your app needs are installed, in the correct version, or up-to-date.

tl;dr package managers automate all the tasks regarding dependencies, saving your precious time 💕

We will share big news regarding package managers at the upcoming ViteConf. Grab your free ticket and tune in this week (Oct 12-13) if you're curious 👀

StackBlitz Monthly Update Post: September 2022

Sylwia Vargas — Thu, 06 Oct 2022 23:04:47 +0000

Hello everyone!

At StackBlitz, we have been working hard on the new tools that will premiere at ViteConf and that I believe will be truly game-changing for Open Source maintainers.

The release will happen before a significant crowd: at this moment, 21,000 devs registered to attend ViteConf! If you haven’t yet, click here to get your free ticket. Here's mine:

Meanwhile, we have been pushing updates and cheering for our community!

Today we are bringing you:

StackBlitz in the wild: news from our community
DX & Compatibility improvements: the change log
New Teammates: our team has grown - do you wanna join, too?
Quick bites for the road

I hope you’ll have a wonderful month!

StackBlitz in the wild

Does running WordPress in the browser without a PHP server sound like fun? Here’s a delightful writeup on spinning it on StackBlitz thanks to WASM. We may soon be able to run an in-browser WordPress IDE - something to look forward to!
Wanda has just released a beautiful Design System components playground powered by StackBlitz - have a look:
tRPC, a library used for building fully typesafe APIs, added a StackBlitz demo on their homepage and we love to see it!
Matt Pocock is soon releasing Total TypeScript, a comprehensive course on TypeScript, which uses StackBlitz to help users learn as they watch the videos without leaving the browser.
Token CSS is a new tool that seamlessly integrates Design Tokens into your development workflow - you can launch a Token CSS demo with a single click!
Josh Morony created a bash script to instantly launch a fresh Angular app for test code, which publishes the app on StackBlitz 🚀 // Detect dark theme var iframe = document.getElementById('tweet-1567483037906259976-489'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1567483037906259976&theme=dark" }
neodrag has just dropped. It is a lightweight plain JS library that makes your elements draggable. You can play with it in this demo.
And finally, oh so many StackBlitz starters to choose from in the whyframe docs! whyframe is a library that “gives iframes superpowers, making it easy to render anything in isolation”.

DX & compatibility improvements

As we’re working on new tools, we are finishing the month with a whole plethora of improvements:

Bug fixes and improvements
- Updated our dashboard with new project starters: effector, NativeScript (mobile section), Quasar, Remotion, VuePress, VitePress.
- Our dashboard now features a description of each of the projects instead of the project slug.
- New repositories now have their name as a header in the README instead of the project slug.
- Introduced improvements to the Console components (for EngineBlock projects):
- Added support for console.table
- Fixed the display of NaN, Infinity and -Infinity values
- Improved the color contrast and readability of console log items.
- Improved the responsiveness of the Console when logging over hundreds of messages.
- Improved StackBlitz EngineBlock error messaging when a library referenced from the code has an entry point file that does not exist in the package.
- Fixed issue in the EngineBlock projects with importing ace-builds package due to the way that it handles AMD and the way that it specifies a webpack file-loader in its webpack-loader.js file.
- The ace editor library entry point overrides the require function with its own custom logic (amd loader).
- Fixed a bug Ctrl+S / Cmd+S not saving project if all tabs are closed.
- Fixed an issue where a standalone preview tab would get stuck in the loading state if the StackBlitz project had some sort of error. These errors are now shown to the user.
- When reloading the page, now the previously displayed screen is copied and displayed for up to 3 seconds.
- Updated our icon set to use Microsoft’s Codeicons in more places.
- Fixed an issue with the dashboard's project list not showing the “Delete this project” menu entry.
- Now user can open the commit dialog in the auto commit mode by alt+click on the commit button (GitHub Issue #2034 fix).
- Clarified the UI shown when opening a binary file in the editor.
- Binaries are now preserved when you connect git repository to a project with binaries (Github Issue #787 fix).
- Fixed the storage quota exceeded error, by using indexeddb instead of localstorage.
- Clarified context for options in the user menu.
- Now user can use git integration with GitHub "Keep my email addresses private" setting on (GitHub Issue #1963 fix).
Blog
- Replaced the generic social image and added the new social image for category index pages.
- A specific title to each Category page, instead of showing generic StackBlitz::Blog title.
- Implemented the new Netlify build image (the new Ubuntu 20.04 images).
Docs
- Created and added numerous demos, like for example this project that showcases all open file options.
- Updated the list of the custom project starters with these friends:
- analogjs.org/new
- ladle.dev/new
- NativeScript:
  - TypeScript: nativescript.new
  - JavaScript: nativescript.new/javascript
  - Angular: nativescript.new/angular
  - Vue: nativescript.new/vue
  - React: nativescript.new/react
  - Svelte: nativescript.new/svelte
- node.new/nx
- qwik.new
- rakkasjs.org/new
- storybook.new
- vitepress.new
- Refreshed content across the docs platform.

New Teammates

Our team has grown! Please meet:

Yuka Masuda, a front-end engineer, a community organizer, a talented knitter, an inspiring baker, and a loving human to a shiba inu 🐕
Dave McChesney, an Enterprise Account Executive, a skilled archer, a true enthusiast of the outdoors, and a pet parent to two wonderful poodles 🐩

Are you looking for a ✨ nurturing ✨ team to join? We have roles open for software engineers (a senior Rails engineer and a senior TypeScript/Rust/Nodde.js engineer), as well as a Product Marketing Manager.

Here are three tweet threads on how it is to work with us:
// Detect dark theme var iframe = document.getElementById('tweet-1479224585899888640-172'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1479224585899888640&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1493877657699819523-130'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1493877657699819523&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1533109972518715393-515'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1533109972518715393&theme=dark" }

Wanna learn more? Feel free to reach out!

Quick bites for the road

Are you ready for ViteConf? Our team member, Patak, spoke recently to the Storyblok folks about some of the marvels awaiting you there!
Here’s an article predicting a looming end of the localhost, inspired by Swyx’ blog post.
Puru Vijay, our team member spoke recently at Svelte Summit on how to migrate React libraries to Svelte
Do you already have a ticket for ViteConf? Just in case, it’s an online and free conference with an all-star speaker list celebrating the web ecosystem at large. Excited? See you on 11-12 October 2022!

What’s next?

We are so excited for what the nearest future will bring — we are cooking something really special for you! In the meantime, stay tuned on Twitter or join our Discord community.

Tech Talk: 'Unit Test the Docs: Why You Should Test Your Code Examples' (Write the Docs 2022)

Sylwia Vargas — Mon, 23 May 2022 17:41:32 +0000

✨ What is this post about: As a part of my professional growth, I make time to watch conference talks on Ruby, Rails, JS, React, tech writing, and tech trivia. Previously, I'd just watch them but now I will take and publish notes for future reference.

✨ Talk: 'Unit Test the Docs: Why You Should Test Your Code Examples' by Ben Perlmutter

✨ One-paragraph summary: What’s the fastest way to make developers complain about your docs? Give them code examples that don’t work. As technical writers, we face the constant challenge of keeping code examples accurate and up-to-date. Just as software developers write unit tests to validate that their code remains functional, technical writers can create code examples within unit tests to validate that their documentation is correct.

✨ Impression: I never thought about writing unit tests for my code examples or including the unit testing into CI/CD pipeline. By the way, StackBlitz has a wonderful SDK for hosting our code examples on GitHub, which helps with keeping examples up-to-date.

Notes

Unit tests
- bits of code that run other code to validate that your code is working as expected
- any non-trivial software project would have unit tests
- they are repeatable
Code Examples
- bits of code that live in the docs
- they are often copy-pastable from the docs to code so they have to be clear and reliable
- often stylized with syntax highlighting so they can stand out and resemble how they'd look in the dev's environment
When documenting code examples it's difficult to keep the code in sync with the source code
Why unit tests in code examples
- code is actually used by a dev
- validates that it works so devs can work with the examples
- can be a part of the CI/CD pipeline
- validates that code example works
- ensures that the code is understood by the documentarian
When to test code examples
- SDKs, middleware
- tutorials
- 3rd party services integrations (ensuring that nothing changed and your code still works)
- complex examples
Why not manually
- time consuming
- difficult to maintain single source of truth if the same code is used in a few places
- formatic gets weird
- no programmatic modifications
Possible tool
- BLuehawk - CLI-based tool to extract code examples from source files
Transclusion
- including contents of one doc inside of another
- like imports or partials
Workflow with Bluehawk
- write code example in unit test and make test pass
- annotate + extract the code with Bluehawk
- transclude the code example in the docs
- pros/cons:
- pro: unit tested code
- pro: better record of where code examples are
- pro: single source of truth
- pro: more repeatable
- con: could be more automated
- con: rerunning the CLI operations (tiresome)
- con: working with version control

Talk Talk: 'One AWS team’s move to docs as code: what worked, what didn’t, what’s next' (Write the Docs 2022)

Sylwia Vargas — Mon, 23 May 2022 17:03:30 +0000

✨ Talk: 'One AWS team’s move to docs as code: what worked, what didn’t, what’s next' by Marcia Riefer Johnston and Dave May

✨ One-paragraph summary: A talk that portrays the journey that the AWS took to switch from authoring the docs in Word (until 2020) to the 'docs-as-code' approach.

✨ Impression: Very fascinating journey in time.

Notes
Read more

Notes

talk about implementing the collaborative process of doc authoring (or docs-as-code)
"Docs as code" - treat documentation the way you treat code:
- version control
- doc artifacts automatically
- trusted set of reviewers
Previous process (publishing in Word until 2020)
- engineer built the software (quickstart)
- engineer created a doc in word
- tech writer edited it
- both collaborated in email (back and forth)
- tedious
- problematic versioning of Word
- publishing to pdf
New process (docs-as-code)
- engineer built the software (quickstart)
- engineer created a doc in AsciiDoc in VSCode
- "it feels like a step back because it's lacking WYSIWYG"
- no worries about formatting, about fonts or margins
- tech writer edited it in AsciiDoc in VSCode
- both collaborated in github
- transparency in history
- less tedious
- open source
- easier for pull requests, editing
- all changes are tracked
- all changes are published automatically
- published to GitHub pages
- automatically (script and cascading stylesheets)
Automation! A game changer in:
- GitHub page creation
- formatting
- version history tracking
Initial pains
- unneeded code tests delayed publishing (a typo fix can take hours because of the end-to-end testing process)
- repetitive content is a pain to maintain if it changes (retroactively, manually)
- doc process got confusing for authors
Outcome
- moving from Word to docs-as-code reduced the time from publishing time by 25% (and then after improvements by further 50%)
Next steps
- dependency on CI/CD developers on debugging
- automate doc testing, linting
- adding version control to boilerplate updates
- adding more doctyped & code variants
- managing translations

Docs as code:

What do you look for on a team page?

Sylwia Vargas — Mon, 16 May 2022 17:05:24 +0000

I am working on adding a team page to our company's website and I'm wondering:

can you recall an example of a team page that'd just really lovely/informative/awesome?
what information do you look for on such a page? is it helpful at all?
when do you typically check team page?

Thank you!

From my side, I remember that React team page helped me with my OSS contributions because I noticed they are just humans with hobbies 😂

I also remember visiting UPchieve's team page and "getting to know" the folks who make the team when I interviewed there. I looked at the skills distribution and roles, as well as the demographics. I wanted to imagine what working there could be like given the size of different working groups.

(not relevant but while I decided to take another offer, I think about the UPchieve interviewing experience only fondly)

Peaceful coexistence

Sylwia Vargas — Wed, 09 Mar 2022 10:17:29 +0000

Well, year three of the #shecoded reflections!

Over the past 12 months I've changed job twice and each time I ended up in a team with mostly guys. In both cases, my initial apprehension quickly disappeared because I simply felt safe. This was a striking contrast to my previous work experiences in tech. So what made these two teams different?

Trust and respect

I feel like my colleagues trust and respect me. This is so basic but, sadly, not always a given. In my previous jobs in tech, I had to resort to a number of techniques to "assert" myself such as casually bragging about my achievements, working really hard to prove my skills, or firmly stating ny boundaries over and over. Why did I need to do it? Imagine a male colleague, who quizzes you (publicly or privately) on minute details of JavaScript intricacies just because "he wants to be precise" so you start watching yourself closely if, for instance, you say "parameter" instead of "argument" just to later realize that he does not expect the same level of precision from the dudes.

Or a dude who interrupts you in the meeting because “in Java this is handled in xyz” way so clearly your solution won’t work. Your solution is in Ruby or React but aren’t all languages the same?

Or imagine an intern asking you, the only woman at a meeting, to take notes. It was not his meeting but he just really wanted to make sure that someone takes notes.

I was shocked when I joined my previous team and as the only Rubyist at a meeting I was referred to as "a Ruby expert" in a serious manner from the get-go and asked to take a stance on a subject. It's not about vanity. It's that the first time I had the opportunity to comfortably say that the question exceeds my competences instead of feeling quizzed and cornered. The feeling of being able to say you don't know and not being scared to lose credibility turned out to be so liberating.

Or, when I'm given a new task and I really don't know where to start, I am not being micromanaged. I am trusted with that I will do my research and ask questions if I don't understand something. In other words, I’m treated like an adult.

Credit

Oh, how many times did it happen that a male colleague claimed credit for not only my idea but also work, even if the workload distribution was evidenced by github commits.

At my current team at StackBlitz, we have a tradition of shoutouts where every week we gather to express gratitude and admiration for other team members. This is the most egalitarian space to tell others how much you appreciate them and how impressed you are with their work. It facilitates the culture of giving credit over getting credit. Why don’t other companies have that? Isn’t it time to stop with the ego and competition in the field that’s so heavily depends on collaboration?

"Difficult" team conversations

In my past experiences some of the subjects that are important for me were simply ridiculed by some team members because they did not concern them and yet they had all the opinions about them. It always took a lot of emotional labor from me to lead a discussion in the team, react to the silly or ignorant remarks, present arguments, research, and stats, and finally "convince" them "if I care so much". Examples include both your standard social justice issues like adding pronouns to the slack profile or changing the name of the repo branch from "master" to "main" but also, really, any kind of issue.

I was simply blown away with how easy these conversations went in my current job. The pronouns question was raised by a colleague once and everyone just immediately added them to their profiles - no discussion or opinions were needed. I still expected that the "master" branch conversation would be a bit more challenging because it's A LOT OF REPOs we are talking about but, similarly, before I even finished pitching the idea, my colleagues already created a to-do list with action steps. Mind you - we are not a predominantly American team and these conversations are not a part of our national discourses. Folks could not be further away from why decolonizing tech matters. It's just that every team member is trusted and respected and if something makes them feel safer or more included, why not do that?

And anyhow, even in the discussions when the issue raised is difficult to implement or raises further questions, it is never made about who raised it ("omg here we go again") and a solution is found collaboratively. It turns out that no conversation seems to be difficult if everyone is treated with empathy and respect.

Funny jokes, spicy conversations, and personal boundaries

In my previous teams, there were always some mildly-sexist or sexually-charged jokes that would make me feel really uncomfortable. Being the only woman, I often struggled to explain why a joke is not funny because the choir of male chuckle was just deafening.

Similarly, as the only woman, I would often find myself touched or hugged by my colleagues because I'm "so sweet". I'd freeze every time and when I finally started expressing my boundaries, I was either labelled unfriendly or it was explained that I'm Polish (and thus cold).

Let me not even get started on some of the conversations my colleagues had about appearance of some women.

I only realized the full impact of such microaggressions when they disappeared from my surroundings. It was such a relief when I joined my team and saw no stupid memes, read no stupid jokes, and was not made to feel like a prey. It's really lovely to be truly a part of the team and be able to joke together.

Better work culture exists

I think the fallacy is that we hear about how tech is toxic and oftentimes, the people who are given the platform are tech bros who do not care about social equality (sometimes beyond empty declarations). This makes us think that all tech is this way and we just need to endure it.

However, I was lucky to find two really healthy teams and I do believe that there are more and more pockets of tech that's balanced and kind. Nurturing such work culture is my goal for this year - and a wish for you all to experience it 💕

Cover photo by Madison Inouye from Pexels

DEV Community: Sylwia Vargas

Adding workflows to an Astro app with Inngest

What’s so special about Astro?

Using API endpoints in Astro

Custom API Endpoint use cases

Adding long-running processes into an Astro app

What’s Inngest?

How to build complex workflows with Inngest in Astro

Adding background jobs to static Astro sites

Get started now

Talk Notes: "Simple Made Easy" by Rich Hickey (2011)

Introduction

"Simple"

"Easy"

Construct vs Artifact

Working with limitations

Changing things

Easy but complex

Making Things Easy

Main points of complexity

Abstraction for simplicity

Information is simple

Simplicity made easy

What I'd like to see AI used for - women's month edition

Salary negotiation

At work

Tech conferences, meetups, steams, events, twitter

Surveys

Is a better world possible with AI?

What is pnpm? Is it really so fast and space-efficient?

What are package managers?

package, dependency, node module

package.json

package managers

What do package managers do?

Who cursed the node_modules folder?

How is pnpm a solution to all our worries and troubles?

pnpm is fast

pnpm is disc space efficient

pnpm has got your back

…but what if my project doesn’t support symbolic links?

But… what about Yarn?

Closing remarks

Further reading

Come work with us on package managers!

Hacktoberfest: docs updates in three steps

Content editing hack

What is this tool?

Wanna try it out?

See it in action

One-click treat for Open Source maintainers

One-click solution to PR reviews

But what is Codeflow?

Explain like I’m five: package managers

Metaphor: LEGO sets

Node modules and packages

Package managers

StackBlitz Monthly Update Post: September 2022

StackBlitz in the wild

DX & compatibility improvements

New Teammates

Quick bites for the road

What’s next?

Tech Talk: 'Unit Test the Docs: Why You Should Test Your Code Examples' (Write the Docs 2022)

Notes

Talk Talk: 'One AWS team’s move to docs as code: what worked, what didn’t, what’s next' (Write the Docs 2022)

Table of contents

Notes

Read more

What do you look for on a team page?

Peaceful coexistence

Trust and respect

Credit

"Difficult" team conversations

Funny jokes, spicy conversations, and personal boundaries

Better work culture exists

Who cursed the `node_modules` folder?