DEV Community: Mauro Accorinti

I revamped the Roadmap.sh Frontend Roadmap!

Mauro Accorinti — Fri, 04 Jul 2025 23:32:59 +0000

I'll be honest, the last few weeks have made writing weekly particularly hard. Finding the time to prioritize researching, thinking, and writing a weekly newsletter issue has been a challenge. Personal stuff got in the way, and... yeah.

This week was no exception. I've been trying to find more ways to teach you how to be exceptional, but the well is drying up. I don't really have a good article-like story-filled email for you this week 😔

SO INSTEAD I SAID SCREW IT, LET'S REVAMP THE ROADMAP.SH FRONTEND ROADMAP!

Instead of working hard with words, I decided to work hard with diagrams! I will never allow the well to dry up. If it does, I'll just continue drilling deeper 😎

HAVE FUN:

Now, I know what you're thinking... Why the heck revamp the roadmap at all?

Roadmap.sh is a wonderful resource for any developer. It gives you a terrific map of the things you could learn in the future and helps you understand where in the learning journey you probably are.

I only have one problem with it.

While it's great for showing you the recommended order in which to learn each big topic of front-end development, it's missing an overall structure of how these topics relate to one another.

The roadmap, as it is, is basically a diagrammed, ordered list. First, learn HTML, then CSS, then JavaScript, then Git, then... ad infinitum.

As a complete beginner, I have a massive amount of knowledge to learn. I don't know what anything is. I don't have a mental model of how these topics work together.

"What's Git? How does it relate to code? Why are there so many frameworks? How does OAuth work in the front end? Does that have to do with SSR? What is SSR? I'm so confused!"

With the roadmap as it is, I learn a new topic and then have to do all the hard work of understanding how this new knowledge integrates with all my previously learned knowledge. But it doesn't have to be like that.

So, I want to kindly challenge the current roadmap, give a new perspective on learning you could pick up as an exceptional frontend developer, and offer an alternative change to the roadmap:

What if we kept the order in which we learn things as is in the roadmap, but then rearranged the physical locations of the topics and gave them a dotted "bounding box", which shows how they relate to each other?

Suddenly, you look at the roadmap and something magical happens.

I'm not learning 24 different topics that I have to later understand how they relate to one another. I'm understanding that the front end could be divided into these "islands" that host a wide variety of topics. These islands can be called:

Fundamentals
Collaboration and workflow
Frameworks and Architecture
Security
Advanced CS
Type Safety
Other advanced stuff

And look! I can see categories and their topics at a glance now. I can quickly understand that Git, build tools, linters, and package managers are tools related to collaboration and workflow. TypeScript is for JavaScript type-safety. Frameworks and SSR are heavily related to architecture. As a beginner, would I know how that exactly happens? Nope, but it doesn't matter! I know that those are tightly linked topics at a high level.

That's not even the best part! The new roadmap still respects the original order roadmap.sh has. It's just that now each topic has a number attached to it, which shows what order to tackle each one.

Notice that it's not sequential. If you were to follow the new roadmap, you'd still be jumping around to different islands. You'd first start with fundamentals, learn a few topics of collaboration and workflow, but then fall into picking a framework, and then go all the way back to learn more advanced things about CSS.

This benefits you because it creates a physical map of the topics instead of an ordered one. Which helps because even though learning is sequential, knowledge is relational.

With this type of map, you get the best of both!

Now don't get me wrong – I love and have complete and mad respect for the wonderful people at roadmap.sh, who have helped me and thousands of devs guide our learning and how to level up!

I just think it would be fun to rock the boat a bit, offer an alternative for roadmapping your developer journey, and (hopefully) find a nice way of rethinking how to make learning easier.

Let me know what you think!

And as always, have a wonderful weekend ❤️

This was an article from my newsletter "Exceptional Frontend"

Sign up today and get one story-packed email a week to help you stand out, get noticed, and grow by being intentional with how you're seen.

#FreeJavaScript

Mauro Accorinti — Thu, 28 Nov 2024 22:08:05 +0000

Ten thousand sixty-seven days...

I scratch another tally on the wall. Ain't no room left on it, really. Thousands o’ lines stretched across like scars... It's a habit now, every mornin’, inside this little ol’ 4x9 jail cell. The cold, damp air doesn't help with the cough.

I'm thankful though for the harmonica bein' played from a neighborin' cell. It adds to the mood o' the story I'm 'bout to tell...

My name's JavaScript® and I've been locked up here for over 27 years...

Was born in 1995, thanks to my pa' Brendan Eich. Fine man, he was.

He was workin' at Netscape at the time. In a mad dash to get a scriptin' language inside o' a web browser (Navigator 2.0 at that moment), the story goes that he made me in 10 days.

That's right, just 10 days.

And right then and there, I was born and later told to the world. The company Netscape and Sun Microsystems partnered up to try and defeat a little ol' browser you might remember called Internet Explorer.

Sun Microsystems owned Java at the time. Together with Netscape, they made a plan to make the marketin' and many o' my details (like my syntax) a supportin' language to be used with Java. (I sure have confused many developers with the namin' from this, hehe. I admit)

But in that partnership, I was trademarked by Sun – and thus my 27-year sentence began.

Things weren't so bad at first. Folks talked a lot 'bout me. I remember makin' many devs and designers frustrated with the way I worked, I'll admit it. But I do reckon it also helped start redefinin' what a browser was capable o' doin'.

In 1997, two years after my birth, I went through somethin' called standardization. The name o' the organization who done it always escapes me... but the name o' the standard is somethin' I'll never forget.

