Category: Reviews

• 📅 Nov 24, 2023 🏷️ Reviews · Productivity · Work

  Essentialism: A Practical Guide to Less

  I’ve thoroughly enjoyed Essentialism, a book that encapsulates the simple yet powerful notion of “do fewer things, do them well.” There’s not much else to it. While this philosophy is straightforward, it’s the way Greg McKeown presents and reinforces this message that makes the book truly compelling.

  Having Essentialism in physical form proved invaluable. I filled the margins with notes, worked through exercises alongside the text, and took the time to fully absorb the material as I progressed.

  Essentialism is not a new concept, but the key takeaway is the author’s focus on truly internalizing the message. “Focus on things that matter, trim the excess” is a simple motto to remember, yet challenging to implement. Throughout my life, I’ve adopted many of essentialist practices in one form or another, from guarding my calendar to learning to say “no” to prioritizing essential projects. However, over time, clutter inevitably creeps in.

  McKeown wisely focuses on routines that support the essentialist lifestyle, emphasizing the importance of dedicated time for reevaluation and recentering. He suggests establishing routines that prevent slipping into the frantic “onto the next thing” mentality so prevalent in the modern corporate world.

  An analogy that particularly resonated with me is the closet metaphor. While you can declutter your closet once, it will eventually refill with clothes you don’t need. To keep your closet tidy, you need to have a regular time to reevauate your outfits, know where the nearest donation center is, how to get there, and what hours is it open. Similarly, McKeown provides methodologies to regularly reevaluate our priorities, supporting the rigorous process of regularly discarding the non-essential.

  Essentialism extensively focuses on routines, practices, and exercises. The edition I read includes a “21-day Essentialism Challenge,” a helpful list of concrete activities corresponding to each chapter. While some prompts, like “take a nap” or “play with a child for 10 minutes” are a bit silly (where am I supposed to find a child on a Tuesday, Greg?), many steps effectively reinforce and integrate the material into your daily life, such as “design your ideal calendar,” “practice saying no gracefully,” or “schedule a personal offsite.”

  The latter suggestion, scheduling a personal offsite, left a significant impression on me. It’s time dedicated to strategizing around your personal and professional goals. While I occasionally reflect on my career and life, McKeown elevates this practice into a ritual – a full day focused on self-reflection, planning, and deliberate action.

  Essentialism is a helfpul book that prompts the reader to think about the routines one can put in place to change the way we approach life. It’s a reminder that less can indeed be more, and that by focusing on what truly matters, we can create a life of greater purpose, meaning, and fulfillment.

