Back on August 6th, 2021, I made a post about the Ford Connect Simulator hackathon project. Of the three contest entries, it was the one I spent the most time and the only entry that didn't win. Back then I wrote "My learning kept evolving as I wrote the simulator, so it would be fun to go back and rewrite (or at least refactor) the simulator knowing what I know now."
I had just left Microsoft a year before, and we had just moved from Tulsa, OK to Goose Creek, SC. I was doing hackathons to interact with community and to add some constraints into what I worked on in my spare time. During the Ford hackathon I really engaged with the community, helping other teams understand how to leverage the API. There were a couple of times where Ford employees reached out and asked if I was interested in working for Ford, since a secondary objective of the hackathon was to find additional talent. My answer was I really enjoyed the people I met and their culture, but I wasn't really interested in a job, having just retired a year ago.
On one of my calls with Ford, the question came up what if I did subcontract work so I wouldn't have to work every day? Starting October 2021, I was contracting for RealogicWorks; working Tuesdays and some Thursdays subcontracting to Ford to work on the simulator. My team was Liz, Scott, Lacy and others that I had met during the hackathon! The arrangement worked out perfectly. The majority of our weekdays days Karol and I would go things around the greater Charleston area (for more details on that, my private Facebook account has all of our adventures!) but Tuesdays I would work (remotely) while Karol would do whatever it is she enjoys (it seemed to me like she was mostly reading her Kindle, playing video games on her phone, and reposting on Facebook anything that aligns with her views.) I would typically work on Thursday as well, unless EventBright, Meetup, Facebook Events or something else offered us a unique opportunity that was only available that Thursday.
I had very few meetings other than the daily standup (which I was attended Tuesday/Thursday) and I would do Slack standup when hard a larger-org meeting. Eventually we ended up adding team meetings as well, but still the majority of my day was focused on the project. There seemed to be a few different types of people at Ford - people who used Slack, people who used WebEx chat, and people who used email. The majority of the people I interacted with used Slack & most of it was channels in Slack, so everyone on the team was included in communication (which helped make standup quicker, since we already had a good idea around status). My email was measured in days per email! (Yes -- instead of how many emails per hour you got, it was how many days since the last email. My @ford.com email had an Inbox that was always all caught up!) Eventually I ended up on SRE and SonarQube notifications, so maybe a couple emails a day, but I could still quickly catch-up Tuesday morning on all the email since last week. I didn't install anything on my laptop or phone so if I wasn't in my office working, I wasn't working. This was amazing work-life balance.
I worked on two projects at Ford. The primary project was the FordConnect API Simulator. This project was a huge learning experience for me. I was new to Ford and new to the technology stack as well. Everyone at Ford was super helpful at answering any questions I had. Unlike the hackathon project, the simulator I was creating was using Java. Ford developer site has tons of information that I tried to absorb my first month there (which isn't that much time when you only work twice a week). Based on all of their best practices, I used the Ford wizard to create a Java Spring Boot project with a Jenkins pipeline and integration into governance tooling, like static code analysis. I decided to take a Test-Driven-Approach (TDD) when I would write a test and then implement the code to pass the test. I was actually using GitHub Copilot which meant my real process was... write a comment for a test case. start writing the test case method and press <tab> to auto-complete the test [fixing whatever the AI engine missed]. start trying to write code to pass the test and press <tab> to auto-complete the implementation [fixing whatever the AI engine missed]. By the end of the project, a typical user story like "As a customer, I want the simulator to give an error when remote-start limit is exceeded, so I can validate my client application behaves correctly" would take about 1/2 day to implement. A few times when I did refactoring, I would get confused as to how to do TDD, so I would just make sure that after the refactoring I still had 100% code coverage.
The simulator exposes a bunch of endpoints that lets a FordConnect API developer simulate various vehicle conditions. I used Swagger annotations (io.swagger.annotations) in my Java code to automatically create the Swagger API contract document. All of the data models have validation as well and hopefully a human-readable documentation so you don't have to be a regular expression expert to figure out what you should send.
The simulator still has some work before it can go live (mostly in the DevOps space) but I created 30 knowledge transfer videos and a bunch of wiki pages, so hopefully the next people to work on the project will be able to ramp up quickly. I look forward to seeing it available to 3rd party developers some day!
The second project I worked on was for automating the rules from the API Intentional Design wiki. This project went through a few iterations, but ultimately what ended up being used in production is YAML rule definitions of rules that are evaluated by the stoplight.io spectral engine. It was super fun to come up with how to define rules using only the core functions. In some cases, I first implemented them using the JavaScript extensions that are supported, but eventually figured out how to remove the custom code and describe the rule in terms of core functions. A combination of the given clause and the schema function turned out to probably be the most powerful. For the simulator, it was just me working on it, but on the linter I was fortunate to get to work with (and learn from) Essam. Once I had something working, I would meet with Essam, and we would discuss various ways to try to improve it more (or how to drive more consistency across our existing ruleset.) Since I was focused on creating the rules, it freed Essam up to create a UI for the tool which I think really helped to increase adoption at Ford -- they even gave a demo of the tool earlier this month at the API Conference! In theory the rules can be easily added to Postman if you have the enterprise team version.
Last month we moved from the house we were renting into a townhouse. In the move, I downsized from two rooms into one for all move stuff. I moved a crazy amount of stuff into my new office, and I realized I haven't really used most of it since we left Bellevue, WA two years ago. Our next move is coming up soon; probably April 2023 (likely to Nashville, TN). I'm excited to have my Tuesdays and Thursday back -- I hope to spend the time working on projects that I haven't been prioritizing (utilizing a bunch of the stuff that I keep moving). As you hopefully can tell from above, working at Ford was a great experience over the past 13 months and I'm really thankful for the opportunity to meet so many great people and get to work on two fun projects!
Comments