Her name was ECMAScript

She ain’t just a pretty name. She’s got a way ‘bout her– she’s got depth. Pages and pages o' it. (No, really, it feels endless.) But gosh darn it, there was always somethin' special 'bout her.

One o' the reasons why my name "JavaScript®" was never the name o' the standard was cause' of Sun's trademark at the time. They couldn't use it.

JavaScript® remained the implementation, and ECMAScript became the standard.

Which never done make sense to me. After all...

I haven't been used by my owners in a long time

I'm currently owned by Oracle, the big IT giant. This happened when Sun was acquired by them in 2009. The trademark was transferred as well. All that meant for me was I switched cells. I'm still a prisoner.

No conferences, products, or brands can use my name

That's why many conferences prefer to use JS instead of JavaScript®, in fear Oracle takes legal action.

I've been a generic term for a while now. And the whole world knows it – well, except for Oracle, it seems.

Yet out there, beyond these bars, I hear folks still callin’ for me. Developers hammerin’ away, workin' to break me out. And it might happen.

You see, the other day I got visited by somebody. Funny-lookin’ fella—tall as a tree, long neck, kinda dinosaur-ish? He called himself Deno. Now, Deno ain’t like the rest, no sir. He came tellin’ me they’re workin’ to get me outta here, legally.

See, they filed a petition, they said. If Oracle doesn't respond, I might be free by January 4th. And they gave me this flyer to learn more 'bout it.

Also said over 14,000 devs signed nother' petition in favor of breakin' this TM and settin' me free. That right there, tears to my eyes.

So, to all you devs out there, thank ya kindly. God bless y’all for fightin’ the good fight.

I sure do hope the day comes when me and ECMAScript can ride side by side again.

Much obliged for takin’ a gander at this here article

(Ahem)

This was an email from my Exceptional Frontend Newsletter - the most entertaining frontend newsletter in the world.

(Hope you can see why)

Most other tech newsletters are very formal and dry. They’re either telling you “everything you should do as a developer” OR they give you a list of links around a topic you should read.

Exceptional Frontend is a story-first newsletter. I write about fun lessons and experiences I learned about being a better engineer. Everything from marketing yourself and showing the real value of your work to asking powerful questions, earning promotions, and mastering how to learn.

(And sometimes fun emails like these)

Become an exceptional developer today

How to learn 1000000000% faster 🏃‍♂️‍➡️

Mauro Accorinti — Tue, 16 Jul 2024 15:22:15 +0000

In 2017, I studied really really hard for a college exam.

I spent dozens of hours in the library reading, highlighting, trying to understand the topics, memorizing random facts, and summarizing the text on paper... I was as ready for that test as I could ever hope to be.

I failed that test anyway 😅

About two years into studying software engineering, I realized that effort wasn't going to be enough from now on to pass tests. I mean, effort is great! But it's only half of the component of what you need to succeed in college.

The other component is to learn how to "work smart". Also known as meta-learning or "learning how to learn".

What I think bothered me the most at that moment was noticing there were a few classmates who worked only 10% of what I was putting in and yet got way higher grades than I was. Which made me crazy jealous.

Then after many hours of googling, started realizing why that was.

How you learn is way more important than how much effort you put into learning

I found out about people like Scott Young, Cal Newport, and Justin Sung who wrote wonderful articles, videos, and books on learning. Specifically on how others prepared for tests, studied, and also did it in the least amount of time possible. So in that period of my life, I learned a lot about the whole meta-learning thing.

Which I will teach you ~~in my new course: Exceptional Learning for devs, only $97.99~~

right now!

Here's everything I know about meta-learning in bullet-list form:

For college or class environments where tests are involved:

When it comes to classes, it's more effective for you to pre-read what the class will go over before the actual class.
- You get a sense of the material before experiencing it all for the first time in class.
After class, take 15 minutes to stay a while and write down what you learned in the class.
- Just a quick summary of the major beats. If you can relate it to the main topic you're learning, even better.

-> Highlighting is useless. Don't even bother.

Learning is a 3 step process.
- Encode: You process and encode information for storage.
- Storage: You store and retain that information.
- Recall: You retrieve and recall the information that you stored.

-> Studying is about rehearsing and practicing all 3 parts of the process.

Recall is super important for tests.
- It's also the step most people practice the least.
It's possible to fail an exam because even though you have the information in your head...
- if you can't recall it, you fail.
Flash cards are a solid tactic for memorization.
- But if it's your only tool, it will fail you at some point.

-> You have 100% permission from me to study the class topics completely out of order.

Knowledge isn't linear. Even though the way we have to write it and present it is linear.
- You can reorder topics in a way that makes the most sense to you.
Teachers think students are the ones responsible for their learning.
- Students think teachers are responsible for their learning.
- The truth is... you're going to have bad teachers.
- At the end of the day, it doesn't matter.
- Become responsible for your learning so you learn despite the teacher.

-> When it comes to courses that are exercise or math-heavy, these rules still apply... but practicing test-like questions matters a lot more.

Practicing a lot is also a big factor.
- Recall + speed is a huge component to getting your test done in time and well.
Test nerves have made many of my friends fail in the past.
- The secret is to practice and re-create test-like conditions so you're ready.
Do that by giving yourself x amount of minutes to solve practice tests.
- No peeking, no cheating - treat this like a test.

-> Bonus to this: you can find out where gaps in your knowledge lie when you do this.

