DEV Community: gunderodd

'Read the Docs' and Escalation of Complexity.

gunderodd — Wed, 08 Apr 2020 05:29:55 +0000

This is going to be a bit of a rant. But I think that, at the very least, it will help me organize a few thoughts about what it is like to teach myself to code. In the best case scenario, possibly I can point out a few things that will help more experienced coders share their knowledge. If I could choose my own target audience, it would be anyone creating educational coding content, regularly providing answers on forums like stackoverflow or r/learnprogramming, and/or making courses for youtube, udacity, udemy, etc.

Since I'm the newb in this situation, why would I be providing advice at all? For one simple reason: The Curse of Knowledge.

It is extremely apparent that many well-intentioned instructors have great difficulty in remembering back to a decade before when they didn't know what they know now. They can't put themselves in the shoes of a student who hasn't had the time and experience to build up a rich vocabulary of jargon, topical connections, and analogies. This leads to some grave errors, both in tutorials and in answers to questions on forums.

All that being said, I'll just break down my gripes into two sections:

1. "Read the Docs."

There is no single cliched phrase that makes me feel so bewildered and inadequate as this one. Sometimes, saying 'Read the Docs," is just an obvious cop out, motivated by laziness. I'd hazard a guess that 70% of the time this phrase appears on forums it fits into this category, written by someone that wishes to appear knowledgeable while also remaining either incapable or unwilling to productively share what they claim to have mastered. Such is the self-aggrandizing behavior of nerds on the internet, and it is commonplace and not particularly surprising.

But I don't want to get too far into the weeds with that group; it isn't worth worrying about bad actors. What really confuses me is how so many otherwise competent instructors seem to think that this is genuinely relevant advice.

I can read the docs on a JS method or a CSS trick, and I can apply that information. But right now I'm working on a fullstack application using SQLAlchemy and Flask and Postgresql. Have you seen the docs for those tools? There are dozens to hundreds of links, each referencing different tools that are completely unprecedented to a coding student, and each link opens up to an article that can only be parsed by someone who already understands another set of jargon. This is a rabbit hole at best and a paradox at worst.

I get that there are some savants out there who are much more clever than I am, who don't use tutorials, and who get started by reading docs and building a project without any hand-holding. But I would think it would be apparent that such outliers are emphatically not the core audience for tutorials and courses.

If you are introducing me to SQLAlchemy, what possible use could it serve to invite me to 'Read the docs?' Which docs? All of them at once? That would be like inviting me to quit your course to read a short to medium length novel full of foreign language terms that I would be forced to look up just to make it through a few sentences. It isn't an exaggeration in any sense to say that I could start on one set of docs and study them and their jargon and the jargon used to define those terms indefinitely. If I intended on actually remembering anything that I'd read, I'd have to also write notes and build small projects with all of those new methods and parameters, and as I am currently incapable of building those projects I would have to find another tutorial to guide me through the process, spinning my wheels in tutorial purgatory.

I've spent 41.5 hours in the last week on a Udacity course. It has taken me that long to go through the material, work on the projects, debug, read and watch other resources to supplement what I can't understand from the course. In what way could it possibly make sense to also follow the instructor's advice to 'Read the docs' for half a dozen complicated tools? How would I ever make progress in that way? Can Achilles catch the tortoise if every step forward requires infinite intermediary steps?

2. Escalation of Complexity.

This is my own term for a phenomenon that might already have a name in learning theory. What I mean is the difficulty of tests, questions, or projects as compared to the preceding educational material.

There is nothing as demoralizing to a student of coding as reading a page explaining a single concept, and then being asked to prove their comprehension by answering a question that escalates the complexity beyond recognition.

For example, let's imagine I wrote a chapter about creating variables in JS, and gave examples of using const or let followed by a name, equals sign, and value. Now it is time to test the student. What problem should I give them to work out?

1. Arrange the following into the correct syntax to declare a variable:

[myVar, =, "Hello, World", const]

or, instead, should I ask

2. Write an algorithm that demonstrates the differences in scope between var, let, and const.

That is a clumsy example, and contrived, but hopefully it at least communicates how it feels for a student to learn how to count to 10, and be tested with a question requiring them to count to 100. The first question could be described as a "1" on a scale of complexity, as it mirrors the content without any twists, and could possibly be answered by an attentive reader who is good at tests but not actually learning code. The second question, however, might earn a score of "20" or more in terms of escalation, and any student who could answer it would prove themselves overqualified for such a course in the first place.

