Things I've been doing since Oct. 2022, which was when I quit my most recent job.
The main reason I decided to take a break from work altogether was ironically to get better at what I do, that is, web development. It's ironic in that even though I was working as a web developer at my last job, unfortunately I felt the time I spent at work was not necessarily effective at becoming a better web dev.
I'm joining Medisola as a frontend developer.
Health, nutritions, and diet are something that I've been very much interested in, and Medisola is a company that provides high-quality, nutrient-dense packaged meals for people with medical conditions and those who care about their diet and nutritions. So I'm very excited to see how I, as a web developer, can help the company build software products and grow its business (starting with building internal tools, it seems)
Though I've pretty much given up the idea of applying for FAANG companies (or any US tech company, really) after realizing there's practically zero chance of me getting interviews as a non US citizen who's currently not even living in the state, I thought it'd still be a good idea to do some FAANG style interview prep while searching for a job in the local market.
I find studying system design particularly useful, not only for the interview prep, but also for understanding modern software architectures in a more holistic way. I think knowing what kind of technologies are out there and popular, when they are useful, and what are the tradeoffs and consequences of choosing one over the other, even at a shallow level, is beneficial for any software engineer. No wonder why there's such heavy emphasis on system design rounds in the interview process. As for the resources, I've found this great website called hello interview, and of course, revisiting DDIA turns out to be incredibly helpful as well.
Having one dedicated Leetcode day in the week helps me maintain algorithmic coding skills that probably would come in handy in my current job search endeavor, and of course, to not forget my identity as a frontend developer, I have two days reserved for doing frontend-related stuff—I'm currently going over resources from GreatFrontEnd, but there are also some web frameworks and libraries I want to checkout afterwards.
As I was planning to wrap up the current sabbatical and start preparing for a job search soon, I wanted to go over one more subject presented in Teach Yourself Computer Science. And Designing Data-Intensive Applications (DDIA) is the book I picked to read. Distributed systems like Hadoop and Spark were something that was very fascinating to me when I was a data analyst early in my career. In fact, they were so interesting that I went out of my way and built a mini hadoop cluster as a side project around 2018. So yeah I was definitely excited to read this book.
Overall, I'd say the author did a really good job elaborating on various distributed strategies such as replication and partitioning, and things that could go wrong in a distributed system. I also learned a lot about traditional databases such as database indexes, database transactions, and how they actually store data on file systems from this book. While reading, it definitely felt like this was something I should've read when I was a data analyst 😅. It even explains terms like OLAP and data warehouses that I frequently heard but only vaguely understood in my data analyst days.
I'm not sure if I ever get a chance to work with distributed systems of a massive scale as a frontend developer, but I believe it still is beneficial for me to learn and be aware about these "under the hood" backend/infrastructure computing systems that power modern IT services that we enjoy using.
Finally, it was time that I confronted LeetCode again, but this time I was better prepared, having just finished extensive data structures and algorithms (DSA) study for the first time in my life 💪. In particular, I followed this wonderfully curated list of 150 LeetCode problems, called NeetCode 150.
I would not dare to say I loved solving LeetCode problems even after learning DSA, but it was overall a good experience for me to review various algorithms and data structures I had just learned and to practice on actual implementations of said algorithms.
While working my way through NeetCode 150, I realized there were a couple of concepts I didn't go over in my first DSA study—most notably, backtracking and dynamic programming. So I had to go back and study relevant chapters in the books—Skiena's book for backtracking and dynamic programming, and CLRS for dynamic programming and greedy algorithms. Somehow Sedgewick's book and his lectures—which were my primary resources learning DSA—do not seem to include those subjects 🤷♂️.
I'm planing to go back and solve NeetCode 150 again at some point in the future to solidify (or to memorize?) my understanding on important data structures and algorithms.
At first, I was very hesitant to learn algorithms and data structures the proper way as elaborated in Teach Yourself Computer Science, mainly because of the significant time commitment implied by the learning materials.
I don't really recall how I convinced myself to do it, but I eventually decided to bite the bullet and learn data structures and algorithms for the first time in my life—well after all, I was planning to do some LeetCode grinding as a part of job search preparation in the future, so why not learning the underlying concepts and ideas first along the way, I probably thought 🤔.
I first grabbed Skiena's book and the accompanying online lectures as my main learning resources, but I abandoned them right before the graph algorithms in favor of other materials I'd found that I liked more: Sedgewick's book and his coursera courses (part 1 and part 2).
The thing I like the most about Sedgewick's book and the courses was the fact that they provide concrete implementations (Java) of every algorithms that they discuss in the book and the lectures. I found it much more helpful to understand algorithms when learning the concepts and implementations together, side by side. I also liked the fact that they took time to explain Java fundamentals in the beginning of the book. It was immensely helpful for someone like me who's not very familiar with Java language, to better understand the implementations (and be able to turn in homework assignments 😂).
By far the most challenging aspect of learning algorithms was understanding theoretical performance analyses, involving order of growth and mathematical proofs (and some advanced graph and string related algorithms..).
I cannot say that I understood everything covered in the book and the courses very well (in fact, far from it. It feels like I'm already forgetting half of what I learned), but at the end of the day, I'm glad that I took time to learn the subject at least this once.
I always appreciate a well-crafted UI component library because it's definitely not trivial to make one that handles a lot of browser inconsistencies, different inputs from various devices, and web accessibility. So I was instantly hooked when I found React Aria and wanted to learn how it works underneath, which led me to contribute a little to this amazing project.
As a non CS major, I've always wondered what subjects CS students learn in college, and I've been looking up online a way to teach myself college-level computer scienece. Luckily, there's this wonderful website called Teach Yourself Computer Science where the authors have put together a well-curated list of subjects and recommended study materials for computer science. I've visited this website so many times, promising to myself that one day I'd start working on the subjects in the list—the promise that had never been realized yet.
I finally decided to take the first step by working through the book called, Structure and Interpretation of Computer Programs (SICP). It was a very hard book to read—I actually only read up to 4.4.3 since CS 61A (the video lectures I was watching as a complementary material) didn't cover beyond that, and I lost all the motivation to finish the book to the end when CS 61A ended 😂. Well to be fair, the general/important ideas presented in each chapter of the book wasn't too hard to understand per se, but the examples and exercises were—mostly because they expect you to have some math and electrical engineering knowledge as a background. And most of these exercises—on top of needing to know some math context to solve them—weren't something that you could solve right away in a few minutes after reading the chapter above. They were rather something that required you to sit down and think hard for hours or even days to solve them—I decided not to invest a lot of time on these exercises but rather look up other people's solutions most of the time; such as sicp-solutions and SICP Solutions. While I'm not proud of not working through most of the exercises myself, truth be told, I wasn't particularly motivated to put a lot of efforts on them since I wanted to spend those extra hours on learning web technologies instead.
Despite the frustrating experience with the exercises, I've found surprising amount of ideas and concepts in the book were very relevant to React.js—things like the simplicity of functional programming (as in given the same input, a function produces the same output everytime), the challenges introduced by assignment and mutation especially in concurrent execution, and ideas like delayed evaluation, memoization, thunks, etc.
At some point in the future when I'm a little wiser (hopefully), I should give this book another try.
In the beginning of May. 2023, I finally decided to take a look at Storybook. I'd seen it being mentioned by many web devs on the internet quite frequently (mostly positive), and some would even argue Storybook is an indispensable tool when it comes to UI component development.
Well, they were certainly not wrong.
I still remember how mind-blown I was, when I first grasped the concept of Storybook—in a nutshell, it provides you an isolated environment to develop a single UI component at a time without affecting other parts of UI or logics in your website. It felt like I found the final missing piece in my web development process when I discovered Storybook. In fact, it felt like Storybook was the most important piece of all, because it is where all the UI components are going to be created, assembled, and incorporated into bigger components, and tested thoroughly.
What's nice about developing a UI component in isolation is that you only need to worry about UI logics (as in how the component will behave) at the moment without having to think about stuff that needs to be handled by a framework or how to process data for this UI component, right away—you can think about them later when you finish developing the component. This sort of separation of concerns, I believe, encourages your codebase to have a better structure—I find it almost always much harder to read the body of a React component in which all sorts of logics are intermingled together.
Anyways, the discovery of Storybook was so sensational to me that I felt a strong desire to contribute to learn more about its internals. So I did just that for a while.
shadcn/ui is a UI component library that is primarily built upon two of my favorite UI/styling libraries, namely tailwindcss and radix-ui, and so I simply wanted to write stories about them 😄 (though at some point, it kinda got boring and I stopped working on it so it's only ~70% complete).
There was an online game that I used to enjoy playing—Teamfight Tactics (TFT). So naturally I had been checking out Riot's APIs to see if I could create something fun or useful with them.
The thing about this particular game is that every now and then (roughly a few months), there's a new "set", and when the new set comes around, the winning strategies you used for the previous set wouldn't work on the new set. So you have to, sort of, learn new strategies for the new set all over again everytime there's a new set. And I wanted to shorten that learning process by analyzing winners' strategies (there are 4 "winners" out of 8 in every TFT game)—this website was an attempt at that.
I had fun making the image viewer component in https://image-experiment.vercel.app/ below, so I decided to create a fancier version of it, including skeleton loading animation, transition animations on navigation, swipe gesture support on touch screen, keyboard navigation, infinite scrolling, etc.
I think smooth and well-behaving animations are great to have on any website—but they are tricky to get right. The animations in this project are mostly taken care of by Framer Motion, which is a great animation library, though I had struggled quite a bit trying to orchestrate different animations to work together and ensuring there was no significant performance issue (jankiness / stuttering) on mobile device.
Web animation is a subject that I want to dive deeper and really grasp the fundamentals firmly in the future, so I could rely less on higher level libraries.
While I was working on CMS integration for my cousin's website, I learned that Sanity provides various image optimization features for uploaded images. So I played with those features a little bit, creating a simple website above that has an image viewer.
I wanted to integrate CMS to my cousin's new website so that he could edit and manage his contents intuitively. I did some research and Sanity looked like a great fit here so I created a tailored Sanity Studio with live editing and preview features for my cousin's website.
(Despite the effort, my cousin doesn't seem to be using the new website and the editor at the moment, while it seems he continues to update and maintain his old wix-made website. I guess I lost to wix.com as a website service provider 😭)
One of my cousins wanted to renovate the website for the lab he was running (made with wix), so I made him a completely new website, using Next.js and tailwindcss.
Well, the original plan was to maintain the website with great discipline by writing about things related to web development and software engineering on a weekly basis, but it quickly turned out to be a lot more challenging than I'd originally thought, so I abandoned the idea (and the website) and moved on to other stuff shortly after.
