and has 0 comments

  The Broken Ladder is a sociology book that is concise and to the point. I highly recommend it. Keith Payne's thesis is that most of the negative issues we associate with poverty or income are statistically proven to be more correlated with inequality and status. And this is not a human thing, as animal studies show that this is a deeply rooted behavior of social animals like monkeys and has a genetic component that can be demonstrated to as simple creatures as fruit flies.

  There are nine chapters in the book, each focusing on a particular characteristic of effect of social inequality. We learn that just having available a sum of money or a set of resources is meaningless to the individual. Instead, more important is how different those resources are from other people in the same group. Inequality leads to stress, which in turn leads to toxic behaviors, health problems, developmental issues. It leads to risk taking, to polarization in politics, it affects lifespan, it promotes conspiracy theories, religious extremism and racism.

  It is a short enough book that there is no reason for me to summarize it here. I believe it's a very important work to examine, as it touches on many problems that are present, even timeless. Written in 2017, it feels like a explanatory pamphlet to what gets all the media attention in 2020.

and has 0 comments

  I have to admit this is a strange time for me, in which I struggle with finishing any book. My mind may drift away at a moment's notice, thoughts captured by random things that inflame my interest. And with limited time resources, some things fall through the cracks, like the ability to dedicate myself to books that don't immediately grab my attention. Such a book is The Ten Thousand Doors of January.

  And you know the type. It's one of those where the way the word sounds as you read it is more important that what it says, a sort of magical white poetry that is attempting to evoke rather than tell, feel rather than reason, while also maintaining a rigorous intellectual style. Alix E. Harrow is a good writer and it shows, however she is too caught up in her own writing. This story features a girl with an ability that is manifested when she writes words of power. She is an avid reader and, in order to learn about her capabilities, she receives a book that tells the story of another girl who was similar to her. And the style of that book is, you guessed it, words crafted to evoke rather than tell.

  So at about 40% of the book nothing had happened other than a girl of color living in a house of plenty, but imprisoned by rules and starved of knowledge or power. Her captor and adoptive father is a white and powerful aristocrat, cold as ice and authoritative in every action or word, while she is a good girl caught between her desires and her upbringing. I've read books like this before and I liked some of them a lot. And this may yet evolve into a beautiful story, but as I was saying above, I am not in the mood for paying that much attention before something happens.

  In conclusion, while I get a feeling of being defeated and a desire to continue reading the book, I also have to accept I don't have the resources to struggle with it. I would rather find a more comfortable story for me at this time.

and has 0 comments

  The Authenticity Project is one of those books that got great marketing and so I got to read, so there is a little feeling of getting tricked to read it, but it's not a bad book. It is, however, terribly naive. It almost begs for the Brit-com makeover transition to the big screen with its physically perfect characters that feel their lives had lost meaning, but have all the resources to change them, the courage of telling the truth leading to strong friendships and not people taking advantage of them and the serendipity for all of them to meet each other and fit together. But it is a feel good book, so why not enjoy it?

  Clare Pooley graduated from a blog turned book about her own struggle with posh alcohol addiction to fiction with this book, after feeling inspired by the power of being truthful. In the book, someone decides to write their most personal truth in a notebook and leave it around so other people can read it and maybe also write in it. This brings together these people who have been living financially rewarding lives, but spiritually empty existences. The writing is decent, the story is obvious and lacking much subtlety, so if you want to read an uplifting fantasy about people getting everything right in their lives, this is the one for you.

  However, despite the book's premise that underneath the facade people are really different, the characters are quite cardboard. Instead of them having layer over layer of complexity, which would have made the story worth reading, it's like they hold party masks over their faces and when they drop them, you get to see all they are, vulnerable and normal while being amazing. There is a twist at the end that was kind of unexpected and a good opportunity to add more dimensions to the whole thing, only it fizzled immediately after the initial shock value.

  Bottom line: it feels as real as a fairy tale. The princesses get the princes, the dragons live happily ever after and everybody gets to keep the gold. It was not unpleasant to read, but I wouldn't recommend it, either.

and has 0 comments

  A few days ago I was stumbling upon a global pandemic book that I couldn't finish because it was avoiding the exact parts that would interest me in the scenario: the disease, the cause, the immediate aftermath. Instead it used the disease as a prop to describe a world in which only children survived. Disappointed, I randomly picked another book, this time one from Liu Cixin, the author of Three Body Problem, which I liked. Lo and behold, it was about a global catastrophe that kills all the adults, too! And while it started great, I have to say that it ultimately was also a disappointment.

  In Liu's defense, it is a story he wrote in 1989, only published in China in 2003 and translated to English in 2019 because of his success with other works.

  Supernova Era has a very interesting premise: a nearby star, occluded from us by a dust cloud, goes supernova, bathing the Earth in deadly radiation. People quickly realize that the genetic damage has affected everybody and only children under the age of 13 will be able to shrug it off, while all the adults will die. Children will have finally inherited the planet. What will the outcome be?

  Unfortunately, this is where the nice part ends. The genetic damage on animals and plants is swept under the rug, logistic issues such as how children would be fed and countries run are only touched upon, the actual effects of radiation damage, its long time effects, the way it would have affected people are completely ignored. And this, also, because the supernova was only a prop to describe a world in which only children survived.

  Liu had a really weird outlook on children back then. In his mind, children are lacking empathy, are only interested in games and even after a ten month training period from adults, they can only superficially grasp the nature of the world. And even if they are as old as 13 year old, they have no sexual drives. To be fair, I doubt that part would have passed by the Chinese censors, but not even mentioning it and portraying prepubescent teens as asexual feels even creepier than mentioning it too much.

  And I remember myself at 12: I was reading five books at the same time, was interested in natural sciences and was avid for knowledge. If people would have said "Now we will teach you how to do what we do", I would have been immensely happy, at least for a little while. But one thing is certain, I loved my friends without reservation and I was always thinking of how I would change the world when I would grow up.

  Not these children. They are written more as psychopathic caricatures of their nationalities. American kids start shooting each other for fun, Brazilians play games of soccer with a hundred thousand players and one ball and the Chinese succumb to fear when they find themselves under no authority and have to resort to a quantum computer to tell them what to do. They play war games that kill hundreds of thousands, but they are emotionally unaffected. They nuke their opponents for laughs. The ending is even more confusing, as it involves switching populations between the countries of the U.S. and China, for no apparent reason and ignoring transport issues and the immediate famine that would lead to.

  Bottom line: an interesting premise that fails miserably at the end, even though the author did make the effort to finish the book. But that's exactly the feeling one gets: someone struggled to finish this, changing direction, bringing in random ideas that are never explored and ignoring the obvious.

