Book of the Week 14: On the Shortness of Life

This week I decided to tackle on a completely different type of book from the book, going all the way back to the time of Roman philosophers. A friend had suggested trying out this short and quick philosophy book, convinced that I would love both the idea of ideas as well as the concept of making the most of our time and our lives.

This book is actually quite short – short enough to actually complete through an audiobook while I was running a half marathon this past weekend! Only about a hundred pages, or an hour of audio. Although life may (or may not!) be short, this read will clearly be worth your time investment.


Rating: 5/5

Verdict: Not much time investment needed to learn about how to invest in your time. Many concepts that people in the modern day rarely bring up.

The underlying concept in this book: Carpe diem. Seize the day. Live your life, today.

While that concept is nothing new, Seneca’s methods of the most of their lives may be. I’d like to bring up three of his main points in this review:

Life is Long Enough

It is not that we have a short space of time, but that we waste much of it. Life is long enough, and it has been given in sufficiently generous measure to allow the accomplishment of the very greatest things if the whole of it is well invested. But when it is squandered in luxury and carelessness, when it is devoted to no good end, forced at last by the ultimate necessity we perceive that it has passed away before we were aware that it was passing. So it is – the life we receive is not short, but we make it so, nor do we have any lack of it, but as wasteful of it.

I really don’t need to add any comment to this, as Seneca has so beautifully explained it himself. But from my take on this: Create an end goal, maybe a couple. Invest all your time into it. Keep at it, step by step, and eventually you’ll accomplish something greater than you could ever imagine.

Don’t wait to retire to start living your life. Start. Living. Today!

Leisure Time vs Busy Idleness

 Even the leisure of some men is engrossed; in their villa or on their couch, in the midst of solitude, although they have withdrawn from all others, they are themselves the source of their own worry; we should say that these are living, not in leisure, but in idle preoccupation.

Ever since I started working full-time, I realized just how little time I had outside of work, so I tried making every moment of my free time count. Topping the previous section of creating an end goal, I make sure that my leisure time actually goes toward a goal, instead of time wasted in busy idleness, in idle preoccupation.

Most people wind down as soon as they get back home, turning on their TV, Netflix, Facebook, etc., and just spending the rest of the day relaxing. After all, you already put in an entire eight hours of work in a day – how could you have the energy to do even more? What would make leisure time an end goal?

My leisure time tends to switch between the following:

  • Playing Super Smash Bros. I would seriously love to become a top level player, top reasons being to reach my hidden potential and to network with more people, and many people, top players and myself included, believe I can get there soon. The main point is, hobbies can be end goals too. I just make sure that every moment I spend playing the game is quality practice, analyzing my gameplay after every match to see how I can improve, one step at a time. Disclaimer: I personally can’t get into any other video games because I feel like trying to make another game an end goal is too much to juggle, and the end goal of multiple video games just starts to become an excuse to play more.
  • Reading a book. As long as the book is a different topic from the previous task I was working on, the context switching makes picking up a book easy. (For example I can’t pick up a programming book after an entire day of work in the software engineering field; those books have to wait until the weekend for me.) Simply relaxing in my bed with a book makes it great leisure. And on top of everything, I’m learning something new every evening, or outside in the courtyard at work during lunch.
  • Writing. My purpose in writing blog posts is 1) to document my learning process as I improve day-by-day as an individual, and 2) to share my stories with the world, hoping they either enjoy the content or learn something new themselves! I’m also steadily working on a book that I would like to release by the end of the year, for the exact same reasons. Just like with reading, as long as the task I work on before writing is different, the context switching makes writing a leisure activity for me.
  • Exploring. I make sure that wherever I go, I absorb as much of the environment as I possibly can. How is this place different from the places I’ve been? How do people act differently here from other places? Whether it’s just a few miles away from home or across the country, whether I’m alone or with friends, I’m always keeping an open mind, both feeding my craving of wanderlust and improving day-by-day as an individual.
  • Working out. The benefits are self-explanatory here!

It seems that my end goals tend to fall under the following when it comes to leisure: self-improvement, and socializing. Likewise, you can definitely do the same! Pick up a skill you would like to develop, whether it’s a physical skill from drawing to sports, or a social skill from communicating to planning events, there are so many choices! Remaining in idle preoccupation seems dreadful, even unimaginable, when there’s so many possibilities to bring out our greatest potential.

When to Spend Money Instead of Time

In guarding their fortune men are often closefisted, yet, when it comes to the matter of wasting time, in the case of the one thing in which it is right to be miserly, they show themselves most prodigal.

Personally I tend to be rather frugal in both time and money, but that may be just because I’m still a new grad without much money yet! Time is money, with the following exception: We can always make back money, but we can never make back time

