These two graphs clarified the value of my GraphQL project at work though they are from the worlds of data science and server infrastructure. Both showcase the leverage of managed services: data scientists focusing on model development and backend engineers on application code. The same applies to UI engineering.
As a UI engineer, I don’t care to spend time optimizing build pipelines, or learning how to use different backend APIs. I instead want to focus on differentiating activities like understanding business needs and translating those needs to a good UI. GraphQL is one such technology that hides backend implementation details from me.
I recommend reading this and maybe using this if you are new to one-on-one meetings. But I believe that managers should personalize their approaches for every report. If they just stick to the same tool, it will eventually feel impersonal and distant.
Software Engineering 🌐
The introductory guide to AssemblyScript
I was a little annoyed before that Typescript’s type information gets thrown away at compile time, only to be re-discovered by Javascript’s engines. Not anymore. AssemblyScript will take the type information and generate WebAssembly, saving the engines’ work.
An article from a Redux maintainer on the pros and cons of Typescript. I agree that Typescript makes you want to write a more straightforward code with a simpler type system (think High-Order Components vs. Hooks in React).
This is a list of internal memos by various executives that somehow got out to the public domain. I haven’t read everything yet, but I found the Facebook memos on their Ads business intriguing. I also liked Microsoft’s postmortem on its Word 1.0.
The game may look simple but is super cool. Players can type any text, and the game will react to it based on the model, considering both the context and the text content.
I have been running my personal development OKR for the last two years. I will report my results for November since it ended this weekend, and I feel extra motivated for this final month of 2019.
On the upside, I read more about Blockchain and Web in November than in October. I also ate fewer sweets and gave feedback more often at work. On the downside, however, I failed to read books consistently (I have more trouble when I am reading nonfiction). I did not meditate or follow Mckenzie exercise as much as I had hoped because of the holiday disruptions. I am most disappointed that I couldn’t make writing a daily habit. Overall, I slightly regressed compared to October from the overall score of 0.63 to 0.60.
In December, I will focus on two goals: to write 100 words every day using https://writingstreak.io/ and to ask for feedback at work every day.
If you are curious, you can see my current goals and past results here.
I didn’t find the technology or the decision unusual. But I loved reading about their process, where the team designed and compared different approaches and communicated their progress. If you are interested in learning more about the way larger engineering organizations operate, this is a good representation of it.
Even though the idea of solving a problem without writing a code scares me about my job security, doing what’s best for the business will help me in the long run. Education, a process, and a spreadsheet are all useful tools to have.
I am fascinated by how similarly apps on different platforms, web, android, and iOS, manage their states despite different terminologies. I parallel the fore-mentioned SwiftUI Architectures to the following React patterns: View in Model-View is stateful like stateful React components. ViewModel in MVVM abstracts common states like a common React hook or high-order-component does. Redux is, well, Redux.
Building a sensible layout takes a big chunk of my development time, possibly more than using the correct colors or typography. This article provides helpful vocabularies like inset, stack, and inline, to use for your design system.
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.
This week, I have 7 1:1s with strangers to talk about their careers and mine. I feel fortunate to have these opportunities to give and learn. Hopefully, some will evolve into long-term, mutually-beneficial relationships.
I read quite a bit about and now have my own opinion of how to what makes a senior engineer. This article goes beyond and describes the next steps a senior engineer could follow.
You can think of tech debt as how you think of financial debt. Just as you would sometimes finance your investment via bank loans, you can pay for your product bets using the tech debt. It’s apt that the VP of Product at Capital One write this article.
A very cool project to leverage HTTP 2 features (multiplexing and server-push) to solve many problems GraphQL aims to solve: over/under fetching, and the n+1 problem. The project also reuses HTTP caching, which GraphQL can only use with predefined queries.
Whatever architecture choices you make, GraphQL or REST, or Javascript or Typescript, remember that you will face unique challenges specific to you and your team.
I got two things that changed my thinking on remote work. First, Silicon Valley may have the best engineering talents, but the good ones are everywhere. Second, remote work is getting more accessible, thanks to the new tools. I hope to work in a completely remote environment to get better at remote work in the next few years.
I always thought games are the worst kind of software to develop due to a marketing-driven, fixed deadline, and the inability to verify ideas. But contemporary games work more like SaaS products, which could remove some of the pressure.
Meetup users came out hard against the service’s plan to charge them, which was expected. But I am still surprised that the disgruntled users are now building open-source alternatives. This series of events shows how easy and cheap it is to start new services.
youngk.im 