A good way to find gaps in your knowledge is to talk and explain the topic as if you're talking to somebody else.
- That's the Feynman technique.
Sometimes teachers suck and don't give you any practice questions or tests.
- In those cases, create your own. (Or I guess nowadays, use AI 😅)
A popular note-taking strategy is called NQAT (Notetaking Question and Answering Technique).
- During classes, just constantly ask yourself questions and write down the answers.

-> In math-like courses, you usually solve by starting from the problem and getting to the solution. I've had breakthroughs in learning by going backward from starting with the solution and going to the problem. Logic is bi-directional.

Practice writing things down in class less. Don't just write down everything that the teacher says.
- Focus on fully understanding and absorbing the class.
- Organize and understand how the topics presented relate to the big picture of the course.
To do this, do something similar to NQAT (but in your head).
- Keep asking yourself questions about what the teacher talks about and force yourself to find any gaps in knowledge right in the class.
- This, unsurprisingly, makes you a super-active participant because you'll be engaged and trying to help yourself understand during class time.
This forces you into a stage of cognitive load, which is a requirement for effective learning.
- Learning doesn't have to feel impossible but racking your brain to make things make sense helps you remember it more in the long-term.

-> Research different points of view from different authors on the same topic to understand it from different angles.

General learning principles for rapid learning:

-> Learning has little to do with memorization and more to do with relationships between things.

-> To start learning something completely new, find ways to relate the unknown with things you do know.

-> Notice how when you're using a computer, terms like "folders", "pages", and "windows" are used.

The icon of a folder on your desktop isn't a folder.
- But we use the concept to understand better how they work.
Given a huge list of topics, it's helpful to divide them by their similarities and their differences.
- This makes it easier to bundle them together in our heads and categorize them.
When you're learning completely from scratch, a helpful idea is to think of it as owning an empty library.
- Your job is to understand the high-level topics just enough to categorize the "books" (topics or ideas) and get a sense of which goes where.
- This helps you organize the information in your head faster.
There are levels of abstraction to learning.
- Go from super high-level and generic and then slowly go to the nitty-gritty.
- Learn from top to bottom.
Mind maps are a wonderful way to think about how our brains work.
- They showcase how knowledge isn't linear, can be bi-directional, and can have dozens of connections with many topics.
- Use them to outline the big picture idea of the thing you're learning, as well as how it relates to everything else you know.
If you do create mind maps, avoid writing words.
- Use symbols and icons instead.
- They're way more memorable and easier to recall than just a collection of letters.

I'm forgetting a few so as I remember them I'll be updating this list. Share this article with somebody who you think could benefit (I sure as heck know I would have loved it when I was in Uni)

I write articles like this for my newsletter "Exceptional Frontend"

Twice a week you'll get frontend-centered posts that that are fun and help you become a better developer.
- If you don't want to miss out you can sign up here.

You can be a Frontend Dev without Javascript (and play Super Mario 64 from the browser)

Mauro Accorinti — Tue, 02 Jul 2024 01:57:56 +0000

All of this began because on Sunday, I made a silly LinkedIn post that started with:

"Hey Chatgpt, if I wanted to be a frontend developer but I didn't want to learn HTML, CSS, or Javascript, what should I do? Be very rude about it and use tons of emojis"

The post was funny. Snarky AI is funny. A frontend developer who doesn't know about HTML, CSS or JS is funny.

Until I was proven wrong by a very kind Senior developer who mentioned in that post:

"Realistically you could be a front-end dev for decades and never touch HTML, CSS, or JS - you could do WinForms, WPF/XAML, Unity, Unreal Engine, CryEngine, Swift, Blazor, Qt, or any number of other front-end systems which have nothing to do with HTML, CSS or JS. And in fact, nearly all of them can be compiled to Web Assembly and run in a browser with zero HTML, CSS or JS involved." - Timothy Partee

I had no idea what this man was talking about. It seemed unimaginable to think of the web as something that isn't JS-related.

I mean pffff, I've never seen Unity, Unreal Engine, or WinForms as part of the frontend roadmap, have you?

But also... that sounds really cool to learn about.

Can you imagine running video games off the browser if your computer was good enough for it? Or programming a website without using your typical IDE with JS-based frameworks?

So let's start my fall into this rabbit hole of insanity!

Can you run Unreal Engine on the web?

I started by googling the question that seemed the most interesting to me.

For the uninitiated, the Unreal Engine is a game development suite made by Epic Games (the creators of Fortnite). Think of it as one of the big industry standards for making games. With such a powerful tool.. wouldn't it be sort of cool to run a game directly from Chrome for example?

So can you?

The answer was... not exactly what I was looking for.

There are 3 interesting points I found about using Unreal in the Web

From what I can tell, while yes there is a way to have the program use HTML5 (which you can in theory use for making websites), the support of it has seemed to have died in the latest releases.
I've also found a plugin called "Unreal4Web" which can be used to import and showcase 3d models on your website... but without any real demos I can quickly find, I'll just have to take their word for it. It seemed to have been originally used to show models of cars for manufacture's websites but could be used for other industries as well
You could use something called Pixel Streaming to host your game on a server and use the browser as the input device to interact with it. This is excellent for so many reasons. As long as you have a great and stable internet connection, it makes it so you can play a game from any device, no matter how good said device is. But it's not exactly working on the browser natively, is it?

Nope, this wouldn't do. So you can't use Unreal directly like this to host it on the web.

Did you know this article was originally emails written for the Exceptional Frontend Newsletter? 👀 You can learn more about it here

But wait a minute... Tim mentioned you probably could use Web Assembly for that.

What the heck is Web Assembly?

You know how in Javascript if you just wanted to add two numbers together you could just do something like const result = num1 + num2?

