We’re really glad you’re here. We know that you have a lot of options about where to work, and we’re honored that you chose Ondema. Welcome!

Our goal is for you to hit the ground running by creating a pull request and deploying code to production on your first day.

The plan

  1. Log into the Ondema Workspace and review your first story.
  2. Clone the repository: https://github.com/ondema/pantera.
  3. Get it running in your local (npm install && npm start).
  4. Write a test that will fail until your first story is written.
  5. Update the front-end code until the test passes.
  6. Push your code and open a pull request.

Cycle time is important. Plans are less important.

We may hit a block along the way where we learn something about a hardware or account issue, or even get distracted by your story and spend a couple of days coding instead of getting something deployed done quickly. Those are also reasonable outcomes on your first day.

The most important part of the plan is that we’re going to execute on it as a team, and iterate on the plan as early and as often as we need to. Over time, we care a lot about getting working software in production. Today, we mostly care about starting an iteration with you, having fun, and learning a lot.

We’re still a very small team, and as you know, humans are extraordinarily adept at discovering new use cases that are not yet supported. If you use our development tools the way we do, your first cycle may be a quick one. If you trip over a brand new use case or some flake that we’ve not yet removed from the development pipeline, we may have to huddle and decide whether we should prioritize the new use case or fix the pipeline issue instead of your story.

Tests are important

Tests are also really hard. Our theory is that a big part of the challenge is that most days we’re trying to climb a couple of learning curves while writing working software and writing tests that validate that the software is working. Often that’s too much, because we’re stupid meat puppets. So we don’t always do TDD.

On the other hand, some days we’re fixing a small bug that can we can test in a straightforward way. On these days, we really want you to write a test that fails, fix the bug so that the test passes, and open a PR. So that’s the workflow we’re going to shoot for on your first day.

We’ll spend some time watching tests run, so you get a sense of how the tests are using our software every day, hundreds of times a day, to make sure that as often as possible we find issues before our customers do, to make sure that we can push as many updates to production every day as we need to, and to make sure that we remember what the software is supposed to do. We forget sometimes, and the tests are an important part of our lore.

Pair programming is important

We need your help. We tend to write illegible code. Sometimes we copy code from stack overflow without reading it correctly. Maybe we thought we read it, but we got it wrong. Maybe we were mostly focussed on a different problem, and we didn’t try to read all that carefully in the first place. Maybe we didn’t know.

For example, all over the code you’ll find stuff like this:

Item = items.filter(i => i.uuid === itemID)[0]

A couple of months ago, I’m looking at a piece of code and there’s a find() on the array, and I feel super silly. items.find() is so much more legible than items.filter(), which suggests you’re going to return an array, not an element in array. And if you’re a fast reader you might see the [0] on the end, but I’m not a fast reader. So I can’t read my own code (this is how I know I’m an impostor developer instead of the real thing).

If you ask us about a line of code that doesn’t make sense, we’re much more likely to write something that makes sense. Because talking about the code makes write better. Because you’ll have suggestions about how to think about a component in a more coherent way. Because you’re smart, and we’re pretty sure that in some ways, and certainly on some days, you’ll be able to push us to improve how we write, think about, and organize our code so that it will become easier to maintain over time. Or maybe we know something you don’t, and we can help you write and organize your code.

In either case, the team just got a little bit better.

Continuous improvement

With each iteration, we become a stronger and faster team. In many cases, we develop professionally as individuals too, which is a really nice side effect. We try to avoid side effects in functions, but with high functioning teams we talk about synergy and catalysts. So maybe side effects are ok with people. At least if they’re good.

With your help, your first day will be a good day, and then we’ll start again on the second day, and see what we can do to build on that. Eventually, very small amounts of continuous improvement tend to add up.

Submit a comment

You may also like

The Intent-Impact Gap in Software
The Intent-Impact Gap in Software
22 May, 2020

One of the continuing lessons of my personal and professional life has been learning every day a bit more about the inte...

Is This Your Card? UX Study on Ondema Card Design
Is This Your Card? UX Study on Ondema Card Design
9 June, 2020

The first time I saw Ondema’s user interface, I instantly recognized the card paradigm as a powerful visualization of ta...

Improve Subcontractor Productivity with Partner Accounts
Improve Subcontractor Productivity with Partner Accounts
29 March, 2022

Contract manufacturing requires close coordination and collaboration across complex supply chains. In the OND Precision ...