Blank page frozenitis is a thing. And apparently Spongebob gifs are relatable to this problem.
Sometimes the hardest part of a project is getting started.
Spongebob has writer's block
If there’s an actual thing that can be talked about and picked a part that can help get the juices flowing. Drafts are often that thing. Even if the draft I make basically gets completely trashed, it still serves a purpose in that it may help get a discussion going about what we did NOT like about that first draft – and the second draft would be better.
So how do we get started? (this blog is really just me describing my general process – but of course there’s no one size fits all for every project and/or person!)
1. Don’t be afraid of mistakes!
Sometimes we aren’t frozen because we don’t know what to do; we are frozen because we are afraid of doing it wrong! The fear of mistakes or high emphasis on perfectionism can be crippling! And sometimes this fear is out of proportion with what the consequences of having a mistake out on the internet would actually be.
Spongebob is fearful of letting anyone see his draft
For a lot of projects, mistakes on the internet are not so bad and can even lead to meeting a nice person on the internet who points out how your product could be improved! Sometimes (not always) a 85% developed project is more useful than waiting for a 100% developed project that may never come. OR sometimes that 85% developed project should be put out there so that the last 15% can be better influenced by others!
Instead of focusing on making it perfect, tell yourself you can return to your project and (re)iterate and fix your content/code as many times as you need. There’s a tricky balance for finding the most effective time to request feedback.
But my point here is, ask yourself:
- The perfectionist - If you are a person who waits for a project to be perfect – would the project benefit from getting feedback sooner? Would your teammate benefit from seeing what you are working on sooner so they can help and give their input?
- The jumpy worker - If you are a person who jumps too quickly to ask for feedback – would the project (and your feedback giving people) benefit from you taking a beat to review the material a bit more yourself? Keep in mind feedback is a lot of work too. So moving too quickly to put something on someone else’s plate can also be not great for your teammates.
Over the years I’ve been both of these at times for certain projects: where I’ve waited too long or not long enough to ask for feedback.
2. Open up a document – anywhere! Somewhere!
Write as you think so you can form your thoughts like clay as you move along. This not only helps you form your thoughts but can help teammates weigh in on your thoughts if you have them written.
Starting with a Google doc or a Google spreadsheet is a good plan. If you start in a Google doc this makes it easily shareable and editable by your teammates. Then when anyone makes an update or leaves a comment or question, anyone who has been shared the doc has the latest in the discussion without the need for another email to be sent.
What kind of doc should you start with?
Software thing -> Open a GitHub issue and/or GitHub repo. Or if this software thing is going to have an interface or would otherwise benefit from a visual, a Google Slide image might help.
Manuscript, Communication, Course, or Presentation -> Start with a Google doc outline.Database, data collection, or listing -> Start with a Googlesheet.Survey -> Start with a Google form.
* Keep in mind there are much fancier platforms than Google Drive to make documents with. But Google documents are free and easily shareable and I generally like to recommend things that are free.
3. Write down the goals.
In this new doc, write down the goals in the bullet point list of needs to happen for this project. The more distinct, succinct and clear these goals can be the better.
It can be easy to get off track super quickly when getting started and miss the mark. These goals you right should as much as possible relate to endpoints that relate to who is going to use this thing.
You also may want to think about how this product is going to differ from already existing products out there. Is there something out there that can already do this better than what you might create?
Who is the user of this product?
The best way to create something that is useful is to have the person who this product is for in mind.
If the person is only you, it will hopefully be easier to answer these questions. But if its something for other people you may have to do more thinking, collaborating, talking and perhaps more formal data collections and surveys to truly understand. 
When they arrive to this product…
- What will this person know (or not know)?
- What will this person’s goals be?
- What will this person expect from this?
4. Make a big picture framework
Keeping these goals in mind, try to sketch out a rough picture of what you think this might look like.
If this is content, make an outline. Outlines often look like this:
I - Why the main topic is so important and relatable.
A - Relatable story about this main topic
B - Stats or stories about the importance of this main topic
II. The fundamentals (prerequisites) we need to cover before we can dive into the main topic.
III - (as many chapters as needed). Main topic(s)
Last chapter - A summary of what this has covered and a reminder of why this is so important.
If this is code, try to structure your code base (keeping in mind you may need to change it later).
Writing mock code or code comments where things might go can be a great way to start. For example:
# Set up my files and folders first
# Import some folder of data here
# Clean each file of this data with a custom function and maybe a purrr::pmap type function to loop through
# (maybe this custom function will be stored in a util folder later)
# Format that data
# Make the plot
sessionInfo()
For better or worse, I almost never start with a blank script or notebook. I almost always try to find something that looks similar to what I will want (something I’ve written before or something someone else has written that is similar to my goals and the steps I will want to take).
ChatGPT, Claude, Barde and other Large Language Models can be handy to ask for big picture structure. Be specific in your requests to them and reiterate and modify your requests if what they give you isn’t quite what you are looking for.
But use these chatbots with caution! You still need to verify any information that these chatbots give you. Read this course for more about how to use AI properly for software dev.
5. Collect and dump
Sometimes even in your draft you don’t need to start from scratch. Maybe you or someone else has created something related to what you are going to make. Copy and paste stuff and dump it into your Google doc or other doc to get started.
Spongebob is looking up sources
If you know someone who may know more about a particular topic, as them to refer you to sources or related code repos.
For both chatbot and search engine usage there’s a few things to know:
- Never take the first answer – reiterate and try different variations your google search or chatbot request.
- Always record your sources! and in the case of chatbots, verify their accuracy!
Find articles that are related? Dump the links to those in your outline where they make sense (no need to read them thoroughly at the get go, just dump them all in there and you can read them thoroughly when you write about them).
6. Start with the easiest thing for you to create
You have some raw materials to mold with after dumping resources and/or mock code into your files. Now try to mold it into something more polished.
Spongebob is cleaning up the dump of stuff
Work on content or code that you are most passionate and knowledgeable about first. Do you enjoy making visuals? Do that first! Are there topics or code you have a lot of familiarity with that it would be easy for you to start with? Start with that!
Stuff that you know less about or that you need teammates to weight in on, mark where that content/code would need to go. Tag them so they know.
ChatGPT, Claude, Barde and other Large Language Models can be handy to ask for drafts or advice on sections you know less about. Again, use these chatbots with caution! You still need to test and/or verify any anything these chatbots give you. This course goes into more detail about this
7. Leave and come back
If you feel you are slowing down at some point. Put it away and come back to it tomorrow! Breaks and rest are productive too! Brains need breaks. Also you literally will be a new person later and will forget some about what you are working on now. This can help you see things with fresh eyes and notice things that you wrote yesterday that didn’t make sense (I’ve done that with this blog post. Some things I wrote before didn’t make any sense today!)
Spongebob is relaxing
8. Feedback feedback and more feedback.
Now that you have some things formed somewhat. It can be a great time to show it to a teammate or others.
But here’s the key: You have to be ready to receive and adapt to that feedback. That means not holding too tightly on to your draft! (Remember it is a draft! Not a final product – and even final products shouldn’t be seen as final products if a new way to improve them is found and can be incorporated).
As you are receiving feedback remember that the feedback isn’t about you its about your product. I know this product may feel like your baby but its a good idea to keep your identity and worth completely separate from this thing you are working on. This is something that takes practice.
Perhaps Spongebob is taking some feedback a bit personally
Some feedback you may disagree with, but as much as possible, you should strive to accommodate your teammate’s suggestions in accordance with their knowledge on the topic or product. Sometimes individuals on a team may see something others don’t! The feedback process is a great opportunity for everyone to learn.
9. Soft launches
As you and your team are incorporate feedback, you will want to decide when or how to collect information from the users of the product you are making. Note that internal products or things that don’t have “users” in the traditional sense. But feedback can can range from super informal to more formal depending on the projects’ needs.
In this chapter I discuss more details about how to conduct formal-ish user feedback.
R version 4.3.1 (2023-06-16)
Platform: x86_64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.5.2
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib; LAPACK version 3.11.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
time zone: America/New_York
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] vctrs_0.6.5 httr_1.4.7 cli_3.6.2 knitr_1.45
[5] rlang_1.1.2 xfun_0.41 jsonlite_1.8.8 glue_1.6.2
[9] openssl_2.1.1 askpass_1.2.0 htmltools_0.5.7 hms_1.1.3
[13] fansi_1.0.6 rmarkdown_2.25 evaluate_0.23 tibble_3.2.1
[17] tzdb_0.4.0 fastmap_1.1.1 yaml_2.3.8 lifecycle_1.0.4
[21] compiler_4.3.1 ottrpal_1.2 fs_1.6.3 htmlwidgets_1.6.2
[25] pkgconfig_2.0.3 rstudioapi_0.15.0 digest_0.6.33 R6_2.5.1
[29] utf8_1.2.4 readr_2.1.4 pillar_1.9.0 magrittr_2.0.3
[33] tools_4.3.1 xml2_1.3.6
