Taking Lead on NgCordova

It was March, and I was on my way up to NYC to interview for the Software Engineering position at Jewelbots. I was using the UX mocks Sara gave me to build a front end for the app to show that I could (come to think of it, I don’t know why I did that). I was using Ionic. Sara Chipps (CEO of Jewelbots) looked at me and said, “So do you think we should build our app in this? Can Ionic support Bluetooth?”

After a quick moment of panic and a little googling, I found ngCordova and said, “This looks like it will work, let’s use Ionic.”1.

It’s been a rollercoaster ever since.  Ionic is a top-notch framework for cross-platform mobile apps2, but one issue is that since it’s relegated to the WebView for each platform, it doesn’t have access to the native plugins through JavaScript. That means Cordova, which means ngCordova (or lots of callbacks).  And ngCordova releases have been… lagging behind3.

Since I depend on ngCordova for Jewelbots4, and since I already spend most of my day looking at ngCordova and Ionic issues, it only makes sense to help maintain ngCordova.  I asked Mike from the Ionic team about taking over lead on ngCordova, and he agreed.

So, starting today, I’m the new lead maintainer on ngCordova.

What does that mean for you?  If you use ngCordova, I’m going to be going through the outstanding PRs and resolving those first; and then go through the issue backlog and prioritize fixes.  My goals:

  1. Keep ngCordova up to date with bug fixes.
  2. Make sure documentation reflects the plugins’ capability.
  3. Allow for developers to quickly see which plugins are compatible with which versions of cordova.
  4. Make sure issues, comments, and PRs are addressed in a timely fashion.
  5. Accepting PRs for new plugins or plugin changes to plugins that are actively maintained.

You’ll notice that I’m not talking about new development of plugins per se.  NgCordova has always been a wrapper for community maintained Cordova plugins, and not a creator of plugins itself.  One important piece, though, is to make sure that developers know which ngCordova wrappers support the various versions of Cordova.

For a truly native experience for app development, plugins are essential; and it’s my goal to make sure the ngCordova experience is as welcoming to new Ionic app developers as possible.

If you work with ngCordova, I want to hear from you. What needs to be improved?

PRs welcome5.

1. It’s interesting to note that while conceptually I understood Ionic was a wrapper for Cordova, I’d been using it for all of about 4 days, and didn’t know how plugin support worked.
2. I gave a talk on ionic at NoVA Code camp, slides here.
3. In the interest of full disclosure, I’ve done a lot of belly-aching about ngCordova. It’s only fair I should put my money where my mouth is.
4. Our custom build is here: Includes BLE plugin compatible with Cordova 5.0; fixed Contacts plugin Wrapper; and a partridge.
5. Please be gentle.

My First Pitch

I’ve been neglecting writing this blog post for a while now, and in a few paragraphs, you’ll see why.  In June, I pitched Jewelbots At MAVA’s TechBuzz event. It was a wonderful event, with exposure to investors and the NoVA tech community.

I didn’t talk much about it at the time, and I didn’t blog about it because, well… I didn’t know how to.

MAVA TechBuzz

MAVA Techbuzz is an event put on a few times a year where early-stage startups can present their idea to a crowd of investors. They’ve played with the rules over the years, but this session, the rules were simple: a 4 minute pitch; with hard limits on the time, and no more than 6-7 slides.  The pitches were given in a ‘bam bam bam’ fashion, with half the companies presenting one after the other; and then a break for Feedback from the Investor panel; and then the rest of the companies present.  I was the second to present in the second half of the session.

And I had four minutes.

To prepare for TechBuzz, I started out by taking our stock pitch deck and modifying it towards both my style and the audience:

  • Kept below Five words
  • Communicate vision, not data
  • Data kept super focused
  • Does not require reading to understand
  • augments what I’m saying instead of replacing it
  • Followed the 10/20/30 rule (really, 6/4/30 given the pitch target)

