Two years ago, I became employee four at Cionic. At that point, the team was split between the Bay Area and two remote employees (I was the second). Telecommuting has been part of my career for the past two decades, but the remote experience has not always been great.

However, another long-running aspect of my career has been the desire to help people: starting out building internal tools at Oracle and Google, then choosing a smaller company focused on improving people’s health and lifestyle at Jawbone, and even becoming an elected public servant in my spare time. To me, Cionic was the ideal next step in my career evolution. Our technology has the potential to change our users’ physical abilities — this is more than improving health, this is life altering.

In choosing to join Cionic, the question for me was can I be effective on a team if I’m 3000 miles away. How can we build working relationships if we’re not in the same room every day? Cionic’s mission in our product is to transform the human experience, and our mission in our company is to transform the startup experience by taking a remote-first approach. I’m excited that I get to work on both.

Identifying Your Strengths and Using Them

A mentor once described the key to success in straightforward supply and demand terms: focus on improving the skills you possess that most of the people around you lack. In other words, find a high demand skill that is in short supply and corner the market.

I’m a good software engineer, and the cloud services available today make me exponentially better than I was at the beginning of my career. On any given day, I’m performing devops, database upgrades, API improvements, and modifying user interface. When I was fresh out of college, this work required at least four different engineers and usually they weren’t on the same team.

As effective as I have become at delivering software, I would not consider that my best skill. I am an extrovert, and I like to build relationships with my coworkers. If you’re gonna spend that much time with people, it’s better if you like each other, and that means getting to know one another. Focusing on these communication and relationship building skills while honing my craft as a software developer, I have gravitated to leadership and management roles. It’s why, as a software architect, I still spend a lot of my time focused on team dynamics.

Software engineering is successfully moving data from one machine to another.
Team building is successfully moving ideas from one person to another.

The Future is Remote Work

We give ourselves great flexibility with the expectation of high availability.

A few months ago, I added that line to one of our job descriptions, and I can think of three inspirations for it:

1. Our remote first work culture has us spread across multiple time zones
2. All of our collaboration tools have apps that I regularly use on my phone
3. The Covid-19 pandemic has wreaked havoc on all of our schedules

At first glance, this may sound like the destruction of work life harmony. However, it really reflects an agreement we have made with each other around balancing the requirements of a fast-paced startup and the distractions many of us must now face in our working lives.

When the Covid-19 shelter-in-place orders first came down, the transition for our team at Cionic was pretty seamless. Our communication was largely already happening in Slack or on Google Meet. Initially, the only difference was an increase in the size of the grid of faces on screen as all of the San Francisco-based team started using Google Meet from their home offices. Over time though, our coordinated efforts started to diverge. With the need to spend time accounting for new safety concerns or managing additional child care burdens on top of being geographically distributed, we could no longer expect normal working patterns.

Our solution wasn’t in a new application or piece of technology, but in creating meetings. Not meeting more, but meeting smarter in order to create synchronous time together:

• Working sessions instead of status updates
• Prioritize recurring 1–1s to build stronger relationships
• Virtual demo time/game nights/happy hours

However, this Covid-era communication is still a work in progress. Videoconference fatigue is definitely a real thing, and being on camera full time brings a unique exhaustion. Our team tries to find ways to do more than just interact with a grid of faces. Here are some of the tools I recommend:

• GSuite/Google Workspace: docs/sheets/slides to me are the best-in-class collaboration tools. If it’s not code, it’s going in one of these, and I’m inviting comments and suggested edits as soon as I have something worth looking at. I make a doc for every meeting and keep a running log of agenda items and notes that all attendees can see in real time.
• Slack: email is dead; Slack killed it (the only emails I get now are from machines and vendors). Not only is Slack great for communication when a video chat is not feasible, it also integrates well with every other tool we use.
• mmhmm: converts my background from a static image to a dynamic presentation tool. I use it during meetings to collaborate on the same document without taking over the video with screenshare. I even use it during my heads down time by displaying my editor to invite collaboration with anyone who might be interested in the code I’m writing.
• Mentimeter: create interactive presentations, including quizzes, polls and word clouds. I’ve used this to passively engage with my colleagues on everything from Labor Day plans to quizzes on required training.

Employers are realizing they can save costs and expand their talent pool through remote work. As hybrid in-office and remote work models become the norm, we need to embrace new modes of collaboration and create alternatives for in-person communication and team building. At Cionic, I’m just as excited to break down the virtual barriers to communication as I am to break through the health barriers that prevent physical interaction for so many people.

If you have cool new communication and collaboration tools your team has adopted, I’d love to hear more in the comments.

Building a Remote First Team was originally published in CIONIC Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

$99 for PyCharm. Sold.

I’m all ready to start cranking on another fine day of CazHaxing, soI fire up my new favorite IDE, and it demands that I give it money. Sigh. I knew this day would come, and honestly PyCharm is totally worth $99. It’s just that well, I’m kind of cheap, so this is pretty momentous.