We should consider spending money on the following things which I would think we try to be stingy on:

  • Mentorship. You can spend money to learn something in a week from a mentor instead of a year independently; that leaves 51 more weeks for other end goals. For example, people argue all the time that you can get a college education without college, but without the resources such as professors, lab materials, etc., is it worth the extra time investment of trying to do everything yourself?
  • Delegation. If you happen to have the money, or if you’re in a managerial position in a company, hire someone to do the more menial tasks: answering emails, cleaning the house, cooking, etc. I would only consider this however if you aren’t currently wasting your time in busy idleness such as watching TV.
  • Outsourcing. Alternatively, instead of menial tasks, find someone who can do a task much better and quicker than you. If becoming great at the skill is not an end goal (and according to Good to Great, if it’s not something you can be the best at, it’s not worth going for), then it is likely worth spending the money on.

This book is such a quick read, everyone should definitely give Seneca a chance. The time you gain out of reading this book will reward you tenfold. Do it, now, now, now!


Book of the Week 13: The Pragmatic Programmer

This week I’ll be covering a topic in the engineering field: the non-technical aspect of the technical field. As this is a topic that’s rarely covered (that doesn’t involve everyday soft skills such as communication and time management), I’m excited to share my review of this exclusive book.

4099Rating: 5/5

Verdict: A non-technical, technical book in software engineering; rarely done let alone rarely done well, but this book does it. Best audience is for professionals who have just started out in their career.

Having worked in the industry for a year now, I feel like now or a few months earlier would have been the perfect time to tackle this book. Andrew Hunt covers many topics that may be – or should be – commonplace to the experienced engineer, including orthogonality, design by contract, and software entropy. Despite the topics being rather introductory, I do see most of my coworkers breaking such practices, even those with over a decade of experience, so there is definitely merit in skimming through this book no matter your skill level.

In addition, despite the topics being introductory, I would suggest against reading this book if you are not yet in the work force (which includes internships). I feel that personally, having my current project in mind when reading each principle gave me a concrete image of these abstract ideas, making them easier to remember.

This book may leave you thinking “I already know all of this!” Everything is rather familiar. However, even though you may know it all, do you actually follow all the practices regularly? Most likely the answer is no, but EVEN IF the answer were yes, reading this book helps you as an experienced programmer gain perspective (see my earlier review Made to Stick and the Curse of Knowledge) of those newer to the industry. Use your knowledge to help those around you!


As usual, I’ll break up the contents by their chapters, briefly explaining the concepts from each section.

A Pragmatic Philosophy

Hunt’s definition of a “pragmatic programmer” is actually rather simple and self-explanatory, really, the things you hear everyday even outside the engineering world. Regardless, before anything else, a pragmatic programmer shall keep the following in mind above all else:

  • Take responsibility for your code. This isn’t high school.
  • Software entropy: Don’t neglect bad decisions (code, design, etc); stay on top of everything. The later you tackle problems, the faster they build up and the more difficult it becomes to clean things up.
  • Be a catalyst for change. Set an example.
  • Don’t just focus on your task; remember the big picture.
  • Always be learning. Diversify your “knowledge portfolio.” At work, take advantage of the project and work environment as much as possible. Outside of work, invest in reading books (both technical and non-technical), learn a new computer language etc.
  • Communication is, as always, key.

A Pragmatic Approach

Hunt now starts diving into the code by introducing several principles to keep in mind:

  • DRY principle: Don’t Repeat Yourself.
  • Orthogonality: Keep sections independent and decoupled (Hunt doesn’t mention this, but essentially the S in the SOLID principle). This doesn’t apply to only code.
  • Code with reversibility and flexibility in mind.
  • Iterate quickly and often.
  • Prototype to learn.
  • Learn how to estimate; iterate on estimating with the code.

The Basic Tools

Many beginners overlook the power of the tools provided to them. IDEs, debuggers, etc. Hunt enlightens the reader with the benefits of investing a little time for learning tools to increase their productivity tenfold:

  • Learn the strengths of using plain text such as XML.
  • Learn the strengths of the command shell.
  • Specialize in a single editor and learn as much as you can about it.
  • Always use source control. Not only in code.
  • Learn how to debug: fix the problem, not the blame. Be able to explain the problem to someone else – “rubber ducking.” Don’t assume anything – prove everything.
  • Learn the strengths of text manipulation languages.
  • Write code that writes code.

Pragmatic Paranoia

Hunt extensively preaches to code defensively. Code in defense against your own mistakes. Assume that the next person reading your code – even if it’s yourself – knows nothing.

  • Design with contracts: understand preconditions, postconditions, and class invariants, and design them before you tackle the code.
  • If the program breaks the contract, make the program crash early. The later the program crashes, the more potential bugs you may need to sift through, and the more the program may be working in an invalid state.
  • Use exceptions for exceptional cases. Remember that exceptions are expensive.
  • Finish what you start. Remember to deallocate when necessary.

Bend, or Break