Due to the hard time limit nature of the pitch, I also chose to write a script instead of capture Ideas and speak on those ideas without a script.  I normally speak extemporaneously; I have in pretty much every talk I’ve ever given.  If I have a format and flow; I’ll keep the key idea in my head for that slide, but I’ll explain it slightly differently every time; but I always react to the format and flow that I’ve encountered for that talk.  It’s weird; I’ve given dozens of talks, and every single audience and room is different; so I tend to react according to the vibe of that room instead of trying to make a script and following it.

I wrote out the script, and practiced it.  I then spent the next few weeks editing that script to take out redundancy, remove any words that didn’t flow, and arrived at the final product.  I used Git to track the pitch’s genesis’s both in terms of the slides and the script.

I practiced that script a lot; both with slides and without, with special focus on ensuring each paragraph ending was a good transition to the next slide.  Finally, on the day of, I went off to TechBuzz to set up and give my pitch.

Day of

TechBuzz is an all day event; the morning time is used for demo purposes, and each company has their own booth. I set up our App as well as the prototypes and met with dozens and dozens of people, using parts of my pitch as well as talking with them about Jewelbots.

Finally, at 4:00 that afternoon, it was time for my pitch.  I walked up to the stage, hit the first slide, saw the picture of my daughters, and boom.

The photo from my pitch
The photo from my pitch

I wasn’t prepared for the emotions I’d feel just seeing my daughters’ picture come to life on that screen.  They represent the future I’m working to a create; and I work every day as if I’m working for them in particular.  Because I am; and there is no more powerful feeling for me than knowing that what I’m working on will benefit them and make their lives better.

For me, Jewelbots isn’t an abstract good; it isn’t something that ‘may help thousands’; it’s a product that will directly impact my daughters’ lives and fill that gap that we experience today.  They will grow up in a world where technology doesn’t differentiate between girls and boys, and where boys get ‘the cool toys’ and girls don’t get that.  It’s a world that recognizes the difference between boys and girls interests, and works hard to cater to those interests. It’s a world where we don’t have to say, “Toys should be gender agnostic” as a way to solve our problems, we can instead say, “If you have an interest in Jewelry, we have products that fuse technology with Jewelry.” My daughters have vastly different interests, even though one is 3 and one is almost 2 — I can see the differences in what they like, and what they don’t.  Faith is every bit the girly girl; and Penny is (affectionately) the Destructor that enjoys taking things apart and seeing how they work.  I want technology to cater to their interests; not remove the individuality that makes them who they are.

All of those emotions hit me right as I saw the picture of my daughters, and I blanked.  Completely blanked. I didn’t even know my own name at that point in time. Luckily I had brought my phone with me and had my script on it, so I was able to glance down and see the next bit of my talk, and I recovered; although I didn’t deliver the speech I wrote down.

If you watch the video of my talk, you’ll see that happen.  I haven’t watched it; partly because I don’t really want to know how bad the mess-up was.  In my head, I must have spent minutes blanking –Time slowed to a crawl.

Lessons Learned

From that experience, I learned the following:

Perfect practice makes perfect:  I spent every day for weeks practicing and refining that pitch.  I could recite it in my sleep. But I did it just for me, or just for me and Emily.  I didn’t do it for strangers, and I didn’t do it in like conditions.  I practiced a lot, but I didn’t practice in the same form that I’d actually give the pitch: With strangers looking at me, coming up to a platform, and going for four minutes.  Perhaps if I had, I would have encountered this emotional reaction before TechBuzz, and could have worked around it.

Don’t ignore your failures; use them to make your talk better: That moment where I stumbled would have been a perfect moment to say, “Sorry, about that, seeing my daughters on the screen and thinking about how Jewelbots will help them caught me by surprise. I care about them a lot; and Jewelbots represents more to me than a product, it represents changing the status quo.”  But I didn’t do that; I tried to hide it.  Later on when I received written feedback, my stumble was chalked up to “didn’t practice” instead of “wow, he really cares about this topic.”  It was a missed opportunity, but a great learning experience.

