New Year Resolutions: 2018

New year resolution has sort of become a joke in recent years, referencing plans people set at the start of the year and unavoidably fall short at the end of year. Though probably true, I still maintain that setting goals is helpful, in that they orient one’s focus and efforts. Personally I have been doing this privately for the past few years, and I am quite happy that every year I have managed to achieve most of them. This year in the spirit of getting more visibility and accountability I plan to write out some of the goals I set for the year, which I shall review at the end of 2018.

Most of the goals in this post are somewhat related to software development, for privacy concerns. 😉


Real life project

If you have been here for a while, you will know I have started an AngularDart series, in which we build a web chat app called Teamoji. Currently the app is only about 50% done, and the first goal of the year is to finish the project and blog series, also launch it online.

Personally I have virtually no experience in devops. (The last time I deploy code is through a FTP server) So this would be an interesting experience to go through. I will certainly blog about this as we progress. I have set up a list of TODOs for this project and we will follow it.

Taking it further

Once the web app is online, I would like to do a follow-on project to make a mobile app for it as well. For a very time I have been interested in Flutter and this would a perfect sized app to adopt. I will devote a separate post to this once we finish the web app.

Going deeper into Backend

After half of a dozen front end heavy projects, I suddenly realized how unfamiliar I am with backend. Over the past year when I was using Node for my uni honors project, I found myself very confused at times and had to rely quite heavily on online help. This year I plan to vastly expand my backend knowledge, through a series of side projects, focused on API building. Since this part is mostly personal learning, through a lot of existing materials, I would not be publishing relevant posts.

Distributed Systems

Over the last year we saw a burst in cryptocurrency, most famously Bitcoin. Personally I have been very interested in Distributed Systems, ever since I took a relevant class at UNC.

This year I would like to allocate time for 2 full system building projects, one centralized and one decentralized. The specific projects are TBD, and as usual I will write up individual posts when I start the project.



Over the past year I have only read 5 books from start to finish, partly because of laziness, and ignorance of the value of reading. In 2018, I plan to read 10 fictions. (Yes you heard that right) When I look at my bookshelf, it is very clear most of the books I have read are technical, or relevant to the tech business. In the interest of balance, I figure it is time to pay more attention into fictions. If you have a suggestion, please let me know. There are still quite a few empty slots.

This doesn’t mean I will stop reading technical books though. To finish the projects above, there’s a quite a list of books and online materials I should go through.

Giving back to the community

I have never considered myself a genius developer. Along the way I have worked very hard, but equally important, I have received countless help from my peers, mentors, and just friends. The point of this blog is to give back some of my knowledge to people just starting out their developer journey, and help someone to get through what I have been through. In 2018, I want to help more people, beyond the medium of text.

I am planning to set up a podcast for myself, to talk about my experience as a developer, and have guests to discuss various topics of software development. As you can probably guess, I have no experience in running a podcast. But over the past year I have listened to many great podcasts and I believe it is a viable medium to share knowledge and experience. If you have topics that you have to hear me talk about, please let me know, either through comments below or private messaging. As guests go, I would have mostly my friends and other developers I know, and we will see how that goes!


Wrapping up

These are my goals in 2018. They seem like a lot for sure, and frankly I am slight terrified at this point when I scroll back and read them again. However, I have confidence to knock them down, or try my best to.

Screen Shot 2018-01-07 at 20.35.00

Have a moment to think about what you want to achieve in the new year, and set up a list to track them too. It doesn’t really matter if you complete them or not; what matters is have you really tried.

Happy New Year!


Impostor Syndrome: thoughts and tips

Recently a dear friend of mine is struggling to enjoy work. As this is their first “job”, a lot of pressure, imagined or not, has become a source of great anxiety. After discussing the mental hardship during these tough moments, I can’t help by remembering how I felt in my first job. Today I want to identify this problem, explain why it exists, and what we can do to mitigate it.

Before I begin, it should be pointed that I have not taken a full-time job either, and all my experience came from previous internships. I do believe my thoughts and pointers are valid, but take it with a grain of salt just in case.

What is Impostor Syndrome

Rather than giving a formal definition about the term, which you can find here, I want to give an example to start with. Imagine you are at a party, standing in a circle of discussion. Weirdly you know all the people in the group, but just cannot understand what they are talking about. You feel a bit embarrassed to ask, so you just listen quietly, and throw in a few “that’s interesting”s. When you are on the way home, you question your intelligence and if you looked stupid at the party, and you end up hating yourself for being an idiot.


