Well, I'm not exactly a Product Manager. I'm still an engineer, but we're trying out something new at Jam (where I work). For this 6 week engineering sprint, I'll be PM'ing the features we build.
This is partly because the sprint has a highly-technical focus (our developer tools), and partly because once earlier, around a year ago, I asked to improve our developer tools.
That time, I gave my case for why our devtools should be improved, and asked for just three weeks to clean up the UX to make them look and feel more like native browser devtools. I got six weeks, and the option for Jam to pay Bernat (the designer I worked with at Tandem) to do designs for us for a couple hours—an option I obviously took.
That project turned out well, and Jam as a whole has been doing great in the year since. So we're at the point where our devtools yet-again have access to resources to make them even better.
Namely, engineering resources: me, and the rest of the engineering team. That takes us back to the title. For these 10 weeks (4wks planning + 6wks eng sprint), I'm not exactly a full-time PM. I'm a PM who's also an engineer. So I've even allocated myself to the engineering sprint.
Have you ever wondered how mail clients work under the hood? Most mail clients fetch your mail with a protocol called called IMAP, and it's surprisingly human-readable.
Here's how it looks:
Three examples of how you might use the IMAP FETCH
query to see the raw data that your mail client uses
Above, I've queried the same message in three different ways, each returning different data. More info on IMAP commands and queries can be found in the latest RFC: IMAP4rev2.
This post is about saving money on hobby projects, by scraping the bottom of the barrel with what your cloud provider offers.
Most cloud providers have a free tier of hosting, with low RAM. For example, Fly.io currently offers 3x instances of a shared-1-cpu instance with 256mb RAM. But what if you need more? Fly.io's pricing page shows you'd pay ~$10/mo for a 2gb RAM instance.
I have a side project that uses very bursty RAM, so it feels annoying to pay for 2gb RAM for a whole month, when I really only need it for a few minutes a day.
Enter the solution: swapping to disk.
(This post originally published on Tandem's blog)
What’s the piece of technology that reduced your headache the most in the last year?
For me, it’d be Portal Windows. It's a library we made at Tandem that lets you render and position native windows as simply as you render and position tooltips in your React app.
tired: juggling your free time. wired: juggling some portal windows
Fiddling with monitors is annoying. This method lets you get an SSH connection to your Pi without having to connect it to a monitor, find an external keyboard, or manually type in your wifi password.
Simple and portable enough that you could do the entire process at a cafe
Taking out the manual process and sending everything over the wire makes it much easier to automate initial config, and I found it very useful when setting up my home servers with Ansible.
This weekend at HackPrinceton, my teammate Benny Yan and I made a prizewinning electronic banjo. It's not an electric (amplified) banjo. The difference is when you hold down frets and strum strings, the sounds it plays are mp3 files, not amplified string vibrations.
Final software and hardware, side by side
In addition, there are LEDs under the fretboard that light up to show you where to place your fingers (in our demo, we showed chord positions, but I have a few other ideas for it that I think would be cool). We also had a nicely designed UI that you could use to show which strings and frets were being pressed down, as well as selecting chords to view and have displayed on the banjo's fretboard, and a list of songs to go through and show chords and lyrics for in realtime.
Here's my first post on here. I wrote it before I ended up setting up my blog. I figured I had to start writing blog posts some point, and by writing my ideas on things as I encountered them, I'd remember my ideas better.
I started writing this after looking at some GitHub API docs, and not understanding how to read files from a private repo. I ended up looking around, realizing the answer after looking at a GitHub gist, and thought I was an idiot for not realizing it sooner. But I realized that even if I was being an idiot, I had read the page and the OAuth page, and knew they needed to fit together somehow: all I needed was an example.
When writing documentation for our own programs, we're biased. Very biased. Not only do we know how to write code or use our software efficiently, but we also know exactly how it works the way it does and the processes it takes.