DEV Community: bretzawilski

npm install make-me-a-dev

bretzawilski — Mon, 14 Jun 2021 17:32:15 +0000

Where does originality come from? If (like me) you're starting out in web development, you may be wondering how some developers seem to come up with brilliant ideas on a regular basis. Or maybe you're just wondering how you can create some dazzling and creative design to show off your skills.

The good news? It isn't magic. The bad news? There also isn't a magical shortcut to get you from beginner to expert in a few short months. Or even years.

But there is a concept that help you understand the creative process as you work to develop your skillset. After all, creativity—as much as we like to romanticize it—isn't a divine gift bestowed upon a select few.

Creativity is remix. And modern development itself is based upon this powerful concept.

Everything is Remix

Remix is the process of creating something new by copying, transforming, and combining ideas. Kirby Ferguson has a fantastic video essay, Everything is a Remix, that traces how all of our greatest thoughts, inventions, and works of art are the result of bringing together the ideas of others.

To go back even further, the Ancient Greek and Roman academies were often situated around imitatio: copying the works of great orators to learn their tricks. In other words—and stop me if you've heard this before—you have to learn the rules before you can break them.

So, fellow novice developer, if you're feeling anxious and un-creative as you slog through your fifteenth tutorial project, try to remember: we all have to learn to copy before we learn to innovate. Even the best artists and authors, at one point, were creating derivative work based on what they loved. Think of it as building a vocabulary in the domain of your (eventual) expertise.

You Have to Build a Lot of To Do Apps Before...

At the beginning we copy so that we can learn the principles at the basis of programming. Without understanding the use of variables or the convenience of looping, we might be able to identify the kinds of applications we want to develop, but we'll have no idea how their pieces fit together.

Resources like freecodecamp.org are great for this kind of practice, letting us first learn the basics and then begin applying them to simulated projects. Similarly, Frontend Mentor and Frontend Practice are based around literally copying other designs to learn principles of web development.

Rather than being dismissive of this stage, it's important to consider the usefulness of learning to emulate others' designs and coding styles. It isn't meant to be a stopping point, but in order to learn the foundations of the field, we need to be familiar with what others have made. Not to simply copy it, but to understand what we like and dislike about particular strategies.

Once we can accurately copy the work of those who inspire us, we can push further.

Make it Your Own

On an episode of the Code Newbie, Danny Thompson shared this advice for overcoming some of the pitfalls of early development life. After following a tutorial and making some component or web application, go back and make it again.

But instead of following the same step-by-step process, change the focus slightly and attempt to work from memory. Change the topic, or the product being "sold." There's no shame in going back to the resource to figure something out, but we begin to pick up speed in development when we engage with the second component of remix: transforming materials.

And we reach this stage much sooner than we think. Taking up the 30 Days of JavaScript challenge, it's easy to follow along as Wes Bos guides you through the varied projects. The first challenge involves creating a virtual drum kit that plays sounds based on key-presses. It's an interesting look at data-attributes on html tags and the <audio> tag itself.

But it's also a laboratory. After completing the tutorial and seeing how the pieces fit together, I decided that I wanted to go back and make another personalized version. I thought about making a soundboard that would play audio clips from a podcast I helped create. But instead of being solely based on key-presses, I wanted the sound clips to activate with mouse clicks as well so that the app could function on mobile devices.

While there are some fantastic resources that encourage this kind of transformation, the trick here is that you can't follow a recipe. You have to think about how you can change something you've copied. The good news is that this doesn't have to be a massive, polished change. Even doing something as simple as altering the color scheme or the CSS styling paradigm (using CSS Grid instead of Flexbox, or trying out SASS) has massive value.

In short, no one's judging you at this stage. Break the things you code and marvel at how weird you can make them. Doing this kind of work starts to produce a massive result in terms of our feelings toward coding. It's empowering to follow a tutorial and make something that's functional. But when you start putting your own spin on a design, it really becomes your own.

