PreterNatural (Carter Bailey #1), by Matt Hilton

I really tried to read and enjoy this book, which is highly rated and reviewed, which makes me wonder whether there is something wrong with me. Whatever the reason, I couldn't even finish it. Everything in this book is grating my senses, from the writing style to the scenes details, from the editing to the basic story outline. If you've read Dexter (the book the TV show is based on, not the TV show itself) you will have found a similar plot, but as I thought that book was bad, this one felt worse. I can't imagine who in their right mind would give this a full rating.

I've found a blog post by the author, Matt Hilton, that describes the unfortunate period in which he wrote the book. His seventeen old daughter just died. Maybe that affected the writing style, maybe the fact that it was written in several versions that then were edited into this one. I don't know. He has my sympathy for his loss, but not for PreterNatural. In his situation I would have expected to at least get the grief part right. Instead the character lives with the mind of his family's murderer in his head and has humorous dialogues with it.

It's a bad book. I won't recommend it in any way. Considering this is the first and only book in the Carter Bailey series, I think even the author probably agrees with me.

Read More

Renouncing New Scientist

New Scientist is a science oriented news site that has existed in my periodic reading list for years. They had great content, seemingly unbiased and a good web site structure. But they went greedy. Instead of one in ten articles being "premium" now almost all articles I want to read are behind a pay wall. While I appreciate their content, I will never pay for it, especially when similar (and recently, event better) content can be found on phys.org or arstechnica.com completely free. So, I feel sad, but I need to remove New Scientist from my reading list. I understand there is an effort in what they do and that quality requires investment and cost, but brutally switching from an almost free format to a spammy pay wall is unacceptable for me.

Read More

LaRose, by Louise Erdrich

The quote So what's the moral of this story? - Moral? Our stories don't have those! perfectly describes the narrative of LaRose. The book is well written, there are a lot of very well described characters that go through their own arcs that intersect often and in uncommon ways, but you are just left with knowing a bunch of people better than before you began reading the book.

Louise Erdrich describes an intertwining world of traditions, history, real life, strong emotions, cool heads and above all, the feeling that it all somehow makes sense (without it actually reaching that point). It could have easily been completed at the middle of the book or continued for a few more volumes, it lacks finality, with the last chapter feeling forced in the way that it tried to complete some concepts. I can imagine Woody Allen saying "It involves Native Americans" after reading it for twenty minutes.

Given what I've said above, it's difficult for me to rate such a book. I enjoyed reading the words, but did not enjoy the book. I ground the words into submission with the whole intention of finishing the story and then reading something else. I loved the characters, even if the myriad of details about them did not interest me in the least. I learned about a people that is, as the book itself recognizes, rapidly going extinct. Is this a good book? Yes! Would I have read it if I knew what I know now? Probably, because I am vain like that. Should I have read it? Probably not.

Bottom line: I will rate it above average, because it most obviously is, but that's about the only reason.

Read More

A new way to program for teams with management in different timezones

I have invented a new way to write software when people who hold decision power are not available. It's called Flag Assisted Programming and it goes like this: whenever you have a question on how to proceed with your development, instead of bothering decision makers, add a flag to the configuration that determines which way to go. Then estimate for all the possible answers to your question and implement them all. This way, management not only has more time to do real work, but also the ability to go back and forth on their decisions as they see fit. Bonus points, FAPing allows middle management to say you have A/B testing at least partially implemented, and that you work in a very agile environment.

Read More

Thoughts on code review

A year and a half ago, as I was going from miserable job interview to the next, I was asked what I think about code review. At the time I said that I thought it was the most important organizational aspect of writing code. I mean you can do agile, waterfall, work on games or mobile apps or business applications, use the latest or the oldest, the best or the worst technology and still code reviewing helps. I still think that way now, but recent experiences with the process have left me thinking of refining my understanding of it. This blog post is about that.

The Good

Why is code review good? The very first thing it does is that it forces you to acknowledge your work. You can be tired and fix one little thing in a lazy way and forget about it and it might work or it might break something, but when you know you have to publish what you did you do things less lazy, more documented, more thought out. It doesn't matter that no one will ever look carefully on the review, as that you are thinking there is the possibility of it.

Second, and obvious, is that any mistakes you made are more likely to come to the surface when someone looks at the code. It doesn't mean people blame you for mistakes, it means the mistakes don't come and bite you in the ass later, when your work is supposed to be making money for some poor bastard somewhere. This is very important because we tend to work on systems more complex that we can or are willing to understand. If a group of people who together understand the system is reviewing work, though, you learn not only about the inevitable code errors you introduce, but also about the errors in judgement or understanding or in the assumptions you made.

Then there is the learning aspect of it. Juniors learn from seniors reviewing their work, they learn from code reviewing each other and everybody learns from reviewing work made by anyone else. It opens up perspectives. I mean, you can review some method that was copy pasted four times in order to do the same thing to four different objects and learn how not to that, ever! No matter how much you would want to when coming in at work hungover and hoping for death a little. For example, I've only recently learned to comment on my own code review before submitting it. Some might say comments in the code should do that, but sometimes you need more, as anchors for discussion, which obviously cannot be carried in code comments. (well, they can, but please don't do that)