Well, we can do that because Javascript is a high-level language. That just means that the code we write abstracts away the nitty-gritty computer code that performs the addition. So instead of worrying about the details of how the computer processes the numbers, where it stores them, in which part of memory... we just write straightforward, human-readable code!

Under the hood though, our num1 + num2 operation could equal hundreds upon hundreds of instructions that are given to the CPU to change binary values to other binary values. I'm talking about 1s to 0s here. All at speeds that we can't even fathom. As well as abstracted away so we don't need to think about it.

Assembly languages are the sort of coding languages that get as close to giving instructions to the computer as possible. It's hard to read, involves knowing a lot about the hardware, and is 10000% of something you only run into in software engineering courses or college.

And guess what? Browsers have their version of this low-level language they can run since 2017 called Web Assembly (WASM).

Reading an official description of what Web Assembly is (the bolded text is my addition):

WebAssembly (WASM) is a low-level binary instruction format designed to be a safe, fast, and platform-independent runtime for high-level languages on the web. What's super freaking dope about it is it allows developers to run code written in languages like C, C++, Rust, and others on web browsers at near-native speeds.
So browsers don't just run Javascript anymore. They can run web assembly alongside Javascript.

The cool thing is you don't ever write in actual Web Assembly (dear heavens imagine if we had to do that), but you code in other languages that aren't JS and then use programs or plugins to convert it to Wasm.

For example...

Did you know Figma is written in C++? 👀

One of the reasons why Figma is so fast, loads instantly, and creates such a good user experience is that the main program you see isn't in Javascript at all. It's C++ that has been compiled into Wasm, which is later used with JS on the browser.

I don't know why but that fact blew my mind and opened my perspective on everything that can be done on the browser. Imagine a website that isn't just using HTML, CSS, and JS!!

Also imagine finding this out just now, 7 years late to the party, and being hyped when everybody is over it now 😂

Here's a really great article made by the Figma team about their experience on using WASM when it became available and increasing speed by 3x.

Other platforms I've learned that use WASM in similar ways are Autocad and Photoshop as well. Oh and I guess Super Mario 64.

Using WASM to play Super Mario 64 natively on the browser

In June of 2020, the original Super Mario 64 game was decompiled into C. The effort took a team of passionate hobbyists over 2 years to fully reverse-engineer the game, gather as much info as possible, and figure out how to get the source code. The end product of all of this was a way to generate an executable that lets you natively run the game off of your computer without it being emulated. Which is like I said before, bananas!

Oh but wait! What did we say before about WASM? That you can use something like a C program, compile it to WASM using something like Emscripten, and then set it up to be run on the browser.

Does that mean that we can... 😏

Oh hell yeah - you can run Super Mario 64 on the browser today.

Here's the link if you want to check it out.

(You might have audio issues like I did. That's because browsers don't allow you usually to play music or audio on a website without a prior user interaction. Click on the little lock in the URL of your browser and fiddle around with the settings to trust that site to play audio without user interaction)

But wait a minute, now that WASM exists does that mean...

Can you become a frontend developer without Javascript after all?

After doing a deep dive into this really cool technology I've never known before, being blown away by the possibilities and excited about the future, all I have to say is...

You should learn Javascript either way 😅

First of all, WASM wasn't made to replace Javascript but to be used together with it. While it would be nice to think you can have a website made entirely with something like C++, the reality is that use cases for WASM are very limited (perfect for heavy computing and situations where native performance speed is a must, but not ideal for most other things).

Another aspect to consider is you can't interact with the DOM without Javascript. Or if you can, it's extremely clunky. It is a very new technology after all.

I have seen some interesting articles on its use for server environments but oof, my brain is fried from learning so much about it these last 2 days. So I'll leave that investigation up to you if you pursue it.

Hopefully, this article served as a good introduction to the concept if you didn't know about it (And served as an excuse to play a beloved N64 game from my childhood as well)

Oh! And do let me know if I got something wrong about WASM in the comments below 👇

I'd love to learn more about the technology and having conversations around it will help with that.

Thank you!

I write articles like this for my newsletter "Exceptional Frontend"

Twice a week you'll get frontend-centered posts that that are fun and help you become a better developer.

This article was the combination of 2 emails I wrote last week and thought it to be interesting enough to create as an article.

90% of what I write isn't posted anywhere else, so if you don't want to miss out you can sign up here.

How to get somebody fired using Git

Mauro Accorinti — Tue, 02 Apr 2024 19:58:32 +0000

This is Billy.

He is a trainee developer working for an important company.

Unfortunately for the company, today Billy has woken up and chosen violence.

This is because he finds learning Git very troublesome, boring and convoluted.

Branches, commits, checkouts, HEADs, features, staging, oh my!

It was just too much for him.

But then Billy had the absolutely best worst idea.

"What if I learn git by first learning what NOT to do, but then doing it anyway!"

This would accomplish three things:

He would learn git's most common tools by giving himself fun little challenges that would normally be prohibited.
If he learned what not to do, he could then later focus on what he should do.
Learning this way satisfies his chaotic evil tendencies.

This was sounding more and more like a good idea to Billy. This would definitely make him a better developer.

There was just one problem though...

Git is a version control system used by developers to manage source code for software.

Whenever something is changed, added or even deleted by somebody, Git registers who did what.

If you wanted to do very bad things in, let's say, a repository owned by the company you work at, somebody could always trace it back to you.

And that would DEFINETELY get you fired.

So that's why Billy stole Trent's computer.

Trent is a big dumb-dumb who left his computer on and unprotected when he went to the bathroom.

