Project Skill Tree: "Studying" Forem's Open Source Code for Markdown Features

Context

Mission Statement
Link to Why I'm Writing This Article

Content

• Introduction
• Looking for the Forem Markdown Editing Feature
  • Problems with Option 1
  • Problems with Option 2
  • Problems with Option 3
• Answer
• Conclusion

Introduction

  The aim of this article is deduce how to extract the Markdown features used for article-writing from dev.to. The website this article is hosted on, dev.to, was built with open-source code produced by Forem. I know that the Markdown feature is not specific to dev.to because another website built with Forem, This MMA Life, which is about MMA and is thus unrelated to coding, uses the same Markdown document editing feature as dev.to.

  That being said, let's try to find the Markdown editing feature in Forem's source code.

Looking for the Forem Markdown Editing Feature

  It's not particularly difficult to find the code used for writing Markdown.

  The only problem is that almost every file looks like this:

  This is real, professional code, the likes of which would take me a month to fully understand. There are few approaches I can take with decreasing levels of difficulty:

1. I can read over the code, understand how it works, and attempt to replicate the most basic parts myself from scratch.
2. I can read over the code, understand how it works, copy and paste what I need, and fix any bugs along the way.
3. I can clone the entire repository, delete parts that I don't need, and fix any bugs along the way.

Problems with Option 1

I will definitely learn the most here, but it's a month or more of learning on my own just to get started. It may be another month or more of coding the whole thing out based on what I've learned.

Problems with Option 2

This is the middle ground, where I try to understand the code by copying only parts that I need. How much code is actually copy-pasted after all? I might learn some things but it's likely that none of it will stick around in my head, which will ultimately make debugging this large application harder in the long run. Despite expediting the process, I will end up with a lot of stress while still taking a month to figure out the code, copy-paste it, and debug it.

Problems with Option 3

  This would take a week to do and is definitely the most expedited option. But like option 2, I'll end up with a ton of tech debt and will pay for it later in the form of a month of stress-inducing debugging.

What choice would you make?

The Answer is...

Secret Option 4 None of the Above

  The markdown document feature goes on the list of features that are nice to have in the future, but are not strictly necessary for basic functionality. I will be building an MVP after all. A simple text form will suffice for now. In the meantime, I can look for libraries such as react-markdown that can potentially fulfill this feature later.

Conclusion

  When building an MVP, it's important to not get bogged down by complex code. It's better to ship the MVP and either get hired by a company or present the basic idea to angel investors who care about education as much as I do. To most people, this seems like an a no-brainer. But like when all you have is a hammer, everything looks like a nail; likewise, when all you have is a keyboard, everything looks like an idea to be abstracted away with code. Many junior engineers make the mistake of biting off more than they chew and making large commitments to a codebase only to find out that no one wants to use their new JavaScript framework.