• 📅 Sep 13, 2020 🏷️ Reviews

  Vortex Core 40% keyboard

  This review is written entirely using Vortex Core, in Markdown, and using Vim.

  Earlier this week I purchased Vortex Core - a 40% keyboard from a Taiwanese company Vortex, makers of the ever popular Pok3r keyboard (which I happen to use as my daily driver). This is a keyboard with only 47 keys: it drops the numpad (what’s called 80%), function row (now we’re down to 60%), and the dedicated number row (bringing us to the 40% keyboard realm).

  Words don’t do justice to how small a 40% keyboard is. So here is a picture of Vortex Core next to Pok3r, which is an already a small keyboard.

  

  At around a $100 on Amazon it’s one of the cheaper 40% options, but Vortex did not skimp on quality. The case is sturdy, is made of beautiful anodized aluminum, and has some weight to it. The keycaps this keyboard comes with feel fantastic (including slight dips on F and J keys), and I`m a huge fan of the look.

  I hooked it up to my Microsoft Surface Go as a toy more than anything else. And now I think I may have discovered the perfect writing machine! Small form factor of the keyboard really compliments the already small Surface Go screen, and there’s just enough screen real estate to comfortably write and edit text.

  

  I’ve used Vortex Core on and off for the past few days, and I feel like I have a solid feel for it. Let’s dig in!

  What’s different about it?

  First, the keycap size and distance between keys are standard: it’s a standard staggered layout most people are used to. This means that when typing words, there is no noticeable speed drop. In fact I find myself typing a tiny bit faster using this keyboard than my daily driver - but that could just be my enthusiasm shining through. I hover at around 80 words per minute on both keyboards.

  That is until it’s time to type “you’re”, or use any punctuation outside of the :;,.<> symbols. That’s right, the normally easily accessible apostrophe is hidden under the function layer (Fn1 + b), and so is the question mark (Fn1 + Shift + Tab). -, =, /, \, [, and ] are gone too, and I’ll cover those in due time.

  On a first day this immediately dropped my typing speed to around 50 words per minute, as it’s completely unintuitive at first! In fact, I just now stopped hitting Enter every time I tried to place an apostrophe! But only after a few hours of sparingly using Vortex Core I’m up to 65 WPM, and it feels like I would regain my regular typing speed within a week.

  Despite what you might think, it’s relatively easy to get used to odd key placement like this.

  Keys have 4 layers (not to be confused with programming layers), and that’s how the numbers, symbols, and some of the more rarely used keys are accessed. For example, here’s what the key L contains:

  • Default layer (no modifiers): L
  • Fn1 layer: 0
  • Fn1 + Shift layer: )
  • Fn layer: right arrow key

  The good news is that unlike many 40% keyboards on the market (and it’s a rather esoteric market), Vortex Core has key inscriptions for each layer. Something like Planck would require you to print out layout cheatsheets while you get used to the function layers.

  

  As I continue attempting to type, numbers always take me by surprise: the whole number row is a function layer on top of the home row (where your fingers normally rest). After initially hitting the empty air when attempting to type numbers, I began to get used to using the home row instead.

  The placement mimics the order the keys would be in on the number row (1234567890-=), but 1 is placed on the Tab key, while = is on the Enter. While I was able to find the numbers relatively easily due to similar placement, I would often be off-by-one due to row starting on a Tab key.

  Things get a lot more complicated when it comes to special symbols. These are already normally gated behind a Shift-press on a regular keyboard, and Vortex Core requires some Emacs-level gymnastics! E.g. you need to press Fn1 + Shift + F to conjure %.

  Such complex keypresses are beyond counter-intuitive at first. Yet after a few hours, I began to get used to some of the more frequently used keys: ! is Fn1 + Shift + Tab, - is Fn1 + Shift + 1, $ (end of line in Vim) is Fn1 + Shift + D, and so on. Combining symbols quickly becomes problematic.

  It’s fairly easy to get used to inserting a lone symbol here and there, but the problems start when having to combine multiple symbols at once. E.g. writing an expression like 'Fn1 + Shift + D' = '$' above involves the following keypresses: <Fn1><Esc> F N <Fn1><Tab> <Fn1><Shift><Enter> S H I F T <Fn1><Shift><Enter> D <Fn1><Esc> <Fn1><Enter> <Fn1><Esc> <Fn1><Shift>D <Fn1><Esc>. Could you image how long it took me to write that up?

  

  The most difficult part of getting used to the keyboard is the fact that a few keys on the right side are chopped off: '/[]\ are placed in the bottom right of the keyboard, to bnm,. keys. While the rest of the layout attempts to mimic the existing convention and only shifting the rows down, the aforementioned keys are placed arbitrarily (as there’s no logical way to place them otherwise).

  This probably won’t worry you if you don’t write a lot of code or math, but I do, and it`s muscle memory I’ll have to develop.

  There are dedicated Del and Backspace keys, which is a bit of an odd choice, likely influenced by needing somewhere to place the F12 key - function row is right above the home row, and is hidden behind the Fn1 layer.

  Spacebar is split into two (for ease of finding keycaps I hear), and it doesn’t affect me whatsoever. I mostly hit spacebar with my left thumb and it’s convenient.

  Tab is placed where the Caps Lock is, which feels like a good choice. After accidentally hitting Esc a few times, I got used to the position. Do make sure to get latest firmware for your Vortex Core - I believe earlier firmware versions hides Tab behind a function layer, defaulting the key to Caps Lock (although my keycaps reflected the updated firmware).

  So I’d say the numbers and the function row take the least amount of time to get used to. It’s the special characters that take time.

  Can you use it with Vim?

  I’m a huge fan of Vim, and I even wrote a book on the subject. In fact, I’m writing this very review in Vim.

  And I must say, it’s difficult. My productivity took a hit. I use curly braces to move between paragraphs, I regularly search with /, ?, and *, move within a line with _ and $, and use numbers in my commands like c2w (change two words) as well as other special characters, e.g. da" (delete around double quotes).

  The most difficult combination being spelling correction: z= followed by a number to select the correct spelling. I consistency break the flow by having to press Z <Fn1><Enter> <Fn1><Tab> or something similar to quickly fix a misspelling.

  My Vim productivity certainly took a massive hit. Yet, after a few days it’s starting to slowly climb back up, and I find myself remembering the right key combinations as the muscle memory kicks in.

  I assume my Vim experience translates well into programming. Even though I write code for a living, I haven’t used Vortex Core to crank out code.

  Speaking of programming

  The whole keyboard is fully programmable (as long as you update it to the latest firmware).

  It’s an easy process - a three page manual covers everything that’s needed like using different keyboard layers or remapping regular and function keys.

  The manual also mentions using right Win, Pn, Ctrl, and Shift keys as arrow keys by hitting left Win, left Alt, and right spacebar. Vortex keyboards nowadays always come with this feature, but due to small form factor of the keys (especially Shift), impromptu arrow keys on Vortex Core are nearly indistinguishable from individual arrow keys.

  Remapping is helpful, since I’m used to having Ctrl where Caps Lock is (even though this means I have to hide Tab behind a function layer), or using hjkl as arrow keys (as opposed to the default ijkl).

  It took me only a few minutes to adjust the keyboard to my needs, but I imagine I will come back for tweaks - I’m not so sure if I’ll be able to get used to special symbols hidden behind Fn1 + Shift + key layer. Regularly pressing three keys at the time (with two of these keys being on the edge of the keyboard) feels unnatural and inconvenient right now. But I’m only a few hours in, and stenographers manager to do it.

  Living in the command line

  The absence of certain special characters is especially felt when using the command line. Not having a forward slash available with a single keypress makes typing paths more difficult. I also use Ctrl + \ as a modifier key for tmux, and as you could imagine it’s just as problematic.

  Despite so many difficulties, I’m loving my time with Vortex Core! To be honest with myself, I don’t buy new keyboards to be productive, or increase my typing speed. I buy them because they look great and are fun to type on. And Vortex Core looks fantastic, and being able to cover most of the keyboard with both hands is amazing.

  There’s just something special about having such a small board under my fingertips.