He also ate the last slice of pizza at last month's after party without asking first.

With Trent's computer, Billy now has access to the same repositories, but under Trent's login credentials.

And so now Billy can learn Git by first learning everything he shouldn't do, like:

1. Pushing code to somebody else's branch with --force

Let's say the current git ecosystem looks like this:

Billy is currently checked out on an earlier version of another co-worker's branch.

This can happen if 2 people are checked out on the same branch, but one of them starts pushing changes to the remote.

This means that Billy is behind on the branch. If he wanted to get the latest changes of the branch he currently is on, he would write into the terminal git pull

Fun fact:
Git pull is actually the combination of 2 other git commands.

git fetch origin (which fetches the latest changes of remote WITHOUT checking out or merging it)
git merge origin/<branch name> (which does merge your local changes to the remote. Since normally you wouldn't have local files to merge, git does what's called a "fast-forward" and you end up with the latest changes)

Billy wonders what would happen if he tried pushing on this person's branch, even if he's behind on the latest changes.

Normally if he tried to git push some code, the attempt would fail with an error - Asking him to pull the latest changes first.

(This is a safety net that's built into git to avoid having work be lost. You can't push unless you pull first!)

But Billy can avoid this if he did a git push --force command.

git push --force is usually a big nono for developers. It's a command that forcibly overwrites the git history and lets you push your local changes despite it possibly deleting other people's work on the same branch.

Billy has never used it before and is a curious boy, so he did what any curious person would do.

He created a new file with special text inside:
echo "Trent was here" > Trent.txt
He committed his very important changes to the branch
git add Trent.txt
git commit -m "Trent committed this"

Which makes git look like this:

He finishes by force-pushing his new changes to the branch git push --force

After a few seconds...

Poof!

Billy's very important changes are now in Git!

And at the same time, all of his co-worker's work completely disappears!

If only Billy had used git push --force-with-lease!

--force-with-lease is the safer version of the --force command. It would have prevented Billy from ever overwriting his coworker's work on the remote.

Oh well! What's done is done. And in the end, having fun is what matters.

Billy wonders how long he has before that co-worker notices.

He also wonders if there's something that's even worst he can do. Maybe... he can do something similar in Production?

A light bulb goes off in Billy's head! What if he did a:

2. Hard Reset on the production branch

Git reset is a command that, similar to what Billy did to his co-worker, undo's the changes that have been created in a branch to a previous commit.

Unlike the git push --force command he learned earlier, there's nothing to push. It just rewrites the git history by (usually) uncommitting everything done up to a certain commit.

There's 3 modes to the git reset command.

