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.