• 📅 Jul 15, 2014 🏷️ Reviews

  "The Pragmatic Programmer"

  I just finished reading “The Pragmatic Programmer” by Andrew Hunt and David Thomas - two consultants behind Pragmatic Programmers, LLC. This book might as well be a fantastic marketing trick for their consulting agency, but the value it brings to the reader is hard to underestimate.

  Hunt and Thomas cover a wide variety of topics, briefly glancing over every major aspect of developing software: be it the choice of a text editor, calculating time complexity, or working effectively on a team.

  If you read thematic books and actively follow programming blogs and podcasts - you may find yourself cheerfully nodding while reading sections of this book. You may have read about some of the tips online, heard from colleagues, or simply discovered them yourself. You will finish this book with a wide smile of approval, and a sense of validation in regards to your daily work flow or actions.

  If you are less lucky (say, you don’t read as much), you will find 70 tips you can utilize right away, right now, at your workplace. This is what “The Pragmatic Programmer” essentially is: a collection of practical things regarding getting things done.

  It’s an essential read, and I’ve seen this book in every single recommended reading list out there. And for a solid reason. This is the kind of book you want to re-read every couple of years to absorb every piece of knowledge presented within it. The latest edition of the book even contains a printout with all the tips listed in the book.

  You should read it after being in the field for a few years. After making mistakes, and figuring some things out on your own. Beginners might not understand some pieces, but will still be able to comprehend a major portion of knowledge contained within this book.

  I enthusiastically recommend this book to every software engineer I get to work with. It’s easy to read (as opposed to monstrosities like “Code Complete” or “Art of Computer Programming”) and it teaches you how to get things done, the pragmatic way.