Sounds familiar? Now switch the context into an office, and you are having Impostor Syndrome now. Often times, people feel bad for themselves for not performing well at work, or not following others’ train of thought, and they feel like they are frauds, pretending that they understand things they don’t; and they are Impostor(that’s where the term comes from).

Why we have it?

First of all, looking back at my earlier jobs, it is so viscerally understandable to have the feeling that you are not as good as you think, or people expect you to be, especially for me and my contemporaries, just entering, or about to, the industry. This is not a singular problem in tech, but across pretty much any industry. Let me walk you through how a new grad walks into the trap of Impostor Syndrome, and sometimes ironically rational.

You begin your first day, surrounded by people who all have more experience than you do. You want to “prove” that you are just as good, and you start your work with the determination of “I can figure things out by myself”. Not after long you get hopelessly stuck, and after a few hours of intellectual and mental battle, you got into a position where you have to ask someone for help, but simultaneously ashamed of showing weakness. When you finally solve the problem after possibly extensive help, you escape from work, wishing people had forgotten how stupid you were today. You get home and cry in the shower, thinking “maybe I am just a fake”, and you dread showing up at work the next day. Voilà?

In my opinion, Impostor Syndrome roots essentially from a lack of confidence, specifically in the workplace. Being fresh out of college, we may sudden realize just how much we don’t know that goes into our work, and that makes us nervous, worrying others may disapprove us. I totally had a mental phase like this, and I think many people have it too. And the worst of all is, you can’t really tell anyone about this, without admitting your unreadiness for work.

Removing the mental block

I want to introduce a different way of thinking about this, which helped me to deal with Impostor Syndrome. Instead of trying to resolve it, try to admit and embrace it.

People around us at work have worked for years, if not decades, to horn their skills in real life situations, which makes them competent when we look at them. They didn’t get to this point in a day. We must understand when starting a new job, most people would objectively struggle, due to inexperience. Most importantly, there’s nothing to be shamed of for not knowing. What matters is how you deal with that.

Also you need to see your career as a process, not a static view(pardon the pun). Right now you are not good at what you do, that’s for sure; so just accept it. What keeps you moving forward is the belief that EVENTUALLY you will be good at it, as long as you put in enough effort.

You may feel that “eventually” is too far and impractical, and that’s reasonable. I cannot predict when I will become a “strong” developer, but I can make sure that I work towards it everyday. In the end, the result doesn’t matter; what matters is the journey you take, and if you enjoyed it.

Some practical tips

If you have something like what I described before at work, try this tomorrow. Forget you are an employee, and think of yourself having a “behind the curtains” look into what smart people do at work. Simply observe and appreciate their work process, and absorb a bit to improve yourself. The trick here is you remove yourself from comparing against your colleagues, and move to appreciate them and in term you will appreciate too.

There’s a more readily applicable tip about Impostor Syndrome I feel like bringing up, and that’s talking about it. Yes it is embarrassing, but honestly talking about it with people you trust helps a lot, even if they just simply listen and nod. I am very lucky to have someone to share my fears and anxieties. And guess what? I can return the favors in the same fashion. Find a friend to talk about it, and offer to listen when they need too. When one mind can’t take, find another one.


I hope this helps you in accepting your weakness and finding ways to improve it. If you want to discuss the details, PM me on twitter and we can talk about it more in detail.

Tl;dr. Trust that you are awesome!


Back to Edinburgh: a short reflection

It’s been such a LONG time! I must start with an apology: I stopped updating here for about a month and a half by now. Previously work was a bit too much that I couldn’t spare enough time for blogging and I didn’t want to write anything not worth reading. Since I have finished work by now, and I will be moving into my new place in a couple of days, it seems right to get back to the site, and we will have our weekly posts as usual from now on.

So today I would like to write about what I did in the summer. For those of you not that familiar with me, I was working at Google London for 3 months this summer, working in the Adsense team. My project is to help people sign up in Adsense easier, to put it briefly. It was hard work all around, since this was a new team for me, with different code conventions and new technologies to learn. But in the end I was able to complete the project and produce a working demo, and hopefully my feature would be rolled out into production soon.

Even though I was glad to finish everything in time, there are a few things I definitely wish I would have known in the beginning. Fortunately, these tips might be helpful to you.