Yet, while transforming the things we love is powerful, it's still not the true height of remix.

npm init -heckYeah

What is Notion? Well, it's a web application that lets us take notes. Oh, but it also kind of works like Excel and you can build spreadsheets. But those spreadsheets can also be displayed as Kanban boards to help with productivity. And you can also publish note pages or databases directly to the web as live websites. And it lets us work collaboratively with others!

In short, Notion is a combination of a lot of other tools and technologies that already existed. Much of the power of Notion as a tool comes from the way it has packaged together all of these different affordances. And if you examine whatever might be your favorite application, you're going to see something similar.

Many of the most innovative ideas out there come from smashing together other ideas that we love. There's no magic conjuring involved, but that also doesn't lessen the impact of these designs. At some point, we make the transition from copying and transforming materials to combining them together. We make mashups.

And this is where we see how programming is so firmly tied to remix. At some point, if you're pursuing JavaScript as a development language, you're going to come across references to npm or yarn, (or ruby's gems or python's pip) and articles are going to start discussing packages and package managers.

Because coding is so complex and involves solving often-similar problems, the development community itself has oriented itself around tools that help us do what we need to do with as little friction as possible. Do you want to convert markdown text files into html? There's a package for that. Do you want to automatically resize and serve responsive images on your site? There's a package for that too.

npm is actually the inspiration for this article, because while it took me a bit of time to wrap my head around the utility of npm, its elegance struck like an epiphany. Because npm is the epitome of remix.

npm init -y is a beautiful command. It leaves behind a simple package.json file in its wake, but that file is almost magical. It lets you add, update, and remove entire worlds of functionality to your code by typing the the name of a package and the version you want to include. Run npm install in the directory and it takes care of the rest.

It's a perfect little map of all the people and ideas that came before you to help you build the application you want to create. Even if you're a solo-developer, you're not alone if you're working with npm and packages, because you're in conversation with the ideas of so many other developers.

Learning and Remixing

It can be intimidating starting out in programming, especially if you've come to it from another path or career. There's a lot of technical knowledge to master and the landscape changes rapidly. But you don't have to go it alone. In fact, I don't think you could if you tried. Development is about taking ideas and combining them together. It's communication, and it defies all the stereotypes of the coder as loner sitting in isolation staring at a screen.

Yeah, there's a lot of looking at screens, but there's also a lot of community baked into it. I've been fortunate to stumble into some literal coding communities that have been welcoming and insightful. And while I'm still doing a heck of a lot of copying, being able to look ahead and see the kind of work that developers do makes me excited to push forward and start transforming my code and combining it with the amazing work of other fantastic devs.

So if you're feeling lost or a little overwhelmed, remember that everyone starts with the basics. Everyone copies. And everything really is a remix.

Dev Journey Thoughts - Starting a Coding MeetUp

bretzawilski — Thu, 10 Jun 2021 19:58:06 +0000

I've been craving community, and a way to connect with others who are on the journey to becoming a developer. Despite living in a large city, it's been hard to find an already-existing group that seems to hit all the targets. So, I thought I'd create a MeetUp to try and spark a new community.

Peer group formation is a pretty important concept in education, usually tossed around in connection with college cohorts and first-year experience programs. But, the need for cohorts doesn't end at university. One of the reason platforms like freecodecamp, The Odin Project, and countless others draw in such large participation is an inherent need to feel some sense of belongingness.

Yet it can be hard to find the right balance. In my journey, I've joined a few existing spaces that are devoted to the topic of development and coding. They're fantastic in their own way, but it can be overwhelming to step into spaces where hundreds (sometimes thousands) of other people are already in the middle of discussions.

So it's not uncommon to split into smaller groups or pairs or teams. But it's easy to forget about the power of local communities, and that's where MeetUps can excel. Right now, we're still in the midst of pandemic restrictions, but eventually the thought of getting together in person to chat over frameworks and other coding topics is incredibly appealing.