and has 0 comments

  Station Eleven started really well. It had the fresh scene setup, the internal thoughts of a complex character, a dissection of actual motivations and emotions, rather than cardboard cliches. Because I have a bunch of books to read and when I start reading I just pick one at random, I didn't know what it was about, and so I had that feeling of "Oh well, it's not sci-fi or fantasy, but I like the writing!". I was convinced I was going to like the book.

  A chapter later and there is a killer epidemic starting. One chapter later twenty years have passed and everybody except young people are alive in a post apocalyptic non technological world. I just couldn't go on. The complex character at the beginning and the interesting setup had been completely obliterated and replaced with tired formulaic ideas. I couldn't care less about any of the new characters or what was going to happen. I don't know what Emily St. John Mandel was thinking when she started writing the book, but it is clearly not for me.

  One of the main reasons to put the book down and not continue reading was the lazy and unscientific treatment of the killer pandemic. We are talking about a flu virus that infects just by breathing for a few seconds next to someone, then disabled those people within a day. Viruses like this do not spread! Moreover, there is no way that a flu virus kills everybody. There are always exceptions, whether due to immunity, isolation or other factors. I love pandemic stories, I read them all with glee, and I did that way before the current situation, and when I see one that teaches nothing, because the epidemic is just a prop in an otherwise unrelated story, I get frustrated.

  A few years ago I was watching a movie with my wife. We both didn't quite enjoy it, but were curious on how it ended, so I told her to skip scenes to get to the end. She was skipping all the scenes I was interested in and watching the ones I couldn't care less about. This book is the same. I understand why people would like it, as I said, the writing was good, but the focus of the story and the characters were in complete opposition to my own interests.

and has 0 comments

  Almost a year ago I was reading Vaccinated, by Paul A. Offit, an ode to vaccines and their de facto promoter in modern medicine, Maurice Hilleman. Offit was angry in the book when talking about the vaccine craze started by Andrew Wakefield, a self interested psychopath that gained money and fame while feeding on the fear and desperation of parents. Yet, he is not even close to how angry Seth Mnookin is in The Panic Virus, a book dedicated solely to exposing the roots and mechanisms of the industry of fear towards vaccines.

  The author systematically dissects, with proof and careful analysis, the entire argument of harmful vaccines causing autism, mercury poisoning or damaging immunity. Let me be as blunt as he is: the theory that vaccines cause autism has been thoroughly debunked and whoever continues to spout such nonsense has not read anything about the subject other than Facebook. Mnookin talks about Wakefield, David Kirby, Jenny McCarthy, Oprah Winfrey, exposing them for the profiteering promoters of deadly lies that they are. He talks about law trials and medical trials and research papers as they destroy any leg these theories stand on, but which never reach the news. He talks about devastated families, tricked into wasting their lives and money championing harmful ideas just for the tiny hope their child might get better.  

  However it is ironic that this book suffers from the same problems that made the vaccine argument lean so much towards the emotional, dramatic, sound-bite sized bullshit: it is technical, precise, verbose, intellectual. It is difficult to read the book because it engages with your brain, assaulting it with educated language and loads of information. Meanwhile, the opponents of the Mnookin's views use animated gifs with large colorful font texts and the occasional kitten. But it is a book that needs reading.

  Consider The Panic Virus as a form of vaccine itself. You need to read it so you don't fall prey to soulless predators that would use targeted well crafted yet completely misleading arguments to sway you to their side for their own profit. I am warning you, though, this is not a happy book. It made me question the worth of the human race as a whole. If such cheap techniques can be so effective in brainwashing so many people into believing absurd lies, then don't we deserve it, all the death and suffering? Aren't we failing at... I don't know, evolution? And the sad part is that most of the affected are fairly educated people, who start to rebel against "the establishment" and branch out into alternative theories without actually employing any technique of differentiating between fact and fallacy.

  Bottom line: I will rate this book the maximum value, because it is important to be read, but it is not a perfectly written piece of literature, nor it is easy to finish. But give it a try.

and has 0 comments

   You may have heard of Richard Feynman from several sources: he was a Nobel winning physicist, he worked in the team creating the first atomic bomb, he said many a smart thing that turned into memes at one time or another and is generally considered a genius. This book is a collection of short anecdotal stories put on paper from recorded interviews with the man, in which you will be surprised to see that he didn't really consider himself very smart. Instead, he was looking at situations where the solution seemed perfectly obvious and did not understand why other can't see it.

   I found the short tales pretty amusing, but also incredibly inspiring. Here is a physicist who makes a bet with an artist to makes one the teacher of the other, so that he learns to draw - something he feels to be impossible, and the artist understands more about science. In the end, Feynman sells paintings for money and the artist is none the wiser. Here is this person who at one time started fiddling with the safes in Los Alamos holding the secrets of the atomic bomb and found how easy it is to crack them. No one else thought it was easy. And above everything, he is always pranking people, making them believe he was smarter or more capable than he really was. But the joke was on him, because every time he did something, he really became good at it.

  The title says it all: "Surely You're Joking, Mr. Feynman!": Adventures of a Curious Character. If anything, he was very curious and kept his mind open to any experience. It's people like these that I admire and, of course, envy with all my being. Feynman seems not only to be a complete man, in both work, fun and personal life, but also get more from the same experience than anyone around him. I found that fascinating and therefore I invite you to read the book yourselves.

and has 0 comments

  A Cavern of Black Ice is a huge 769 page long book, but only the beginning of a story that happens in a fictional realm of feudalism and magic. You just have to have the classic hero journey, starting with a young man torn from the world he knew and was comfortable to him, partially mentored by a wise and hitherto unknown relative, given a reason to trek on a perilous journey and beset by powerful, yet strangely ineffectual enemies. Of course, Deus ex Machina abilities that help him and his quarry escape tight situations are also there.

  But there is more: various clans living in a cold inhospitable North, the ambitious ruler of a city coveting the resources of said clans, a mysterious and powerful entity chained by the ruler, a strange and magical race of people even further north, a secret sorcerous society, female assassins that you can't quite remember what they look like, a dark realm where dangerous creatures await release and so on and so on.

  The thing to understand here is that J. V. Jones set to create a vast universe in which multiple interests clash to create a captivating story. The writing is good, the characters are decent, but there is something missing and while I can't quite put my finger on it, I suspect it involves editing. There is too much text for what the story wants to say and when characterisation is concerned, some actions or even complete characters are just pulled out of a hat. And remember, this is just one of at least four books in the Sword of Shadows series and it barely scratched the surface of it all.

  Bottom line: I liked the book, but not so much as to be absolutely certain I will continue to read the rest of the series. When I finished reading it I felt actual relief. If you want to spend some time immersed in a fantastic fantasy universe, this might be a good fit for you.