Find your speaking style, and stay close to it:  I’ve given a lot of talks, but this was the first time I’ve ever written a script for my talk. I don’t do that. I form ideas and have a sentence for each idea, and then the rest I just use to speak from;  it leads to a better flowing, more natural talk, even if it’s not 100% reproducible.  Giving this pitch showed me that I’m not the sort of speaker who can memorize and give a talk as well as I can ‘speak from the hip.’

You can’t bat 1.000: This is something my wife told me after.  Even months later, the sting of this talk still follows me, but she’s right — I’m not perfect, and I won’t always hit it out of the park, even if I feel like I should be able to.  All I can do is be better next time.

Overall, TechBuzz was an amazing experience and I’m grateful to have had the chance to pitch Jewelbots.

What have been your lessons learned from giving talks?

Getting Webstorm to ignore output folders

Webstorm is pretty good for Angular Development (I only have a few qualms); but one behavior that’s annoying is that it searches all folders in a directory when looking for usages.

For instance, in the Jewelbots App repo if I search for files named controllers.js, I get both app\ references and www\ references:

Screen Shot 2015-07-23 at 11.23.26 AM

But in this setup, www is really just an output directory. When I run grunt build; that’s where all the files go for deployment.  So it doesn’t actually help me to search there.

It turns out, there is a way to ignore or exclude certain folders from search:

  • Right click directory you want to exclude
  • Go to “Mark Directory as”.
  • Choose “Excluded”

Screen Shot 2015-07-23 at 11.25.10 AM

Now when you search, files in that directory won’t show up in the results:

Screen Shot 2015-07-23 at 11.26.18 AM

Five reasons why I didn’t Join a Coworking Space

A little over four months ago now, I joined Jewelbots. I also wrote a retrospective on the first four months.

When I first joined Jewelbots, Sara mentioned that they’d either cover me working from home (pay for internet) or they’d cover me working from a co-working space. Since I’d had mixed results with Working From Home previously, I elected to take a serious look at co-working spaces.

Here’s why I didn’t join one.

1. Coworking Spaces aren’t built for productivity. If you’ve ever heard me rant about open office floor plans (twitter, blog post), then you know I dislike them immensely. The chief reason is that they foster collaboration at the expense of productivity. If you spend 8+ hours a day doing something, don’t you want to feel like you accomplished something meaningful at the end of those 8 hours? What about if ‘meaning’ in your line of work meant releasing code?

Collaboration is a great goal if that’s what drives your business (It’s even a good idea otherwise; except that you have nothing to collaborate on if you go out of business). If software drives your business, then perhaps you should optimize for creating software?

See? There I go again. Even in a blog post about coworking spaces, open office floor plans rear their ugly head. I probably won’t edit that out.

My point is, coworking spaces are generally open offices (most money per sq. ft. that way), and open offices do not enhance productivity.

Why would I pay to be in a space that makes me less productive?

2. Coworking spaces don’t let you control your environment. As I write this, I’m on a standing desk with three monitors, a laptop, a freshly painted room, and standing pads. Oh, and I have a smattering of dev boards, an iPhone for testing, and a Ladycorn I was supposed to ship out last night. How easy would this set up be to replicate at a coworking space? The three monitors would be out; the standing desk would be a huge if (if no one else grabbed it that day), and I certainly wouldn’t have the comfortable chair. That brings me to the next point, money.

3. The economics don’t work for productivity. In order to get that same setup (I paid for all this, btw) in a coworking space; I’d have to pay for a private office (about $600 a month), sign a year lease, and have all of this shipped there.

That’s just not economically feasible for a single remote employee to do in a startup. In order to pay for itself, I’d have to be $7200 a year more productive than I would be otherwise, and that’s just for office space. That doesn’t count the desk, the chair, the monitors, the arms, or any of the other accessories (around $3000 all told).

4. The choices just aren’t that great. I live in Springfield, VA. For those of you that don’t know the dynamics of the Washington DC area; I live at the end of the Blue Line. If I want to travel to Arlington (the ‘major’ metropolitan center that isn’t DC), I’d have to spend 20-30 minutes (each way) on the Metro each day; in addition to the 10 minutes to commute there and back. If I want to go into DC; that’s another 20-30 minutes (depending on the day). At best that’s an hour to get to and from work, at worst it’s 2 hours. And that’s if nothing goes wrong (which it does, all the time). In Arlington, there are currently two choices for Co-working spaces; one’s part of an unused coffee shop, and the other is a small office space above a bank.

