Org Web Adapter

Editing journals/2019_05_07.org

:PROPERTIES:
:ID:       926d19bc-bfeb-49c8-958d-4e7b9f7e4d70
:END:
#+TITLE: Daypage Journal

* Tuesday, 5/7/2019
#+BEGIN: clocktable :scope file :maxlevel 2
#+CAPTION: Clock summary at [2019-05-07 Tue 13:05]
| Headline          | Time   |      |
|-------------------+--------+------|
| *Total time*      | *3:47* |      |
|-------------------+--------+------|
| Tuesday, 5/7/2019 | 3:47   |      |
| \_  Tasks [5/12]  |        | 3:47 |
#+END:
** Tasks [11/13]
*** DONE Run van over to Blue Hill :@home:errand:carrepair:
CLOSED: [2019-05-07 Tue 13:03]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 09:00]--[2019-05-07 Tue 10:22] =>  1:22
:END:
*** DONE Project Euler exercises for interview practices
CLOSED: [2019-05-07 Tue 13:04]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 10:22]--[2019-05-07 Tue 11:45] =>  1:23
:END:
*** DONE Lunch with kiddos :@family:meals:lunch:
CLOSED: [2019-05-07 Tue 13:04]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 11:45]--[2019-05-07 Tue 12:10] =>  0:25
:END:
*** DONE Water fruit trees and rake up leaves :@farm:chores:orchard:
CLOSED: [2019-05-07 Tue 13:05]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 12:15]--[2019-05-07 Tue 12:48] =>  0:50
:END:
*** DONE Set tasks for the day :@personal:daily:
CLOSED: [2019-05-07 Tue 13:02]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 12:58]--[2019-05-07 Tue 13:02] =>  0:04
:END:
*** DONE Write up production issue essay for Thorn interview :@personal:jobsearch:thorn:
CLOSED: [2019-05-07 Tue 13:41]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 13:05]--[2019-05-07 Tue 13:41] =>  0:36
:END:
**** Submit URL
https://app2.greenhouse.io/tests/f9befa46cbbd2df90bb09ded5fd7c50b
**** Essay
We had just shipped a minor new feature, and my manager sat down and explained
the work he wanted me to do next. "They're going to force us to pay per request.
That means in a few months we'll start having to pay Google close to to $400K a
month for our maps API usage." Doing some quick math in my head about what I
remembered about Google Maps costs, I wasn't even sure how that was possible.
There was something like 25K free requests per DAY, and then $0.5 per 1K
requests after that. We must have been using millions of requests per day.
Indeed, we were.

Our software primarily tracked rides from Point A to Point B, and allowed routes
provided to drivers to be dynamically updated when a new rider appeared on the
route with a new drop off, adding a Point C and a Point D to the trip. The
concept itself was fairly straightforward, but the solution for searching for
optimized paths against the Google Maps API was not optimized for calling
frequency at all.

My first order of business was to review our Google Maps API usage. Looking
through the provided dashboard of call frequency, approximately 70% of all our
calls to the API was to the location service.

After discussing my findings with my manager, it turned out the existing
solution was written before Google added Routes to it's API. Routes provides a
way to bundle points together and get a Google-optimized route through all
points, rather than submitting one pair of points at a time and piecing the
entire route together.

Thus, my solution was to create a route path composed of our current location,
and all pickup and dropoff locations and submit that to Google's Routes API. Our
average route complexity was above three, so I estimated before our production
deploy that we were reducing calls by at least a factor of two. In fact,
profiling calls via logging output and a simple Splunk query demonstrated the
actual improvement to be closer a factor of three decrease in our calls to the
Maps API.

There were other optimizations to make in the codebase to avoid our Google Maps
API usage from causing bankruptcy -- including a GPS ping that every driver and
rider was triggering every second for which I also helped build an algorithm for
determining the optimal time to ping, this turned out to be closer to every five
seconds -- but the Routes optimization saved us close to a quarter million
dollars in expense.

One issue I had when I began this work was an assumption that the Routes API
being such an obvious solution, that it likely had been tried. I spent longer
than I should have researching other possilbiities in the code before I thought
to mention the idea to my manager, who quickly verified that it was a valid
solution path. Reviewing findings when debugging with co-workers is something
that should happen early and often.

A second key insight that came from this work was the importance of small-scope
unit tests. The initial solution I devised didn't work on some edge cases that
were only apparent when doing integration tests on staging. Smaller unit tests
on the edge of the problem would have allowed for a faster turn around time on
the actual code fix.
*** DONE Review projects and clean up GTD lists :@personal:review:
CLOSED: [2019-05-07 Tue 13:51]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 13:41]--[2019-05-07 Tue 13:51] =>  0:10
:END:
*** DONE Read Shane Parrish on providing feedback :@read:
CLOSED: [2019-05-07 Tue 14:14]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 13:51]--[2019-05-07 Tue 14:14] =>  0:23
:END:

https://fs.blog/2016/02/roger-fisher-and-alan-sharp-on-how-to-really-provide-feedback/
**** Takeaways
Three types of feedback:

1. Appreciative
2. Advice/Coaching
3. Evaluative

All three are valid, but the motivations for them are very different. What are
you trying to do?

Evaluation will generally be the least helpful. Few people genuinely need to be
evaluated, or at least told how their evaluation matches up with others.

"Withholding deserved praise is basically immoral." -- Charlie Munger

Solicit feedback early and often. The best thing you can do is demonstrate what
you want from those working beneath you by modeling that behavior.
*** DONE Write in daily journal :@personal:habit:journal:
CLOSED: [2019-05-07 Tue 14:26]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 14:15]--[2019-05-07 Tue 14:26] =>  0:11
:END:
*** DONE Prep for DOD interview :@personal:jobsearch:review:
CLOSED: [2019-05-07 Tue 18:39]
:LOGBOOK:
CLOCK: [2019-05-07 Tue 14:26]--[2019-05-07 Tue 15:00] =>  0:34
:END:
**** A little about myself
+ Been working full-time as a REMOTE developer for 8+ years
+ Started out in newspapers, actively contributing to open source
+ Used django because it started as a newsroom tool, quick CMS, custom content
  types, fast turn around building templates
+ Spent 4+ years supporting a custom CMS and building websites and plugins with django-CMS
+ Built a number of custom donation forms for non-profits that included some
  crazy payment processors (PayPal Pro ... sigh)
+ More than anything, I like challenging myself to learn new things
+ Built out a React front-end for a data import tool at my last job, had
  responsibliity to build backend and frontend and that was fun
+ Not totally sold on the React model, a little heavy for most things, like
  Preact and projects like that that use the same data model but with fewer
  toolchain requirements
+ Started out with a fully distributed company, spent the last 2.5 years with
  remote-friendly startups
+ Takes time to build culture, not everyone is built for it, and not every
  company understands what the tradeoffs are
+ Written communication has to be superb in remote engineering teams
+ I find email is good for whole team communication, Zulip/Slack better for
  one-on-one or small teams
+ Salary expectations around 120k, but I'm flexible at this point
+ Originally from Chicago, but spent last deacde in Maine
+ Four kids, ages 1 to 8 on a small farm by the ocean
+ We raise goats, sheep, chickens, ducks and turkeys
**** Questions
+ Do folks collaborate often on issues, or are tickets inidvidual projects?
  (pair programming ever?)
+ How does an issue become a ticket, and who controls when work starts?
+ Repo style and release schedule?
+ Size of engineering team?
+ How are projects/sprints evaluated and iterated? Actionable retros?
*** DONE Interview with David @ DOD :@personal:jobsearch:interview:
CLOSED: [2019-05-07 Tue 18:40] SCHEDULED: <2019-05-07 Tue 15:00>
:LOGBOOK:
CLOCK: [2019-05-07 Tue 15:00]--[2019-05-07 Tue 18:39] =>  3:39
:END:
** Journal
Actually woke up pretty early and didn't feel groggy, but stayed in bed anyhow.
Not sure whether it was a good mood, but Nabby was sleeping well beside me and I
didn't want to take too much of a chance waking her up. Compared the last night
she's feeling much less feverish today, but sleep is probably still a good
thing.

One curious aspect of today was realizing that, facing down my interview with
DOD today, the kids were driving me nuts. At lunch, Silas and Asa were just
rambling about things and my headspace was well and totally taken up with
thinking about the interview.

I'm also not sure why I'm so nervous about this interview. ReCharge seems pretty
excited to get me, and I have two other interviews I'm facing down with Thorn
and Sourceress. But DOD was my first, best hope, so maybe I've hung more of my
confidence on doing well there.  Either way, I need to do some prep work for it,
and get my head in a good place to put my best foot forwards.

One of the more difficult aspects of interviewing is knowing what you're walking
into. Some folks just want to talk over topics and test your thinking, others
ask more specific technical questions to figure out where knowledge ends. Still
others do really specific techinical problems like solving sorting or
algorithms. This last set drives me nuts because google being what it is, most
such issues can be sussed out so long as you know how to use a parciluar
programming language. This is where things like Project Euler or koans come in
handy, giving quick little problems to explore how a language works.

---

Well that interview did not go well. The talk part was fine, but then we got
into a short quiz on how to generate a symmetric diff of two lists and I
completely flubbed it.