and has 0 comments

  It's very rare for me to have such a strong reaction to a book as I has to The Shallows. A combination of high expectations from the people who recommended it and the ironically poor quality of the book almost forced me to stop reading it. It gives me a great and perverse pleasure to summarize this book into a single paragraph: the Internet is bombarding us with information and stimuli, therefore training our brains to skim the surface of things and depriving us of the ability to "deep read", meaning slowly digesting large blocks of text and fully processing what we read is now difficult to impossible for most people. That is it! There is nothing else in this book. And the reason why this book was bad is that it brings nothing more to the original idea explored by the author in an Atlantic Monthly cover story than quotes from other people who agree.

  Nicholas Carr decries (and cries and cries) the way the medium of the information we digest is changing the way we process that information. He uses page long paragraphs filled with big words meant only to make him look well read to repeat the same things over and over again, all the while complaining about people skipping to the juicy parts. I mean, I've been known to use a few pompous words myself, but I don't think I've ever went out of my way to use complicated expressions when simpler ones would do.

  The multitude of citations from people ranging from ancient Greek philosophers to Artificial Intelligence scientists are cherry-picked to make his case of the demise of the "deep read" in favor of meaningless web skimming. Carr makes the correct case that too much information trains us to not completely absorb the content of the things we read, but he completely misses the mark on why that happens, ironically made evident by his style of writing: boring, pompous, long, verbose. In a classic (by now) bubble effect, he writes a book about his fears that no one but people who share those fears would actually be able to read.

  Also ironic is that he makes some predictions (in 2010) about artificial intelligence and how people will use the various (and nefarious) web services like Google Wave that now make one laugh out loud.

  The point, Carr, is that people who are bombarded with lots of information learn to quickly categorize that information, then send it in the correct bin. You skim an article, see that it is mostly word filling around a central idea, you extract that idea, then move on. There is no deep reading because there is no deep writing. It happens with books, too. One is quick to determine when one book is captivating, engaging and well researched rather than repetitive, single-sided and written for the pleasure of reading oneself and looking smug rather than for knowledge sharing or the pleasure of others. The point (made clearer by research in how AI systems designed after brains function) is that this is how brains have always worked: filtered out as much as possible of the meaningless and tried to absorb as quickly as possible the meaningful. It is literally a search for meaning, you buffoon!

  So, yes, no one finds the time to laboriously study a book, annotate it, keeping well received paragraphs and quips in notebooks they carry with them. But that is because there is more information out there that brings more value through its diversity. In a very sad way, The Shallows reminds me of those religious people who complained about how laic books made people not study the Bible and absorb its teachings.

  Now, the book is not completely without merit. It's just very annoying. The way we use our brains does change the abilities we later have. It's what brains are meant to do: adapt.

  Would it hurt to regularly take a break from distraction, reading something that we have decided is important and high quality, then taking the time to think and absorb and maybe reread what we thought was valuable? No, of course not. I am intimately familiar with the restlessness that comes when trying to spend more than an hour doing the same thing or keeping my attention focused on one thing only. In this, Carr is not wrong. But in assuming that slowly and carefully navigating an avalanche of information is possible, he is definitely going too far.

  Instead of complaining about how we don't absorb meaning because we are too busy filtering out noise, one could be optimistic about the ability of people, helped by technology and not despite it, to improve the way they separate chaff from wheat. Instead of decrying the size and complexity of the information that one must use, making it impossible to hold it all in one brain, why not enjoy the ability to collaborate, network and share that makes it possible for that information to be well processed by groups of people?

  Bottom line: the ideas explored in this book are conservative in nature, fearful of change, focused on what drives that change yet blind on where it takes us. It is the intellectual pompous version of the old man wagging his cane in the air, shouting in anger at young people. It is a book that examines one phenomenon without bringing one any closer to an understanding of it. Woe betide things will change! Well, duh!

and has 0 comments

  It was more than two years ago when I was reading the first four books in the series and not being very impressed. Then there was a long break in which I wasn't really interested in reading the fifth and last: The Dark Talent. But I am a big fan of Brandon Sanderson so I finally read it. It's very short, pretty pointless and ends badly. And by badly I mean written in a bad way, which is quite unexpected, but even worse, it ends in a cliffhanger, pending a sixth book.

  The entire series is tonally all over the place, but I remember for the first books it kind of grew on me, even if it was funny one moment, tense the next, breaking the fourth wall immediately after. The Dark Talent, though, I hated! I couldn't empathise with any of the characters, I found the jokes elaborate yet dull and the twists were obvious chapters before.

  I guess Sanderson can't do only good. He has to vent the silly and the bad and the weird in order to write the good ones like The Reckoners and Elantris. I am pretty sure I will not read any of the books in this series.

