Unboxing the PocketCHIP

One year ago, I backed The CHIP, the world’s first $9 computer. It arrived one month past its original ship date, which is impressive for a Kickstarter campaign.

Since this was the first consumer hardware project I’ve received a reward for, I was unsure as to what it’d look like when it arrived.

It arrived in an simple envelope:

unnamed11

with good box art inside:

unnamed10

From a production perspective, I wonder if the two-color box is cheaper to manufacture? It gives the box a retro-80s feel, which is a nice touch.  Here are the other sides of the box:

Special attention to the directions on the back:

unnamed8

Simple directions and it negates the need for an instruction booklet inside.

Opening up the box, a simple foldable cardboard wrapper held the PocketCHIP:

unnamed5

Opening the sticker-adhered flap produced my first look at the Pocket CHIP itself:

unnamed4

static adhesive covering for the LCD; but otherwise no frills. No USB, no note, nothing.

From a production perspective, the fewer parts, the more it reduces assembly costs and time for packaging, making it cheaper. An economical idea for a company running a Kickstarter.

From a consumer perspective, this is exactly what I’d expect from a Kickstarter delivered product.  It’s easy to be spoiled by glossy boxes or specially wrapped and adhered USB cables, but at the end of the day I’d rather have a launched Kickstarter than a high-finish package.

The CHIP team did a good job of balancing first impressions with physical cost constraints.

Holding the CHIP in my hand was… different than I expected it would be:

It is a Pocket item in name only; but has a nice translucent (plastic? poly something or other?) backing that makes it durable.  The angled back also makes it easier to hold in one hand — if you have large hands (Sorry, Donald).

The Pocket CHIP includes the CHIP itself (second image, above), a battery, an LCD, a keyboard, and a unibody case that holds everything together.  It hosts Debian 8; a custom OS UI, and a touchscreen.

Looking at the device, there are a few reasons why this case is extra special.  They put breakout pins for all the exposed pins; and they’ve even included the communication buses (I2C, SPI, UART) in case you want to include a peripheral.  I have a SPI LED Driver evaluation board sitting next to mine, so I may have to give that a try.

Turning on the PocketCHIP boots up the custom OS; a Debian Linux distro with a custom UI:

unnamed1

(after the tour, that is)

Image-2

Pico-8 is a retro gaming platform that lets you write games in Lua.  You can also do normal Linux-y things, like drop down into the terminal:

Image-1

or even browse files:

Image

Out of the box, it was worth more than the $50 I paid for it; and I’m a bit surprised it’s selling for that low.  I would have expected the PocketCHIP to cost around $75 or so. Either way, it’s a great way to get a computer in your hand.

Next up for me is to program a demo that uses the full screen, and not just the 128×128 pixels given by the Pico-8 platform.

Quiz: Do you have a Remote Work Culture?

Just like 2016 will be the year of the Linux desktop, it’ll also be the year of the remote worker.

Only one of those sentences is true. Sorry, Linux.

I’ve talked about my experiences with remote working before, but I’ve never put down the criteria that differentiates a company that has remote workers with a company that has a remote work culture.    So here’s a quiz for you; tally your scores up, and we’ll talk about the results at the bottom.

3: this applies and in practice works 80% of the time or better
2: this applies contextually; and generally between 50-80% of the time
1: this applies less than half the time, if at all.

 

  1. Your office has the capability to host remote workers through video conferencing software or chat software.
  2. All policies regarding remote work, holidays, and ‘flex’ time are written down and accessible to all employees, even if they’re remote.
  3. Important information is disseminated in such a way that people who aren’t present won’t miss out: company persistent chat (like Slack or Hipchat), or email.
  4. Decision makers make an effort to wait to disseminate information until remote workers can video-conference in.
  5. Your office has persistent video conferencing software set up in your office; or your conference rooms contain a web cam and persistent video conferencing addresses (a dedicated Google Hangout)
  6. Remote workers are promoted or given raises at the same rate as in-office workers.
  7. You have a promotion plan in place for remote workers.
  8. You don’t ask remote workers to relocate to the main office.
  9. “Work/Life Balance” applies to everyone in your company, not just people you see day-to-day.
  10. Remote workers consistently say they feel “a part of” the company culture in feedback sessions.
  11. You have regular feedback sessions with all your employees, including your remote workers (1 on 1s, virtual coffee, etc).
  12. Meetings are always scheduled in advance. Impromptu meetings are rare.
  13. Remote workers know the hours of time per day they should be immediately available, and the hours they should be available within 15 minutes of contact.
  14. When there is a special event at the office, you also send something to your remote workers so they don’t feel left out (cake for the cake gods).
  15. If your remote workers came to you with an office culture issue; you’d take their issue seriously and work with them to resolve it, even if it meant changing company practices.
  16. “In office” employees consistently say they feel connected to remote workers; and there aren’t signs of a rift between the two groups
  17. At least once per month, remote workers pair program or work alongside their office counterparts on the same project together, at the same time (probably utilizing some sort of screen sharing software).