5. You can’t control internet speed or connectivity.

Internet’s really important to programming. In this instance, I couldn’t do something as simple as deploy our site to Elastic Beanstalk because the internet was terrible. That’s a bad thing. What would have happened if our site went down and the internet went down at the same time?

Coworking spaces are probably great. But they don’t work for everyone, and after trying it for a few days, I realized they didn’t work for me either. They embody all the bad parts of an open office floor plan and working at Starbucks, all while paying for the privilege.

Four Months of Remote Work

It was four months ago that I joined Jewelbots.

Four months. Seems like a lifetime ago.

This has been the second time in my career that I’ve been doing remote work full time; the first time was when I was very much a junior programmer.

Here’s what I’ve learned in these four months:

1. It’s hard to separate work and home. Really, really hard.  When commuting to another place, it takes physical effort to go back and do work; and that is (shamefully?) usually all that’s enough to make sure work stays at work. At home, I can just drift downstairs and get some work done.

2. It’s hard to separate piddling around with actual work.  Yea, I put in more hours; but do I really get more done?  Probably not.  There’s laundry to switch out, animals that want attention, etc.  So while I may put in 10-12 hours a day, I’m probably closer to the south side of ‘8’ for hardcore work.

3. Having a quiet space is even more important at home.  My current office setup includes no door; and until I move my office into a space with a door, it’s super important that I’m either with headphones or that the house is quiet. Since my wife and kids are home for the summer, that means great headphones.  I also recommend “Music to Code by” (originally recommended to me by Jonathan Sampson).  It was composed by Carl Franklin, programmer and host of the .NET Rocks! podcast.

4. 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.  Brooke and Sara both work in our NYC office, and since they’re in a small office together, they can easily share information. Because I’m not in said office, I have to be extra sure to stay up to date.  David Fullerton talks about this issue in the blog post “Why We (Still) Believe in Working Remotely“:

You have to commit to it as a team (and a company). There’s no halfsies in a distributed team. If even one person on the team is remote, every single person has to start communicating online. The locus of control and decision making must be outside of the office: no more dropping in to someone’s office to chat, no more rounding people up to make a decision. All of that has to be done online even if the remote person isn’t around. Otherwise you’ll slowly choke off the remote person from any real input on decisions. (non-bold/italic emphasis mine)

This is something we’ve worked through as a team, and it’s gotten easier; but it is tough to do at first. Would you rather say something to the person standing in front of you or would you rather get on a Slack Channel and type it to that same person?

5. Virtual Coffee is a must. Working remotely means having less opportunity to interact, which makes those daily interactions all that more important.  Everyone needs feedback on what they’re doing, what they should continue doing, and what they need to be redirected on.  Working Remotely means scheduling explicit time for that so that it happens.  We’ve had good success having a bi-weekly feedback session; and even if there’s no feedback to share, it still gives us time to connect with people we work with.  Think of it like getting coffee together — virtually.

6. All Progress must be visible or reportable. I spent time porting a bluetoothle library over for use in Ionic (long story short, the other library didn’t support the latest version of Cordova).  Normally that’d be a blurb in a standup, but remotely, that counts as part of my output.  Since we use Slack, it’s really easy to set Slack up to report Git pushes.  Unfortunately, there’s no easy way to have a Slack Integration for reporting conference calls, emails sent, or any other work that doesn’t really seem like work until you’re remote. To combat that, we share our Google Calendars, and everything we do goes on our calendar.  With a bug with Shared Calendars in Sunrise, that sometimes means me popping in on a meeting I shouldn’t, but for the most part it works.