I think fostering a sense of shared ownership is a critical part of making something like this succeed. Rather than focusing around an individual or a mentor, there's a great deal of power in working together to solve problems. And that's the kind of community I want.

I tried the "guru-led" variety in the past and it turned into a rather sobering affair. Listening to soapbox ideological rants and essentially arguing for participants to ignore other perspectives or documents. It felt solipsistic. And the amount of fear and anxiety I saw in the faces of other attendees was too much to handle.

As part of my journey in general, I'd like to chronicle a bit of the formation of this group. It's small and has yet to meet for the first time, but I'm thinking about resources that can be added.

Key among those is a website, but one that is focused on providing members with a space to learn git and practice pull requests by adding themselves to a members list and linking to github portfolios and/or personal sites. Links to resources that are particularly helpful. Nothing out of the ordinary, honestly, but just a way of staying active.

Monthly challenges would also ground some practice and provide a way to collect member examples and compare different code strategies. Essentially, I'm going to be trying to think and find activities that foster engagement and allow the participants to have a stake in the ownership of the group.

Let's see what happens.

Making a Project My Own

bretzawilski — Mon, 07 Jun 2021 18:49:39 +0000

I would't say that I'm trapped in tutorial hell, but I am working through a series of resources that are teaching me more of the ins and outs of web development. Today was a #Javascript30 day, and I decided to make the first proejct in the series—the drum kit—my own.

For the past four years, I've been making a podcast with a friend. We chat about movies in the Criterion Correction, and we usually have a good time. It's a small program, but we enjoy it. As I was looking at the #Javascript30 drum kit, I couldn't help but wonder: how can I make this my own? How can I extend it beyond its original functionality?

Well, first I decided to get rid of the deprecated keyCode property so I'd stop seeing strikethrough lines in my code. It was a really simple fix. Turns out the property.key works quite well and...just uses letters.

I also decided that I wanted to change up the content. Instead of a drum kit, I wanted to make a soundboard with some clips from our podcast. This was a really easy substitution—the hardest part was locating audio clips in our old files, and that was just a matter of taking the time to do it.

The second tricky (though not very) element was making the app work on mobile devices. See, the original uses keydown events to trigger the sounds and the visual transitions on the page. But on a mobile device, there isn't a keyboard to use. Instead, I needed to make a good old-fashioned click event on each of the triggers for the sounds.

The biggest takeaway I need to investigate is document.getElementsByClassName versus document.querySelectorAll. I thought they'd be equivalent, but the forEach command that works so well on querySelector...does not work on getElementsByClass. So, that will be something I plan to investigate further.

Additionally, I need to better understand the options for the css transform property. I first made changes to the size of objects individually, but seeing the use of transform: scale(1.1); was enlightening.

So, another day of coding down, and a fun project as the result.

If you're interested in boosting your own JavaScript skills, check out the entire 30 Days of JavaScript challenge.

Lessons from the IDE — Justify, Align, and Decisions

bretzawilski — Wed, 02 Jun 2021 21:22:34 +0000

Welcome to Lessons from the IDE, a recap of successes, failures, and glitches (so, so many glitches) from my daily coding. This article was originally posted at bret.design

Another day, another battle with CSS. I finished the Frontend Mentor "Stats Preview Card Component" today, and you can see my solution here. I'm going to try to take this concept and re-work it for my own site with another image and some separate text.

In the classes I teach, I often talk about writing as remix. Originality isn't a matter of thinking of what no one else has considered. It's really about combining ideas that haven't been brought together before. In that way, creativity doesn't have to be some mystical talent that and individual possesses or doesn't possess. It's a process of gathering a library of sources to mix together.

Coding is the same, in more ways than I thought. package.json files are testaments to the power of remix, letting us pull from the work of so many other creators. Even working in isolation as a solo coder, it's impossible to escape working with others' ideas, and that's a huge benefit.

As a novice developer, I often have to remind myself:

My job isn't to invent what has never existed before
I'm building to learn and to repurpose what I learn
Tutorials are always stage one; stage two is making it your own

