smizell

I wrote my own feedback below but left out this crucial piece you've mentioned here. I think to add to it, my family treats it as if I'm not there. I can't watch the kiddos for a few minutes or help get the laundry during work time. It's easy to do a lot of small things and have a completely disjointed day.

And the opposite is true, when I'm off work I'm off. My team can't treat me as always available because I'm remote. That takes time to establish.

Good point to mention.

I've had successes and failures working four years remotely, so that's my disclaimer. But the key for me has been to have a dedicated space with a dedicated computer for work. If it's easy to work on the couch you'll do it, so try to never work outside your area (if you can). Only work in your work area.

Also, protect your personal time. Do simple things, like mark out your lunch time on your calendar and don't let meetings creep into it—you'll be surprised how much this can help. Stop work at a time like 5pm and propose alternate times when people schedule things after it. People are usually open to moving meetings and may have not considered your stop time. Time zones make this harder as it's hard to keep track of when lunch is for people. Meetings during personal times should be exceptions.

Try to keep work things off your phone, though that's easier said than done with things like Slack or email. They make it too easy to work without feeling like you're working. I'm failing here currently :)

These above are all things you can do as an individual. But I think the success will also depend on your team. If you are the only remote person, it will be harder than if everyone is distributed. You'll need to ask people to write more and act like everyone is remote because you'll miss out. I've found that if you're the only remote person, it helps if your team works from home a day or two a week so they have to work remotely.

To summarize, set clear boundaries and expectations with yourself and your team with how and when you work and try to move your team to be remote-first.

Author here, great link—thanks! Do you know of any coverage tools that implement this?

You might find it useful to spend some time looking into the hypermedia constraint of REST itself (i.e. hypermedia as the engine of application state). The point of REST is to represent state machines by including hypermedia links in the responses of the API. Those links describe the state transitions a client may invoke in a given state.

Instead then of mapping CRUD operations to HTTP, you would map your application semantics to HTTP methods via link relations. Link relations let you go as far past CRUD as you would like to go depending on your domain and allow you to describe your states and state machine.

I always think a good way to think about a hypermedia state machine is in the context of HTML. Consider a todo app example. You might enter the application and get an empty list of todo items. If you have permissions to add a todo, you might have a "create todo" HTML form. Once you use that form, that todo has a new form called "mark complete." Once invoked, that todo has new transitions called "mark incomplete" or "archive." Once archived, you might see a new form for "unarchive." All of this captures the state machine and transitions in the REST API itself using domain-specific semantics.

Of course, there are other ways of solving this problem, but REST with hypermedia is a great way to work with state machines. There are lots of hypermedia JSON formats out there if you're interested in exploring (e.g. HAL, Siren, Collection+JSON, etc.).

True. I would consider a continuous stream like that to not be helpful change management. But if you have to have continuous breaking changes like that, you would want clean cuts. My point is, find ways to evolve your API without breaking things.