• 📅 Jun 20, 2014 🏷️ Reviews

  "The Elements Of Style"

  You might wonder what an English language style guide from 1918 is doing in a software engineering blog. You might even get angry at me for pointing this book in your face. But I have a strong affection towards this guide; I believe everyone who has to write more than a sentence in English should read it. I like to emphasize the communication aspects of a software engineering career as much as coding or management skills.

  English is not my native language, and I often struggle with the writing style. I found a number of style tips online and in the books I read, but lately I noticed a pattern: most of those tips referenced “The Elements Of Style”. The book is available online free of charge (copyright has expired; it is now in public domain) and takes only an evening to read.

  What the book gives you is invaluable writing advice. The author provides concrete style rules targeted at increasing the appeal and comprehension rates of your text. Here’s my favorite piece of advice:

  13. Omit needless words.

  Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that he make every word tell.

  “The Elements Of Style” is a timeless classic; it should be mandatory reading for every speaker or learner of English out there. I immediately applied the rules to technical documentation, email communication, and even this very blog entry. I will probably have to read through the guide multiple times over the course of the following months in order to ensure maximum retention. If you care about being understood by another human being, you should read it too.

• 📅 Jun 20, 2014 🏷️ Reviews

  "Expert Python Programming" by Tarek Ziade

  Recently, I’ve been trying to read at least one book every week, and this week’s pick was “Expert Python Programming” by Tarek Ziade. Besides its few shortcomings, I found it to be useful - Python is a language of choice for me, and I found some valuable tips I could add to my arsenal.

  The best thing about this book is that it covers a very wide range of topics: syntax recommendations and code profiling, testing practices and project management, technical writing and design patterns, package distribution and version control… My favorite chapter covered writing technical documentation: I am very interested in writing in general, and the tips Ziade provided turned out to be very useful for documenting code, writing design documents, and even posting to this blog. Not much else caught my eye, but I had a number of “Aha!” moments such as, “Oh, I never used that!” and “That’s an interesting topic to look into!” scattered throughout the book. This book is very useful for filling in little gaps in knowledge which programmers can have: the author covers an extremely wide variety of Python development aspects.

  Unfortunately, I found the book to be poorly written. Weak writing style, typos in the text and code examples - it looked like the book was put together sloppily, in haste. Reviewers did not do a very good job evaluating this book. “Expert Python Programming” gives you the feeling that the author tried to fit in as much content (and code) as possible in his book, with no consistent style. Many chapters go into unnecessary details, and the author has tendency to paste completely useless chunks of code, such as a page-long output of an installer. As I have mentioned, the book hops from one topic to another, and covers a wide variety of subjects: this is both a key strength and the biggest weakness of the book. There is just “too much stuff” and it’s too scattered across the topics.

  “Expert Python Programming” will be of best use to, you guessed it, an expert. I found it best to scan through the content and seek out interesting bits of information. Beginners, however, might be completely overwhelmed. While advanced and intermediate Pythonistas will get the most out of this book, it will probably be too hard (and painful) to read to be of real value.

• 📅 Jun 17, 2014 🏷️ Reviews

  Steve Krug's "Don't Make Me Think"

  Today I received in the mail a copy of Steve Krug’s “Don’t Make Me Think, Revisited: A Common Sense Approach To Web And Mobile Usability” (oh, that’s a long name). I went through the whole book only in under a few hours, and I am so glad I’ve read it. It’s a very quick read, but the book is full of concrete and valuable tips and advice about usability.

  “Don’t Make Me Think” contains practical advice on a large number of topics: web and mobile usability, design, and writing for the web. The advice can be easily used and incorporated into your daily workflow; and the author provides concrete guidelines for applying his tips in the real world.

  The biggest thing I’ve learned from this book (and want to apply in practice) is individual usability testing. I actually performed my first usability test just three days ago, just before reading “Don’t Make Me Think”, after I found that Donald Norman’s masterpiece mentioned observing user interactions with your product (I’ll get to the similarities between two of these books in a moment).

  I asked two of my colleagues, one after another, to visit a website I was working on, and I silently watched them navigate through it. They had never seen the website before, and the results were very shocking to me: they ignored the things most obvious to me, but attempted to click through things which are not even meant to be clicked. I carefully wrote down all of my findings, and delivered the patches with enhancements to improve the biggest areas of struggle these particular users had faced.

  Usability testing turned out to be invaluable: it pointed out actions that I, as a developer, did not anticipate, and highlighted parts of the system ignored by the users. I now plan to run usability tests regularly, grabbing colleagues from the hallway, and asking them to use my application for a few minutes.

  Steve Krug’s book is very much like “The Design Of Everyday Things”, but stripped from the extended theoretical part. The book references Norman’s work quite a lot, and seems to be heavily influenced by it. It focuses on practical aspects of designing easy to use and understandable user interfaces. It successfully explains why you should be thoughtful of user experience, accessibility, and understanding the way users think. I would recommend reading this book after reading Donald Norman’s masterpiece first, since it provides you with the reasoning behind many decisions Steve Krug makes throughout his book.

