Why I Swapped MS Word for VS Code — And Traded DOCX for Markdown

Table of Contents
Consider this all-too-familiar scenario, a common peril in our profession: a critical Shareholders’ Agreement, a deadline breathing down your neck. Suddenly, MS Word seizes up mid-clause. Tables, meticulously constructed, disintegrate with a single keystroke. Crucial annotations — perhaps a query from a partner or an internal note — vanish into the digital margins moments before a pivotal filing. This isn’t merely inefficient; it’s an unacceptable risk in a field where precision is paramount.
For years, like most legal practitioners, I relied on MS Word and its ubiquitous DOCX format. But the daily onslaught of chaotic version control that felt like chasing ghosts through a hall of mirrors, formatting that behaved with infuriating unpredictability, and the challenge of reconciling feedback from a dozen channels — email, PDF annotations, instant messages, even photos of handwritten notes — cried out for a more robust, reliable, and auditable workflow.
My motion for a new trial, so to speak, led me to a triumvirate of tools from the software development world:
- Visual Studio Code (VS Code), a powerful and stable editor,
- Markdown, a refreshingly straightforward markup language for content structure, and
- Git, an unwavering version control system that provides an ironclad audit trail.
This combination offered an experience more akin to meticulously building a watertight legal argument, with every draft and revision accounted for, than wrestling with the capricious nature of traditional boilerplate. What began as a personal experiment has since fundamentally transformed my approach to drafting everything from cross-border transactions to intricate legal opinions and compliance documentation.
Today, I lay out the case for this transformative shift, address reasonable skepticism, and yes — voluntarily confess where the new workflow still has limitations.
A. The Case Against MS Word and DOCX#
Precision, clarity, and an unimpeachable record are hallmarks of effective legal work. However, the very tool most practitioners rely on — MS Word — increasingly struggles to uphold these standards in complex scenarios. Its foundational approach to document creation and management reveals critical shortfalls when subjected to the pressures of collaborative drafting, meticulous versioning, and the need for transparent audit trails.
Exhibit A.1 — Version Control Nightmares: The Perils of Concurrent Drafting#
Modern legal work is inherently collaborative, often involving multiple internal reviewers, client input, and negotiations with opposing counsel — frequently happening simultaneously and across different platforms. While MS Word’s “Track Changes” offers a basic layer of revision history, it quickly buckles under the strain of real-world collaborative pressures.
The Illusion of Control with “Track Changes”: While useful for simple, sequential reviews, “Track Changes” becomes a minefield when multiple editors work concurrently or out of sequence. Merging different sets of tracked changes from various copies of the same document is fraught with peril, often leading to lost comments, overwritten edits, or a document so riddled with conflicting markups it becomes nearly unreadable.
Decentralized Feedback = Digital Anarchy: Crucial feedback rarely stays confined to MS Word comments. Edits arrive via email attachments, annotations on PDF printouts, suggestions in WhatsApp or Telegram messages (sometimes as mere photos of marked-up pages), or verbal instructions during calls. Integrating these disparate sources of input back into a single “master” MS Word document is a manual, error-prone, and incredibly time-consuming reconciliation effort.
The “Which Final is FINAL?” Dilemma: The result is a proliferation of files with names like
Contract_Draft_v3_ClientComments_FINAL_FINAL.docx
. Identifying the authoritative version becomes a high-stakes guessing game. Hours are wasted keep tracking and comparing all these documents, trying to discern which “final” version actually incorporates all agreed-upon changes.No Single Source of Truth: Without a centralized system to manage contributions and versions, there’s no definitive “single source of truth.” Different team members might unknowingly work on outdated versions, leading to duplicated effort and conflicting revisions that must be painstakingly unpicked.
It’s like trying to build a coherent case history from a pile of scattered, sometimes contradictory, handwritten notes, with no clear chronological order or attribution. This chaotic process doesn’t just drain resources; it jeopardizes the accuracy and integrity of the final legal instrument.
Exhibit A.2 — Formatting Labyrinths: The Hidden Costs of WYSIWYG#
MS Word operates on a “What You See Is What You Get” (WYSIWYG) principle, which sounds helpful but often conceals a minefield of formatting issues lurking beneath the surface.
The Tyranny of Styles: You meticulously apply heading styles, only to find them inexplicably overridden or reverting to a default after a minor edit. Automated numbering for clauses and sub-clauses can suddenly break sequence or indent erratically.
Table Turmoil: Legal documents frequently rely on tables for clarity. Yet in MS Word, these can be incredibly fragile. Adjusting a column width can cause text to overflow unpredictably, borders to vanish, or the entire table structure to contort.
Inconsistent Outputs: What looks perfect on your screen can render differently on a colleague’s computer, when printed, or when converted to PDF. This inconsistency stems from MS Word’s reliance on local settings and printer drivers.
The “Gremlin Effect”: Many have lost billable hours to mysterious formatting shifts — line spacing that jumps, sections that mysteriously re-indent, or entire blocks that adopt formatting from a single pasted character.
The core issue is that MS Word attempts to manage both content and presentation simultaneously, often leading to conflicts and unpredictable behavior. The time spent “fighting” MS Word’s formatting is time not spent on substantive legal analysis. When time is tight, and quality is paramount, this is more than annoying — it’s a professional liability.
Exhibit A.3 — Opaque Audit Trails: Navigating the Fog of Revisions#
In legal practice, the “what,” “why,” and “by whom” of a change can be as important as the change itself. But MS Word often obscure this vital history.
The “Save As” Labyrinth: Saving multiple versions (e.g.,
Agreement_v1.docx
,Agreement_v2_comments.docx
,Agreement_v3_final.docx
) creates a confusing proliferation of files. Determining the true lineage of a clause becomes digital archaeology.Ambiguous Authorship: Even with “Track Changes,” the metadata can be unreliable. Changes might be attributed to a generic “User” or “Admin,” not the actual drafter.
Lost Context: MS Word’s “Track Changes” shows what changed, but rarely why. The rationale behind amendments often lives outside the document — in emails, chats, or meeting notes.
The “Accepted Changes” Black Hole: Once changes are accepted, the previous state and the identity of the suggester are often lost unless old versions are meticulously compared.
When clients, counterparties, or regulators demand clarity on the evolution of critical provisions, an audit trail based on file naming conventions and potentially compromised metadata is simply not robust enough. The lack of a clear, authoritative, and context-rich history of revisions is a fundamental weakness that can lead to misunderstandings, disputes, and an inability to confidently assert the provenance of your legal work. In short: Word’s audit trail doesn’t hold up under scrutiny.
B. The Case For VS Code and Markdown#
Exhibit B.1 — VS Code: A Modern Editor for Modern Drafting#
The limitations of MS Word prompted a search for a more stable, efficient, and controllable environment for drafting. This led me to VS Code. While its name suggests it’s purely for software developers, VS Code is, at its core, an exceptionally powerful and versatile text editor — and it’s free. Think of it not as a tool for writing complex software, but as an industrial-strength workbench for your words. Here’s why it matters for legal work:
Unwavering Stability and Performance: Unlike MS Word prone to crashes or slowdowns with large, complex documents (especially those with extensive tracking, comments, or large content), VS Code handles text with remarkable speed and reliability. This means fewer interruptions and less risk of losing work.
Distraction-Free Writing: VS Code offers a clean, customizable interface that prioritizes the content itself. It strips away the often-cluttered ribbons and menus of traditional software, allowing for deeper concentration on the substance of your legal arguments and clauses.
Customizable Power Tools: While simple to use for basic text editing, VS Code has powerful built-in features and an ecosystem of extensions that can enhance the drafting process. Features like advanced search and replace, side-by-side document comparison, and customizable shortcuts become invaluable. (We’ll see how this pairs powerfully with Git and Markdown).
Platform-Agnostic and Future-Proof: It works consistently across Windows, macOS, and Linux. Your core drafting tool isn’t tied to a specific operating system’s quirks or a proprietary file format that might become obsolete.
Essentially, VS Code provides the robust, reliable, and clean environment necessary to build a better drafting workflow. It’s the dependable chassis upon which more specific improvements, like the adoption of Markdown, can be built. The advantages are clear: minimal to no license fees, flawless stability and performance, and the foundation for taking complete control over your documents.
Exhibit B.2 — Markdown: Content First, Presentation Last#
With a stable and efficient editor like VS Code in place, the next transformative step was adopting Markdown for the actual drafting of the content. Markdown is a plain-text syntax that uses intuitive symbols (e.g. #
for headings, *
for bullets, **
for bold etc.) to structure content. It’s clean, portable, and incredibly easy to learn.
## Article 5: Termination of Agreement
Either Party (the **"Terminating Party"**) may terminate this Agreement in its entirety by providing not less than **thirty (30) calendar days** prior written notice to the other Party (the **"Non-Terminating Party"**).
Why Markdown truly outshines DOCX:
Clarity Over Cosmetics: When drafting in Markdown, your entire focus is on the content — the legal arguments, the contractual clauses, the factual statements. You’re not simultaneously battling with font choices, line spacing, or paragraph indents. Presentation are handled separately, as it should be, at a later stage via automated tools. This clear separation minimizes distractions and allows for more precise, considered drafting.
Zero Gremlins: Because Markdown is plain text with simple structural markers, it’s immune to the “formatting gremlins” that plague MS Word documents. There are no hidden codes to corrupt, no complex styles to unexpectedly break. Your headings stay headings, your lists stay lists. The document’s structure remains robust and predictable, regardless of how many times it’s edited or by whom (when using proper version control).
Ultimate Output Control: While you draft in clean Markdown, the final appearance (the “presentation”) is controlled by applying a stylesheet (often using CSS) during a conversion process. This means you can define exactly how headings, paragraphs, and other elements should look in the final DOCX or PDF, and apply this styling consistently across all your documents via automated tools. Want to change the font for all Level 2 headings across 50 agreements? You change it once in your stylesheet, not 50 times in 50 DOCX documents.
Human-Readable & Portable: Markdown files are inherently human-readable even in their raw form. They are also incredibly lightweight and portable, opening instantly in any text editor on any device, ensuring your core legal work is never locked into a proprietary format.
By separating what you write from how it looks, Markdown brings a new level of clarity, control, and efficiency to legal document creation. It allows legal professionals to concentrate on what they do best — crafting precise legal text — while ensuring the final presentation is consistently professional and exactly as intended.
Exhibit B.3 — Git: The Ultimate Version Control for Legal Drafting#
With a stable editor (VS Code) and a clean content format (Markdown) established, the final piece of this transformative workflow is Git. Git is a powerful, industry-standard version control system originally built for managing complex software code. Its principles, however, are exceptionally well-suited to overcoming the versioning and collaboration nightmares common in legal document preparation.
Think of Git as providing an unalterable, auditable, and collaborative history for every document, far surpassing the capabilities of MS Word’s “Track Changes” and manual file naming conventions.
Why Git is a game-changer:
1. Immutable History#
Granular, Attributed Edits: Every time a set of changes is saved (a “commit” in Git terminology), Git records precisely what was changed, who changed it, when it was changed, and importantly, why the change was made (via a mandatory commit message). This creates a detailed, chronological ledger for every clause, sentence, or even word. It’s like “Track Changes” on steroids — with actual traceability.
No More “Contract_FINAL_v3_revised_by_John_FINAL.docx”: Git eliminates the chaos of multiple file versions. There is only one current version, with the ability to instantly view or revert to any previous state in its history. Want to see what the indemnity clause looked like three weeks ago before client feedback? Git can show you in seconds.
# Example: View a concise log of all changes git log --oneline contract.md # Example: See the exact differences between two versions of a clause git diff <commit_hash_1> <commit_hash_2> -- indemnity_clause.md
Reliable Audit Trail: This meticulous, timestamped, and attributed record provides an unparalleled audit trail. When questions arise about the evolution of a document, Git offers definitive answers, not guesswork based on file names or potentially unreliable DOCX metadata.
2. Collaboration Without Chaos#
Centralized Change Proposals: When working with collaborators (colleagues, and even for tracking client feedback systematically), Git, especially when used with platforms like GitHub or GitLab, enables a structured review process. Instead of emailing marked-up DOCX documents, changes are proposed as “Pull Requests” (or “Merge Requests”). Think of a “Pull/Merge Request” as formally filing a motion to amend the document. It clearly presents the proposed changes, allows for discussion and justification directly alongside the edits, and maintains a full history of the deliberation before the changes are integrated (merged) into the main document.
Managing Disparate Feedback: Even client feedback received via WhatsApp, Telegram, or email can be methodically incorporated. Each piece of feedback can be translated into a specific Git commit or a branch, ensuring that every external suggestion is tracked, addressed, and integrated transparently.
Parallel Work Without Conflict: Git allows different individuals to work on different sections of a document simultaneously (using “branches”) without treading on each other’s toes. It then provides robust tools for intelligently merging these separate lines of work back together.
By implementing Git, the process of drafting and revising legal documents transforms from a potentially chaotic scramble into a disciplined, transparent, and highly auditable workflow. It doesn’t just track changes; it provides a comprehensive, reliable narrative of a document’s entire lifecycle, empowering legal teams with greater control, clarity, and confidence in their work product.
Closing Arguments: The Quest for a Better Workflow#
Legal practitioners aren’t just wordsmiths — we’re systems thinkers. We analyze, draft, redline, revise, and maintain records — all while upholding standards of precision, accountability, and professionalism. Why shouldn’t our drafting tools reflect that complexity?
MS Word may still dominate legal practice by habit, but that doesn’t mean it’s the best fit for the evolving, collaborative, tech-literate legal work many of us do today. A familiar face, yes — but one prone to fits of formatting rage, a memory like a sieve when it comes to who changed what and why, and a tendency to spawn endless, confusing offspring like Agreement_FINAL_useTHISone_v12.docx
. It’s the legal equivalent of trying to build a precision watch with a rusty hammer and a vague blueprint. The billable hours lost to its tantrums could probably fund a small nation.
VS Code, Markdown, and Git don’t just offer cosmetic improvements. They offer version control with surgical clarity, formatting that behaves, and workflows that scale. In short, they let us practice law with the same attention to logic, structure, and process that good code demands. This new workflow provides:
Simplicity: I’ve shown you a world where your focus is on the law, not on whether your bullet points have suddenly declared independence from your paragraph. No more wrestling with hidden formatting that seems to have a mind of its own.
Transparency: I’ve demonstrated an audit trail so pristine, so detailed, it would make a forensic accountant weep with joy. Every change, every author, every “why” — logged with the unwavering precision of a court stenographer on a triple espresso.
Affordability: I’ve revealed that these powerful tools come without the hefty price tag of proprietary software, freeing up resources that could be better spent on, say, more coffee.
Versatility: And I’ve proven that this approach isn’t just for one type of legal document — it’s the Swiss Army knife for everything from a one-page NDA to a behemoth due diligence report, all while being as portable as your brilliant legal mind.
The choice, it seems, is clear. Do we cling to the chaotic comfort of the past, with its attendant frustrations and inefficiencies? Or do we embrace a future where our tools support our precision, enhance our clarity, and protect our sanity?
You don’t need to be a coder to benefit. You just need to be ready for a better way to draft.
With that, esteemed colleagues, ladies and gentlemen — I rest my case.
Common Objections & My (Pre-emptive) Rebuttals#
I understand the inclination to stick with established precedent. However, when the evidence overwhelmingly supports a more efficient and reliable method, we must address the counter-arguments. Let’s cross-examine these common objections:
❓ “Look, everyone I deal with — clients, opposing counsel, even my barista — expects documents in MS Word’s DOCX or PDF format. If I start using Markdown, aren’t I just creating a compatibility nightmare and making more work for everyone, including myself, when it’s time to share?” - Concerned Colleague
🗣️ That’s a perfectly valid concern! And to be clear, the goal isn’t to force raw Markdown files on an unsuspecting world. The final documents you deliver will still be the polished DOCX or PDF files everyone knows and expects (I use vscode-pandoc to convert Markdown to DOCX/PDF). Think of Markdown as your internal, high-precision drafting workshop. You build the document with exacting control and clarity there, and then, with a simple, reliable conversion step, you produce the perfectly formatted DOCX/PDF for external consumption. It’s about a superior creation process leading to a familiar, high-quality output.
❓ “I’ve been using MS Word’s ‘Track Changes’ for redlining and collaboration since the dawn of time. It has its quirks, sure, but it’s THE standard. Why complicate things with a developer tool like ‘Git’? Isn’t that overkill for legal documents?” - Seasoned Practitioner
🗣️ We appreciate the familiarity of “Track Changes”! However, when multiple reviewers are involved, or when you need an ironclad history of why a change was made, not just what changed, “Track Changes” can quickly become a tangled web. Git, on the other hand, offers what we’d call a ‘forensically sound’ version history. Every single change is logged with who made it, when, and crucially, a mandatory note explaining the reason for the edit. It’s like having a detailed, unalterable deposition transcript for your document’s entire evolution, eliminating the chaos of FINAL_FINAL_v3_useTHISone_EditedByJane.docx
.
❓ “Frankly, I’m swamped. The idea of learning somehting new like ‘Markdown’ and ‘Git’ sounds time-consuming and technical. I’m a lawyer, not a programmer. How can I justify the time investment when I have deadlines and billable hour targets?” - Busy Lawyer
🗣️ That’s the million-dollar question, isn’t it? If these tools required a steep learning curve, I wouldn’t be advocating for them. Basic Markdown can be picked up in an hour – genuinely less time than you might spend wrestling a rebellious MS Word table into submission. The initial time spent is quickly repaid by the hours you’ll save not fighting formatting, not manually reconciling versions, and not deciphering cryptic tracked changes. It’s a small upfront investment for a significant long-term gain in efficiency, accuracy, and frankly, a reduction in document-related stress. Think of it as sharpening your pencil before you start writing your arguments – it makes the whole job faster and smoother.
❓ “Okay, but really — what’s the catch? If this whole Markdown–Git–VS Code stack is so great, why isn’t everyone already using it? There’s got to be a reason legal practitioners haven’t ditched MS Word en masse.” – Frenemy
🗣️ Fair question — and you’re absolutely right to ask it. In fact, I hereby revoke my right not to incriminate myself. Consider this my voluntary confession, without counsel present.
The reality is: this workflow wasn’t designed with legal practitioners in mind. I’m essentially trespassing in a system built for developers, not drafters. So yes, there are shortcomings — some technical, some cultural, all surmountable.
DOCX ↔ Markdown round-trip is clunky. Converting a DOCX file into Markdown and back again with pristine formatting? It’s possible — but not painless. You’ll lose some finesse and spend time cleaning up. More “conditional bail” than full exoneration.
Markdown doesn’t love legal formatting. Numbered sections, indented subparagraphs, signature pages — these aren’t out-of-the-box features. They can be done, but they require engineering your own systems or stylesheets. It’s not plug-and-play.
The mental model is different. Terminal commands, Git branches, and thinking in commits instead of tracked changes demand a coder’s mindset. For legal practitioners trained on MS Word ribbons and file trees, it can feel like showing up to court in scuba gear.
In short: I plead transitional. This isn’t the final ruling — it’s a motion for modernization.
The wish list, respectfully submitted into evidence:
A smart, legally-savvy DOCX ↔ Markdown converter that understands not just formatting, but legal structure — sections, annexes, signature blocks, and even redlines. A tool that handles “Track Changes” like a seasoned paralegal.
A true legal drafting framework, akin to what Vite or Next.js provides for web developers, or what uv offers for Python workflows. A system that combines templating, live previews, reusable clause libraries, citation management, version control, and PDF/DOCX exports — all in one place, with interfaces legal practitioners can actually use.
Until then, we proceed on good faith and reasonable doubt, armed with better practices and stronger precedents. We build with what we have, advocate for what we need, and with a growing chorus of like-minded legal hackers, tinkering toward something better and making progress one amendment at a time. Because if we don’t build the future of legal drafting ourselves, someone else will — and we may not like the fine print they write.
P.S. I hereby give a hearty thumbs-up to every em dash sprinkled throughout this post — long live the dramatic pause! All views, vibes, and inevitable blunders are proudly mine, mine alone, and I’m sticking to ’em like glitter on a craft project gone wrong.