We developers are stereotyped to be unsociable, and I do have to admit that it comes with some grounds. Yes it can’t be easy to squeeze yourself into an already well-built circle, and it may feel left out. I certainly have this problem: during the internship I didn’t connect well with other interns, both for practical and mental reasons.

One day I was confiding this to a good friend, and she gave a quite profound yet meaningful response:

“You are not what you think you are; you are not what others think you are; you are that you think others think you are.”

A bit twisted I know, but let me explain. Naturally we care about what others think of us, and sometimes it is hard to do something because it may come off as stupid and we would feel embarrassed. However, a big part, if not the most important, part of “blending in” is put yourself forward. It may seem desperate and pathetic, but you must realize that these are not what you are, they are things you feel like people would think. As long as you keep a sincere interest in people and be brave to start talking, making friends is less daunting as you think.

And for what it is worth, this will be helpful to you, both professionally and in life in general. I was not aware of the importance of communication in software development until quite recently. Even though software is something to reason about, more then often you need to present your ideas well so others can understand and therefore agree with, or bring up concerns. Take this as an example: I had a problem with a front end component during the internship, and I was explaining this to a colleague. He didn’t quite get the problem at first and asked me to elaborate further, so I did. Literally in the middle of talking I suddenly realized something I hadn’t considered before, and problem solved itself. If I were to sit silently and think about it on my own, it could easily take hours.


At first I thought this may just be something I have to watch out for, but it seems that it is more prevalent than I thought, so I want to explain this a bit. It originated from work again, when I was thinking about how to design UI for my project, I got into a debate with a colleague. We each had a different plan of implementation, and as the debate went to it was clear that his plan was better in the long term, with less maintenance and high extensibility. Yet, as stupid as it may be, I wasn’t quite ready to drop my plan, kept stating it would be easier to implement and the potential problems are only potential, and we have other mechanisms to guard against them.

In the end, I was persuaded to adopt the other plan, but there’s something quite interesting to discuss here. Even though my idea was logically suboptimal, it was still hard for me to completely discard it, simply because it was my idea. We all have, more or less, some self-righteousness to insist on our ideas, whether or not they are actually good ideas. And this goes back to what I was talking about earlier, if we admit our ideas are bad, that kind of implies we are not clever as we claim, and that hurts our faces.

But there’s a caveat here, ignored by many people: you intellect, if can be reflected, should only be reflected by your best idea, not worst. Therefore, if you do come up with a bad idea, it doesn’t mean you are stupid as well.

Take Google as an example. Over the years they have made some bad decisions as well, investing on products that never actually got on. Yet, nobody can denied the brilliance of its search algorithm, and few competitors are even present in this field. Certainly it is a bit off to compare a company to a person, but you get the idea.

Last few words

Hopefully the things I discussed above helped you in some way. Let me know if you have something to add, or if you disagree with some of the things I mentioned. Next week we should be back with a technical post. Have a great week, and I will see you soon!

Mid-year reflection: 2017

It’s been a long time. I must start this post with an apology. Every semester then finals are close, it becomes hard for me to keep writing. Fortunately now that finals are behind, and a nice summer is coming, I will be back on my weekly posting schedule, sort of. I will explain this in the end.

So finals are done, time to pack up and leave school, and in my case, the US. This year of exchange has finally come to an end, and truthfully I am more than glad to have come to UNC. I have had the fortune to learn many new technologies, and more importantly, meet many more great developers along the way. I won’t mention names, but please know that I thank you all for this hard but rewarding year.

With that said, today I would like to do a mid-year reflection on myself, particularly in the technical side. I will talk about things I did in these 5 months, stuff I learned, and finally my plan for the rest of 2017. So let’s jump right in.

Compiler: a regret

If you recall my post at the start of year, I listed the classes I am taking. Now I want to look back and see the result. Sadly, I have to admit that the compiler class didn’t turn out to be too great for me. The main goal of the class is to build a mini-Java compiler in Java. The reason I wasn’t happy with the class has nothing to do with that per se, the project is well constructed and clearly defined. I am a bit upset because I cannot take pride in my final code. As a developer, one should take responsibility, and pride in their codebase. If you don’t even like your own code, it seems unlikely for others to like it either. For the second half of the project, I went with a less-optimal architecture, and found out it was too late to change it later. Also, I wasn’t able to put in enough time and effort in development and testing. Overall, as the title suggested, compiler finishes with a regret. Ideally I would like to re-do the project sometime in the summer.