And there is more! You get documentation of the code for free. When someone doesn't understand what the hell is going on, they ask questions, which leads to you answering in whatever code review software you use. This will remain there for others to peruse long after you've left the company and went on to slightly RGB shifted pastures. I still dream of a non intrusive system that would connect reviews to the code in your IDE, so you can always see a list of comments and annotations for whatever you are looking at.

One of the benefits is that code review makes everyone in the team write code in the same way. For better or worse. I will detail that in a moment, but think about what it means to read a piece of code, trying to understand it, then switch to the next one and see it written in a completely different style. You waste a lot of time.

Finally, I think the confidence code review gives you can lead not only to better code, but also faster code. More on this comes next. This is controversial, but I think you can use code review to check your code, but only if you trust the reviewers. You might fire off commit after commit after commit, confident that your peers will check what you, normally, would have to double and triple check before committing. It's risky, but with the right team it can do wonders.

The Bad

OK, so it's a great thing, this code review stuff. I knew that, you knew that, why are you wasting your finger strength? Well, there is a dark side to code review. I've heard some purists insist on some rules for code review with which I am not completely comfortable with, for example. I invite said purists who also read my blog to come rant in the comments below. Also my recent experience which touches on said rules and introduces others. Let me detail the bad.

There are programmers and programmers, projects and projects, management and management. Where one developer writes some code and hopes people will look at it carefully and instruct them on what they could improve, some people just lazily write something that kind of works, thinking whoever will do the code review will also do the work of making their code remotely usable. Where in some projects developers remain working after hours because they want to see their code do good and the project succeed, in others people couldn't care less: they do their time and break the door when the bell rings. Don't expect careful code reviews then. And there is the management issue, which might protect the developers from anything unrelated to coding or they might pester them with meetings and emails and processes that break concentration, waste time and surely do not help with the attention span of a code reviewer. But in all of the worst cases above, code review is still good, just less effective.

One of the rules I was talking about above was to never commit code unless its code review was accepted. Note the bold font on the never. It was like that whenever I heard the rule. Sounded bold. But I completely disagree with that.

First, if you have developers that you can't trust to commit something, don't let them commit. Either find someone better or do something with their privileges, a system that prevents them from committing. Same goes for people you can't trust to read the code review and update the code afterward a bad or defective commit.

Second of all, you might work on a file that should appear in more code reviews. No, the system where you do the work, ask for review, then shelve the files so you can work on the next thing doesn't work! It takes time, concentration and leads to bad resolves that break your code. Just commit the first thing and move to the next. When your review comes back full of bugs, just finish what you are working on, commit that, then return to the code and implement fixes for the issues found. That is a problem for code review software that can't understand a file committed after changes were made to it doesn't mean you want to include all the changes since time immemorial. That's a software issue, though. Just create a new review and somehow link it to the other, via comments or notes. Creating a personal branch for all developers or other crazy ideas like that are also crap.

Not committing work that you've done means delaying your other work, testing, finding problems in it, etc. Having to juggle with software in order to submit to a rigid process that is indifferent to the overall pace of development and the realities of your work is stupid. Just work, commit, review, test, rework. It's what we do.

It's also, I think, an error in judgement to force code review. As good as I think it is, you can work without it. It is an optional process, so keep it that way. Conditioning development on an optional process makes it mandatory. It might sound like a truism, but people don't seem to realize things unless you articulate them.