Little did I know that PyCharm would become essential in “solving” my how do I create the Flask app and SQLAlchemy db so that I’m not running unit tests in the live DB.

First off, I gotta thank Hurwitz for pointing me to Flask’s config.from_object usage pattern. That was the first step, which allowed me to sanely define my various configurations for dev and test.

Awesome, except I still can’t figure out how to specify the different configs import. There’s the obvious solution of just use a test Flask app for the unit tests except (EXCEPT!) how do I import the models and also tell them about the SQLAlchemy db object?

I banged my head against that wall until lunch, and it took about 30 seconds of our walk to get falafel for Peacock to solve this for me. “Just use an environment variable to specify theconfig.”

Facepalm. It seems so easy now.

Now this is where PyCharm earns its license fee. At CH2, I figured out how to run unit tests in PyCharm but decided that I liked nose from the terminal better because the PyCharm UI wasn’t adding much. The RAY of three weeks ago was so naive. PyCharm lets me specify environment variables in my test configuration, so now I don’t have to deal with specifying in my shell (or through nose in some fashion which I couldn’t find).

This made my day, especially when PyCharm complained about the unittest module breaking PEP8. Hah. Maybe I should go back to my old ethos that style guides are pointless.

Here’s some code for future reference.

1. Declaring the app and db in my top-level app:

app = flask.Flask(__name__, template_folder=’web/templates’)
app.config.from_object(os.getenv(‘FLASKCONFIG’, ‘config.default.Config’))
db = flask.ext.sqlalchemy.SQLAlchemy(app)

2. Defining configs in config/default.py:

class Config(object): …
class DevelopmentConfig(Config):
…
class TestConfig(Config):
…

3. Grab the db from the app whenever you need it.

import app
db = app.db

I was also able to solve another mystery that had been plaguing me since CH1: how to create a unique index using the SQLAlchemy declarative syntax. No big aha moment here; just a shit-ton of googling until I finally figured out the right way to use __table_args__:

__table_args__ = (db.UniqueConstraint(‘type’, ‘from_pid’, ‘to_pid’),)

So simple and yet another reason to not always default to dunders = magic (i.e., don’t touch).

Alright, next time, I might actually build that UI (by which I mean an actual product to run on top of this wonderful infrastructure).

In true CazHax form, we got rolling at roughly 11:30 and followed that up with a leisurely two hour lunch. There’s a reason the Caz comes before the Hax (that reason is grammar but the point still stands). Also, in true RAY form, I’m finishing this post at the beginning of CH3.

I dedicated myself to a bit of yak shaving for this CH:

1. PyDocs — If you actually make the docstrings, trivially easy. Who knew? Except that the way I have set up Flask and SQLAlchemy causes a circular import that breaks PyDocs, which was really just foreshadowing for my later pains.
2. Sprint.ly and Github integration — Again trivially easy and pretty awesome. I’m a huge fan of sprint.ly. Every other agile tracker I’ve played with is either way too complicated (and thus painfully slow) or just ugly. There’s a lot to be said for making a tool pretty so that you actually want to use it.
3. Unit Tests and Nose—Now for something useful. Got unit tests running in PyCharm as well but decided that wasn’t all that great. Maybe when I need a debugger during the tests but for now, I much prefer nose from the command line. And hey, my tests always pass anyway. Always. Pass. Anyway.
4. User Creation UI — Oh yeah, I’m actually building something. Sweet all ready to go and fuuuuuu. My unit tests are actually running in the dev DB and not the test DB. Well, let me change around how I’m defining app and db and voila, still running in the wrong place. I don’t know if it’s just me, but this has now come up every time I’ve used Flask and SQLAlchemy together. The documentation (at least the quickstart) is way unclear on how to define these things. I also don’t really get the global context, which is probably why I keep screwing this up. So I mucked about for an hour and have made my app completely unuseable. Oh well, gotta have something to do for CH3.

We finished off the day in our usual style. Destroyed Tokyo with 7d6 and drank about a gallon of Propel. Super Caz. Super Hax.

I work in software, but I don’t get to write code very often. Basically, if I want to hack, it’s gotta be on my own time. My problem is that I lack the discipline to dedicate a day, an hour, even 15 minutes, to hacking on something when I’m on my own. I decided I should enlist my friends to provide a forcing function, and thus CazHax (Casual Hacking) was born.

We don’t have to work on the same thing. We don’t even have to write code. It’s just a commitment to working on something and it’s a mild commitment at that (today the World Cup trumped productivity somewhat).

I’m calling today a success because I actually wrote code on a project I’ve been thinking about for months now. It was nothing major, but it exists now.

Since I wanted to make a day of it, I decided I would also force myself to learn some new tools along the way:

1. Pycharm instead of emacs
2. postgres instead of mysql
3. SQLAlchemy instead of hand-crafted SQL
4. Git operations in Pycharm instead of the command line

Considering I worked within those 4 constraints, I’m not so bothered that it took me 6 hours to create a table and then another hour to write the methods to insert rows.

And what the hell, why not throw in a new blogging tool too? Checking “First Medium Post” off my to-do list.