and has 0 comments

  The first 20% of Gods of Jade and Shadow has nothing to do with anything fantastic. Since I have a large collection of books and choosing which to read more or less at random, I was afraid that I chose one of those young girl coming of age stories, because basically the first fifth of the book is a Cinderella story. Nothing wrong with that, just I didn't feel like reading such a story then and I almost stopped reading it. But a few days later I kept going.

  And the book picked up, with the introduction of Mayan gods, only that afterwards it all turned into one of the watered down episodes of American Gods from the TV show (not the book, which was great!). It's a big road trip, with enough information to basically know where the characters will end up and in what state they will get there. The only unknowns were the bits of Mayan mythology, which were nice, but not nearly comprehensive, and the final chapter. And the final chapter is full of symbolism, only I felt that it didn't have a lot to do with the rest of the book. Worse, a lot of the characters introduced in that first 20% were basically abandoned for the rest of the story. It was like Silvia Moreno-Garcia started to write something, then she thought of a cool ending and then she abruptly veered off and filled in the space to get to that ending.

  Bottom line: it was decent writing and perhaps in a more receptive mood I would have "got it", but as it is, I didn't. It seemed an attempt for something that the book never got to be, instead I got something fractured that didn't feel neither original nor magical.

  You can consider this an interview question, although to be fair if someone did ask me this for an interview I would say they are assholes. What is the difference between the pre-increment operator and the post-increment operator in C#?

  They look the same in C and C# and Javascript and Java and all the languages that share the curly bracket syntax with C, but in fact they are slightly different. Slight enough to make someone an asshole for asking the question as if it were relevant, but important enough for you to read about it. One of the most common interpretations of the syntax is that x++ is incrementing the value after the operation, while ++x is incrementing it before the operation. That is wrong.

  In fact, for C++ the return values are different between pre and post operators. I am not a C++ dev, so I give you this reference link: "Pre operators increment or decrement the value of the object and return a reference to the result. Post operators create a copy of the object, increment or decrement the value of the object and return the copy from before the increment or decrement." So one returns an object, the other returns a reference to an object. It is also possible that the assignment be done after the value was produced in C or C++. In C# the assignment must be done before any value is returned.

  In C#, to paraphrase Eric Lippert, "Both pre and post operators determine the value of the variable, what value will be assigned back to storage and assign the new value to storage. The postfix operator produces the original value, and the prefix operator produces the assigned value." So it's (kindda) like this piece of code:

int Increment(ref int x, bool post) {
  var originalX = x;
  var newX = x+1;
  x = newX;
  return post ? originalX : newX;
}

  So why the hell does it matter? I mean, it's a rather meaningless difference between the programming languages and the before/after mnemonic is making the code pretty clear, doesn't it? OK. Let's try some code and let me see how fast you come up with the answer. Remember, this is supposed to be simple, so if you are thinking too much about it, it doesn't matter you get the correct answer. Ready?

  1. Any difference between x++ and ++x if the resulting value is not used?
  2. var a=1; var b=++a; What's the value of b?
  3. var a=1; var b=a++; var c=++a; What's the value of c?
  4. var i = 0; for (i=0; i<5; ++i) Console.Write(i+" "); Console.WriteLine(i); What is printed at the console?
  5. var i = 0; for (i=0; i<5; i++) Console.Write(i+" "); Console.WriteLine(i); What is printed at the console?
  6. var a=1; a=a++; What's the value of a?

And all of this was about the increment operator as normally used for integer values. There is a big part about operator overloading in there, but I believe less relevant in the context of differences between pre and post increment/decrement operators.

There is one important part to discuss, though, and that is best code practices. When to use post and when to use pre. And they are really easy: separate statements from expressions! Statements execute code with side effects, they should return nothing. Expressions return values without side effects. If you never use the value of an increment or decrement and instead use it as a statement with side-effects, there is no difference between ++a and a++. In fact one doesn't need the preincrement/predecrement operators at all! In this context, the answers for the questions above is 1. No 2,3,6: You are using it wrong! 4,5: the same thing, since without getting the value we have scenario 1.

Just for reference, though, here are the answers:

  1. No
  2. 2
  3. 3 (b is 1)
  4. 0 1 2 3 4 5
  5. 0 1 2 3 4 5
  6. 1

Hope that makes you think.

 Intro

  When I was a kid, computers didn't have multithreading, multitasking or even multiple processes. You executed a program and it was the only program that was running. Therefore the way to do, let's say, user key input was to check again and again if there is a key in a buffer. To give you a clearer view on how bonkers that was, if you try something similar in Javascript the page dies. Why? Because the processing power to look for a value in an array is minuscule and you will basically have a loop that executes hundreds of thousand or even millions of times a second. The CPU will try to accommodate that and run at full power. You will have a do nothing loop that will take the entire capacity of the CPU for the current process. The browser would have problems handling legitimate page events, like you trying to close it! Ridiculous!

Bad solution

Here is what this would look like:

class QBasic {

    constructor() {
        this._keyBuffer=[];
        // add a global handler on key press and place events in a buffer
        window.addEventListener('keypress', function (e) {
            this._keyBuffer.push(e);
        }.bind(this));
    }

    INKEY() {
        // remove the first key in the buffer and return it
        const ev = this._keyBuffer.shift();
        // return either the key or an empty string
        if (ev) {
            return ev.key;
        } else {
            return '';
        }
    }
}

// this code will kill your CPU and freeze your page
const qb = new QBasic();
while (qb.INKEY()=='') {
 // do absolutely nothing
}

How then, should we port the original QBasic code into Javascript?

WHILE INKEY$ = ""

    ' DO ABSOLUTELY NOTHING

WEND

Best solution (not accepted)

Of course, the best solution is to redesign the code and rewrite everything. After all, this is thirty year old code. But let's imagine that, in the best practices of porting something, you want to find the first principles of translating QBasic into Javascript, then automate it. Or that, even if you do it manually, you want to preserve the code as much as possible before you start refactoring it. I do want to write a post about the steps of refactoring legacy code (and as you can see, sometimes I actually mean legacy, as in "bestowed upon by our forefathers"), but I wanted to write something tangible first. Enough theory!

Interpretative solution (not accepted, yet)

Another solution is to reinterpret the function into a waiting function, one that does nothing until a key is pressed. That would be easier to solve, but again, I want to translate the code as faithfully as possible, so this is a no-no. However, I will discuss how to implement this at the end of this post.

Working solution (slightly less bad solution)

Final solution: do the same thing, but add a delay, so that the loop doesn't use the entire pool of CPU instructions. Something akin to Thread.Sleep in C#, maybe. But, oops! in Javascript there is no function that would freeze execution for a period of time.

The only thing related to delays in Javascript is setTimeout, a function that indeed waits for the specified interval of time, but then executes the function that was passed as a parameter. It does not pause execution. Whatever you write after setTimeout will execute immediately. Enter async/await, new in Javascript ES8 (or EcmaScript 2017), and we can use the delay function as we did when exploring QBasic PLAY:

function delay(duration) {
    return new Promise(resolve => setTimeout(resolve, duration));
}

Now we can wait inside the code with await delay(milliseconds);. However, this means turning the functions that use it into async functions. As far as I am concerned, the pollution of the entire function tree with async keywords is really annoying, but it's the future, folks!