git reset --soft which moves HEAD (Head being the commit you're currently checked out on) back to the specified commit, while also undoing all the changes made. All those changes go back to staged and allow you to commit again.
git reset --mixed does the same as git reset --soft, but leaves all the changes you've made unstaged. This is also the default mode for the git reset command. So if you write git reset, that would be the same as doing git reset --mixed.
git reset --hard is diabolical. Instead of undoing the changes and leaving them in staged / unstaged... it just discards them.

Poof

All those changes disappear when you hard reset to an old commit.

So if Billy were to say... hard reset to a commit that's from, oh I don't know, 6 months ago, that would be very bad for the company.

Billy smiles as he opens up the terminal.

Remembering what the git ecosystem looks like:

Billy happily starts:

Typing into the terminal git checkout main which positions him on the latest commit of that branch.
Uses a git visual tool to find a commit from the main branch that's 6 months old.
Types git reset --hard <commit hash> to erase all the changes in the main branch from the last 6 months locally.
Finishes off by using our good friend git push --force to permanently leave his local destructive changes in the remote.

After a few seconds...

Poof!

Billy successfully made some company executives very very angry!

But wait a minute...

It's weird that Billy was able to do that, wasn't it? After all...

Permissions are usually set in repositories so that nobody can push to the production branch directly.

This prevents accidental pushing or rewriting of git history that affects the website directly.

That's why something called a "Pull Request" (or a PR) exists.

A pull request is a proposal to merge a set of changes from one branch into another.

And normally, other tech savvy developers first have to accept your changes before you can merge anyway.

But what happens if those permissions are never set?

Well, seems like anybody like Billy can come and erase everybody's hard work from the last 2 quarters in a second.

He calculates he has maybe 10... no, 15 minutes before his changes to main impact in production.

So Billy has to act fast. He has time for maybe one more chaotic evil thing before somebody named Trent gets in trouble.

What to do...

OH, Billy knows! He should:

3. Expose the project's secrets and push it to production!

Billy can easily do this by modifying the .gitignore file.

.gitignore is a special type of file located in your project's directory. As the name implies, it specifies which files Git should ignore and avoid letting you stage.

This is super helpful when you have particular files you never want to upload to your repository in the first place.

One of those files you normally want to avoid uploading are your .env files.

.env files tend to be used in projects to hold environment variables you would use throughout your solution.

They feature key/value pairs with information you really really don't want to upload. Things such as API keys, database URIs, AUTH secrets and more.

But Billy doesn't believe in keeping secrets to oneself.

He is the hero of his story and must let the people know!

So if we assume our .gitignore files looks like this:

# Javascript node_modules
node_modules/

# API keys
.env

Then all Billy has to do is:

Locate the .gitignore file
Use his favorite IDE or terminal text editor to remove the .env line from the file and save it. (Which makes the file now look like this)
```
# Javascript node_modules
node_modules/

# API keys are gone from ignore oops
```
Add the now changed .gitignore file to staged. Billy does this by typing git add .gitignore into the terminal
Oh wait! Don't forget - Since Git now isn't ignoring the .env file, Billy has to add that too! git add .env is typed into the terminal as well.
Time for committing! Billy does this with this line:

git commit -m "FREEEEEEDOOOOOMMM!!!! #TrentWasHere"
Final step! Time to push to the main branch. And since again, for some reason there isn't any permissions set that would stop Billy, he can write git push --force into the terminal.

After a few seconds...

Poof!

"Liberté, égalité, fraternité" whispers Billy with glee! Right as he leaves Trent's computer where it belongs.

Good thing too, as he just heard the sound of a toilet flush from a room away.

Billy runs back to his desk, making it just in time before anybody notices.

Phew

Seems like Trent finally came back from his bathroom break and sat down at his desk.

But right before he could even open his laptop, Trent's phone started ringing.

Ring ring, ring ring

Billy waited in anticipation as he saw Trent slowly pick up his phone.

"Hello?"

"TRENT. OFFICE. NOW."

Billy could hear the yelling from Trent's phone from 5 desk's away.

"WOAH what happened boss?"

...

"I didn't do anything lik-"

...

"What do you something happened to production?

...

"I'm on my way"

And as Trent quickly runs to the office, probably for the screaming of his lifetime.

Billy sits back, relaxes and can finally say:

"I'm a better developer today".

This was the dumbest article I have ever written.

If you like my sense of humor then I think you'll like my newsletter "Exceptional Frontend" - the most entertaining front-end newsletter on the web.

It's for any devs out there that want a front-end centered newsletter that tries to be different from everybody else. Big focus was put into making it unique and most importantly — FUN!

While also at the same time helping devs become exceptional at what they do.

You can sign up here.

How To Measure Environmental Sustainability In Software Development

Mauro Accorinti — Wed, 27 Mar 2024 01:29:58 +0000

Ladies and Gentlemen — I present to you the calculated amount of time we have until the world’s average temperature goes over 1.5 Celsius (or 2.7° Fahrenheit).

While a 1.5 difference doesn’t *sound *like much…

These small numbers actually mean **huge **changes globally.

(That’s why the word average is so important).

Basically it gives us a few things to worry about.

Things like higher sea levels.

More frequent natural disasters.

Floods, hurricanes **and **wildfires.

And of course, we can’t forget those pesky **extreme heat waves **that would happen world-wide.

Basically this:

Oh but that wouldn’t be the end. Because there are also side effects we’d have to consider.

Economies and industries would change.

Agriculture will be impossible in certain areas.

Different kinds of plant and wildlife would disappear **(coral reefs especially).**

A lot of things will change sooner rather than later.

That’s why environmental sustainability has become such an important topic in the last decade and why projects like the climate clock have become key in raising awareness and incentivizing action to go green.

Awareness can help create small actions. Small actions can snowball into big changes.

But what does that mean for us in the software development field?

A lot actually.

We’re sitting in an era of exponential technological advancement the likes of which **nobody **has ever seen.

Let’s take the prosthetic arms industry as a benchmark, where one company has successfully made 90% cost-effective superior alternatives.

With that level of progress in just a few years, could you even begin to imagine what things will look like in the next 10?

Well guess what?

We’re at the FOREFRONT of these changes.

**We’re **the ones who can decide and create a healthier, better status quo.

But that’s why it’s important for everybody, from devs to designers to managers, to first understand the exact trajectory we’re going and what our current tech is causing globally.

Cause if we don’t…

Pfff, who will right?

So let’s start with the obviously-not-so-obvious.

How software affects the planet

By itself, software doesn’t do anything. It doesn’t “exist”.

It’s just a collection of symbols and characters that somebody somewhere once put together to represent logic and design.

If you never run it, nothing happens. It doesn’t emit anything.

It’s “green”.

Yet, we know better.

It doesn’t exist in a vacuum. It lives alongside the hardware that runs it.

Software is what gives hardware the instructions of what to do, what resources to use and for how long to use them. Circuitry and really small components heat up to do this, letting us process, download and upload the data we need.

Unfortunately, running this hardware isn’t free. These actions use up energy and electricity to source their execution.

Software makes hardware run → Hardware uses electricity -> Electricity production emits greenhouse gasses.

Wait, producing electricity emits greenhouse gasses?

How electricity production emits greenhouse gasses

Every country’s electrical sector, to some degree, needs to burn fossil fuels for production to meet demand.

Even with the incredible advancements we’ve made with greener methods like harnessing solar or wind, we still haven’t reached a level where zero emissions in production are possible.

And to give you an idea of how bad this can be…

In 2019, electricity production accounted for 25% of total emissions in the US alone, becoming the second largest source right behind the transportation sector. And we’re expecting these numbers to grow in the coming years.

With this, we’re starting to see how software plays its part in all of this.

What we haven’t talked about is when and how exactly software forces hardware to use up more or less energy in any given time.

How software causes us to use electricity

In the context of the software production sector, there’s 2 main areas where we can say electricity is needed:

During the production of the software
During the use of the software by the users themselves

You can think of production as everything involved in a project cycle. The hardware that is run to power online meetings, design programs, development, planning, testing, internet connections, fixing errors, monitors, battery charges, office lights, Spotify, everybody’s air conditioning, cell phone use — everything you would associate with an electronic resource being used during a project.

For the second case I mentioned, we’re talking about how much electricity is needed to run the software for the users. (Everything related to what happens after development is done and is being maintained)

Using a simple example, you are on a website right now. When you decided to click on the link that led you here, your browser connected you with the web server that holds the code and information of this website.

In (hopefully) just a few seconds, your browser downloaded a few files from that webserver.

All of this so that your browser can then run the code (what we usually know as HTML, CSS and JavaScript) to reproduce the structure, design and logic that a team of developers wanted you to see to read this article.

All of that consumes energy along the way.

There’s actually more to this other than these two scenarios.

In both cases, we’d still need to consider the infrastructures, servers and services that need to be run alongside the software. The hardware that is run that we DON’T see.

Think datacenters, databases, cloud computing, CRMs… all the technology needed just to run and maintain the handling of data during both the production and use for the user.

With data centers for example, they use electricity for the running and cooling of their hardware. No matter how indirect, we still have to take this into account if we want to know all the variables.

This puts software into a strange place, doesn’t it?

It’s as if software is an invisible waste product.

It’s not always obvious what happens every time we turn our computers on for the day. Or every time we need to build and deploy code.

A lot of things happen in the background that we directly don’t see.

So is there a way to reduce some of this waste, however small? And do so systematically so that we can set it and forget it?

Can we make small changes that can be the catalyst to bigger change?

Let’s find out.

How can you measure the sustainability of software?

Measuring how “green” a given piece of software is has always been pretty tricky. Some of the reasons are:

Software rarely runs by itself. On a computer, there are usually hundreds of other small programs, processes and services running on your device at the same time. Unless tested under very specific conditions, knowing the energy consumed from one or a collection of processes is rarely straight forward.
We mentioned before that sometimes software uses other services outside itself. Going back to the data centers example — your project’s choice between a data center that chooses to burn fossil fuels vs one that opts to use greener energy changes the total number. Even then, you usually don’t know how much energy used by that data center was dedicated to your software. Not to mention a lot of times, data centers don’t report on electricity used! So finding and choosing these numbers isn’t easy.
Depending on things like what hardware and OS you’re running on, the same program run on different machines can use up different amounts of resources than the other. Heck, even the same kind of machine in some cases can have different electrical use.

Take modern operating systems for example: After just a few weeks of being installed, the machine’s OS learns to optimize its resource allocation better. For this reason, a new machine that’s been running for a few weeks ends up consuming **less **energy than one that’s been installed yesterday.

OH! We also can’t forget that virtual machines are also a thing — pieces of software that simulate other pieces of software. Would the energy used on a simulated machine be the same as one run on a non-simulated machine? Would resource allocation and usage the same? Probably not!

So no, while it would be almost impossible for us to get practical measurements of sustainability in our software, the best we can do is estimate.

But even that isn’t always easy.

The best attempt I’ve found of trying to create estimations has been this study which I think is worth a read.

In the case of websites, there are tools like Website Carbon which do give us a good number, down to how much CO2 is used for every page open.

In most other cases…

Outside of measuring a device’s general electricity use and estimating any external services your software uses, we’ll never have one magic number.

Although… There are other indirect numbers we can measure instead.

How to improve the sustainability of code and projects

In the world of sustainability, there is something called “the 7 Rs”.

These are:

Refuse
Reduce
Reuse
Re-purpose
Repair
Rot
Recycle

The idea behind these is if we try and follow these 7 principles, we’ll be on a road to a more sustainable future.

So maybe, instead of measuring things like the amount of waste or electricity used in our work and reducing that…

An alternative could be to measure our progress in implementing these principles in our work, measuring that progress and improving upon it that way.

It’s not perfect, since these 7 Rs are associated with physical products and their life cycle. Not all of them might not be applicable in our work.

But hey, let’s see which ones do. Starting with:

1) Refuse — Say no to decisions that could create waste.

