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.
Oftentimes, it feels like we overengineer the solutions we build. Patching packages never feels this way.
When I use patch-tool, it's often the best solution.
It may not be the best long-term solution, but it's so darn fast. And at a startup, speed of development directly translates into product velocity.
So let me tell you how to use it. With an example: Patching Datadog.
Do you know how some kids want to be teachers when they grow up?
Do you know why?
I do. When I was in fifth grade, I was shy, short, and quiet. I had skipped two grades, and so I was two years younger than the other students. My parents had moved five times (Vermont, Pennsylvania, Indiana, New Mexico) before we had come back to Texas, and I didn't have a lot of friends. Or, for that matter, experience making them.
But in the mornings, before school, every day, I would get dropped off at around 6am by my parents. I would wait with the crossing guard until my teacher came to school, and then go sit with her in the classroom and write in my journal, and do my work, until school started. I still remember her name was Mrs. Hill.
In that class, I went from being a very-quiet, very-unsure, very-shy child, to being a mostly-quiet, mostly-unsure, mostly-shy kid. And, as anyone who's been in that situation can tell you, that's actually a lot of improvement. I felt proud when I could shape a spoon out of aluminum foil for our hands-on science demonstration, I felt good about writing, in a way I thought was interesting. And at Camp Tyler, an outdoor school that each 5th grade class in our public school distict visited for a week, I had fun.
(This post originally published on Tandem's blog)
What’s the piece of technology that reduced your headache the most in the last year?
tired: juggling your free time. wired: juggling some portal windows
I don't know. Maybe it's because I've got lots of things to do. Maybe that's just something I tell myself when I procrastinate work that seems hard. Why is writing hard? Because it's vulnerable? Or because vulnerable work is held close-to-heart, and the standards are higher, so I truly do need to do more work to get it out?
Why don't I feel like writing?
I don't know! Sometimes the words come out, and sometimes they don't. I guess this is one of the times where they just don't. Would I be better at editing right now? Why don't the words come out easily? Is it because I'm stressed, is it because I'm frustrated? Is it because I'm too tired and have exhausted all of my thinking potential earlier in the day? Should I not be writing late?
Why don't I feel like writing?...
Okay, this title-repetition has worn off. I can't keep going the whole way, should I scrap it? Should I just delete the whole thing and start again? Sometimes, when I delete the whole thing, I feel that the next time, I might be less inclined to start it in the first place.
My parents live in a fairly rural area of Texas. There's no cable internet, and fiber is out of the question—they're the target demographic for Starlink. When I was in high school, we used our phone landline for a very-flaky, too-expensive DSL. Nowadays we use hotspots.
So if there's no hotspot, there's no internet.
And when I flew in this winter to visit, my paid hotspot plan didn't activate on time. So there I was, sitting in quarantine, trying to use my laptop with no internet. But annoyingly, I already had unlimited phone data.
I wondered: why can't I use my phone's LTE data to hotspot? As it turns out, it's not that you can't—-it's just that iOS doesn't want you to.
Here's how I managed to get a DIY hotspot working on a regular, non-jailbroken iPhone.
Most task managers make two assumptions. Do you make them too?
It's not obvious that they're wrong—-they actually seem useful. But both at work, and at home, making these assumptions will reduce your effectiveness.
And if you have trouble context-switching, procrastinate tasks, or have an ever-growing task backlog that looms over your head, these assumptions have likely caused you unnecessary pain.
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.
Having a home server has many benefits:
And you might find this useful, when you have:
I used to find writing for a public audience to be a taxing process. I wasn't sure why, but I thought it might be because my workflow was bad. To tackle that, I built a small project. I hoped it'd be an end to my writing troubles.
This post goes over how I built that project (it is kind of a cool project). But it also goes over why it was the wrong solution.
To decide what I "needed" to build, I started by comparing workflows: I looked at the way I wanted to write, and contrasted it to the way I did write.
My previous workflow had me spend a lot of time in my text editor. Which I thought was bad for writing, because when I'd start writing, I'd try live previewing my blog, and only an hour later realize I was knee deep in minor CSS changes.
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.
So you're a beginner to either hackathons or hardware hacking, and you're not sure what to bring? Well, at HackDFW, we've got a pretty solid hardware setup, so you should have everything you need. At hackathons that aren't as focused on hardware though, here's an example list of what to bring. There's also a section on helping you figure out which board to use for a project, and some cool hardware projects to inspire you.
You won't need everything on this list; you'll probably use less than a third of it for a single project, and you'll probably have projects that might need something more than what I've listed. It's always good to be prepared, though, and you can't slap on another sensor in a hardware project as easily as you can download and require another library in a software project.
Here are some things that it'd be hard to really make a hardware project without:
This isn't just for people who haven't gone to hackathons before, but also for people who went to one and had an underwhelming experience. Hackathons are all different, so don't let one bad experience shy you away from them.
So you're going to a hackathon. You've signed up, and you don't know quite what it is, but you're interested, maybe because you've heard good things about them or they sounded like fun. They're all pretty similar in concept, but when I think of hackathons, I think of coroporate hackathons and collegiate hackathons.
Corporate hackathons are generally smaller than collegiate hackathons. Both in size, and in time spent working. That's not to say they're bad, some of the ones I've been to have been better than some of the collegiate hackathons that I've been to, despite their size. These hackathons will generally be 50 people or less, and all the ones I've been to have been less than 24 hours, and they've also had participants go home for the night and come back in the morning. They also usually have no problem with providing enough food and snacks.
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.