Isn't this amazing? In order to port to Javascript code that was written in 1990, you need features that were added to the language only in 2017! If you wanted to do this in Javascript ES5 you couldn't do it! The concept of software development has changed so much that it would have been impossible to port even the simplest piece of code from something like QBasic to Javascript.

Anyway, now the code looks like this:

function delay(duration) {
    return new Promise(resolve => setTimeout(resolve, duration));
}

class QBasic {

    constructor() {
        this._keyBuffer=[];
        // add a handler on every key press and place events in a buffer
        window.addEventListener('keypress', function (e) {
            this._keyBuffer.push(e);
        }.bind(this));
    }

    async INKEY() {
        // remove the first key in the buffer and return it
        const ev = this._keyBuffer.shift();
        // return either the key or an empty string
        if (ev) {
            return ev.key;
        } else {
            await delay(100);
            return '';
        }
    }
}

const qb = new QBasic();
while (qb.INKEY()=='') {
 // do absolutely nothing
}

Now, this will work by delaying for 100 milliseconds when there is nothing in the buffer. It's clearly not ideal. If one wanted to fix a problem with a loop running too fast, then the delay function should have at least been added to the loop, not the INKEY function. Using it like this you will get some inexplicable delays in code that would want to use fast key inputs. It's, however, the only way we can implement an INKEY function that will behave as close to the original as possible, which is hiring a 90 year old guy to go to a letter box and check if there is any character in the mail and then come back and bring it to you. True story, it's the original implementation of the function!

Interpretative solution (implementation)

It would have been much simpler to implement the function in a blocking manner. In other words, when called, INKEY would wait for a key to be pressed, then exit and return that key when the user presses it. We again would have to use Promises:

class QBasic {

    constructor() {
        this._keyHandler = null;
        // instead of using a buffer for keys, keep a reference
        // to a resolve function and execute it if it exists
        window.addEventListener('keypress', function (e) {
            if (this._keyHandler) {
                const handler = this._keyHandler;
                this._keyHandler = null;
                handler(e.key);
            }
        }.bind(this));
    }

    INKEY() {
        const self = this;
        return new Promise(resolve => self._keyHandler = resolve);
    }
}


const qb = new QBasic();
while ((await qb.INKEY())=='') { // or just await qb.INKEY(); instead of the loop
 // do absolutely nothing
}

Amazing again, isn't it? The loops (pun not intended) through which one has to go in order to force a procedural mindset on an event based programming language.

Disclaimer