Blast from the past

I also decided to take a look at two websites that I made back in the dark ages of the web. They're both hosted by Tripod, which through some demonic power has managed to stay online despite the collapse of its contemporary peer, Geocities. Both sites make use of framesets and I also managed to make link image-buttons that change from monochrome to color renders when you hover on them.

I need to look at the code, because I'm fairly certain CSS wasn't a part of that feature, and I sure didn't know javascript back then. Unless I pulled a copy/paste job in the code. However, it did make me want to do two things.

I need to archive those sites, scrape the code, and put them up on github; maybe I'll even check the Wayback Machine to see if I can grab different renditions.

I mean, these sites are prime archaeological relics of the past, from a time when Netscape Navigator was the browser of choice and the web itself felt very...gray. No, really, my predominant memory of the internet in those days were gray pages in a gray browser. That and webcrawler.

I need to rebuild those sites without the frames, and with a little better design, but in the spirit of the originals. Perhaps I can think of it as communing with my teenage self.

Alignment glitches

Of course, the day wouldn't be complete without a maddening CSS issue with a simple solution. In my attempts to center content in divs, I spent quite a long time trying to get my text to center itself using all of the CSS Grid tactics I could think of, referring to several cheatsheets along the way.

But, in my haste to make use of Grid, I forgot that text-align is a property in CSS. Whenever I tried to do a justify-items: center; call, content that fit on a single line would behave nicely and move to the middle of the div. But if the content extended across several lines, it would become justified but the last line would hang to the left.

At long last, I remembered that I could simpel call text-align: center; and be done with it.

Choices and Dilemmas

Finally, I found myself running into a debate that I'd avoided up to this point. Since coming back to code, I decided that I would angle myself towards React development, since it's the most popular frontend JS framework. However, in these early stages, I won't lie; some of the tutorials I've watched practice dark magic that I can't yet understand in terms of passing props and managing state.

So I looked at some introductory resources on Vue and...it started making a little more sense. I'm not deep into React right now, but so many of the resources I passively encounter on daily.dev focus on React. Yet, if Vue makes more sense, should I start learning that framework instead?

In the end, I decided to do the only rational thing: double down on vanilla JS basics and delay the decision.

Lessons to Remember

Remember the basics and don't aim for the flashiest solutions: you'll forget something like text-align: center; and kick yourself once you fix the code.
There is too much to learn.
But that's a good thing, because it means there's always a direction to pursue and growth mindsets are real.
Community is important, even if it starts by talking to yourself in blog posts.

Conclusion

Thanks for taking the time to read through Lessons from the IDE. Tomorrow I'm hoping to do something slightly different and write up a comparison of two prominent developer-facing slide-deck applications: RevealJS and sli.dev.

Which one will become the markdown-driven slide-deck builder of my dreams?

Lessons from the IDE — :root, Boxes, and SRCSETs

bretzawilski — Tue, 01 Jun 2021 20:46:49 +0000

Welcome to Lessons from the IDE, a recap of successes, failures, and glitches (so, so many glitches) from my daily coding. This article was originally posted at bret.design

Today I started working through one of the free challenges from Frontend Mentor, the "Stats preview card component." It was listed as a "newbie" difficulty, so I thought as a newbie, it wouldn't cause too much of a problem. Spoiler: I was wrong.

That said, the value of any project is locating gaps of knowledge. In this case, I found quite a few gaps in my understanding of CSS and divs. I've been trying to strengthen my Grid and Flexbox skills over the past few days, so setting up the initial card wasn't too painful.

Oh, and I almost forgot. Today marks my first entry for #100DaysOfCode

Let's get to the :root of it

