This issue is the 50th of my newsletter. The first issue was published on November 25, 2018, so today marks a nice full circle. I am grateful for all of my kind readers who still have the patience to open and read through the letters. Especially I want to thank those of you, including my wife Eunyoung, for your kind encouragement and necessary feedback. Looking forward to another 50!
I was just thinking about how privilege is everywhere (even in speaking English). Entrepreneurship is no exception. If you can’t afford to fail, you will choose not to fail.
This link has a survey of the technology landscape. It covers both Web and Server development which allows a UI engineer like me to reevaluate my learning investment. I found this piece, Front-end integration via artifact, most useful.
After reading Continuous Delivery, I have religiously automated all manual tests and wrongfully chosen not to do any manual tests. I, as a result, released a fair bit of bugs to production. My colleague showed me how stable software could be with proper manual testing, which led me to read the linked article.
“It’s just the algorithm” cannot be an excuse. Her writing makes me worry about the general inexplicability of modern-day production algorithms. Worse yet, some customer service departments may find that plausible deniability useful.
Not sure about others, I for sure take the internet for granted. Whenever I read something like this, I awake and marvel that it is working at all for most people most time.
Triple-A games focused on storytelling provide deeper immersion than typical blockbuster movies. I see one day, interactive films and the storytelling games will blur into one.
I have been enjoying a writing guide by Steven Pinker, the best-seller author. Of all the lessons, I was most impressed by the argument that some grammar rules, which I studied to perfect, are overly correct; that a writer ought to strive for clarity even when that means violating some nitpicking rules.This point got me to ponder whether I would.
I started learning English as a second language since I was six-years-old. By now, I really don’t have a problem speaking, listening, writing, or reading. And I sometimes dream in English too.
Despite two decades of education, I still take extra care when I use English. I keep mentally noting my grammatical errors every day and make sure I don’t make the same mistake. I aim to be perfect because I think I am only borrowing someone else’s language. In this state of mind, there is no way I could intentionally break grammar. I now realize the ability to break away from rules is a privilege. Even when no one notices, I do and I will censor myself. This is the classic impostor syndrome.
When media or politicians discussed regulating the software industry, I feared that the regulation would close the door to newcomers. Opening the doors to more startups and people should make “disruptions” less painful and more beneficial to our society. This belief made me against most regulatory approaches.
But I heard an analogy of the architecture design of a building vs. the actual building that changed my mind. An architect student is free to come up with a plan and learn from it, but the construction of the design that could affect people’s lives should be regulated. We can apply the same thinking to code vs. running service. This analogy will be my frame of thinking going forward.
If your team works remotely, you need to put more effort into building the relationship. Gitlab uses video chats to organize social events to connect its people.
Do you let people outside your team commit to your codebase? I have heard and seen that different approaches at different companies: from collective code ownership of Facebook to strong code ownership at my previous employers. Most likely, the procedures are more organic than chosen consciously. Food for thought.
If anything, I like the sound of “quantum supremacy.” It is something out of a sci-fi. Seriously, though, quantum supremacy is an idea that there is a set of problems cheap for quantum computers, but prohibitively expensive for classical computers. Cracking modern cryptography could be one such problem. The linked blog post about Google’s achievement is human-readable, so check it out!
This article is rather long and not too approachable. But it helped me understand the Apollo Client’s behavior more deeply. I recommend it to the experienced GraphQL users.
Since there are so many chat apps, your product manager wants to add the feature to your app as well. You may think it’s just another WebSocket feature and say yes. And you will spend days and nights solving group chat moderation and abuse monitoring. I know. I have been there. Think through the feature and understand possible implications beforehand.
As I gain more years of experience, I keep wondering about a couple of things. First, where do I go from here? Second, where will I be when I retire? Per the first question, these two articles (here, and here) provide a good roadmap. Per the second, I am not so sure. But I was glad to find out about Python creator’s retirement last week. I hear a lot about up-and-coming young engineers, but not about older engineers. Some part of me was relieved that at least some engineers successfully retire.
We all share the responsibilities with our managers to get the resources and deliver. It is about trust and transparency. Help your managers and, by doing so, help yourself.
Work-life balance is for all of us to think about. We, as individuals, need to find the right balance for ourselves. I like my line-of-work, and I want to do it well. I happen to like my employer, as well. But I won’t sacrifice my evenings or weekends for it.
I had a hard time understanding this article since I haven’t had to think about performance deeply. This article is essentially about creating resource hints for data and code, a step forward from HTML’s resource hints. I hope the instrumentation be rather straightforward; otherwise, I fear I won’t care enough.
The idea isn’t new. If our product is not delightful and, thus, not viable in the market, we should strive to be delightful enough. However, I do think it is useful to have a different vocabulary to emphasize the point.
AlphaGo beat Lee Sedol less than four years ago. When DeepMind announced that they would go after Starcraft II, I wondered how long it would take to create an AI capable of beating top human players under the similar interface constraints. DeepMind achieved that a little over three and a half years. This is a fantastic feat, considering the enormous problem space, and imperfect information.
Open source funding is still an ongoing issue for which key infrastructure players are trying to come up with solutions. I hope they work at scale, but I am also pessimistic about human nature.
I was fortunate to go to the GraphQL Summit in San Francisco. It has been a while since I went to a conference. And it was good to be in that immersive environment (though I wasn’t able to make a meaningful connection). The talks helped me organize the fragmented GraphQL knowledge in my head. To remember and share what I learned, I wrote a review of the Summit here. I am going to QCon next week, which I very much look forward to as well.
I wholeheartedly agree that a great decision is not an outcome, but a process. I don’t think the acronym works, but still, there are some excellent questions to ask when making a hard, irreversible decision: by when should I make the decision? What are my options? How should I make the decision? How will it look like ten months from now?
When I was asked if I would choose Redux again for a new project after my Redux talk, I said I would use GraphQL. GraphQL clients solve Redux’s complexities, such as normalization, cache persistence, and complex scaffolding, out of the box. Apollo Client especially made my life easy. I am looking forward to the coming performance optimization in this release.
I never considered any other smaller public clouds in my previous projects. So I was surprised when Corey Quinn, whose newsletter and consulting work is solely about AWS, recommended DigitalOcean for simpler, smaller scenarios.
@testing-library/react-hooks-testing-library
I love React hooks, especially compared to the alternatives like high-order components, or class components. The type system makes so much more sense. I was only unhappy that the hooks were not that testable, but this library I found out this week helped me a lot.
In my 1:1 with my director, he told me that the leaders ought to create clarity. I thought this letter was a prime example; it explains Grubhub’s position and strategy in an unambiguous term.
I loved this issue of Andrew Ng’s newsletter very much. It overviews the significant issues AI practitioners face: the possibilities of Rogue AI, Public Trust Erosion, Surveillance, Bias in AI, Job Safety, and AI Winter.
I have been to the GraphQL Summit 2019 hosted by Apollo in San Francisco. I was very excited since GraphQL is the technology I use and learn about every day. Overall, it was an excellent opportunity to see the increasing penetration and impact of GraphQL. Speakers frequently quoted this number from the npm survey: 23% of Javascript developers are using GraphQL. Naturally, many talks focused on scaling GraphQL from large companies such as Shopify, Paypal, and Expedia. The technology is not just for greenfield projects or startups anymore. But, their mobile talk lineup was relatively weak, possibly indicating the immaturity of GraphQL on mobile.
Talks were primarily divided into two categories: client-side and server-side. I mostly went to the client-side ones. Of those I went to, I enjoyed Fine-Tuning Apollo Client Caching for Your Data Graph, Client-side GraphQL at scale, and, The GraphQL developer experience the most. The followings are my notes on the talks I attended. I hope the notes guide you to find something interesting.
From the start, Danielle made a good point about the real benefit of GraphQL. It’s not just about minimizing payload or reducing round trips. It’s about the productivity boost from the integrated experience with typed API, normalization, and intelligent caching. React, Prettier, and VS Code solved the challenges of component structure, formatting, and type intelligence. Now GraphQL solves the next big problem, data fetching. I like that she went into the whys of GraphQL and also gave an end-to-end view of the tooling. I recommend it to those whose GraphQL journey is just starting.
I was a little disappointed with Shruti’s talk since I didn’t find it that relevant to GraphQL. As she focused mostly on React hooks, this is your talk if you aren’t familiar with hooks.
Ben talked about the new features in the upcoming Apollo Client 3. I found the material very relevant because my team is already seeing a huge performance bottleneck from Apollo Cache. There were several exciting features: Garbage collection, declarative cache config (though it doesn’t statically check the config yet), and improved pagination handling. Since most of the features are about performance, the talk is meaningful for those using Apollo Client at scale already.
As a frontend developer, it can be frustrating trying to adopt GraphQL since you find yourself dependent on backend counterparts. Michelle talks about how you can go around the inertia by using a GraphQL middleware (or BFF). Though I believe client-side resolver is the lighter weight approach, it was inspiring to see her org, eventually turning around thanks to the superior developer experience. She then continues to talk about her plan to adopt a federation. This talk is appropriate for those interested in figuring out the GraphQL adoption strategy.
Apollo Lounge (not a talk)
I spent an hour in between talks to talk to Hugh Willson, one of the Apollo engineers behind Apollo Client 3, about the performance bottleneck I saw in the beta release. The problem was that the Apollo Client took a long time to respond to a large query response (a tree of about ~2000 objects) even with the denormalization turned off. Due to the time constraint, we didn’t get to the bottom of the issue. But it was nice to see how an Apollo engineer goes about debugging the client and also get reassured that my configuration was not a problem.
After seeing Danielle’s talk, Steven’s talk didn’t feel new to me. Especially because I am following the development process he outlined almost precisely. But if you ever wonder how all these generated types (whether they are from Apollo Tooling or GraphQL Code Generator) fit into your type system, this talk is for you.
The most entertaining talk I have ever been to. Alex made GraphQL subscription via WebSocket unforgettable. However, as I went to the talk expecting to see GraphQL streaming (a misunderstanding on my part), I ended up getting a little disappointed. If you are building a real-time app, watch this talk when it becomes available.
Even though GraphQL’s governance mostly feels irrelevant, it matters to all of us. Orta talked through how the current GraphQL Foundation came about and how he saw through the changes. This talk isn’t for everyone, but if you like to contribute to the spec one day, watch this.
The whole talk felt like a sales pitch of his company, OneGraph. But Daniel indeed showcased many inspiring tools leveraging: a point-and-click GUI to build a query, an Excel plugin to import GraphQL data into a spreadsheet, and a type checker for queries embedded in markdown documents. The talk was more inspirational than useful.
Vishakha focused on how minimized payload and some intelligent caching using GraphQL improves PayPal’s performance. But honestly, I didn’t have a lot of take-away.
Shopify’s admin app has ~1000 GraphQL queries and ~700 entities. The company came up with a couple of useful libraries to mitigate this complexity. One library filled the gap in Apollo Client’s type system using collocated d.ts for GraphQL documents, which I found smart. Another autogenerated mock data based on GraphQL schema. I plan to adopt both of them at my current projects. If you are pressed for time, you don’t need to watch the talk since the documentation on the libraries do an excellent job of explaining what they do.
Edit: All videos can now be found here. I linked the videos to my review as well.
It was a stressful week for me. I ended up having 6 out of 9 scheduled chats, with both hits and misses. While I learned quite a bit and met some interesting people I would like to keep in touch going forward, I felt burned out by the end of the week. Devoting this much time hampered both my work and personal life. I will probably allocate less time and be more selective in accepting 1:1s in the coming month.
Anyhows, this week covers quite a few topics on infrastructure. I hope you enjoy them! I am going to get some more rest…
Remote workers at the nascent stage did not work out despite the commitment from the founding team to build a remote team. After setting up a needed structure for clear direction and communication, they were able to perform at a high level.
The author’s assumption of general mediocrity and complacency is not my cup of tea. I also believe some form of pushing information (or status meetings) can lead to serendipitous findings. But I do agree that employees should be educated on what’s expected of them and how their work impacts the business. (See open-book management)
I pushed to achieve Continuous Integration/Continuous Deployment wherever I worked. Continuously deploying is not always the best course action, and you need to make a risk/reward tradeoff. How likely will this change cause failures? How impactful will the failures be? If the deployment at the given moment is not worthwhile, there is no shame in waiting for the right time.
Serverless and JAM stack are gaining significant steam thanks to their “no-code” architecture. They may not be appropriate for large tech companies, but they provide easy wins to the resource-constrained.
I never thought of this, but I can see that the number of schemata keeps increasing over time in the event-driven architecture, which could make maintenance a nightmare. Schema Registry is a solution where you can store the schemata and load them to parse a JSON per the stored schema dynamically.