Nevertheless, I have put up the current codebase on github, for those of you who are interested.

Serious Games: eye opener

In my serious game class, the main goal is to create a playable game with serious purpose for our client. My project is to create a game that lets players caption images, which in term builds into a training set for machine learning research. You can sign up and play out game here.

Screen Shot 2017-05-09 at 13.50.33

For this project I was in charge of backend and database. I went php, mostly because it has a nice interface with MySQL. Everything is hosted on the CS department, except for the images, which come from mscoco. I did a full ORM layer between SQL and the API as well. Overall, I think I did ok with this project.

What’s interesting with this project comes from two places. One, in order to engage viewer, my colleague designed a robot character that goes along the game, and talks to play every now and then. The dialogue was designed to be funny but also helpful. I was amazed by how much those dialogues worked in our presentation round. People seemed to really like it. Personally I would never be able to write those up, partly because I am not really a humorous person, but also the sheer difficulty to construct the dialogues. Bottom line is, in game design a creative mind is very important, if not necessary.

The other bit that really shocked me is our front end dev Aaron, who mocked the prototype in a week, with pure Javascript, not even jQuery. Because I did some front end work in the past year, I know how hard it is to even simply layout a few divs like I want. Aaron did not only that in a flush, but also added audio, fancy animations, and navigation tabs, many of which I have no idea how to implement. I am very lucky to be have access to his source code, and I plan to thoroughly read it during the summer.

Our source code can be found on github as well.

Distributed Systems: into the weeds

The most challenging class of this semester. The class started with 35 people, and ended with 15 or so. We did a lot in this class: Java NIO, RMI, and a special RPC implemented our professor, called GIPC. My friend John has a nice post on RPC, and I encourage you to read it.

We also learned about consensus mechanisms, with Paxos algorithm as the most complicated one. To give a short description, Paxos is an algorithms sued to achieve a certain level of consistency over many participants. John also has a Paxos implementation and illustration online, if you are interested to learn more about it.

My own code can be found on github too. I also explain each assignment and implementation plan in README.

Datacenter: learning to be a researcher

Being a graduate level class, this one focuses on high level architectures employed in datacenter. The topic ranges from intra-datacenter networking to database architecture, to real time analysis, and so on. I learned some basic MapReduce, which I did a post already. The project is to find a dataset online and do some analysis with it. Sounds simple, but it is not that easy when I actually sat down and try to implement. In the end I chose to analyze a very little subset of the data, and draw observations from that. You can my code on github. I also included the research paper, which is part of the project.

Plans coming up

Unfortunately after this post I will be absent for another 3 weeks, due to family visit and some other personal business. At the start of June I will go back to London and restart our schedule. In terms of topic, I plan to do series on dartlang, a language I have talked on the site before. This time I want to go deeper and try to write some short tutorials on how to design and implement a web/mobile app quickly and effectively. So stay tuned on that. In the meantime, if there’s a topic you want me to talk, technical or not, feel free to leave it down in the comments, or reach out to me on Twitter.

In terms of what I planned for the rest of 2017 personally, I will do a separate post on that topic, given this post is already long enough. 🙂

Lastly, I am happy to go through everything over the past year. I look forward to going back to Britain and seeing old friends too. Hope you all have a nice summer, and I will see you in three weeks!


Handling a mess: a little reflection

First of all, I am quite sorry about not posting anything for the past few weeks. I was occupied by school and left for San Fransisco for my spring break. Fortunately, because of that trip, I had a great topic to write about today. When I was on the plane back home, I kept thinking about all the stuff I have to in the coming few days: finishing 3 school deadlines, signing a new contract with my employer, following up on other side projects, and writing this very blog no less!

Now it’s Sunday about noon, and I feel surprising good about handling these tasks, and same for the coming week. So I want to talk about how I manages this mess in the past 4 days, and hopefully you can learn something from it.


This is, in my opinion, what makes the most difference between success and failure. When under a lot of stress from many sides in life, we are prone to want to start away, clearing that pile of work as soon as possible. Despite out best wishes, this would actually make things slower.

My feeling is, when you are just “going in”, usually it is with little thought about how long the task will take, what problems could occur and where you can potentially find answers, and sometimes even the fact that you can even start that task because someone else might be blocking you.