First, I decided to capture some of the colors of the design through css variables. The :root pseudo-class was one of the first quality of life improvements I encountered when I started coding again. Rather than having to update a whole list of color hexcodes or property values for each element (I hadn't tried SASS or another pre-processor in the past), global variables let you declare properties that you can slot into nearly any selector.

I've seen them most commonly used for setting up a color palette (or dark/light mode color options), but if there's a particular margin or padding setup you plan to use across various elements, you can also declare those in a variable.

They look something like this:

:root {
    --primary-color: blue; 
    --secondary-color: rgb(173, 94, 215);
    --accent-color: #f72585;
    --card-padding: 1rem 2rem;
}

After establishing the variables, they can be dropped elsewhere in the stylesheet, which is incredibly helpful if you decide to change your colors later on. If you apply the --accent-color in three different places, then you don't need to hunt down each of those instances in the code. Change the global variable and your work is done.

Here's a look at variables in action:

main {
    background-color: var(--secondary-color);
    padding: var(--card-padding);
}

a {
    color: var(--accent-color);
}

Quick Headache Prevention

I don't know much, but I know box sizing used to be a huge pain. Setting the size of divs meant having to calculate not just image content, but also padding, borders, and margins. Thankfully there's a way to change the box-sizing model that means you only have to worry about the content size and padding, which makes life a lot easier.

Many programmers suffered for this fix, so I give my obligatory thanks here:

html {
    box-sizing: border-box;
}

*,
*:before,
*:after {
    box-sizing: inherit;
}

This did seem to make aligning the two main divs of the project simpler. But, as I said before, glitches are part of life. And not all content plays nicely.

Boxes and boxes of fun

Another issue I came across was having an image fill a div. For the main image of the card project, I had to find a way to use CSS to add a tint to a black-and-white photograph. At first I tried to use the background property of a div to set the photo as the background image for the div and put a semi-transparent fill over it.

This works, but you can't just apply a color for some reason. It needs to be a linear gradient, even if you're looking for a solid fill color...

#image-container {
    background: linear-gradient(var(--image-tint-color), var(--image-tint-color)), url(images/image-header-desktop.jpg);
}

But, there's a bit of an unintended side-effect. If you're not interested in responsive fluid resizing, you can set the width and height of the div and you'll be all set. However, you need to use fixed values like pixels, or else the div registers as empty and doesn't render properly.

I saw a solution for this involving setting the padding of the div to a percentage representing the ratio of the background-image, but I also decided to see if there was another way to tint an image.

Yes, there is.

You can plug in an old fashioned image into a div container and set the container's background color to appear in front of the container's items through the object-fit: cover property. From there, use an rgba color assignment to select a semi-transparent fill color and you've got a basic image tint. Voila.

  .image-container {
    background-color: rgba(165, 62, 255, 0.536);
    object-fit: cover;
    overflow: hidden;
  }

However, I did run into one final issue that took a bit of Googling to fix. The image in my div wasn't exactly aligned with the boundaries of the div itself. I learned that an <img> tag automatically displayed in-line has a phantom line-height value attached to it. So the fix for my pixel-imperfect alignment was to set my image to display as a block.

I'm noting this because I can see it causing me a lot of stress in the future if I were to forget this simple fact.

img {
  display: block;
}

Curse you gods of responsive images...

Of course we all know this isn't the end of images, and I'm still grappling with the syntax of the following code. Basically, I knew that srcsets were a thing from a prior project, but I still didn't understand how to set them up without simultaneously displaying them overlapping on the page.

I know, this stinks of newbie problems, but I spent longer than I'd care to admit looking at several different templates to get responsive images to work and serve different images to different screen resolutions. I'm not even sure my current solution is optimized as it stands, but this did the trick for my project.

<picture
  ><source
    srcset="images/image-header-desktop.jpg"
    media="(min-width:1000px)"
  />
  <source
    srcset="images/image-header-mobile.jpg"
    media="(max-width: 999px)"
  />
  <img src="images/image-header-desktop.jpg" alt="Please, just work!" />
</picture>

The two source tags list the images that are part of the srcset and the media property determines how those images are displayed. In this instance, the larger of my images, image-header-desktop.jpg will display any time a user's browser resolution is greater than 1000 pixels.