For a more real world example, let me try to describe my experience with my current Udacity course, and to list some examples of the complexity that is introduced in the first unguided project, as compared to the project that we built along with the chapter material.

The first real project introduce and requires...

The use of virtual environments, while providing a single set of instructions that assume operating system and don't bother explaining that they are not universal
3 or more tables for the DB, each with 10 or more columns of information to keep track of, as compared to 1 table with 2 columns in the walkthrough project.
The use of template inheritance
The use of Bootstrap
A project scaled at over 10 html pages, 6 individual forms, a separate config file, as compared to a walkthrough project with one of each
Greater variation and complexity in the employment of fetch(), using json, and all the other topics introduced in the material

I am absolutely not suggesting that a good teacher should never challenge their students with a moderate escalation of complexity. I am absolutely not suggesting that struggle is bad, or that the most important lessons aren't learned by doing rather than passively watching/reading.

What I am saying is that any high quality instructor, in code or any other subject, should constantly be aware of the complexity of the problems they use to test their students knowledge, and should be intentionally manipulating that complexity. A good teacher should be able to articulate why one project is appropriate based on what it requires, and why a slightly more or less complex project would be unsuitable.

Conclusion:

I have am extremely lucky to have access to endless free and paid learning resources to help me transition into a new career. I take responsibility for my own progress in this pursuit, and recognize that it is limited by my intelligence, dedication, consistency, study habits, lifestyle choices, and so on.

If you answer questions on forums because you have a sincere desire to share what you've learned, or if you produce educational content and want to provide a high quality service that will earn you more clicks, likes, ad revenue or tuition fees, please reconsider both the generic advice for beginners to "Read the docs" and the escalation of complexity in your material. Ask yourself:

If a student is learning to use _____ technology for the first time, what are the chances they will be able to grok the full documentation for that tech?

Am I advising someone to 'Read the docs," in good faith, perhaps with a link to the relevant page that a beginner might not have found on their own? Or am I saying it to save myself time?

Is it possible that I am subject to a Curse of Knowledge bias, and am unable to imagine that a beginner would not be able to form the proper google search keywords to find the answer to their question?

Am I asking a student to answer a question that does not escalate complexity, escalates the complexity to a point that will require them to think, to a point that will inevitably frustrate them, or somewhere in between?

How can I be aware of the complexity of tests and projects in my course, scale it, and intentionally apply it, while avoiding the temptation to mistake an expert's grasp of a subject with a beginner's?

Mini Solutions Series #3: Can't forEach()

gunderodd — Mon, 06 Apr 2020 01:00:02 +0000

BUG:

"forEach() error" or "forEach() not working" or "for each is not a function javascript"

Detailed Description:

In the past I haven't had enough confidence in my grasp on basic JS syntax to know why my use of the handy forEach() method wasn't working. I did complete Wes Bos's 30 Day JavaScript Series, and I vaguely remembered him mentioning something about a common beginner's mistake.

Fortunately, by this point in my studies there is less mystery about proper syntax, and I decided to pop into Stack Overflow, and it didn't take long for me to realize...

Solution:

...that what I was trying to iterate over LOOKED like an array, but it wasn't. It was an HTMLCollection. But you can turn that into an array with the equally convenient spread operator, and then use forEach().

The explanation that helped me.

Takeaway:

So, using

const myArray = [...document.getElementsByClassName('myClass')]

INSTEAD of

const myArray = document.getElementsByClassName('myClass')

BEFORE trying forEach() is the code that fixed my problem.

Bonus Tip:

I'm trying to cram a 4-6 month Udacity Fullstack nanodegree program into 1 free month. Saving money is a great kick-in-the-ass motivator, and I've never spent so many hours coding in a week. I can see that up until now I've underestimated my ability to soak in a lot of new information and debug dozens of new problems - my head is spinning a bit, but instead of feeling overwhelmed I actually feel more competent as a coder than ever before.

Mini Solutions Series #2: Missing Box Shadow

gunderodd — Sun, 15 Mar 2020 13:41:03 +0000