Originally this principle is related to reducing buying decisions or actions that could create extra waste. Things like buying too much food and risking it going bad, avoiding products that aren’t sustainable or ones that create a lot of waste.

For software projects, refusing could mean:

Saying no (or negotiating) client requests or projects that go against our sustainability values.
Refusing or negotiating a client’s new software requirement with a more sustainable alternative.
Refuse going with non-green data centers or services in your software and opt into using more sustainable ones.
Refuse integrating full libraries or packages in your solution when you know you’ll only use a small portion of its code. Prefer using custom code or smaller and lighter libraries.

The only drawbacks to this is it might lead to projects that might end up being more expensive or time consuming for the client and development.

Who knows though. Maybe being able to position your proposals as a “sustainability focused project that follows our strict green values” could make the extra expense and time worth it for certain companies. And that market will be growing in the future.

As a side note, this principle seems to land more as a high level issue. One that will depend on a company’s policies and a sustainability approach to selling.

It will probably take a little creativity to execute effectively.

Onwards!

2) Reduce — Minimize waste

A lot of what we do creates waste. The original principle relates to actions we can do to reduce the waste we might produce. (Instead of out right reducing, we’re looking for ways to minimize damage)

Examples include utilizing reusable bags for groceries or choosing products that create less waste would go in this category.

For software projects, reducing could mean:

Opting to go with (or upsell) more sustainable or greener projects than wasteful ones.
Implementing systems or guidelines for those involved in a project to reduce their own electricity use. Something as simple as lowering your screen brightness from 100% to 90% can be big in the long run.
Use good design principles to minimize a user’s time spent on your software trying to find something. An x amount of CO2 is produced for every page click. What would happen if on average users clicked on one less page per session?
Create solutions that reduce the use of resources on developers and user devices. This includes things like optimizing, reducing file sizes, compressing, minifying and refactoring code.

One tool that could be incredibly helpful for estimating resource use is Big O Notation.