Just to make sure, I do not recommend this style of software development; this is only related to porting old school code and is more or less designed to show you how software development has changed in time, from a period before most of you were even born.

  I didn't want to write about this. Not because of a false sense of security, but because everybody else talked about it. They all have opinions, most of them terribly wrong, but for me to join the fray and tell the world what I think is right would only put me in the same category as them. So no, I abstained. However, there are some things so wrong, so stupidly incorrect, that I can't maintain this silence. So let's begin.

  "The flu", "a cold" are not scientific, they are popular terms and they all relate to respiratory infectious diseases caused by a variety of viruses and sometimes bacteria or a combination thereof. Some of them affect us on a seasonal basis, some of them do not. Rhinoviruses are the ones most often associated with the common cold and they are seasonal. However, a whooping 15% of what is commonly called "a cold" comes from coronaviruses, thus named because of their crown-like shape. Influenza viruses, what we would normally call "flu" are a completely different type of virus. In other words, Covid-19 is more a common cold than a flu, but it's not the seasonal type. Stop wishful thinking that it will all go away with the summer. It will not. Other famous coronavirus diseases are SARS and MERS. The SARS epidemic lasted until July, the MERS epidemic spreaded just fine in the Middle Eastern summer weather. This will last. It will last for months from the moment I am writing this blog. This will be very important for the next section of the post.

  Also, there is something called the R-naught (R0), the rate with which a virus spreads to other people. It predicts, annoyingly accurate, how a disease is going to progress. This virus has an R0 probably twice as high as that of the influenza virus, which we all get, every fucking year. Draw your own conclusions.

  The only reason we got rid of SARS and MERS is because they are only infectious after the symptoms are apparent and the symptoms are pretty damn apparent. Covid-19 is very infectious even before the first cough, when people feel just fine. Surely masks will help, then? Not unless they are airtight. Medical masks are named so because medics use them in order to not cough or spit or breathe inside a patient, maybe during surgery. The air that the doctor breathes comes from the sides of the mask. So if you get sick and you wear the mask it will help the people that have not met you while you had no symptoms yet.

  Washing the hands is always good. It gets rid of all kind of crap. The primary medium of spreading Covid-19 is air, so you can wash your hands as often as you'd like, it helps very little with that. Stopping touching your face does little good, either. There is a scenario when someone coughs in their hand, touches something, then you touch it, then you pick your nose. Possible, so it's not all worthless, it's just statistically insignificant. What I am saying is that washing your hands and not touching yourself decreases the probability a very small amount. That being said, masturbation does increase the activity of your immune system, so be selective when you touch yourself.

  The idea that old people are the only ones affected is a myth. Age statistically correlates with harsher symptoms because it also correlates with negative health conditions. In other words, people with existing health conditions will be most affected. This includes smokers, obese people, people with high blood pressure, asthma and, of course, fucking old people. The best way to prepare for a SARS-Cov-2 virus (the latest "official" name) is to stay in good health. That means healthy food, less alcohol, no smoking and keeping a healthy weight. So yes, I am fucked, but at least I will die happy... oh, no, I am out of gin!!

  Medically, the only good strategy is to develop a vaccine as soon as possible and distribute it everywhere. It will lead quicker and with less casualties to the inevitable end of this pandemic: when more people are immune than those who are not. This will happen naturally after we all get infected and get healthy (or die). All of the news of people who got sick after getting healthy are artefacts of defective testing. All of it! Immunity does not work like that. You either got rid of it and your body knows how to defend itself or you never had it or you had something else or somebody tested you wrong.

  That being said, fuck all anti-vaxxers. You are killing people, you assholes!

  Personally, the best you can do is keep hydrated and eat in a balanced way. You need proteins and zinc and perhaps vitamin C (not sure about that). Warm bone broths will be good. Zinc you get from red meat and plant seeds. There was a report of drinking green tea being negatively correlated with influenza infections (different virus, though). And don't start doing sport now, if you haven't been doing it already, you can't get the pig fat one day before Christmas. Sport is actually decreasing the efficiency of your immune system.

  This is the end of the medical section of this post. There is nothing else. Probiotics won't help, Forsythia won't help, antibiotics will certainly not help. The only thing that fights the virus right now is your immune system, so just help it out. If there was a cure for the common cold you wouldn't get it each year every year.

  But it's not over. Because of people. When people panic, bad things happen. And by panic, I mean letting their emotions get the better of them, I mean not thinking people, not zombie hordes, although sometimes the difference is academic.

  Closing schools and workplaces and public places has one beneficial effect: it makes the infection rate go down. It doesn't stop the spread, it doesn't stop the disease, it just gives more time to the medical system to deal with the afflicted. But at the same time, it closes down manufacturing, supply chains, it affects the livelihood of entire categories of people. So here is where governments should step in, to cover financially the losses these people have to endure. You need money for medical supplies and for keeping healthy. Think of it as sponsoring immune systems.

  The alternative, something we are seeing now in paranoid countries, is closing down essential parts of national economies with no compensation. This is the place and time for an honest cost vs. gain analysis. Make sure the core of your nation is functioning. This is not one of those moments when you play dead for a few minutes and the bear leaves (or falls down next to you because he really likes playing that game). This is something that needs to work for months, if not a year or more. This is not (and never was) a case of stopping a disease, but of managing its effects. Some people are going to die. Some people are going to get sick and survive. Some lucky bastards will cough a few times and go on with their day. Society and the economical system that sustains it must go on, or we will have a lot more problems than a virus.

  Speaking of affected professions, the most affected will be medical personnel. Faced day in and day out with SARS-Cov-2 infections they will get infected in larger numbers than the regular population. Yes, they will be careful, they will wear masks and suits and whatever, but it won't help. Not in a statistical way, the only way we must think right now. It's a numbers game. It's no longer about tragedies, it's about statistics, as Stalin used to say. And these people are not regular people. They've been in school for at least a decade before they can properly work in a hospital where Covid-19 patients will be admitted. You lose one of these, you can't easily replace them. Especially in moron countries like my own, where the medical system is practically begging people to leave work in other countries. The silver lining is that probably, at the end of the outbreak, there will be a lot more medical people available, since they went through the disease and emerged safe and immune. But there is a lot of time between now and then.

  Closing borders is probably the most idiotic thing one can do, with perhaps the exception of countries that had real problems with immigration before. If sick people don't crowd your borders in order to take advantage of your medical system, closing borders is just dumb. The virus is already in, the only thing you are stopping is the flow of supplies to handle the disease. Easter is coming. People from all over the world will just move around chaotically to spend this religious holiday with their family. It will cause a huge spike in the number of sick people and will probably prompt some really stupid actions taken by governments all over the place. One could argue that religion is dumb at all times, but right now it makes no difference. It's just an acceleration of a process that is already inevitable, Easter or no Easter.

  Statistics again: look at the numbers and you will see that countries get an increase of 30% in infected cases every day. It's an exponential curve. It doesn't care about your biases, your myths, your hopes, your judging. It just grows. China will get infection cases as soon as travelling restrictions relax. Consider the ridiculous situation where one somehow protected their country against infection when the whole of the world went through a global pandemic. It doesn't even matter. It's not even healthy, as sooner or later that virus will affect only them. The best they can do is manage the situation, bottleneck it so that the medical system can cope with it.

  Do you know what the most important supply chain is in this situation? Medical supplies. A lot of countries get these from China and India. Because they are cheaper. So they can sell them to you at ten times the prices and make those immense profits that generated the name Big Pharma. It's not a conspiracy theory, it's common knowledge. What do you think happens when you close your borders with China and India?

  In this situation, the globally economy will stagger. It will be worse than the 2008 crisis. But while that was a crisis generated by artificial and abstract concepts that affected the real economy, that of people working for other people, this one comes as real as it gets, where people can't work anymore. That means less money, less resources, scarcity of some resources, less slack to care of the old and sick in your family. It's a lose-lose situation: the most affected by the pandemic will be affected either by people not being able to care for them or people giving them the disease while caring for them because they must make much more effort and human contact to get the supplies needed. Now, some countries can somehow handle that by employing a healthy transport infrastructure and care system, but in others, where they can barely handle normal quantities of sick people that come to hospitals themselves, they will never be able to cover, even if they wanted to, the effort to give supplies to previously affected people.

  So does that mean you have to go to the supermarket and get all the supplies you might need for months to come? I am afraid to say that it does. The reasonable way to handle this is for the governments of the world to ensure supply and financial support for everybody. Then people wouldn't need to assault shops to get the last existing supplies. If you can trust your government to do that, by all means, trust you will always have a nearby shop to sell you the goods you need to stay alive and health. But I ask you this: if you got to the farmacy and bought their entire stock of some medicine that you might need and then you hear your neighbor, the person you greeted every day when you got to work, died because they couldn't get that medicine, what then? What if you hear they need the medicine now? Will you knock at their door and offer it to them? Maybe at five time the price? Or maybe for free? What if you are the neighbor?

  And you hear that some country has isolated the virus and are making a vaccine. Oh, it's all over, you think. But before they even start mass producing it, they need to test it. People will die because of how overcautious and bureaucratic the system is. People will die when corners are cut. People will die either way. It will take time either way. This thing will be over, but not soon. After they make it, you will still have to get it. That means supply chains and money to buy things.

  Bottom line: it's all about keeping systems going. In your body, the immune system has to be working to fight the disease. In your country, the economy must be working in order to handle the effects of the disease. Fake cures and home remedies are just as damaging as false news of the crisis not being grave, getting over soon or going away by itself.

  Here is a video from a medical professional that is saying a lot of the things I've listed here:

[youtube:E3URhJx0NSw]

  One more thing: consider how easy it was for this panic to lead to countries announcing national emergency, a protocol that gives extraordinary powers to the government. A few dead here, a few sick there, and suddenly the state has the right to arrest your movement, to detain you unconditionally, to close borders, to censor communications. Make sure that when this is over, you get every single liberty back. No one it going to return freedom to you out of their own good will.

Summary