You may say: Man that’s a lot of thinking instead of doing. That’s true, but I am positive one would happy that they did all of this before starting the task. Think of it this way. You have to drive to a location, possibly in a hurry. You could just grab your keys and rush to the car and traffic, but I would check the traffic and see which way is fastest, if there’s enough gas in the car, and if not where can I get some. Think about how long this takes, compared to the time you will spend if your car runs out of gas in the middle of the way.

In my example, I spent basically an entire morning mapping out all my tasks, breaking them down to small stages, and writing them down and sticking them to my monitor.

There is something in planning that you have to pay extra effort to: Breaking things down. As a software engineer, I am sure you know the power of modularisation. Taking care of small problems and combining them later is always better than trying to take a huge problem head on. For example, when I am breaking down a task, I would do some research and think about what the little pieces are, how they combined later to work the entire thing, and write those pieces down below the task and do them one by one.

My list for the past few days. (The right one is mashed out due to client privacy)

Last but not least, always remember to leave some space in your plan, since you are very likely to have to re-plan it later.

Monolithic Mindset

Quite a fancy phase, but the idea is quite simple: only focus on one thing at a time. In the past, I had been constantly thrown off when I looked at my TODOs and saw dozens of things to clear. Honestly this is quite natural, I was under a lot of stress, but especially in that situation you want to focus on one thing more, because you have no time for mess up, even for just one little task.

Personally I believe a balance has to be reached between quality and quantity, but I lean slightly towards quality. I would sacrifice some quality of my code so that I can ship on time, but never so much that I wouldn’t want me name on that code.


These are just a few things that work for me, but I hope you can draw something from them and be more productive in work, and in term, happier in life.

As always, if you have something to differ, or you want to say a bit more about the topic, I would appreciate your comment. Have a nice week, and I will see you next week.

Building a dev team

Recently I came cross this interesting blog from Ben Halpern, talking about things to watch out when working on a side project. Although all of his points are reasonable and should be followed, one of them jumped out to me: “Start it yourself, eventually find help”. Over the side projects I have worked on with various teams, this bit is due for more elaboration, which is my goal for this blog post. Today I want to write about a few tips I learned over the years that make a successful development team.

Talk, talk, talk

From a discussion thread I followed earlier this week, developers value communication skills a lot in their peers. From a technical point of view, you want you co-workers to have clear and concise comments in code, and moreover, be able to explain things orally with a few sentences. Also when you get stuck on a tech issue, a weird bug for example, it would be wonderful if there’s someone in the team to talk to, and they may be able to shed some light to the question. As a little side note, I wrote another post earlier about “getting unstuck”, so have a read if you are interested.

From a more business point of view, communication skills are just as important too. It is crucial for everyone in the team to have some idea about what others are working on, and their progress. This is not just for management, but for developers to coordinate themselves. For example, if I am building a standard web app, I wouldn’t worry about Models and Databases if I knew backend isn’t ready yet, and more important, if I have a rough idea of where the progress is, I can preemptively integrate part of the database in, and catch bugs at an early stage, which is easier to fix.

Last but not least, and I understand this bit is kind of hard to achieve, team members should ideally build up personal relationships too. Talk about your weekend plans, and other things in life too. Personally I favour a more organic team, which feels less like a job and more like coding with friends. Let me know how you think about this in the comments, is it maybe too good to be true, or if you have seen or worked in a team like that?

You don’t need two warriors

If you have played a multiplayer game, you would know everyone in your team is here for a specific reason: warrior to be at the front slaying monsters, and healer at the back for support, for an over-simplification. In my opinion a dev team to have the same principle.

Prof. Diane Pozefsky, one of my professors at uni, has this team layout for a team of four, which I think is quite nice and effective:

  • Architect. Overall design of the system.
  • Designer. Design for UI/UX.
  • Product Manager. Contact point to client, vendor, users.
  • Writer. Keeping documentation updated.

Of course everyone still has to code; these are more like extra responsibilities for each of them. I like this structure for two main reasons: a) it separates UI design and system design, considering the fact that most developers who focus on the efficiency and layout of the codebase probably know less about what users want to see and feel. (No offense to sys design people who do) And b) you NEED someone to handle the docs. I have seen so many good projects with bad documentation, which just confuse me and make me not use their services at all.

My team build

Since most of my work is web dev, I have a slightly different team structure to the one described above. If you want to know about some web dev basics, check out Dave’s video. My team build looks at this:

  • Front end guy
  • Back end guy
  • DevOps

