I have a new project! It’s called ReadFaster.app. I’m launching it May 1, 2020.
When I usually talk about my projects, I’m either thinking about starting something or already have something in progress. This time is different: I’m already done!
I started this project for Startup School. I needed something to build and decided to work on something I’ve wanted for a while.1 Plus this idea is simple enough to implement that it gave me time to focus on other aspects.
This project was more about the process and execution, and less about the idea itself. It was my first time taking the Startup School course, attending group sessions, getting feedback about the idea, and talking to users… all before writing a single line of code. Usually I start with code 🙃. I learned a lot this way, like how to really focus on the problem and the why.
I did most of the implementation in the last couple of weeks. It was a nice way of taking advantage of all of the free time I have during this COVID-19 pandemic.
Here are some implementation details. I did a few new things this time:
Now that this is all done… I should to get back to reading 😂.
A former colleague used to tell me that when it comes to QA, there’s no replacement for someone manually clicking around and trying different things in your product. After thinking about that for a few years, I agree with it more than ever.
Automated unit tests, integration tests, end-to-end (E2E) tests are all important. They make sure things work as expected. They catch any breaking changes you may accidentally introduce. You gotta have them. But they’re only as good as your test cases. You can cover a lot of ground with just a few test cases, but getting to 100% coverage often requires unreasonable amounts of time. Not worth it. That’s OK—done is better than perfect.
You know what QA approach I think has a great return on investment? Just clicking around and trying different inputs. You don’t need to think so much about what to test. Just play around with things. It’s often very clear when things don’t work as expected. I find lots of issues this way.
You can start by opening up your documentation and following what it says. This is how users start using your new features anyway, right? It’s important to make sure those cases work flawlessly.
Demo prep is also a great way to find issues outside of automated tests. Those are usually the first times I try out a feature with an actual use case or workflow instead of something in isolation. Plus, the issues I find aren’t just bugs that slipped past automated tests but also usability issues, things that make workflow implementation really hard or impossible.
The final test for quality comes from having a person trying out what you built. Better for you to run that test before a customer.
I’ve been trying to read more. I’ve had a Goodreads reading challenge every year since 2017, and my goals have been at least 12 books a year. Even though I’m more serious about reading than ever, I’m actually reading less. It’s been difficult to come up with a reading strategy that becomes a habit.
I often have to securely share sensitive files with colleagues. I do this several times a day so to save time I have a few scripts that run GPG commands to encrypt and decrypt files.
Happy New Year! I turned 26 late last year. The nice thing about having a birthday near the end of the year is I can plan for the next year of life with the calendar year, and treat New Year’s resolutions as age resolutions too. Here’s what I have planned for 2020.
My most recent work with GitHub Actions involves migrating Transverse from being deployed manually using Ansible run on my laptop to a CI/CD approach using Ansible on GitHub Actions. Now I can push changes and deploy from anywhere without requiring access to my personal laptop or the private keys to connect to my server.