Once you finished with the foundation, it doesn't matter who you call to architect your house or fix problems you might have. Businesses and software are exactly like that. Think hard about your foundation, it will save you a lot of effort later on. I've been working in a lot of different places and was surprised to see they didn't know there are other ways of doing things. I distill the foundational principles one needs for a good software solution and maybe not just software:

  • Separation of concerns - processes, components and people should be able to function in isolation. If you can test they work when everything else is shut down, you're good. People should only do what they are good at. Components should do only one thing.
  • Cleanliness - keep your code readable rather than efficient, your process flow intuitive, roles and responsibilities clear. Favor convention over documentation, document anything else.
  • Knowledge sharing - Allow knowledge to be free and alive in your organization by promoting knowledge sharing, collaborative documentation, searchability.

Intro

  I am not the greatest of all developers or architects, but I am good. I know how things should be and what they should do in order to reach a goal. When people ask me about software, my greatest gaps are around specific software tools or some algorithm, not the general craft. That is because of several reasons: I enjoy my work, I've been really enthusiastic in my youth and sponged everything I could in order to become better and I've worked in many different types of organizations so I know multiple ways in which people have tried to do this. As I grow older, the last one may be my most valuable skill, but I am yet to find the employer to realize this.

  You see, what I've learned from my career so far is that most businesses live in a bubble. Used to not only learn software development as I am working on some task, but also network with other people in the craft from all across the business, I kind of expected every other developer to be like that. Or at least the senior devs, the dev leads and architects, maybe some managers. But no, most of the time, people are stuck in their little position and never stray from it. They may invoke life work balance, or they are just burned out, or they just don't care enough, but more often, they haven't even realized what they are missing. And that's the bubble. A bubble is not a prison, is just a small area in which people stay voluntarily and never get out of.

  This is why gaming development is so different from business app development. That is why development in an administrative business with a small software department is so different from development in a software company. It is why development in small shops is so different than in large software companies. Sometimes people, really smart people, have worked for a long time in only one of these ecosystems and they only know that one. They can hardly conceive of different ways to do things.

  So this is why I am writing this post, to talk about the foundations of things, that part that separates one from the other, forever, no matter what you do afterwards. And this applies to business, people organization, but especially well to large software projects. You see, if you start your solution badly, it will be bad until you rewrite it. Just like a building with a weak foundation. It doesn't matter you bring the best workers and architects afterwards, they will only build a wonderful house that will fall down when the foundation fails. You want to make a good thing, first plan it through and build the greatest foundation you can think of and afford. It's much easier to change the roof than the foundation.

  And you wouldn't believe how many times I've been put in the situation of having to fix the unfixable. "Hey, you're smart, right? We started this thing a million years ago, we thought we would save some money, so we got a bunch of junior developers to do it, and it worked! But then it didn't anymore. Fix it!" And I have to explain it to them: you can't scale duct tape. You can go only so much with a thing held together by paper clips, chewing gum and the occasional hero employee with white hair and hunched back and in his twenties.

  Now of course, to an entitled senior engineer like me any software evokes the instinct to rewrite it in their own image. "Also, get some juniors to carve my face into that hill over there!". Sometimes it's just a matter of adapting to the environment, work with what you have. But sometimes you just have to admit things are beyond salvation. Going forward is just a recipe for disaster later on. It's the law of diminishing returns when the original returns were small to begin with. And you wouldn't believe how many people agree with that sentiment, then declare there is nothing that can be done. "They won't give us the budget!" is often muttered. Sometimes it's "We only need this for a few years. After that we start from scratch" and in a few years some "business person" makes a completely uninformed cost and gain analysis and decides building up from existing code is cheaper than starting over. But don't worry, they will suuuurely start from scratch next time.

  Sometimes the task of rewriting something is completely daunting. It's not just the size of it, or the feeling that you've achieved nothing if you have to start over to do the same thing. It's the dread that if you make the same thing and it takes less effort and less money and it works better then you must be inferior. And it's true! You sucked! Own it and do better next time. It's not the same thing, it's version 2.0. You now have something that you couldn't have dreamed of when building version 1.0: an overview. You know what you need, not what you think you will need. Your existing project is basically the D&D campaign you've played so many times that it has become a vast landscape, rich with characters and story. You've mapped it all down.

  This post is an overview. Use it! To be honest, reaching this point is inevitable, there will always be a moment when a version 2.0 makes more sense than continuing with what you have. But you can change how terrible your software is when you get to it. And for this you need the right foundation. And I can teach you to do that. It's not even hard.

Separation of Concerns

  Most important thing: separation of concerns. Components should not be aware of each other. Compare a Lego construction to a brick and mortar one. One you can disassemble and reassemble, adding to it whatever you need, the other you need to tear down and rebuild from zero. Your foundation needs to allow and even enable this. Define clear boundaries that completely separate the flow into independent parts. For example a job description is an interface. It tells the business that if the person occupying a job leaves, another can come and take their place. The place is clearly defined as a boundary that separates a human being from their role in the organization.

  Software components, too, need to be abstracted as interfaces in order to be able to swap them around. And I don't mean the exact concept of interface from some programming languages. I mean that as loosely as one can. A web service is an interface, since it abstracts business logic from user interface. A view model is an interface, as it abstracts the user interface logic from its appearance. A website is an interface, as it performs a different task than another that is completely separated. If you can rewrite an authorization component in isolation and then just replace the one you have and the application continues to work as before, that means you have done well.

  Separation of concerns should also apply to your work process and the people in it. A software developer should not have to do much outside developing software. A manager should just manage. People should only be in meetings that bring value and should only be in those that actually concern them. If the process becomes too cumbersome, split it up into smaller pieces, hire people to handle each of them. Free the time of your employees to do the job they are best suited for. 

  One important value you gain from isolating components is testing. In fact, you can use testing as a force towards separation of concerns. If you can test a part of your application in isolation (so all other parts do not need to be working for it), then you have successfully separated concerns. Consider a fictional flow: you get on the bus, you get to the market, you find a vegetable stand, you buy a kilo of tomatoes, you get back to the bus, you come home. Now, if you can successfully test your ability to get on a bus, any bus, to get anywhere the bus is going, in order to test that you can buy tomatoes from the market you just test you can find the stand and buy the tomatoes. Then, if you can test that you can buy anything at any type of stand, you only need to test your ability to find a stand in a market.

  It seems obvious, right? It feels that way to me. Even now, writing this post, I am thinking I sound like an idiot trying to seem smart, but I've seen droves of developers who don't even consider this. Businesses who are not even aware of this as a possibility. "We have testing teams to make sure the application is working end to end, we don't need unit testing" or "We have end to end automated testing. For each new feature we write new tests". When you hear this, fight it. Their tests, even if written correctly and maintained perfectly, will take as long as one needs to get on a bus and go to the market. And then the other test will take as long as one need to get on a train and get to the airport. And so on. End to end testing should exist and if you can automate it, great, but it should be sparse, it should function like an occasional audit, not something that supports your confidence in the solution working correctly.

  So go for testable, not for tests. Tests often get a bad wrap because someone like me comes and teaches a company to write tests, then they leave and the people in the company either skip testing occasionally or they change bits of the application and don't bother to update the tests. This leads to my next point: clean code.