If the user's browser resolution is lower than 1000 pixels, the second source tag sets it so that they will be served the smaller image-header-mobile.jpg instead.

I'm going to have to investigate this further, but it worked for my current purposes, so I'm going to call this a tentative success on the day. I'm somewhat spoiled because I let the eleventy-img package take care of this on my personal site rather than having to handcode it.

Lessons to Remember

If you run into alignment problems, try implementing the box-sizing: border box fix.
Don't assume the first solution you find is the best solution. I tried working with image-tinting the background-image of a div for a long time before discovering the object-fit approach for a standard <img /> tag.
Images need to be displayed as a block in order to correctly fill a div!
srcsets are powerful, but I'd be lying if I said I fully understood the intricacies of the syntax since I believe I'm missing a few properties here...

Conclusion

I've still got some work left to do on the challenge project, but it's nearing its completion. I'll either wrap up work on it tonight or tomorrow, but I'll be sure to keep track of any additional bugs I encounter. There's bound to be more than few.

Thanks for reading and I'll be back tomorrow with more Lessons from the IDE.

Using Zettelkasten and Obsidian to Learn More Effectively

bretzawilski — Mon, 31 May 2021 14:35:19 +0000

Personal knowledge management (PKM) is on the rise, with popular applications like Roam Research, Obsidian MD, and Notion leading the charge into a new kind of note-taking. Except, it's not exactly new. Well, not all of it, at least.

If you've ever kept track of valuable information through a bullet journal, word document, or an online task manager, then congratulations: you've had some experience with personal knowledge management. The gist of it is that we're surrounded by information, and without a system to handle that information, it's easy to become overwhelmed.

Writers like Nicholas Carr have warned us about the dangers of easy access to information. If it's so easy and instantaneous to Google what we want to know, then why bother committing that information to memory? Carr's argument is something I resisted for a long time, but his main assertion—that the tools we use to think shape how we think—is hard to ignore.

And if there's one thing we know about the tech industry, if there's a problem to be solved, then numerous products will likely be developed to solve the issue. In this case, one of the answers is straightforward.

All we need are index cards.

Enter The Zettelkasten

Well, maybe we need more than just index cards. We need a system to make those index cards work together.

Niklas Luhmann was a German sociologist who developed such a system—a catalogue containing nearly 90,000 individual notes on index cards that were organized in a loose structure that Luhmann described as a "web-like" system. The system was ingenious for its results as much as for its simplicity.

Zettelkasten simply means "slip box," as in a box in which you could file slips of paper. Index cards, in this case. Those index cards would be labeled with an arbitrary designation. And because the information had to fit on a single index card, the content of those cards was brief by necessity.

Let's say I wanted to take notes on Javascript. Well, the first card I make might be 1. JavaScript. On that card, I might write a brief definition of JavaScript, noting that it is a dynamically typed language used for web development.

Then, let's say I want to provide some more information on closure in JavaScript. Card 1A. Closure might be next. But let's say I deviate to thinking about CSS. Card 2. CSS would be added to my slip box after 1A. Closure. Now I go back and want to talk about JavaScript classes, so I create card 1B. Javascript Classes. But then I decide to go further into Closure and discuss the concept of "the backpack", so I create card 1A1. The Backpack.

Don't worry if you're not following. The main idea is to create a system that is not rigidly structured. If I later decide to expand upon any of these notes, I can simply add one to the box with a more specific designation. Card 1A1a. Closure Execution Contexts can be added regardless how "far down" I go into closure.

In many ways, this replicates some of the strengths of the card catalog systems that dominated library search and retrieval systems before digital cataloging was a thing. And in addition to the relational positioning of notes, it was also possible to link related notes by adding a list of "relevant cards" at the bottom of any entry. In that case, if I create card 30A. Python Classes and want to link to class similarities in JavaScript, I can just write the reference 1B at the bottom of that card to know to look elsewhere.

Photo by Aaron Burden on Unsplash

