Update: I changed my name from “Mimi” to “Marty” and started using he/him pronouns in July 2019. This article keeps the original “Mimi” and “she/her” self-references in order to maintain a sense of timeline.
This retrospective could have many alternate titles, including:
“How I Discovered My Technical Writing Process”
“Leetcoding Was The Easy Part: The Many Woes of Formatting Code in a Blog Post”
“The Importance of an Editorial Calendar”
“April 2019 One Month Project: A Love-Hate Relationship”
“A Month of Production Challenges”
“April 2019 One Month Project: Problem Solving in More Ways Than One”
And so forth. April’s One Month Project was to write up an article on each Leetcode coding challenge I did, outlining my thought process and explaining the official solution at the end. I ended up severely underestimating the amount of time and effort required to produce a post. What I thought would only take an hour or two usually took two days at the very least, with breaks in between.
In the end, I only wrote up three articles:
I’m proud of the things I wrote; I think that they’re technically sound and get my points across well. I’m not proud that there were only three of them, or that it took me so damn long to get each one done.
Why did each article take so much time to produce? Let’s break it down.
I had to come up with a snippet-writing process
Writing code for an article is different than writing code for the sake of actually using it in a project. Explaining each step of my thought process involved going through each line of code and using snippets to make sure the reader could follow along:
In my code editor, I would write:
Notice how the two snippets in the code screenshot have headers that correspond to the two sections in the article screenshot. I included screenshots of each section as I drafted my article in Google Docs. When it was time to publish, I would then copy, paste, and code-format each snippet in the correct section.
It’s quite a smooth process, and I love it. I didn’t have this starting out, though; it was born out of frustration after I had to meticulously copy and paste parts of the same code snippet for different sections. It took a lot of trial and error before I settled on writing out each snippet consecutively.
I had to come up with a word-writing process
When I went to write the first article, I’d already completed the coding challenge associated with it. I had my solution and I understood the answer that Leetcode provided.
Ah, I thought, I already know everything about this one. Explaining it will be the easy part.
I turned out to be totally wrong, as I usually am when I’m cocky about something I haven’t done before. Explaining everything was totally not the easy part. I had to re-trace all the steps in my thought process and break everything down, which was way harder to remember after I’d seen the posted solution. I found that I thought and communicated a lot more clearly if I solved the challenge as I wrote, rather than dividing the process into “problem-solving” and “writing up”.
It was through this discovery that I came up with my article-writing process, where I would write a code snippet (such as the initial pseudocode) and immediately write the section corresponding to it.
Understanding the elegant solutions required research
Leetcode provides pretty and (mostly) optimal solutions to their coding challenges. Sometimes, these solutions would be so different from my own that they required a whole new level of understanding. I would read these and be like “um, what?”
So then I would have to go and research things like bit manipulation, read and experiment enough that I knew what was going on, and then write it up. As you can imagine, this took some time that I didn’t budget for.
Code formatting was more involved than I thought
Before I started this Leetcode series, I simply had screenshots of my code on all my articles. A few people wrote me and requested actual, copy-and-pasteable snippets, so I downloaded a WordPress plugin called CodeColorer, which allowed me to provide snippets in my signature Miami Vice code aesthetic.
CodeColorer is a great plugin, and I recommend it to any WordPress user who wants to include code on their site. However, I found that formatting my code was a bit tricky.
With CodeColorer, you sandwich your code in between two shortcodes, like so:
When I first started using CodeColorer, I’d format all of my posts in WordPress’s visual editor, like I did with all of my other blog posts:
Unfortunately, this removed all of the indentation on my code:
This was skin-crawingly unacceptable to me. It turned out that, in order to make my code render correctly, I would have to use the WordPress text editor, which meant editing my post as an HTML document:
Now my code was pretty, but the editor would show my post like this:
Sometimes, I would forget to format a header to H2 or something, and then I’d have to go and put the tags in myself via the text editor, because switching to the visual editor when there was formatted code would destroy all of the formatting.
I ended up coming up with a third process:
- Copy and paste the article from Google Docs into the WordPress visual editor like I usually do
- Hit Publish
- Scan published article for any heading errors
- Go back into the post, switch over to the text editor, copy and paste the indented code into each and every snippet
It was a total headache, but it actually became quite streamlined by the time I got to the third article (notice a pattern going on here?)
I had to wait between writing, editing, and posting
As you can imagine, solving these challenges, researching the elegant solutions, and writing everything up in a clear way was a lot! I took a lot of breaks in between different parts of the process, such as writing and posting.
The entire thing could be broken down like so:
- Come up with pseudocode/code for a section
- Write up the section
- Repeat for all sections of my own solution
- Run code and fix any errors in the code (I have yet to run into actual “your solution is totally wrong” errors, but I’ve had plenty of syntax issues, especially since I came back to Java after coding in Swift for so long!)
- Write up complexity analysis section
- Elegant solution research
- Elegant solution write-up
- Run through the whole damn thing and make sure it’s coherent
I adopted a mantra: “Present Mimi writes, future Mimi edits.” And dear Lord, future Mimi hated her job, but she also sort of lived for it. 
Tl;dr — that first article was the hardest to produce because I was coming up with processes as I wrote it. Each one after that got progressively easier, even if the questions didn’t. Once the framework was in place, I knew what I was doing. It still took me a while to get the hang of things, though, so that’s why there were such long periods in between posting.
This. Project. Was. Hella. Involved. It required coming up with a framework through trial and error and breaking down incredible amounts of complexity into simple words and sweet little code snippets. All of this was on top of Leetcoding itself, which was a scary thing in and of its own, at least at first.
As with all challenging endeavors, my reward was the incredible amount of things I learned. Here are the insights I gathered from this month’s project:
Insight: Leetcode isn’t nearly as scary when you have a framework
Ah, yes, the entire reason I chose this project in the first place — I thought that Leetcode problems were super scary!
My writing framework also makes a great problem-solving framework. After coming up with it, I realized that a coding challenge is really just a set of steps to work through. What are my initial thoughts? How do I turn that into pseudocode? Actual code? How do I analyze time and space complexity? How can I optimize? And so forth.
I’m not going to say “I’m super confident about Leetcode hard problems!” because I’m totally not, but now I’m able to focus on the actual problem-solving part right away, rather than having to spend time forcing myself to be emotionally ready before I can start. This newfound problem-solving confidence is very nice to have.
Insight: I’m now (a little more) realistic about my technical writing timelines
(See also: the entire post above)
Writing about technical topics, especially when breaking down layers of complexity, requires a lot of research and process-creating. I also have to wait for Future Mimi to come around and force clarity onto muddied insights.
I still pride myself for quick turnaround time when it comes to articles, but I’ve learned to be realistic about my timelines and to not beat myself up when articles take longer to write than expected. Scope creep is a thing! Shit can turn out to be more complicated than I imagined. It’s okay, and it’s a good idea to regularly plan for it.
Insight: Expecting to write and publish on the same day is unrealistic
Halfway through writing my first post, I called my sister up in a panic.
“This thing is taking so long,” I whined. “I’m going to have to make my readers wait for something I promised, yet again. I suck at making estimates.”
She looked at me with a combination of exasperation and disgust. “You know, you can’t expect to consistently produce blog posts on the spot, every single day. Life gets in the way. Why don’t you just have everything written and then post them the day of, like you do with your Instagram posts?”
This blew my mind a little. I shoot a lot of pictures and often wait literal years before publishing some of them to my Instagram account. Why shouldn’t my approach to technical blog posts be the same?
Insight: An editorial calendar is very helpful when used properly
Theoretically, I already knew this. I’ve used editorial calendars on and off, but never really in the way they were meant to be used — i.e. to plan things out well in advance.
As much as I like to plan things out, I also get a lot of spontaneous inspiration. The real challenge is balancing the two: having a schedule with a set number of deliverables, while leaving room for things to change at a whim. I still haven’t figured out how to do this; it’s a process that continually evolves. 
Going forward, I will have an editorial calendar for each month, and I will start doing stuff for that month well in advance. This is different from anything I’ve done before; in fact, I’ve already gotten a head start on content all the way up to July. How’s that for a change?
Insight: I shouldn’t wait ‘til halfway through the month to announce my One Month Project
This goes with the last two insights — I had a bunch of life stuff come up early this month, so I didn’t announce my project (or get started on it) until April 12th, which is almost halfway through the month! The month before that, I announced my project on March 9th, which isn’t much better. How can I possibly expect to complete all of the stuff I want to do if I don’t give myself enough time to do it?
With the help of an editorial calendar, I should have everything come out on time — retrospectives on the last day of the month and announcements on the first day of the new month. I can be off by a few days, but I really shouldn’t be.
I think that getting three in-depth Leetcode articles out this month was pretty good, all things considered. I learned a lot about writing/formatting technical pieces, problem solving, and content creation in the, uh, 18 days I allotted myself for this project. I didn’t expect to run into so many content issues, but I’m glad I found a process that works for me.
I’m looking forward to next month, with its pre-planned editorial calendar and realistic timelines. ???? I certainly don’t plan on stopping my Leetcode habit; look out for more Leetcode-related announcements in the future! ♚
 What can I say? I’m an intellectual masochist.
 How long have I been blogging and figuring all of this out? Years. The answer is years. One day I’ll be closer to getting there …