Cleanliness

  Cleanliness applies to everything, again. The flow of your solution (note that I am being as general as possible) needs to be as clear as possible, at every level. In software this usually translates in readable code and builds up from that. Someone looking at the code should be able to instantly and easily understand what it does. Some junior developers want to write their code as efficient as possible. They just read somewhere that this method is faster than the other method and want to put that in code. But it boils down to a cost analysis: if they shave one second off a process you run ten times a day, they save one hour per year; if another developer has to spend more than one hour to understand what the code does, the gain means nothing.

  Code should be readable before being fast. Comments in code should document decisions, not explain what is going on. Comments should display information from another level than the code's. Component names, object names, method names, variable names should be self explanatory. Configuration structures, property names, property values, they should be intuitive and discoverable.

  And there is another aspect to cleanliness. Most development environments have some automated checks for your code. You can add more and even make your own. This results in lists of errors, warnings and notifications. On a flow level, this might translate to people complaining about various things, some in key positions, some not. Unit tests, once you have them, might be passing or failing. It is important to clean that shit up! Do not ignore warnings or even notifications. You think a warning is wrong, find a way to make it go away, not by ignoring it, but by replacing the complaining component, marking it specifically in the code as not a valid warning and document why, run all the tests and make sure they are green or remove the tests that you think are not important (this should not happen usually). The reason is simple: in a sea of ignored warnings you will not see the one that matters.

  To be perfectly clear: by clean code I don't mean code that follows design patterns, I don't mean documentation comments on every property and method, I don't mean color coded sections (although that's nice). What I mean is code clean enough to read without cringing or having to look in ten other places to figure out what it does. If your hotdog falls on that code you should be comfortable enough to pick it up and continue eating it.

  Cleanliness should and must be applied to your work process. If the daily meeting is dirty (many people talking about unrelated things) then everybody is wasting time. If the process of finishing a task is not clear, you will have headless chickens instead of professionals trying to complete it. If you have to ask around where to log your hours or who is responsible for a specific job that you need done in order to continue, you need to clean that process. Remove all superfluous things, optimize remaining ones. Remember separation of concerns.

  Cleanliness extends to your project folder structure, your solution structure, your organizational structure. It all has to be intuitive. If you declare a principle, it should inform every query and decision, with no exception. "All software development people are at the fifth floor! Ugh... all except Joe". What if you need Joe? What if you don't know that you need Joe, but you still need him? Favor convention over configuration/documentation, document everything else. And that leads me to the final point: knowledge sharing.

Knowledge Sharing

  To me, knowledge sharing was always natural. In small companies there was always "that guy" who would know everything and couldn't work at all because people came to ask him things. In medium companies there was always some sort of documentation of decisions and project details. In large companies there were platforms like Confluence where people would share structured information, like the complete description of tasks: what they are about, how decisions were made, who is responsible for what, how they were split into specific technical tasks, what problems arose, what the solutions were, etc. And there were always your peers that you could connect to and casually talk about your day.

  Imagine my surprise to find myself working in places where you don't know what anyone else is doing, where you don't know what something is and what it is supposed to do, there are no guidelines outside random and out of date Powerpoint files, where I am alone with no team, brought in for problems that need strong decisions in order to fix but no one is willing to make them, and already I have no idea who should even attempt to. I solve a common problem, I want to share the solution, there is no place to do that. People are not even in the same building as me. Emails are come and go and no one has time to read them.

  Knowledge should live freely in your company. You should be able to search for anything and find it, be able to understand it, contribute to it, add more stuff. It should be more natural for the people in your company to write a blog post than go for coffee and complain. It should be easier to find and consume information from people that left the company than to get it from colleagues at the desk next to you. And maybe this cannot be generalized to all departments, but it is fucking important: people in the office should never need to open Microsoft Office (or any similar product suite). I can't stress that enough.

  You should not need printed documents, so no need for Word. Excel files are great for simple data tasks, but they are not specific. If you need something done repeatedly and you use Excel sheet, it is probably better to build a tool for it. Don't reinvent the wheel now, but use the best tool for the job. And there are better and more modern tools than Powerpoint files, but I will allow the use of them because, in the context of knowledge sharing, everyone should feel free and confident enough to make presentation for the team. My tenet still stands, though: the Powerpoint file would be used in a presentation. Hardly anyone else should need to open it. I mean, there would be a video of the presentation available, right?

Vision

  Imagine a park. It is sunny, birds are singing, there are people walking on hardened dirt walkways, cyclers biking on their asphalted bike lanes, benches everywhere, with a small notepad attached to them that people can just pick up and read or write their own notes. Places in the park are clearly indicated with helpful arrows: children playground, hotdog stand, toilet, football field, bar, ice ring. Everything is clean, everybody is doing what they do best, all is good. You feel hungry, you see the arrow pointing towards the hotdog stand, you walk there calmly and ask for one. The boy there give you a bun and a wurst. He is new, but he has a colleague that knows exactly how much mustard and ketchup to put on the hotdog. He even asks you if you want curry on it. 

  Imagine a park. It is sunny, birds are singing. Some walkways start of as asphalt, then continue as dirt. Some stop suddenly or end in a ditch. There is a place that serves hotdogs next to a toilet. You have to ask around to find out where to find it. You get lost several times, as some people don't know either, but they still come with an opinion, or they are just misinformed. You get tired, but you can't sit on a bench, they are all taken and there are so few of them. You have to look both ways several times before you walk to the stand, because of cyclers. You stand in a line, then order a hotdog. The boy there gives you a bun with a wurst in it. You ask for mustard, but the boy is new and it takes him a while to find it after looking for some paper that tells him where it is. You have to dodge a football that was coming at your head. Someone flushes the toilet.