7. Being open about strengths and weaknesses. It seems antithetical to workplace advancement; but it’s absolutely crucial in a remote work situation.  I talk about my weaknesses because even thought it’s uncomfortable for me, it’s crucial to ensuring frank communication, and when you’re working remotely, you don’t have those normal cues to know how you are being perceived. Candor is a strength.  This doesn’t only mean sharing your weaknesses, it also means sharing your wins.

8. Having a hangout devoted to wins is important. Software Development (and Startups?) means failing 500 times only to have it work the 501st time.  It’s easy to focus on the failures; but the wins are so much more important to the team.  Take time to share nothing but wins.  Brooke set up a Weekly “Wins Hangout”, and it has been beneficial.  The whole team gets together and talks about what their ‘wins’ were that week, no matter how small.

9. Invest in making your workspace better. In an office, you can’t control your environment as much, but since it’s so important to happiness, it’s absolutely crucial for a home office.  We even went so far as to paint the Maroon basement a soft Yellow to reflect light instead of absorb it. It worked wonders.  I also purchased a sit/stand desk that doesn’t break the budget because that little extra control helps.

10. Keep a schedule that works mentally, physically, and emotionally. I’m still struggling with this. Since it’s easy to start work early, and I want to show that I’m valuable, I’ll work at all hours instead of what I’d do at an office: have a schedule. I need to work out to stay fit and work at specific hours.  If I were going into an office, I’d be up at 6, working out by 6:30, and in the office by 8.  That’s harder to replicate remotely (since there’s no gym next to my office), but it’s something I have to do to stay emotionally, mentally, and physically healthy.  This is where coworking spaces near a gym could help, but coworking spaces have their own problems (that’s for another blog post).

What do you do to make remote work work for you?

Post updated to reflect the original recommender of the Music to Code By composition.

Five Reasons to be Excited About Jewelbots (even if you’re not a girl)

Early Concept Art of Jewelbots
Artist rendering of early Jewelbots prototype

Our Kickstarter launched yesterday. There’s been a lot of work to get to this point, but one question I keep hearing is a variation of “I’m not a girl, so why should I care about Jewelbots? Why should I back your product?”

That’s a great question, even if it’s really two questions.

Here are a few reasons why you should be excited about Jewelbots, even if you aren’t a girl.

Screen Shot 2015-07-09 at 10.15.02 AM
It’s sooo tiny. The current Jewelbot board size — smaller than a quarter.

1. Jewelbots are open source.  You like open source, right? This is your chance to
fund a completely open source product.  From 3D designs for the charm, to the firmware, to the board; it’s all open. We believe part of our mission is to help educate; and part of education is having examples to work from. More over, we want to see all the interesting things that people can do and make with their Jewelbot;  products should encourage that behavior, not inhibit it.

2. Jewelbots have a lot of applications. The inner workings of the Jewelbot are essentially a newest-generation Bluetooth Low Energy device capable of sending and receiving messages to other BLE devices.  Pair this with another Jewelbot or with your phone and you have a tracker for your wayward dog, or an early warning  system, or even a phone finder.

a 3D Printed “Looks Like” Charm Prototype

3. You can 3D Print your own Charm. Growing up in the 80s and 90s  we had shows like The Power Rangers, The Legend of Zelda, and Thundercats.  Haven’t you always wanted to have your own Thundercats glowing emblem, or your own Power Morpher, or your own Ether Medallion? Well, I have.  Because we’re engineering Jewelbots to be printable; you don’t need to stick with the stock flower charm; you can customize it based on what you are interested in.

I’m pretty sure this is how Skynet started…

4. Jewelbots are more than a product, they’re a platform. Jewelbots are a mesh network of wearables that can communicate over distances with BLE;  This has lots of untapped potential. Why limit ourselves to wifi or cellular networks to send and receive messages?

5. Supporting Jewelbots supports a social Good. Jewelbots the company is committed to getting girls interested in STEM.  We’ve already run two hackathons geared towards exposing girls and children in general to STEM, and we want to run more.  By supporting Jewelbots, you’re supporting our mission to broaden technology’s appeal.

As a bonus, supporting Jewelbots also means supporting behavior from companies we all want to see more of. Help us make that happen.