Category: Graduate School

  • My introduction in the Piazza forum for Graduate Algorithms (GA)

    My introduction in the Piazza forum for Graduate Algorithms (GA)

    At the beginning of every semester, each student is encouraged to post on the forum (i.e. Piazza), introducing themselves and answering the following questions:

    What is your name? Where do you live? Why take Graduate Algorithms? What do you hope to learn? What other OMS courses have you taken? What is something interesting about you? (Optional) LinkedIn profile

    Here’s my response:

    What is your name?

    Matt Chung

    Where do you live?  Seattle, WA

    Why take Graduate Algorithms? What do you hope to learn?

    Of course, this class is mandatory for us in computing systems specialization, so that’s a big reason. Another reason would be is that I’ve taken data structures course, but never an algorithms course. So, excited to learn more about the second half of DSA.

    What other OMS courses have you taken? 

    2 more to go!!!

    Graduate Introduction to Operating Systems (GIOS), Computer Networks (CN), Information Security (IS), High Performance Computing Architecture (HPCA), Educational Technology, Compilers, Advanced Operating Systems (AOS) Distributed Computing

    What is something interesting about you?

    I published a YouTube video 14 years ago when I was into parkour and tricking, and the video has close to 500,000 views (https://www.youtube.com/watch?v=zXrot9ShfvM).

    I took a non-linear path to becoming a software engineer at Amazon Web Services, where I currently work as a C developer building network packet processing devices for EC2 Networking.

    Most recently, I’m reevaluating my career as a software engineer at FAANG and looking to pivot (not sure where/what exactly) so I can spend more time with my wife, daughter, and our two dogs; spending more time with them has been the silver lining of all the COVID-19 lockdowns.

    (Optional) LinkedIn profile

    https://www.linkedin.com/in/matchu/

    https://blog.mattchung.me

    https://twitter.com/memattchung

  • Distributed Computing @ OMSCS over – what a ride!

    Distributed Computing @ OMSCS over – what a ride!

    Last semester, I decided to enroll in the brand spanking new Georgia Tech’s Distributed Computing course offered for the first time (as part of OMSCS) this past Spring 2021. What a ride! Learned a ton, including Lamport’s Logical Clocks, the FLP theorem, and the notorious PAXOS for consensus. Hats off to Professor Ada and the wonderful teacher assistants for delivering a rigorous and rewarding course. The lectures were top notch and the distributed systems labs (originally created at University of Washington by Ellis Michael) were challenging to say the least.

    Only 2 more semesters until graduating from Georgia Tech with my M.S. in Computer Science!

     

  • Distributed Computing CS7210 Distributed Computing – A course review

    Distributed Computing CS7210 Distributed Computing – A course review

    Distributed Computing was offered in the OMSCS program for the first time this past semester (i.e. Spring 2021) and when the course opened up for registration, a storm of newly admitted and seasoned students signed themselves up — me included. I was fully aware that I was walking into unknown territory, a bleeding edge course, and expected a lot of rough edges, of which there were many. That being said, the course is great and with some some tweaks around pacing, has the potential to be the be one of the best courses offered for students, especially those specializing in computing systems.

    Overview

    The course quality is top-notch. The lectures are intellectually challenging, the assigned readers are seminal pieces of work, and the projects really drill the theoretical concepts. Overall, depending on your programming experience, expect putting in at least 20+ hours per week (with some students reporting anywhere between 30-50 hours).

    Recommendation: If you are a seasoned engineer (with at least a couple years of programming experience under your belt) and someone who can handle ambiguity with little hand holding, then I highly recommend taking the course. But if you are just starting out in your computer science journey, then I would hold off for at least a couple semesters; take the recommended pre-requisites (i.e. graduation introduction to operating systems, advanced operating systems, computer networks) and wait until the course’s rough edges are smoothed out. As another student on omscentral pointed out, this class is “for experienced engineers, not students.”

    What to expect from the course

    Pros

    • Lectures are easy to watch and are packed in digestible ~5 minute chunks
    • Assigned readings (from first half of semester) are seminal pieces of work by famous computer scientists like Leslie Lamport and Eric Brewer
    • Skills and knowledge acquired directly apply to my career as a software engineer and computer scientist
    • Instructors and teacher assistants are extremely professional, care about the students well-being, and quite generous with the grading curve

    In this class, you’ll develop a foundation around designing and building distributed systems. You’ll understand the importance of systems keeping track of time and the different ways to implement clocks (e.g. scalar clocks, vector clocks, matrix clocks). In addition, you’ll appreciate how systems achieve consensus and being able to make trade offs between choosing different consistency models such as strict consistency, eventual consistency. You’ll end the semester with learning about the infamous CAP theorem and FLP theorem and how, as a system designer, you’ll make trade offs between consistency, availability, and the ability to withstand network partitions. Of course, you’ll eat and breathe Leslie Lamport’s PAXOS. So if any of these topics interest you, you’re in for a treat.

    Cons

    • Bleeding edge course means that there were lots of rough edges
    • Projects were very demanding, often requiring multiple hours to pass a single test worth very little towards grades
    • Triggered lots of uncertainty and desperation among students throughout the second half of the semester

    As mentioned above, this class induced a lot of unnecessary stress in students. Even for someone like me, who cares less about the actual letter grades on transcripts, felt pretty anxious (this class potentially could’ve held me back another semester, since up until the grades were actually released, I had assumed I would get a C or lower).

    Impact on mental health

    One concerned students published a post on the forum, asking if students were mentally okay:

    I just wanted to check in with everyone on here in the class. I know these projects are stressful and for me it’s been something of a mental health hurdle to keep pushing despite knowing I may very well not succeed. Hope everyone is doing ok and hanging in there. Remember no assignment is worth your sanity or mental health and though we are distanced we are all in this together.

    Anonymous Calc

    Many other students chimed in, sharing their same frustrations

    I found both of the projects very frustrating. Specially this one. I am working for last 2 weeks (spending 50+ hours in writing/rewriting) and still passing only 7/8 tests. I never had unfinished academy projects. This is the first course I am having this.

    Adam

    I couldn’t help but agree:

    Honestly, I was fairly stressed for the past two weeks. Despite loving the course — content and rigor of the project — I seriously contemplated dropping the course (never considered this avenue before, and I’m 2 courses away from graduating after surviving compilers and other difficult systems courses) as to avoid potentially receiving a non-passing grade (got an A on the midterm but its looking pretty bleak for Project 4 with only 12 tests passing). At this point, I’ve fallen behind on lectures and although there is 1 (maybe 2) days left for Project 4, I’ve decided to distance myself from the project. Like many others, I’ve poured an insane number of hours into this project, which doesn’t reflect in the points in Gradescope. I suspect both the professor and the TAs are aware of the large number of people struggling with the project and will take this all into account as part of the final grading process.

    Tips

    Programming Projects

    Here’s a list of the projects, their weight towards the final grade, and the amount allocated to each assignment.

    • Project 1 – Environment Setup – 5% – 2 weeks
    • Project 2 – Client/Server – 10% – 2 weeks
    • Project 3 – Primary/Backup – 15% – 3 weeks
    • Project 4 – PAXOS – 15% – 3 weeks
    • Project 5 – Sharded KV Store – 15% – 4 weeks

    Project 1 and 2 are a walk in the park. The final 3 projects are brutal. Make sure you start early, as soon as the projects are released. I repeat: start early. Some people reported spending over 100+ hours on the latter projects.

    Unless you are one of the handful of people who can pour in 50+ hours per week in the class, do not expect to get an A on the programming projects. But don’t sweat it. Your final grade will be okay — you just need to have faith and ride the curve. All you can do is try and pass as many tests as possible and mentally prepare for the receiving a C or D (or worst) on these assignments.

    Summary

    The course is solid but needs serious tweaking around the pacing. For future semesters, the instructors should modify the logistics for the programming assignments, stealing a couple weeks from the first couple projects and tacking them on to final projects (i.e. Primary/Backup system, PAXOS, Sharded Key-Value Store). With these modifications, students will stress out way less and the overall experience will be much smoother.

     

  • Distributed Computing – Goodbye and thanks for the wonderful semester

    Distributed Computing – Goodbye and thanks for the wonderful semester

    I just finished Spring 2021 at Georgia Tech OMSCS and published a farewell note on the classroom’s forum (i.e. Piazza platform) and would like to share that here:

    This was one hell of a semester! Hats off to professor Ada and our great TAs — I learned a great deal about both theoretical and practical distributing computing knowledge, experiencing first hand how tweaking a retry timer by a few hundred milliseconds can make or break your day.

    But above all else, thanks to all the other students in this class, I felt extremely supported, more supported than any of the 8 courses I had previously taken in the program.

    More than once throughout the class I contemplated just throwing in the towel. The last couple projects in particular really wore me out mentally and emotionally (e.g. 10 hours troubleshooting for a one-line fix to pass one single test) and if it wasn’t for the constant support of all my peers over Piazza and Slack, I would’ve probably not only dropped from the course but the journey itself would’ve felt a lot more isolating, especially in the midst of the pandemic.

    Now, there are definitely rough edges with this course, particularly around pacing on the last couple projects. But given that this was the first semester that distributed computing was offered as part of OMSCS, I anticipated minor bumps coming into this class and have no doubts that the logistics will get smoothed out over the next couple semesters.

    Finally, for those of you graduating this semester, congratulations! Way to go out with a bang. And for the rest of us, see you next semester!

    Thanks again for all the support and let’s stay connected (contact info below). Now, time for a much needed nap after taking the final exam:

  • What are good models and what models are good?

    What are good models and what models are good?

    Schneider, F. B. (1993). What good are models and what models are good. Distributed Systems, 2, 17–26.

    Paper Summary

    In his seminal paper on models (as they apply to distributed systems), Schnedier describes the two conventional ways — experimental observation; modeling and analysis — we normally develop an intuition when studying a new domain. And for the remainder of the paper, he focuses on modeling and analysis, directing our attention towards two main attributes of distributed systems: process execution speeds; and message deliver delays. With these two attributes at the forefront of our minds we can build more fault-tolerant distributed systems.

    Main Takeaways

    The biggest “ah hah” moment for me was while reading “fault tolerance and distributed systems”. In this section, Schneider suggest that system architects should, from day one, focus their attention on fault-tolerance system architectures and fault-tolerant protocols, with an eye towards both feasibility and cost. To build fault tolerant systems, we should physically separate and isolate process, connect process by a communication network: doing so ensures component fails independently. That’s some seriously good intuition; I hope to incorporate those words of wisdom as I continue to learn about distributed and as I design my own distributed systems.

    Great Quotes

    In a distributed system, the physical separation and isolation of processors linked by a communications network ensures that components fail independently.”
    One way to regard a model is as an interface definition—a set of assumptions that programmers can make about the behavior of system components. Programs are written to work correctly assuming the actual system behaves as prescribed bythe model. And, when system behavior is not consistent with the model, then no guarantees can be made

    Notes

    Defining Intuition

    Distributed systems are hard to design and understand because we lack intuition for them
    When unfamiliar with a domain, we can develop an intuition for it in one of two ways:
    • Experimental observation – build prototype and observe behavior. Although the behavior in various settings might not be fully understood, we can use the experience to build similar systems within similar settings
    • Modeling and analysis – we formulate a model and then analyze model using either mathematics or logic. If this model reflects reality, we now have a powerful tool (a model should also be both accurate and tractable)

    Good Models

    What is a model?

    Schneider’s definition of a model is as follows: collection of attributes and a set of rules that govern how these attributes interact. Perhaps as important (if not important) is that there’s no single correct model for an object: there can be many. Choosing the right model depends on the questions we ask. But regardless of which specific model we choose, we should should choose a “good model”, one that is both accurate and tractable. Accurate in the sense it yields truth about the object; tractable in the sense that an analysis is possible.

    What questions should we ask ourselves as we build distributed systems?

    While modeling distribution systems, we should constantly ask ourselves two questions: what’s the feasibility (i.e. what types of problems does this solve); and cost (i.e. how expensive can the system be). The reason we ask ourselves this question is three-fold. First, we don’t want to try to solve an unsolvable problem “lurking beneath a system’s requirements”, wasting our time with design, implementation, and testing. Second, by taking the cost into consideration up front, we can skip choosing protocols that are too slow or too expensive. Finally, with these two attributes in mind, we can evaluate our solution, providing a “yardstick with which we can evaluate any solution that we devise.”

    Why is studying algorithms and computational complexity insufficient for understanding distributed systems?

    Although studying algorithms and computational complexity address two above questions (feasibility and cost), it ignores the subtle nuances of distributed systems. Algorithms and computational complexity assumes a single process, one that is sequential in nature. But distributed systems are different: multiple process communicating over channels. Thus, we need to extend our model to address the new concerns.

    Coordination problem

    I’m hoping I can update this blog post’s section because even after reading this section twice, I’m still a bit confused. First, I don’t understand the problem; second I don’t understand why said problem cannot be solved with a protocol.

    Synchronous vs. Asynchronous

    Why should we distinguish synchronous systems from asynchronous ones?

    It’s useful to distinguish a synchronous system versus a asynchronous system. In the former, we make assumptions: speed of system is bounded. In the latter, we assume nothing — no assumptions about neither process execution nor message delivery delays.

    Author makes a super strong argument in this section, saying that ALL systems are asynchronous, and that a protocol designed for a asynchronous system can be used in ANY distributed system. Big arguments. But is this true? He backs his claim up by saying that even processes that run in lockstep and message delivery is instantaneous still falls under the definition of a asynchronous system (as well as synchronous system).

    Election Protocol

    What can we achieve by viewing a system as asynchronous?

    By no longer viewing a system as synchronous sand asynchronous instead, we can employ simpler or cheaper protocols. The author presents a new problem: N processes, each process Pi with a unique identifier uid(i). Create protocol so all processes learn leader.

    According to the author, although we can solve the problem easily, the cost is steep: each node broadcasts its own uid.

    So how can we solve the election protocol assuming a synchronous system?

    We can define a τ to be both 1) greater than largest message delivery delay; and 2) largest difference observed at any instant by reading clocks. Basically, we use a constant and each process will wait until τ * uid(i) before broadcasting. In other words, the first process will broadcast and the messages will arrive at all other nodes before the second node attempts to sends a second broadcast.

    Failure Models

    When trying to understand failure models, we assign faulty behavior not by counting the occurrences, but by counting the number of components: processors and communication channels. With this component counting approach, we can say a system is t-fault tolerant, a system continuing to satisfy its specifications (i.e. keeps working) as long as no more than t of its components fault. This component driven concept is novel to me and forces me to think

    Why is it important to correctly attribute failure?

    The author states that we need to properly attribute failure. He provides an example on message loss. A message can be loss due to electrical issues on the channel (i.e. blame the channel) or maybe due to a buffer overflow on the receiver (i.e. blame the receiver). And since replication is the only way to tolerate faulty components (I’d like to learn more about this particular claim), we need to correctly attribute fault to the components because “incorrect attribution leads to an inaccurate disattributed system model; erroneous conclusions about system architecture are sure to follow”.

    What are some of the various models?

    He then talks about the various failure models including failstop, crash, crash+link, and so on. Among these failures, the lease disruptive is “failstop” since no erroneous actions are ever taken place.

    Although it may not be possible to distinguish between a process that has crashed versus a process that’s running very very slowly, the implications and distinctions are important. When a process has crashed, other processes can assume the role and responsibility, moving forward. But, if the system respond slowly and if the other processes assume the slow process’s responsibilities, we are screwed: the state of the world loses its consistency.

    When building failure models, how deep in the stack should we go? Should we go as far as handling failures in the ALU of a processor!? Why or why not?

    We don’t want to consider a CPU’s ALU failing: it’s too expensive for us to solve (which relates ot the two attributes above, feasibility and cost); in addition, it’s a matter of abstractions:

    A good model encourages suppression of irrelevant details”.

    Fault Tolerance and distributed systems

    As the size of a distributed system increases, so does the number of its components and, therefore, so does the probability that some component will fail. Thus, designers of distributed systems must be concerned from the outset with implementing fault tolerance. Protocols and system architectures that are not fault tolerant simply are not very useful in this setting

    From day one, should think about fault tolerance system architectures and fault tolerant protocols.But he goes on to make another very strong claim (probably backed up too), that the only way to achieve fault tolerance is by building distributed systems (really, is it?!).

    In a distributed system, the physical separation and isolation of processors linked by a communications net-work ensures that components fail independently.

    This makes me think about systems that I design. How do I model and design systems such that I encourage process and communication boundaries, so I clearly understand the failure models. This is why it is so important for control plane and dataplane separation. It’s another way to wrap our minds around failure scenarios and how system will react to those failures.

    Which model when?

    Although we should study all the models, each model “idealizes some dimension of real systems” and it’s prudent of us to understand how each system attribute impacts the feasibility or cost — the two important benchmarks described earlier.

  • Distributed Computing – Lesson 1 Summary

    Distributed Computing – Lesson 1 Summary

    Summary

    Distributed systems are everywhere: social media, internet of things, single server systems — all part of larger, distributed systems. But how do you define a distributed system? A distributed system is, according to Leslie Lamport (father of distributed computing), a system in which failure of some component (or node) impacts the larger system, rendering the whole system either unstable or unusable.

    A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable – Leslie Lamport

    Lesie Lamport. Source: https://www.heidelberg-laureate-forum.org/laureate/leslie-lamport.html

    To better understand distributed systems, we can model their behaviors using nodes and messages. Nodes send messages to one another, over unreliable communication links in a 1:1 or 1:N fashion. Because of the assumed flaky communication, messages may never arrive due to node failure. This simple model of nodes and messages, however, does not take the nodes capturing events into consideration; for this, our model must be extended into a slightly more complex one, introducing the concept of “state” being stored at each node.

    When evaluating distributed system, we can and should leverage models. Without them, we’d have to rely on building prototypes and running experiments to prove our system; this approach is untenable due to issues such as lack of resources or due to the scale of the system, which may require hundreds of thousands of nodes. When selecting a model, we want ensure that it can accurately represent the problem and be used to analyze the solution. In other words, the model should hold two qualities: accurate and tractable.

    Using Models. Source: Georgia Tech

    Building distributed systems can be difficult for three reasons: asynchrony, failures, consistency. Will a system assume messages are sent immediately within a fixed amount of time? Or will it be asynchronous, potentially losing messages? How will the system handle the different types of failures: total, grey, byzantine (cannot tell, misbehaving) ? How will the system remain consistent if we introduce caching or replication? All of these things are part of the larger 8 fallacies of distributed computing systems.

    CAP Theorem. Source: Georgia Tech

     

    Ultimately, when it comes to building reliable and robust systems, we cannot have our cake and eat it too. Choose 2 out of the 3 properties: consistency, availability, partitioning. This tradeoff is known as CAP theorem (which has not been proven and is only a theorey). If you want availability and partitioning (e.g. cassandra, dynamodb), then you sacrifice consistency; similarly, if you want consistency and partitioning (e.g. MySQL, Megastore), you sacrifice availability.

    References

  • Failure: I want more of it.

    Failure: I want more of it.

    Students in the Georgia Tech program collaborate with one another — and collaborate with professors and teacher assistants — through a platform called Piazza. But at the end of the semester, this forum shuts off to read only mode, meaning we all lose connection with one another.

    Because of this, I recently created an e-mail list called computing-systems@omscs-social.com for other Georgia Tech Students who are interested in staying in touch. The motivation behind the mailing list is to share job opportunities, connect with other working professionals, and perhaps most important: provide peer support for one another. This felt like a natural next step since the study sessions (called “war rooms”) that I hosted were pretty successful.

    Piazza post. 70 views. 1 sign up

    But after posting a link on Piazza and sharing the idea, only 1 out of 70 people signed up. Total failure, right?

    Sort of.

    The lack of people signing up for the mailing list reaffirms two of my believes. First, the entire notion of “build it and they will come” is not true. Especially as software developers, we know that we can build the most shiny, most magical, most performant piece of software … and nobody can care.

    The second belief is that failures are a good thing. According to the late Randy Pausch, these setbacks are what we likes to call brick walls:

    The brick walls are there for a reason. The brick walls are not there to keep us out. The brick walls are there to give us a chance to show how badly we want something. Because the brick walls are there to stop the people who don’t want it badly enough. They’re there to stop the other people.

    – Randy Pausch

    In order to grow, you need to fail — a lot — because there’s no linear path to success.

    You can see this pattern of trial and error with Josh Pigard’s most recent venture that he recently sold for $4 million: big success, right? Yes, definitely.

    But notice all his other failed projects listed on his personal website.

    Josh Pigard – projects that were shut down

    On some level, the above are considered failures since the projects ultimately shut down. But that’s not how I see it. I’d like to think that Josh learned a lot of things from those failures, which fed and led him to building and selling his company.

    From this example alone, I think I can take away a lot of lessons learned. In particular, like my wife,  I am a perfectionist. I want — sometimes need — things to be perfect. But that’s surface level, only what maybe the outside can see. There’s a shadow side.

    Really, like many others, I have imposter syndrome. I’m constantly worried that I’m going to get exposed as some sham. My response to imposter syndrome? Striving to be right all the time. And I believe that taken too far, trying to be right all the time can stunt growth because to grow — personally and professionally — I need to constantly be experimenting, tinkering, trying out things that might just fail.

    To wrap things up: will I shut down and abandon the mailing list? Maybe. Maybe not.

     

  • Weekly Review – Week ending in 2020/11/01

    Weekly Review – Week ending in 2020/11/01

    No Halloween this year

    I used to love Halloween growing up, not so much the dressing up part but the knocking on doors and getting handed fist fulls of candy. Now, as an adult, I love returning the favor and always think about giving out larger than average candy and chocolate.

    But not this year, thanks to COVID-19.

    Hopefully 2020 will be the one and only year that we skip Halloween …

    Starting writing my first e-book

    I’m compiling all my blog posts on “advanced operating systems refresher” into a single, nicely formatted e-book. The book will provide a summary and detailed notes on Udacity’s Advanced Refresher course.

    Media Consumption

    Watched the first two episodes of “This is Us”. Again, as I mentioned in my blog posts, the writer’s (and cast and crew) deserve a huge applaud for pivoting and incorporating two major events in history — the COVID-19 pandemic and police brutality on black lives — into the story line. That’s no easy feat but they are pulling it off.

    Watched Borat subsequent film. I found the film hilarious and ingenious. Reveals how complicated people can be. For example, two trump supporters end up taking Borat into their homes and at one point, they even speak up on behalf of women.

    Home Care

    I’m super motivated keeping our new home in tip top shape. I had learned that the previous owner’s took a lot of pride in the house, the retired couple out in the front or back yard on a daily basis, the two of them maintaining the lawn and plants.

    Learning how to take care of the lawn. That includes learning the different modes of mowing (i.e. mulching, side discharge, bagging), the difference between slow release and fast release nitrogen, the importance of aerating, the importance of applying winterizer two weeks before the last historical freeze day, how to edge properly and so on.

    Family

    Still working from home and still appreciate the little gestures from Jess throughout the day. I sometimes get lost in a black hole of thoughts and troubleshooting, not drinking any water or eating snacks for hours at a time. So the little snacks that Jess drops off go a long way.

    Health

    Although taking care of mental health, not so much physical health. Only exercised once last week which was basically jogging on the treadmill.

    Graduate School

    Applied theory of lightweight recoverable virtual machine to work. In advanced operating systems, I took the concept of the abort transaction and suggested that we install a similar handler in our control plane code.

  • Five tips for surviving (or thriving) in the OMSCS program as a computer science graduate student

    Five tips for surviving (or thriving) in the OMSCS program as a computer science graduate student

    Overview

    In this post, I’m sharing five tips that I’ve picked up over the last 2 years in the program. At the time of this writing, I’m wrapping up my 7th course (advanced operating systems) in the OMSCS program. This means that I have 3 more courses to complete until I graduate with my masters in computer science from Georgia Tech.

    This post assumes that you are already enrolled as a student in the program. If you are still on the fence as to whether or not you should join the program, check out Adrian’s blog post on “Georgia Tech Review: yes, maybe, no”. Very shortly, I’ll post my own thoughts and recommendations on whether or not I think you should join the program.

    Five Tips

    Prerequisites

    Before enrolling in a course, check the course’s homepage for recommended prerequisites. Once you are officially accepted into the program,  you’ll soon discover that unlike undergraduate, you can enroll in courses despite not meeting prerequisites. The upside of this relaxed approach is that students who are really eager to take a course can do so (assuming seats are available). The downside is that if you are not prepared for the course, you’ll be way in over your head and likely will drop the course within the first few weeks since many courses are front loaded.  For example, thinking about taking advanced operating systems? Before jumping the gun, take the diagnostic exam. Doing so will help you gauge whether or not you set up for success.

    Time management

    Manage your time by setting and schedule and sticking to it. If you are an early bird like me, carve out 50 minutes early in the morning, take a shot of your expresso, and get cracking.  Set specific times in which you will sit down and study (e.g. watch lectures, review notes, work on a project) and aim to stick to that schedule (as a new parent, I understand that plans often can easily be foiled).

    Trade offs

    Know when and what to slip or sacrifice. This is super important. We all 24 hours in a day. And we all have other responsibilities such as a full time job or children to take care of. Or something unexpectedly will just pop up in your life that demands your attention. That’s okay. Graduate school (and doing well in graduate school) is important. But there will be other competing motivators and sometimes, you’ll have to sacrifice your grade. That’s okay.

    Expectations

    Know what you want to get out of the program. What are you trying to get out of the program? Or what are you trying to get out of the current course you are enrolled in? Are you here to learn and improve your craft? Then focus on that. Or are you here to get a good grade? Then do that. Are you here to expand your network and potentially apply to a PhD program? Then make sure you attend the office hours and meet with the professors.

    Course reviews

    Read the reviews on OMSCentral.  If you haven’t read reviews on OMSCentral.com for the courses you plan to take (or are currently taking), please go and do that. Right now. On that website, you’ll find reviews from former students. They give you a better sense of what you’ll learn, what projects you’ll tackle, how engaged the professor is , whether the grades are curved, how difficulty the exams are, and maybe most important: how many hours you should expect to put into the course.

    Notifications

    Create e-mail (or text) notifications in your calendar for upcoming due dates. It sucks when you forget that an upcoming assignment is due soon. Sucks even more when you find out that the due date has passed. Although you can rely on Canvas (Georgia Tech’s current system for managing their courses), I still recommend using your own system.

    Summary

    The above tips do not guarantee a smooth journey. Chaos will somehow creep its way into our time and things will get derailed. That’s okay. Take a deep breathe and revisit the tip above on prioritization. Remind yourself why you are in graduate school. Now go out there and kick some ass.

  • Finally clean air & Daily Review – Day ending in 2020/09/18

    Finally clean air & Daily Review – Day ending in 2020/09/18

    Hooray! Today is the first day in a couple weeks that air quality is considered good, at least according to the EPA. I’m so pleased and so grateful for clean air because my wife and daughter have not left the house since the wild fires started a week ago (or was it two weeks — I’ve lost concept of time since COVID hit) and today marks the first day we can as an entire family can go for a walk at a local park (it’s the little things in life) and breathe in that fresh, crisp pacific northwest air. Of course, we’ll still be wearing masks but hey, better than staying cooped up inside.

    Yesterday

    What I learned yesterday

    • Static assertion on C structures.  This type of assertion fires off not at at run-time but at compile time.  By asserting on the size of a structure, we can ensure that they are sized correctly. This sanity check can be useful in situations such as ensuring that your data structure will fit within your cache lines.

    Writing

    • Published my daily review that I had to recover in WordPress since I had accidentally deleted the revision

    Best parts of my day

    • Video chatting at the end of the work day with my colleague who I used to work with in Route 53, the organization I had left almost two years ago.  It’s nice to speak to a familiar face and just shoot the shit.

    Graduate School

    • Finished lectures on barrier synchronization (super long and but intellectually stimulating material)
    • Started watching lectures on lightweight RPC (remote procedure calls)
    • Submitted my project assignment
    • Met with a classmate of mine from advanced operating systems, the two of us video chatting over Zoom and describing our approaches to project 1 assignment

    Work

    • Finished adding a simple performance optimization feature that takes advantage of the 64 byte cache lines, packing some cached structs with additional metadata squeezed into the third cache line.

    Miscellaneous

    • Got my teeth cleaned at the dentist. What an unusual experience. Being in the midst of the pandemic for almost 8 months now I’ve forgotten what it feels like to talk to someone up close while not wearing a mask (of course the dentist and dental hygienist were wearing masks) so at first I felt a bit anxious. These days, any sort of appointments (medical or not) are calculated risks that we must all decide for ourselves.

    Today

    Writing

    • Publish Part 1 of Barrier Synchronization notes
    • Publish this post (my daily review)
    • Review my writing pipeline

    Mental and Physical Health

    • Slip on my Freebird shoes and jog around the neighborhood for 10 minutes. Need to take advantage of the non polluted air that cleared up (thank you rain)
    • Swing by the local Cloud City coffee house and pick up a bottle of their in house Chai so that I can blend it in with oat milk at home.

    Graduate School

    Organization

    • Review my tasks and project and breakdown the house move into little milestones

    Family

    • Take Mushroom to her grooming appointment. Although I put a stop gap measure in place so that she stops itching and wounding herself, the underlying  issue is that she needs a haircut since her hair tends to develop knots.
    • Walk the dogs at either Magnuson or Marymoore Park. Because of the wild fires, everyone (dogs included) have been pretty much stuck inside the house.
    • Pack pack pack. 2 weeks until we move into our new home in Renton. At first, we were very anxious and uncertain about the move. Now, my wife and I are completely ready and completely committed to the idea.