40+: You’re doing really well. Your remote culture is solid; and while there are things to work on, you’re in a good place.

25-39: You’ve got some work to do. Your remote workers may feel disconnected, or they may feel like they’re missing vital information.  Your office workers may also feel disconnected from your remote staff. Take a step back and have honest conversations with all parties. Remote work may not be for you, or you may need to double down on it.

<25: You don’t actually have remote employees, right?  If you do, they’re probably experiencing serious issues; and need your help to make them right. You may also have higher than standard turnover with your remote employees.

 

Special thanks to Brent Ozar (twitterblog) for reviewing this post.

What are some Alternatives to Parse?

Back when I was figuring out which MBaaS to use to power Jewelbots app backend a few months ago, I chose Parse.  Luckily, I included an entire write-up on all the MBaaS (Mobile Backend as a Service) providers I could find at the time.

Since listing the dead ones would be not useful, I’ll list only the ones that are “Alive”, plus new ones I’ve found.

I’m limiting my search to companies that provide a MBaaS and host it for you.

Provider Focus Cost/Month (startup) Status
AnyPresence Unclear Not Provided. Contact wall Alive
App42 Startup MBaaS + Managed Analytics $0-$99 Alive
Appcelerator Cloud MBaaS + App Platform SDK $39-$259 Alive
Apstrata Indie MBaaS <$800/month for Startup ($.08 per user) Alive
Buddy Enterprise MBaaS (unknown, they hide the service behind a “ContactWall”) Unknown (call for demo/pricing) Alive
Cloud Mine Enterprise MBaaS ContactWall (Call for pricing/demo) Alive
Feed Henry Enterprise MBaaS Unknown (ContactWall) Alive (Acquired by Redhat in Late 2014)
Firebase Startup MBaaS $0-$49 Alive
IKnode MBaaS $9/month Alive? – Last commit to their Repo June 2015.
Kii Enterprise MBaaS? (Unclear from their site) ContactWall – Call for Pricing/Demo Alive
Kinto Startup/Open Source MBaaS Free Alive
Kinvey Enterprise MBaaS $2000/month (Free for Startups) Alive
Kumulos Startup MBaaS $10/month based on “fair usage” (not defined) Alive
Windows Azure Mobile MBaaS Totally confusing Alive

Since we were always just using Parse for development, we’ll be moving our infrastructure to AWS; and will likely at least document (if not open source it) when it’s done.

Eight Months of Remote Work

Last time I did one of these, it was four months ago, and I mentioned this:

All conversations must be in a digital medium. Working with people who are in an office together means either all conversations have to go through Slack, or missing out on critical information.

Sounds easy, right?

It isn’t.

Missing information isn’t the only issue I’ve run into; and I was all prepared to write a blog post about it, until I found this blog post, on what affects remote workers the most.  In order from most to least:

Screen Shot 2015-11-17 at 9.56.17 AM.png

That blog post hit me right in the gut.  It’s exactly how I feel, with roughly the same mixture as the survey.

To help combat these issues for remote workers (right now, just me) we’ve had a “George Cam” (todo: change name when we hire more remote people) that we keep up in the office and I am able to interact with everyone over that.

It works. Ship it.

Except after a few months of this, we (ok, me, since I was the only one remote) noticed a few issues:

  1. Ambient noise is the enemy. In Open Office Floor Plans (like the current environment we’re in (not by choice)), the ambient noise combined with the built in microphone on the MacBook Pro means that unless my office-mates are facing the laptop, I have a hard time picking up what they’re saying. This causes me to miss some or all parts of a (probably important) conversation and have to ask those on the other end to repeat what they said.  If it’s annoying for me, I can only imagine how it feels for them.
  2. I need to see people. Non-verbal language accounts for 93% of all interactions. Since my camera points in the general direction of everyone (but most people’s faces and bodies are out of frame), I get a good shot of people’s hands… Which doesn’t help when I need to see their body language to discern what’s going on.
  3. Just like in real life, not all conversations should involve me. Sometimes, I awkwardly invite myself into things that aren’t actually for me.  It happened just yesterday; I heard two coworkers talking about an event one evening this week, and somehow assumed it had something to do with work; I wanted to make sure I was free that night / was there for it.  Since it wasn’t actually work related (and I wasn’t actually invited), that made that exchange a little awkward.  Again, this is something that wouldn’t happen if I were there, as body language would tell me I wasn’t invited (as would the fact that they’d probably wait until I walked away, which is hard to bet on when the person is remote).
  4. Being two-dimensional (I’m on a computer screen) means that it’s easy to forget I’m there (or not there), and sometimes I’ll miss important conversations because they happened spontaneously and I just happened to stand up and walk away right before or at that time.  If I were in the office, that wouldn’t happen, since it’s much harder to forget about a three-dimensional human being.