And then there is human nature. If you ask me to code review for you, I will stop what I am doing and perform the review, because if I don't, you can't commit. It hurts my work, because it breaks my concentration. It hurts your code review, because I am not focused enough. Personally I am best at reviewing in the morning. None of the organizational crap happened yet, no meetings, no emails telling me to write other emails, no chat messages asking questions that I have no desire to answer. I am rested, I am a bit pumped from making the minimum physical movements required to get me to the office and so I am ready to singlemindedly focus on your review. It shouldn't matter that you committed the code yesterday. I'll get to it when I get to it.

The Ugly

The ugly is not only bad, but also disturbing. It's not a characteristic of the code review per se, but is more related to the humans involved in the process. Code review has some nasty side effects on certain people and in certain situations. Let's discuss this for a bit.

I was saying above that it's good everybody writes in a certain way. That actually may stop people from innovating in the writing of code. Do it this way, that's the pattern we're using, you will hear, without the slightest hint of the possibility to improve on that pattern. Same thing might happen with new ideas that you might feel need to be introduced in the project, or some refactoring, or some other creative work that would make you proud and motivated to continue to do good work. As I said above, it's a people problem, not a process problem, but when it happens, it stifles innovation, creativity and ultimately the fucks you give on what happens to the project as a whole.

Code reviews, like any other communication medium, may be abused. People may be attacked or shamed by others who don't really like them. They might not even be junior and senior, as it might involve time in the firm rather than technical skill, or some other hierarchical or social advantage. Ego fights can also erupt in code reviews, which can exacerbate the problem if they are blocking reviews. Arguments are good, pissing contests are ugly, that kind of thing.

Reviews waste time. That's really not a people problem, it's a process problem. All processes, that is. You need to put in the work to do a good review. Just glancing over and saying "it looks good", without trying to understand what the code is supposed to do, is almost worse than refusing to do the review. I am plenty guilty of that. Instead of thinking about what the guy did and trying to help, part of my brain just keeps rummaging on what my current development task is. This is another argument to separate reviewing from code writing. You need your zone for both. When code review waste rather than spend time, that's ugly.

Finally, I think one major issues with code review is that it encourages lazing off on unit testing, proper testing, refactoring and even simple writing of the code. This is a management issue, mostly, and it's ugly like vomited shit. When people write horrid code filled with bugs assuming that code review will fix their lack of interest, that's ugly. When you are urged, more or less vigorously, to skimp on the unit or manual testing because the code review was accepted, that's ugly. But when you are trying to improve the general quality of the code and the answer is either that you don't have time for this or that any change is unnecessary because the code review passed or even when you are unwilling to do the refactoring, knowing what a hassle will be to send it through review, that's damn ugly. It means you want to do more than your share and you get stuck in a process.

And on that note, I end this wall of text. Process before people is always ugly.

Comments and opinions, if you dare! :)

Read More

Powerful features in Javascript ES2015: enforcing required parameters

I just read a very cool article (Understanding Default Parameters in Javascript) and my takeaway is this smart piece of code to enforce that a parameter is specified:

const isRequired = () => { throw new Error('param is required'); };

function filterEvil(array, evil = isRequired()) {
  return array.filter(item => item !== evil);   
}

So all you have to do is define the isRequired function in a shared library file and then use it in any function that you write.

Are you a bit put off by the fact you can use functions as default parameters? Welcome to Javascript, a language that seems designed by Eurythmics

Read More

The Fox Was Ever the Hunter, by Herta Müller and Philip Boehm

What the hell have I tried to read? It felt like a Google bot trying to describe random YouTube videos, a meaningless brainstorm of a neural network trained on black and white images, an intentional insult to anyone attempting to make sense of the book. At a mere 260 pages (on my smart phone) I thought that no matter what the subject or writing style, I would finish it, but after 60 pages of understanding nothing and using all my will power to continue, I've decided to call it quits.