Which basically just follows the structure of a standard web app. Although this has worked pretty well for a few web apps I worked on, so I would personally recommend it to people starting a simple web project.

Fluid Team

I have to admit I stole this term from this blog post, which talked about having a team in which everyone can do what their want to do, and thus improve passion and the product ultimately. Personally I have a different take on the term. In an ideally fluid team, everyone should be able to help with others, or you have a “jack of all trades” in your team who works as a fluid utility member from places to places.

Now I understand that’s very hard to do, and personally I have not had the fortune to be in such a team. Let me know how you feel about this in the comment. Would you rather have work turf clearly established, or would rather have a loose border that others can come in and help, and vice versa?

Closing thoughts

When you are first starting out in the world of real projects, simply working in a team can present challenges, at along building one for yourself. My tip would be just go for some “blind match” opportunities, where a team is built randomly. This can be uni projects, hackathons, etc. When you enough experience working as a team, and you have seen each team work out or fail, you would have absorbed some idea about team building. Then try to go and have your own team. Maybe the first few would suck, but just keep going and trust you will get the hang of it. 🙂

See you all next week.

My developer life

For this week’s non-tech blog, instead of trying to give you guys any advice, I think it might be better and more down to earth to let you know how my days look like as student and software developer. Hopefully you can utilise some of it.

As mentioned before, I am still a student, not a full-time developer. It would not be fair if I say this lifestyle is a typical “developer” one. So I would like to split my days into weekdays and weekends. My weekday is more like a college student, and my weekend is more like a developer.

My desk just before writing this blog 🙂




  • 8:00 Get up
  • 8:30 Breakfast and reading
  • 9:00 Gym
  • 11:00 School(classes, meetings, etc.)
  • 17:00 Badminton training
  • 19:00 Go home and chill

Now allow me to talk about why I decide on this schedule.

First of all, I believe reading is still one of the best, if not the best, way to get knowledge. What’s why I always save 30min in the morning to read about all sorts of material. Technical, fictions, research papers, whatever. For me reading is a not only a way to learn, it’s also a way to practice staying in focus. Growing up I am a bit of a scatterbrain, always distracted by things. Sitting down and shutting off all external noises is important to my career, and could also be quite enjoyable sometimes.

Another thing you might notice is that I have a lot of physical work planned out each day, and this is not a coincidence. The work of developer is mostly sedentary, which in time is probably not so good for the body. Plus working out poses many benefits to us developers. If you go through your week with a single exercise, you might want to rethink about your schedule. Simply walking around the campus or work is better than nothing.

Last but not least, there’s almost no coding planned out, which would be a bit of shame for a developer, but please let me explain. For one, at school we are learning programming and other CS topics everyday, and I always try to squeeze an hour at night to code, sometimes more if there’s a pressing deadline. For two, and this may make a few of you angry, I think the work of a developer is a lonely one. Not many human interactions, just you typing in front of a computer. So during the week, I try to do as little coding as possible, in exchange to talking to friends, families. Personally I consider this a good trade, one has to be a human before a developer.



  • 9:00 Get up & breakfast
  • 10:00 Work
  • 12:00 Lunch break
  • 14:00 More work
  • 17:00 Dinner & rest
  • 19:00 More work
  • 21:00 Home workout
  • 22:00 Shower and chill

The premise is that I have no other plans for the weekend except for coding. This schedule looks more like a 9~5 workday for a typical developer, and allow me to elaborate.

First of all, this schedule is very work intensive under first glance, but there should be an asterisk for it. My work doesn’t only include coding, it can also be doing side projects, setting upcoming deadline and planning out work, and even writing blogs like this one. But my intention is to get a lot of coding done over weekends, because I am usually free from other businesses.

Another little fun thing to point out, and this is not really related to you, my weekend lunches and dinners are usually home-made. I quite enjoy cooking, and when there’s more time I can spend on it, I try to make some different dishes compared to weekdays. However, from time to time I still order food, especially when I am under a tight deadline.

Even in weekends I would try to get some workout done. It is usually just following home workouts on YouTube, and I will link my playlist here. Please note I only pick one or two them to do at a time, not the whole list.

Just to re-illustrate, this is not every Saturday and Sunday for me. Only when I have no other plans.


So that’s my days as a student/developer. Let me know you like it or hate it, if you have anything in common to mine, or anything you want to say. And I will see you guys next week.