Since we have feedback sessions often, I’m able to bring up these issues, and here’s what we’ve done to address them:

  1. Get a good microphone, and place it in the middle of the group.  The difference is amazing. Now I can hear everyone talk to each other and talk during standup, instead of straining to listen because the Mic wasn’t in the middle of the action.
  2. Have personal hangouts when we need to have discussions; perhaps in a conference room.  The office cam is great for general chit-chat and one-off conversations, but not so good when I need to see the person who is talking to me.  The personal hangout allows me to read body language, and that’s really important.
  3. Write private messages to ask one person if the conversation that’s going on is personal or work related.  That’s a more subtle approach than blurting out, “There’s a party? When is it?”
  4. Have all important conversations go through Slack.  Of course, that doesn’t happen (would you expect 80% of your company that sat next to each other to slow down their conversation so they could type it?), but that’d be the only way to be sure I didn’t miss really important communications.   It’s not just about me. It’s about what works best for the entire team. Since the fix is harder than the work around, I do ask that they at least put a note about the conversation in chat and I can follow up when I’m back.

As I write this I’m heading to NYC to spend the next few days for some face time with the rest of Jewelbots.  So for the next few days, at least, I won’t be a remote worker.

Why?

Recently I had the occasion to start learning and writing firmware.  If you’re like me, you’ve spent most of your software career writing web applications in a high level language, and have never needed to worry about memory management, or space constraints, or even what data structure to use.

Ok, so I’m being a little facetious with that last one, but for most web applications, Big O notation simply doesn’t matter: Most data structures and algorithms are Good Enough.  In fact, you could throw a dart at any major data structure and it will perform adequately for most workloads1.

Big O CheatSheet

So this means Computer science classes are a waste of time, and we should all just start writing Web apps, right?

Well… no. Throughout the course of learning how to program hardware, I’ve encountered from very stark realities: Hardware is the honey badger of platforms. Whereas other platforms may be forgiving, or may let you get away with something that isn’t a “Best Practice”2, hardware simply does not care about your feelings and desires to launch software. You have 16KB of Ram, and 256Kb of ROM, and that’s it (and in SoC terms, that’s a lot). All those optimizations that we used to make fun of? Well now we’re doing them.

I wasn’t totally unprepared for this turn of events; I had been going through the Programming Pearls book for years3, and so my mind was open to the challenges of writing low level code.

But, nothing I’ve ever done professionally has really prepared me for this. I’ve worked on a few “Web Scale” projects, but mostly been able to optimize code without having to really do low level stuff. Since there’s a tradeoff to business for optimization, it’s always been a ‘good enough’ approach.

And that’s my fault.

The entire world around me is filled with answers, but I’ve never asked the right questions at the right time. Imagine how good at programming I would be if instead of taking apart the computer and put it together, I simply kept asking people “how can I program this?” Or imagine if instead of partying and wasting my college years playing Tribes, I had asked my professors what I would need to learn to build a compiler?

My father (a reporter and journalist) used to say, “It isn’t the man with the answers, it’s the man with the questions.”4

What if I had taken his advice sooner? Where would I be now?

I’m privileged to be able to work across the entire software stack, and working at a hardware startup has been extraordinary; but I can’t help but wonder what I’d be doing now if I had asked questions sooner in life. Would I have gone to MIT? Would I have fulfilled my potential sooner? Would I have understood what I wanted to do with my life sooner?

I’ll never know, of course, but, as they say: The second best time to plant a tree is right now.

If there’s one piece of advice I have for my 7 year old self, it’s: Ask ‘why’, and don’t stop until you’ve found the answer. And then find another question to ask.


1: “Most” meaning most, of course. If you work with Web Applications (or even most applications), your user base or data set just isn’t large enough to worry about this sort of stuff; you’ll generally find greater gains fixing things elsewhere. That isn’t to say it doesn’t matter at all, just that for most of us, it doesn’t matter most of the time. It’s like the Pareto principle, only less succinct.