The project must be as flexible as possible, or else it won’t survive in the long run. Hunt explains concepts on just how to do this, extending upon his concept of orthogonality and decoupled code from “A Pragmatic Approach”:

  • Make as much of the program configurable as you can, from screen sizes to algorithms.
  • Put abstractions in code. Keep details in metadata. Metadata keeps the program flexible.
  • Always design for concurrency. Keep linear thinking to a minimum, and keep in mind how to maximize parallelism.
  • Separate views (the displaying of data) from models (the data itself).

While You Are Coding

This section finally dives directly into code implementation, whereas all the previous sections were more abstract ideas to take into consideration:

  • Recognize when a program is implemented by coincidence. Program deliberately (with an understanding of all requirements, with a full design in mind, with no assumptions – but if you do make assumptions, document and test them).
  • Understand the basics of Big-O notation. Estimations will take you far.
  • Don’t hesitate to refactor. Refactor early, and refactor often. If any of the principles in this book are violated, refactor. If something is out of date, refactor. Keep software entropy in mind. Refactoring is necessary since requirements and designs are never static.
  • Don’t refactor and add functionality at the same time.
  • Ensure you have good tests and run tests often before refactoring.
  • Make code easy to test. Keeping the bullet point design with contracts in “Pragmatic Paranoia” in mind. Design to test.
  • Never use code you don’t understand. It will be difficult to debug and maintain if you don’t. If it’s difficult to understand it takes time for you to understand it, take the time to understand it, then refactor if possible.

Before the Project

What you do outside of code, before you code, is at least just as important as coding itself. Hunt emphasizes the need for taking care of prerequisites with the bullets below:

  • Seek out requirements. Don’t just let them come to you; deliberately gather as many requirements as possible before you start designing, let alone implementing.
  • Work with a user to think like a user.
  • Keep requirements abstract. Abstract requirements are more extensible and understandable to implement.
  • Maintain a glossary for your project. This glossary could be used for both front-end and back-end developers for a single source of truth.

Pragmatic Projects

How are “pragmatic” projects run? Hunt’s tips on making teams run as smoothly as possible:

  • Organize around functionality, not job roles. Remember that functionality does not necessarily mean end-user use cases.
  • Automate as many mindless tasks as possible. Manual procedures are slow and error-prone.
  • Test early, test often, test automatically. Test the tests. Once again, keep in mind software entropy.
  • Test for state coverage, not code coverage. Just because every line of code is covered in tests does not mean every possible state is. Unfortunately, no tool can determine every state for you, so this is where designing with contracts comes into play. Design those contracts as aggressively as possible.
  • Find bugs once. Time spent on finding the same bug multiple time is time wasted. Document found bugs, fix the code, fix the unit tests, fix everything to ensure that this bug will not appear anymore.
  • Build documentation with your code, don’t just use documentation as an add-on. Keep all of these programming principles in mind when it comes to documentation. Treat documentation with equal care.
  • Sign your work. Anonymity can lead to sloppiness because nobody will know you cased the problem. Be proud of the work you do, and take responsibility for the work you do.

So despite the topics of this book being so introductory, why a full five stars? Simple: How many other books are like this, let alone do it so well? Even with my lack of experience and my initial judgment saying that this felt too familiar, I had already gotten great feedback from code reviews saying that my code is a lot cleaner, as if “I had gained an extra year of experience overnight” (verbatim!).

This book breaks things down so well because the concepts are actually quite abstract, but Hunt makes the abstractions so concretely understandable (another shout-out to Made to Stick) that any programmer can benefit from this book regardless of experience.

This post may be helpful with everything being so concise, but regardless the book definitely deserves its own read. These principles will truly sink in once you dive into Hunt’s explanations, and those principles will last throughout your software engineering career.

Book of the Week 9: Soft Skills: The software developer’s life manual

This (insert length of time not being a week)’s book features a well-rounded approach to life… specifically for software developers. I’m in the software field (and just starting out too so what better time!), I read, and I’m striving for a balanced life, so of course the sheer title of this book caught my eye!

23232941Rating: 3/5

Verdict: Lots of useful points throughout the book, but too broad and too introductory.

John Sonmez has quite a resume. Aside from being a developer, he dived into the realms of bodybuilding competitions, real estate, online course content creation, and writing – both in blogging and in this book. While he doesn’t brag about these achievements in the beginning or on the cover to attract your immediate attention, you see him bringing up these chapters of his life as he gives himself credibility to this holistic message. If you’re a software developer and you could only read one book in your life, this would probably be it.

Continue reading “Book of the Week 9: Soft Skills: The software developer’s life manual”

1 Year in Software Engineering. 7 Lessons.

Early April marks the first full year of my engineering career. Having already received my annual review, I decided to start this topic early. There are SO many fundamental skills that I’ve learned that I hadn’t picked up in school or any of my past engineering jobs, and I definitely want to share them out here in the open.

Lesson #1: Explaining Design

I’ve been learning that my main flaw is trying to both understand and explain software design beyond the surface level.

Continue reading “1 Year in Software Engineering. 7 Lessons.”