This is the second installment of a collection of short summaries of the solutions that I found to bugs in my code. I want to document some of these solutions for my own sanity (so I can remember challenges that I've overcome in the past), and in the hopes that someone googling for an answer in the future will find their own solution more quickly this way. I'll include a few keyword and phrasing variations that someone might use in their search.

BUG:

"why no box shadow" or "box shadow missing on header" or "can't see box shadow" or "css no box shadow on div" or "box-shadow no effect"

Detailed Description:

Super straightforward. I wanted a typical box-shadow on the header for a design that I was working on tonight, and it just wasn't showing up.

Experiments:

I added a border to the header, and that worked, fine.

I added the same box-shadow to other elements, which also worked fine, and ruled out a syntax error.

I backtracked and noticed that my original mobile header did show a shadow under the header, but not after responsive design changes for a desktop format. I began googling, which led me to try a few more things that didn't work as I intended.

Solution:

Quick answer.

Thorough Explanation:

A longer answer isn't really required, but here is a video for more on z-indexes if you are thirsty for knowledge.

Takeaway:

Background images can cover up box shadows. Raising a div in the visual hierarchy with a z-index can plop it back on top, revealing the drop shadow that was working but hidden. To use a z-index, an element must have fixed, absolute, or relative positioning as opposed to the default static setting. The specific number 10 was arbitrary, in this case, and 2 or 1000 would also work just fine.

So,

position: relative;
z-index: 10;

is the code that fixed my problem.

Mini Solutions Series #1: Broken Media Queries

gunderodd — Fri, 13 Mar 2020 19:43:53 +0000

This is the first installment of what I intend to be a collection of short summaries of the solutions that I found to some bug in my code. I want to document some of these solutions for my own sanity (so I can remember challenges that I've overcome in the past) and in the hopes that someone googling for their answer in the future will find their own solution more quickly this way. I'm also going to try writing out a variety of the ways that I think I or another programmer might phrase their searches.

BUG:

"media queries not working on device toolbar" or "responsive breaks not working in chrome dev tools" or "chrome dev tools devices not changing with media queries" or "why media queries no effect in chrome tools"

Detailed Description:

I designed a website (desktop first instead of mobile first, bad habit) and started adding media queries for responsive design. When I resized the screen in the developer tools I saw my changes (small header, fewer grid columns, etc), but when I clicked on the "Toggle Device Toolbar" button to use Chrome's built in devices, none of my responsive design was reflected.

Experiments:

First, I re-read about media queries, and remembered to add "only screen" after the "@media" bit, and I got excited because I thought that would fix it...but it didn't. No change.

Second, I added a big ugly border to the header under 'max-width: 599px', and determined for certain that I wasn't crazy, because the header just wasn't showing up on the mobile views.

Solution:

Quick answer.

Thorough Explanation:

Takeaway:

I ran into this problem because I never really understood why that meta tag is in most boilerplate HTML. Now I understand a little better, and will probably remember if something like this happens again. I ran into the problem because I made a local copy of one of a CodePen of mine and forgot to include that tag.

So,

content="width=device-width..."

is the line that fixed my problem.

Little Victories and Major Meltdowns in Front End Comic Design

gunderodd — Tue, 11 Feb 2020 10:59:41 +0000

Parallel to my goal of learning to code for a career change, I’m motivated to learn how to build my own web-comic/illustrated/animated/multimedia-art-and-storytelling-experiences. You know, c o n t e n t. Anyone doling out advice about how to learn to code mentions, at some point, the importance of building your own projects that interest you. For me, that means this sort of thing.

I’ve been working on this comic off and on for half a year, in between free code camp and javascript tutorials and group projects. I wish that I’d worked twice as many hours and finished it in half the time, but I have to acknowledge that the original concept (a short story with half a dozen pen drawings for illustrations) simply grew out of hand very quickly. And, since it took so long to get to a point that I felt good about calling it ‘done’, I can look back to the start of the project and see a consistent escalation in my grasp of the HTML, CSS, and JS required to complete it. And that is satisfying in its own right.

When I started this comic, I only knew a fraction as much about HTML and CSS. I didn’t know any JS to speak of. Now I can debug the legion of positioning errors and faulty margins and broken z-indices that plagued me back then. This article is about things that I learned as I built it, and what I want to build next.

Easy-Peasy Parallax

Parallax is hot in web design, and has been for a minute, and it has always looked amazing in animation. Back when I started this comic I knew that I wanted to employ parallax, and I spent a fair amount of time finding the right JS snippet to borrow and figuring out how to integrate it into my site. Unfortunately, it never really worked smoothly, and I couldn’t even get close to understand how it worked, and I’d rather not use JS in my projects if I’m just crossing my fingers and hoping it does some magic.

Then, I read about background-attachment: fixed, which was one of the single most satisfying discoveries that I made during the entire project. It turns out that you can use a CSS background image to achieve parallax with almost no effort. Just remember to set a height on the background.

Blend Modes

Blend modes are used in digital art to combine images to come up with creative color and texture effects. Discovering that CSS has two properties to work with them (background blend mode and mix blend mode) was the biggest single breakthrough of the project for me. I used them all over, and the comic wouldn’t look half as interesting without them.

On the other hand, blend modes turned out to be one of the worst aspects in regards to translating to other browsers. Even Firefox and Edge, both of which basically display my comic as I intended while I built it in Chrome, do not display the blending modes in the same way, rendering some pages illegible.

For future comics, I’ll have to figure out how I can display completely different panels, basically, but as I researched how to go about doing that I found that it isn't kosher to try to detect what browser the user has. That makes the use of blend modes a big question mark for me. I’ll probably use them in comics and other creative projects where I can ask the user to try out Chrome for a good experience, but not on my website or other projects where it is my responsibility to put the UX first. As it is, some of the panels in my comic simply don't display anything in Edge and some other browsers, which sucks.

Testing is Hard

Up to now, I never tried to comprehensively test a project across all devices and browsers. I did some responsive design, but when it came to different CSS properties and their compatibility I didn’t realize just how sticky things got. As far as I can tell at the moment, there are a few paid services that will emulate different browsers and devices, but even then it isn’t as certain as actually experimenting with the project on, say, a 2012 Android browser on a device from that year with its respective OS version.

I’m curious what I’ll find out as I continue to learn about this...I mean, if you work for a big coding company that creates designs for lots of clients, is there some guy who lives in a closet full of cell phones and laptops from every year and infinite VMs to try it on everything? How does anyone get this part of a project done correctly?

Image Optimization

After the rough draft, the comic took nearly a minute and a half to load, because my media folder weighed in at 120mb or more. I was using JPG and PNG formats, with a couple of GIFs. I left each image at the highest possible quality, most of them measuring two or three times as wide as they would need to display on most computers, because I have a natural abhorrence of my lovely illustrations being pixelized. (Side note: Is 'pixelized' a real word, and if not, why not?)

By the time I pushed the last commit, I learned a lot about image optimization and put a few key points into practice. The most important part was using WebP format, which I had never heard of until recently. You can easily convert your images in a free image editor like Gimp, or at https://squoosh.app/ . I am shocked by how much quality they retain while the size shrinks down to a fraction of the older formats, and just doing this step cut my load time down from a roughly minute and a half to maybe 8 seconds.

I also stretched the limits of my JS comprehension to figure out a lazy loading solution, which shaved off a few more seconds from the initial load time. I used this excellent tutorial by Kevin Powell, so that I could have some understanding of what I was doing. Incidentally, his solution used Intersection Observer, which, again, I’d never heard of until last week, and since then I’ve been using it for all sorts of scroll effects and animations.

As exciting as this all was, the WebP format has some unfortunate drawbacks. Safari doesn’t support them, and neither does IE. Once again, this made me struggle to decide exactly how much effort I wanted to put into making the comic work for every user on every platform. I was expecting to run into some CSS features like filters that wouldn’t work as well in other settings, but simply not having any images show up in a web comic is a bit lame.

This led me down another rabbit hole, namely the <picture> element with its fallback images, giving browsers the option to load traditional, larger files like JPGs, or the WebP files if they can handle them. Now that it is all said and done, I am still not sure if the time I spent on the research and implementation of this approach was really worth it; the comic still looks mostly unpresentable on Safari and IE, despite all of that extra effort.

And it didn’t end there, unfortunately. Using <picture> is a good approach for the HTML side of the project, but I used plenty of images as the background of <div>'s in the CSS. Thankfully, this same excellent CSS-Tricks article also went on to describe Modernizr. I downloaded some code from them that allowed my comic to detect if the user’s browser supports WebP images, generated a class to reflect that, and gave me the ability to show the necessary file type.

In the end, I learned A LOT about file types and optimization, the <picture> element, and lazy loading, and at least the comic loads in 4 or 5 seconds. If I had to do it again, I would definitely optimize my files, and I might take the time to edit them down to sizes that don’t waste bandwidth, but I probably wouldn’t use the <picture> element, because it was a lot of work that didn’t do much to open up the comic to other browsers, and I’m pretty sure it broke my lazy loading snippet, which is currently in a sort of limbo state of console logs giving me contradictory information that I can’t wrap my mind around.

And in conclusion...

I ended up with an interesting comic, and I learned a lot, and I can tell that the projects I'm working on now are WAY better because of all the experience that I built up with vanilla CSS and JS. I might come back to 'gods' in a year and patch all of the remaining issues, or maybe I'll leave it be and let it remind me of where I was in my personal coding journey at the start of 2020.

8 things I learned in The Collab Lab

gunderodd — Fri, 17 Jan 2020 22:33:05 +0000

I Did A Thing, And It Was Fun And Made Me Bang My Head Against A Wall

I started teaching myself to code a little over a year ago, and even going in I knew that I needed to make sure to make the pursuit social. I value the encouragement and accountability that I can’t get just working on my own, and I also knew that networking was theoretically going be useful somewhere down the line. But I had no idea just how quickly a few fun Meetups would lead me into the biggest challenge and best learning experience that I could have asked for: The Collab Lab.

Two months ago I got accepted into the second cohort of this brand new sort of bootcamp, a place for junior developers, recent bootcamp graduates, and newbie self-taught students like myself to join up in a team to tackle a project and learn about the enormous fraction of a web developer’s career that isn’t covered in code tutorials. For 8 weeks, we built a React app from the ground up, attended weekly conference calls, collaborated on code with our teammates, shared resources, patched bugs, stressed out publicly on Slack, and in the end got some indispensable experience that I sincerely doubt we could have found in any other code school, Meetup, or online resource that I have come across.

This post is my own reflection on the project, now that it is completed. I’ll break it down into eight things that I learned, one for each week, in no particular order and with no guarantee that I won’t ramble on well outside the margins of any reasonable reader’s patience. To start off, here is a time lapse of our team’s weekly demos, showing the app from its initial stages all the way up to the final polish:

We called it Listably, and here it is, a working web app and smart shopping list, hosted on Netlify. Feel free to try it out.

Week 1: Being On A Team

The first week is the most difficult to condense, because I had to learn so much just to get started. When the project started I was still learning vanilla Javascript, and suddenly I had to cram React, as well as Firebase for our data and Cypress for testing. The process of learning a new technology was already familiar to me, but doing it on a schedule, with a team of people who all brought their own experience to the table, was brand new.

Learning React was far easier for me because I had a consistent set of challenges to overcome, and because I could look at what my teammates were doing and ask them questions about how it worked, or go directly to our coaches to get an explanation from someone who has been using the technology for years.

Right off the bat, we started out by focusing on communication. The project started out with a Zoom conference call to get to know each other a bit, and both teams, two students apiece, started a Github wiki page to keep track of our progress, brainstorm, and collect the resources that we found the most helpful in one place. To be honest, I’m super proud just of this one aspect of Collab Lab. The organization is soooooooo satisfying, and I never could have guessed how important that attention to detail would become based on all the time that I’d spent working on solo projects, for myself and by myself. Here is our lovely wiki home page, with each team’s notes for all 8 weeks:

Pro Tip: Wiki pages are a great place to store sensitive DB information, because no one except you will ever care about reading them.

At the end of week 1/start of week 2, we did another conference call to demo what we'd accomplished, ask more questions, and get started with our new group pairings:

Week 2: Slack, Zoom, Stories, AC, Retros, Code Reviews

Just getting used to web developer jargon, getting familiar with the concepts of breaking a task down and assigning jobs to each team, and getting comfortable with discussing code on video calls would have been enough to make this project worth the effort.

I love that each of these things would have confused me and made me uncomfortable 8 weeks ago, since they were basically brand new concepts, but now I feel that when I get a job I will already know the ropes.

Most of all, I know that I am now 100% better at explaining code that I’ve written out loud. I am better at making sense to other people out of material that only made partial sense, inside my head, in the past.

Pro Tip: A coder with a strong grasp of developer jargon should be able to summarize an entire topic in such a way that no one else on the team is 100% certain whether they are correct or making things up.

Week 3: Drivers and Navigators

Before Collab Lab, I’d assumed that coding was always done alone. You’d write something, then show it to your team, end of story. Pair programming is a game changer. Just like code reviews or conference calls, pair programming forces you to articulate what you think you know. Every session is a mini exercise in the Feyman Technique.

Pair programming also comes with hazards. I found out that it can be easy to let the more knowledgeable partner drive the whole time. It can feel difficult to suggest taking over if you don’t feel confident about the material, and it can be hard to slow down and explain what you are doing if you get in a flow, get excited, and just want to finish up the work. But navigating those patterns is completely worth it.

Pro Tip: If you find that you are unable to explain how a technology or approach should work, simply ask someone else in the meeting to explain their understanding, and then nod and say something like, "That's basically correct."

Week 4: Using Git Well (And Dealing With Merge Conflicts)

Anyone working on their own projects, and many people working on their assignments for various bootcamps, might get the wrong impression of just how powerful Git can be, and how complicated it can get. I feel so much more comfortable with managing branches than I did in the past, and also much more motivated to continue learning now that I can see what a lifesaver certain tools can be. For instance, I only learned about Git Rebase in week 8, and I know it would have saved me some headaches if I'd only found it early on 😭😭.

Specifically, this project taught me how important it is to create separate branches for side issues and patches. So much better than digging through the commits looking for a file I changed 2 days ago.

Pro Tip: When dealing with merge conflicts, never accept any incoming changes, because if the other team wrote their code once, they won't mind doing it again.

Week 5: Asking Good Questions

Everyone knows that a newbie asking newbie questions might get their head bit off on Stack Overflow or Reddit, and they might come away with no information about how to improve their question in the future, and attribute the incivility to anonymity and trolling.

But what happens if your own team can't help you, because your questions are too vague even for them?

Over the course of this project I was frustrated to find out just how often my questions appear crystal clear while coming out of my mouth, only to get cloudy the moment anyone else has the misfortune of hearing them. It is so important to not assume that other people know what you mean, to put yourself in their shoes and imagine how your question would sound if they aren't currently by some cosmic coincidence reading the same article that you are.

This works in the opposite direction, too: If I think I know what someone else is asking me, I'd do us both a favor by verifying that with my own questions, rather than shooting them a link to an unrelated subject that leaves them more confused than before they asked.

Pro Tip: If you need to exit any conversation quickly, just yell, "Read the docs!" and run away. Oddly enough, not a single one of my coaches or teammates at Collab Lab put this tip to use...

Week 6: Cooperating On Subjective Stuff

I'd estimate that 70% of the actual coding in the project seemed objective. Sure, there are other ways we could have gone about using hooks or naming variables, but the way towards accomplishing the week's AC was to follow a linear path, using the best idea the either team member could come up with at the moment.

Then, there was the other 30%. It is much harder to make a decision on styling or organization when there is no single right decision. Group dynamics with subjective decisions are more difficult; I learned that I'm more likely to feel stubborn about using MY idea if it is about styling or app structure that feels good to me. I learned that picking your 'battles' (i.e. discussions about preferences on margins 😂) is important, and compromise is important.

Pro Tip: Always insist that your opinion is the best for every issue in the production process, otherwise your team will sense weakness and question the supremacy of your theories.

Week 7: Tips From People Who Went Where I'm Trying To Go

The conference call for week seven was especially important for me, because Caitlyn gave a great talk about her experience moving from the Collab Lab, in the first cohort, to her first coding job. She talked about how much of the job involves meetings, writing just a few lines of code and reading hundreds, and how many different considerations go into writing good code for a company project rather than a bootcamp lesson or tutorial. Some of what she had to say felt intimidating, a lot felt encouraging, and all of it was insightful.

Pro Tip: I hope no one is taking any of these Pro Tips seriously...THEY AREN'T GOOD IDEAS

Week 8: Calling It Done

I have spent most of my life working on creative projects, and then facing the inevitable struggle of finishing them. Does it need more work, or am I being a perfectionist? If I call it finished, am I being lazy, or pragmatic?

Honestly, this entire period of the project was far easier because it wasn't just my thing. It is sort of low-key amazing to have a structured timetable, a deadline, and a whole team to work together on polishing the final details (and agreeing on what details are nitpicks that aren't worth the effort).

Pro Tip: Van Gogh once said, "No project is ever truly done if you just quit the job before the deadline, refuse to push your commits, and steal the company server." [emphasis mine]

Thanks so much to everyone who participated in this project with me, and to the coaches who put it together. Collab Lab was free for the four of us, and our three excellent coaches all volunteered their time. We used freemium tools, but the project could use some donations to upgrade on Github and Slack, etc. Please consider sponsoring the program.

The Collab Lab Cohort #2 consisted of:

Team:

Michelle

Claudia

Mindy

ME!

Coaches:

Andrew

Stacie

Alejandro

Follow Cohort #3's progress, and beyond, at @_collab_lab