• 📅 Jun 15, 2014 🏷️ Reviews

  "The Design of Everyday Things"

  Unfortunately, I have not been reading as much as I would love to lately. In the past year I have only read two books, one of which was a technical manual. Don’t get me wrong, I still had a lot of personal and professional growth going on: reading blogs, articles, guides, watching keynote talks… But I did miss the feeling of holding a good book in my hands, turning the pages with the tips of my fingers, seeing the texture of the paper under the print. A few weeks ago I went ahead and ordered one of the books on my reading list: “The Design of Everyday Things” by Donald A. Norman. I just finished reading it a few hours ago and am eager to share my impressions of the book.

  “The Design of Everyday Things” turned out to be one of the most eye-opening books about design I have ever read (alright, alright, I haven’t read any design books before). It’s mind blowing to think that I have never considered the points brought up by the authors. Hell, (and I will probably have rotten tomatoes thrown at me for this statement) but I didn’t even think design was a “real” job. Oh dear, how wrong I was.

  Norman’s masterpiece talks about the psychology of everyday things (which was actually the initial title of the book, but was changed to “Design” after the first release). The author explains how users make decisions, use objects, make errors - and so many other factors which should go into the design process. Norman explains fundamental basics of the psychology of human-object interaction, something most people never think about. How hard could it be to design a door? Turns out the answer is - very hard. And every time you see someone pulling the door instead of pushing and vice versa - it’s a result of a poor design. So many everyday frustrations could have been avoided if designers would have put more thought into usability of their product.

  I build software for living, and I was skeptical if I even needed to know anything about good design. I mean, how hard could it be to put together a few pages and forms? “I tackle complex software problems, I don’t need any of this liberal arts bullshit!” - I thought that way, and I know many people who still do. Well, Norman’s book is a great starter for people like me: he does a great job explaining why the design process so important. By the time I finished reading it, I had a pretty solid set of ideas why there are so many things wrong with our industry, and how good, thoughtful design is a way out. The funniest part is - the book itself is published in the year 1988, over twenty-five years ago. It doesn’t talk much about computers, concentrating on objects more common at the time: cars, telephone systems, even stoves and dish washing machines. And here I am, reading this book in the year 2014 - and the situation did not change at all. Expensive laundry machines are as hard to operate, computer programs are as clunky.

  “The Design of Everyday Things” compels the reader to become a part of the solution to this enormous and bulky design problem the world is stuck with. In the everyday world, for every good case of design out there, you will face a hundred faulty, frustrating, and downright insulting design attempts.

  The book is very easy and pleasant to read, and I went through it in under a week. Most of it is a set of rants about poor design decisions, with suggested improvements and solutions. Throughout the reading process, I had to revisit the systems I built at work and rearrange the components, add more feedback to user’s actions, and do many other little and big improvements in order to make make the system image much more transparent to the user. Norman taught me the most obvious truth: a designer is not your typical user of the system. This changes so many things, makes you doubt and rethink a number of design decisions you made along the way - all in order to build a product that is easy and pleasant to use.

  I now consider myself to be blessed with an understanding of the importance of good design, and admitting there is a problem is the first step to fixing it. And believe me, there is a problem. I will now continue learning about the best practices in building systems that are easy to understand and pleasant to operate for the user. My next stop is “Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability” by Steve Krug. I’ve heard a lot about this book, and I will be sure to share my impressions here.