2: Used un-ironically, for once.

3: Really, I keep picking it up, doing an exercise, and putting it down. It’s like Godel Escher Bach for me.

Pre-order your Jewelbots Today!

Yesterday the Jewelbots team hung out at Maker Faire NYC and took part in a panel titled “It takes a Village”, a look at how we use each of our diverse skillsets to build Jewelbots (spoiler alert, the Jewelbots team is awesome).  During that panel, we also announced the opening of the Jewelbots store, where you can pre-order your Jewelbot (and buy multiples!).

If you backed our Kickstarter, this is a chance to grab more; and if you missed out on our Kickstarter, this is your best chance to be part of one of the first production runs of Jewelbots (like anything else in the manufacturing world, it’s first come, first serve; and manufacturing can be cruel if you wait too long).

Another bonus for you (and for us): if you pre-order is that it has the potential to make the lead time shorter. It makes sense when you think about it; a manufacturer that is getting paid for 20,000 orders is going to place that at a higher priority than 5,000 orders.

Anyway, I’ve talked long enough; if you haven’t already, visit our Jewelbots store, and pre-order your Jewelbots today.

And if you think that Jewelbots aren’t your Jam, I give you five reasons to be excited about Jewelbots (even if you aren’t a girl).

Being Vulnerable

I’ve made tons of mistakes over the years.  We normally call them bugs, but since around half had to do with code and half with human beings, we’ll label them as mistakes. It’s funny, I never remember bugs I’ve created and fixed in code (unless production went down) but I always remember social faux pas or missteps I’ve made. Maybe that’s because I can’t fix them after they’ve happened.  There’s no source control, no continuous delivery system, nothing to repair the damage except, “I’m sorry. I won’t do that again.”  The damage is still there, the bug isn’t fixed, there’s just another guard clause added to hopefully not trip it again.

I don’t say this to minimize the value of an apology.  If anything, it makes me want to learn how to apologize better, since I know it’s going to happen at some point, no matter how hard I try.

I wasn’t there five years ago.  Five years ago I was sure of myself, my ability as a programmer, and most definitely the best estimator I’d ever encountered.  I was that good. So good in fact that I kept the Army-induced confidence in all of my conversations, even when there were internal doubts.  I will say this for the Army, they know how to make you feel confident about your abilities.  It’s easy to dismiss most business ‘crunch time’ as it doesn’t really come close to what I went through in the military.  That disparity made me confident, and that confidence made me arrogant about my abilities.

And then that arrogance came crashing down all around me.

The project itself was a new piece of software for the company I worked for, on a project where I was the sole day-to-day back-end developer in a new language and new framework, and I had no idea what I was doing, but I was too arrogant and too scared to tell anyone else.  Today, that amount of code I wrote would have taken a quarter of the time, but then, not knowing anything and not even knowing the right words to search for, and being too scared of showing my vulnerability to ask others, I just plowed right through it. I didn’t ask for help, didn’t say to anyone that I was ‘in over my head’, and I didn’t show that vulnerability to anyone.

It’s no surprise then that everyone started to notice that the project wasn’t finished yet; that we were behind, and that I wasn’t as good of a programmer as I had led others to believe (arrogance masked as confidence has serious side effects).  At that point, the damage was done.

Trust is the glue that holds software teams together.  My teammates had to trust that I’d tell them when I needed help, or when  I was in over my head, or when I’d over-promised. That trust was broken because I was scared of being vulnerable.  Ultimately, It took a lot of time to repair that trust; but even with all that effort; there would always be that mistake.  Unlike a bug in my code, I couldn’t just fix it, check it in, and never have to think about it again.

I thought vulnerability was a weakness.  It wasn’t. It was the key to trust. It was the key to feeling like I was part of the team. It was key to delivering the product on time.

Ever since that incident, I’ve taken great care to be more open and vulnerable to my teammates, even going so far as to saying very clearly in interviews and team meetings what I’m good at and what I have no experience doing.   To break down the fourth wall for a moment, this is the point where I should talk about the list of things I’ve done; or how you can be a better software developer, or person, or whatever.

But I don’t have a checklist. I don’t have bullet points. I don’t have any insights, except to say that I’ve fully embraced being vulnerable. I never used to be OK with talking about my weaknesses, and now I wonder if I talk about them too much.  It hasn’t negatively affected me yet, but that fear is always there that it will.

Vulnerability means constantly reassessing my abilities; and focusing on my weaknesses.  It means sharing that with my teammates.  While there’s always a fear of rejection when I do that, it’s far better than the alternative.