Sonke Ahrens provides a fully fleshed out description of Zettelkasten in his book, which I joke is the best book with the most boring title: How to Write Smart Notes. Luhmann used this system, largely before widespread adoption of the internet, to compose over 500 scholarly publications, including numerous books, over the course of his life. He would often describe his thinking process as a matter of engaging in conversation with his Zettelkasten (Schmidt, 2018, "Niklas Luhmann’s Card Index: The Fabrication of Serendipity").

Of course, a wealth of applications have attempted to take this method and rework it for the digital era. Wikis in themselves are a similar undertaking in theory, as they are intensely interlinked documents containing information. With a Zettelkasten, though, the process becomes more individualized, and a large portion of the work of making a Zettelkasten comes from finding and taking note of the linkages between ideas.

For that reason, I like to think of Zettelkasten as serendipity machines—tools that help us connect ideas that we wouldn't have otherwise linked if we weren't actively trying to do so. While Roam Research wasn't the first application to work with this kind of linking structure, it exploded on the scene during its early days of 2019, finding a market of individuals desperate to get their thoughts in order, and while it didn't model itself strictly on the Zettelkasten, its goal was to create intricately linked notes that could be connected together and traced for inspiration.

The general mindset behind tools like Roam and Obsidian is that if we make the attempt to connect our thoughts together, we'll profit immensely from the rich intersections of ideas. And the beauty of these tools is that they aren't prescriptive in how they function.

Obsidian, in particular, lets users decide how to organize their thoughts. If you like folders, you can create folders. But if you want to have a "flat" system like the Zettelkasten, where notes are placed near other similar notes and linked to other relevant ideas, then that's possible too.

Obsidian and Learning to Code

This is all a long introduction to get to a somewhat simple point. Tools like Obsidian—or Roam, or Notion, or Zettlr—can help us be more productive in our thinking and our learning. It assists us in using the knowledge we come across so that we don't forget what we've learned quite so quickly, and it serves as a relational database for our brains in which we can quickly retrieve data and trace previous thought processes.

While I've been using Obsidian for quite a few months to organize my research for writing projects, I just began to use it for learning to code better. At first, it felt a little counterproductive, since there are some fantastic resoures like the Mozilla MDN out there to grasp the basics of web development.

But the benefit of a Zettelkasten-like system is that we have to synthesize the ideas we encounter in our own words. We have to ensure they make sense to us, and that means while I might grasp a really important concept about the array.prototype.map() method from the Mozilla MDN, I'm going to remember it better if I can write out my understanding of how .map() works.

Another aspect of modern PKM tools is backlinking. Again, drawing on the features of a wiki, platforms like Roam, Obsidian, and even Notion have enabled automatic backlinking. That means, if you create a digital link from one note to an earlier note, the program will recognize that connection and display it on the earlier note without any additional work on your part. Arguably, the idea is to render very clear the connections between ideas with as little friction as possible.

Obsidian and Writing

Even better, Obsidian makes use of markdown files—plaintext documents that are readable from essentially any computer device made in the past 40+ years. They'll never go obsolete, and you'll never have to worry about support for them disappearing. Additionally, there are a variety of tools that let users take Markdown files and output them as Microsoft Word or Adobe PDF documents (among a variety of other document types).

In fact, this blog post was written in Markdown within Obsidian. In the end, though, the software is less important than the engagement. As Niklas Luhmann proved, you can create a highly effective personal knowledge management system without touching any digital tools. The important aspect is trying to build connections across concepts and putting complex ideas into your own words for better understanding.

In the end, I've found a lot of benefits to building out my own digital Zettelkasten in Obsidian, and I'll be curious to see how it helps me better understand the world of development. But, if you're interested in learning new concepts more effectively, then I'd encourage you to check out one of the tools listed in this post.

A lot of guru-esque figures have appeared in the personal knowledge management arena, but once you reach past some of the marketing bluster, there's a lot to be gained by taking up a note-taking system to help organize your thoughts.