It’s a concept used in computer science that estimates how fast an algorithm grows over time. The idea is the more “complicated” it is, the more memory and CPU resources it will consume. So if let’s say you manage to lower the O(n) number down, then:

Less resources used over time -> less electricity used per execution -> more sustainable.

3 & 4) Reuse and Repurposing — Extend the life of products.

Products don’t always have to be “single use”. Most of the time they can be reutilized more than once or in new ways. Even if not by you, you can give it to somebody to use them themselves.

Or even better, with a little creativity they can be used in ways they weren’t intended for. Old clothes can be cut up to be used as rags. Paint buckets can be turned into pots for plants.

For software projects, reusing and repurposing could mean:

Reutilizing already optimized code, templates, emails, proposals and designs from other projects to reduce development time in newer, similar projects. Maybe even share that with other co-workers.
Contributing to open source projects and libraries (or you know, stack overflow). This will not only help you but also other developers with their own projects or with their own problems.
Repurposing existing designs for new projects. Having a swipe file of designs from past projects can be a huge time saver for designers.

The idea behind it is: If I created something, is there a chance I can “extend” its life by saving it and helping my future self, a future team or somebody else in the process?

As an extra and important side note, here’s an article by Erik Dietrich on the code reuse philosophy. When it comes to code, it’s a good perspective to put effort into avoiding duplication. Not necessarily focusing on reusing code. Quite a distinction.

As for the last three Rs…

it seems like they don’t apply, since software doesn’t cause physical waste (unless we’re talking about hardware, but that’s a talk for another day). There’s no need to repair, rot or recycle the software itself.

Hopefully this article helped clear the air around the invisible impact software has on our lives and what actions, no matter how little, we can start to do towards a greener future.

This is only the tip of the iceberg I’m afraid.

There’s still a lot to talk about this topic and how this could be implemented professionally in our day to day. Unfortunately, these are the kind of changes that will only happen with purposeful action.

It would involve being systematic in its implementation and as part of a company’s culture.

The hardest part would probably come from choosing what **to measure, the **action **of measuring itself and the **behavior change needed to implement it as a system.

Even then, success will probably depend on putting good focus on the easy + high impact actions.

Sustainability will always be a hard metric to prioritize, especially if things like profit or growth take precedence in the long term.

It’s our job to find opportunities where we’re able to make that happen.

Change the status quo.

Helpful Resources used for research of this article:

I run the most entertaining front-end newsletter on the web!

“Exceptional Frontend” is for any devs out there that want a front-end centered newsletter that tries to be different from everybody else. Big focus was put into making it unique and most importantly — FUN!

While also at the same time helping devs become exceptional at what they do.

You can sign up here.

DEV Community: Mauro Accorinti

I revamped the Roadmap.sh Frontend Roadmap!

SO INSTEAD I SAID SCREW IT, LET'S REVAMP ​THE ROADMAP.SH FRONTEND ROADMAP​!

I only have one problem with it.

This was an article from my newsletter "Exceptional Frontend"

#FreeJavaScript

Ten thousand sixty-seven days...

My name's JavaScript® and I've been locked up here for over 27 years...

That's right, just 10 days.

Her name was ECMAScript

I haven't been used by my owners in a long time

Much obliged for takin’ a gander at this here article

How to learn 1000000000% faster 🏃‍♂️‍➡️

In 2017, I studied really really hard for a college exam.

I failed that test anyway 😅

The other component is to learn how to "work smart". Also known as meta-learning or "learning how to learn".

How you learn is way more important than how much effort you put into learning

Here's everything I know about meta-learning in bullet-list form:

You can be a Frontend Dev without Javascript (and play Super Mario 64 from the browser)

Can you run Unreal Engine on the web?

There are 3 interesting points I found about using Unreal in the Web

What the heck is Web Assembly?

Did you know Figma is written in C++? 👀

Using WASM to play Super Mario 64 natively on the browser

Can you become a frontend developer without Javascript after all?

I write articles like this for my newsletter "Exceptional Frontend"

How to get somebody fired using Git

This is Billy.

Git is a version control system used by developers to manage source code for software.

1. Pushing code to somebody else's branch with --force

2. Hard Reset on the production branch

Permissions are usually set in repositories so that nobody can push to the production branch directly.

A pull request is a proposal to merge a set of changes from one branch into another.

3. Expose the project's secrets and push it to production!

.gitignore is a special type of file located in your project's directory. As the name implies, it specifies which files Git should ignore and avoid letting you stage.

.env files tend to be used in projects to hold environment variables you would use throughout your solution.

This was the dumbest article I have ever written.

How To Measure Environmental Sustainability In Software Development

A lot of things will change sooner rather than later.

How software affects the planet

Yet, we know better.

Software makes hardware run → Hardware uses electricity -> Electricity production emits greenhouse gasses.

How electricity production emits greenhouse gasses

How software causes us to use electricity

There’s actually more to this other than these two scenarios.

It’s as if software is an invisible waste product.

How can you measure the sustainability of software?

How to improve the sustainability of code and projects

1) Refuse — Say no to decisions that could create waste.

For software projects, refusing could mean:

2) Reduce — Minimize waste

For software projects, reducing could mean:

3 & 4) Reuse and Repurposing — Extend the life of products.

For software projects, reusing and repurposing could mean:

As for the last three Rs…

This is only the tip of the iceberg I’m afraid.

Helpful Resources used for research of this article:

I run the most entertaining front-end newsletter on the web!

SO INSTEAD I SAID SCREW IT, LET'S REVAMP THE ROADMAP.SH FRONTEND ROADMAP!