greencurry43
Joined 13 years ago
Joined 13 years ago
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.
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.
Another interesting read is around the configuration complexity clock [1], in that over time we move from hard coding things to building configurations to coming full circle and hard coding things again. I like to think internal DSLs closes that loop well.
[0] https://www.martinfowler.com/articles/languageWorkbench.html
[1] http://mikehadlow.blogspot.com/2012/05/configuration-complex...
In this video, he talks of a concept called functional core, imperative shell. The functional core is your code that contains your core logic that can be easily unit tested because it just receives plain values from the outside world. The imperative shell is the outside world that talks to disks, databases, APIs, UIs, etc. and builds these values to be used in the core. I'll stop there—Gary's video will do 100x than I can do here :)
Thanks for the feedback here. I modified the post a bit to not show the arrays because the library doesn't return arrays but rather aync generators. The power of this is that you have a single interface for interacting with all data no matter if there are zero or many results.
This is library is a proof of concept. In a perfect world, there would be a nice wrapper around this query result for interacting with the data.
This would provide a single order by calling the first yield for the generator. No need to worry about the underlying result.With all of this said, it doesn't have to be this way. I'm exploring ideas here. The important concept is that GraphQL can be used to express the expectations of the client and a library like Graphable JSON can go find the needed data in the API. This gives the expressiveness of GraphQL with the benefits of REST. The sky is the limit. Thanks again for the feedback!