It "helped" that I had no idea what I was reading. I just picked a book at random from my library and started it. I didn't know Herta Müller was a Nobel laureate for literature, I didn't know she was part Romanian, nor did I know of the Romanian movie based on the book. I could just read and enjoy the content. Or not. I don't know how I can describe this book in a way that is comprehensible. I had to read the synopsis of the movie in order to understand what The Fox Was Ever the Hunter tried to say! I am Romanian, I've lived through communism, even if I was just a kid at the time, I should have no reason not to at least understand the basic plot of the book, but I didn't get it. Eyes just glossed over the pointless descriptions, unnamed characters identified by body characteristics or clothing, useless details and unrelated chapters. One chapter ended in "The comb's teeth were blue." It wasn't a particular comb, it didn't feature in any interesting way in the story (had it been one), it was just a piece of detail that should have conveyed the lack of interesting things in the gray communist era or something. The book is filled with stuff like that.

Bottom line: I didn't find any positive thing to say about this book. No sentence that made me feel something, no interesting fact, no eye opening writing style, no plot or character that made any sense or brought any pleasure as I was reading it. It was like being so thirsty that you try to drink desert sand. It works just as well as this book. I hate it with fervor.

Read More

Persepolis Rising (The Expanse #7), by James S.A. Corey

Persepolis Rising went into an interesting direction. One that I don't particularly like, but interesting nonetheless. The seventh book in the Expanse series is happening about 30 years after the sixth. You have to remember that lifespan is slightly longer in the future, so that's not a show stopper or a revamp with new characters. It also featured yet another condescending asshole who wants to rule everything using the protomolecule.

Now, the thing I love about The Expanse is the locality in the Solar System, the exploration of the near future society of space that is mere decades away from now (assuming we discover the Epstein drive, hmm...) Moving the action on other planets in other systems, more into the future and messing with alien tech doesn't help that. Instead it is turning it into yet another Stargate or similar franchise, where they just up the ante until there is no more up and people are bored. The authors have dodged the same bullet a few times in the past, though, so it just may be that they are aware of this and careful to thread the fine line between hard sci-fi and the ability to relate to what is going on in the story.

There isn't much about the story that I can tell without spoiling it. Some dudes want to go Roman Empire on the 1300 solar systems available and "civilize" humanity. Holden and the crew of the Rocinante have different ideas. However, the book basically ends in a cliffhanger so if you hate that kind of stuff, I recommend you postpone reading it until the eighth book is published. I liked the writing, the pacing and again I read it in mere days. Is it a masterpiece, not really, but it reads well. Now I have to wait until I can get my hands on the next book to see where the story is going, but considering that plans are to end the series with the ninth book, I wonder if I shouldn't just wait until they are all written and spare myself the misery of ending up with another, larger, cliffhanger at the end of the next part of the story.

Conclusion: I liked it, but I would much rather have read another dozen books about the Belters and how they made their home in the asteroids. If you think about it, the last few books did away with even the pretense of space colonization realism and it is always a small pain seeing how the stories always favor planets, which are not only less rich with the type of materials needed in space, but also have a lot more limited space. Asteroids can support trillions of people, and that in this Solar System alone. But that's another rant altogether. Just make sure you calculate the exact energy and reaction mass you want to spend in reading and then waiting for the next part of the story, which may not be published yet.

Read More

Babylon's Ashes (The Expanse #6), by James S.A. Corey

I was left a little disappointed by the books in the Expanse series. The TV show was doing great with the ideas in the books masterfully woven together, while the books were turning more and more into pulp. The greatest sin, for me, was that they took the action out of the Solar System, which was the main quality of the Expanse concept. Well, I am happy to report that, without a large increase in quality, Babylon's Ashes has returned to be a Solar System story, complete with intrigue, space war, politics and the Rocinante finding itself in the middle of everything important, again. It may be formulaic, but it's the formula that I like! Plus, it is clear that the quality of the TV show is feeding back into the books, which is great.

So Holden and Naomi need to deal with the fact that her psychotic ex-boyfriend and father of her child is a mass murderer who is leading the whole Solar System to war, chaos and finally starvation. Some characters die, which put Holden even more in the spotlight. Quite pointless characters are preserved, like Prax, which I personally despise, and others are added, like the pirate captain Michio Pa. In this book, the authors are tying up the loose ends: the state of the Solar System, the war, the situation at Medina station. The path toward the future is still in the balance at the end of the book. It's almost like asking "so, do we do cool Belter culture Solar System stories or do we pulp it out in the alien worlds?". Well, I will read Persepolis Rising next.

Conclusion: I liked the book enough to read it in a day or two and it made me want to read the series again.

Read More