Sunday, January 14, 2018

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.

Saturday, January 13, 2018

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! :)

Sunday, January 07, 2018

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

Thursday, January 04, 2018

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

Book cover 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.

Wednesday, January 03, 2018

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

Book cover 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.

Monday, January 01, 2018

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

book cover 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.

Sunday, December 31, 2017

The Dream

So I am having this dream. Or I am so having a dream? Anyway, weird fucking dream, like Coscarelli meets Happy! via those explaining videos where someone talks very fast while drawing what is going on while an obnoxiously and totally unnecessary music plays joyfully in the background. Although that was mostly a way to graphically depict my inner thoughts... in the dream... so that I could understand what I was thinking. The dream concerned altered states of mind, biology, physics, logic, anything really.

Everything was altered, but also very real. It was all real. One moment I am doing something horrible, like killing innocent bystanders by throwing them from a tall place onto other people that were trying to make me stop killing people or pushing terrified (and annoying) kindergarten kids out of my way, my wife in tow, enjoying every second, the other I am home, waiting for the cops to show up, amazed that I got away, only for someone to force very strong psychiatric meds down my throat and make me realize that it was all a fantasy of someone who isn't even who I thought I was. Then I wake up and I am a terrible (and amusing) force of evil trying to understand both who I am and why do the people that force feed me medicine look like my parents, while they clearly are not. I terrify them and so I can tell them what to do, maybe they won't discover I am as terrified of not knowing what the hell is going on. But I will be having fun, as a God given right.

And then it switches again, with a good friend arranging the trip that will take us out of the country, on a touristic toury tour that me and the wife will use to escape the authorities that no doubt are looking for us right now because we killed all those people in probably the very tour we are organizing because they were standing in our way and we were bored. And in the dream I realize that every such permutation of reality is part of the dream, but also very real. I could stop at any moment and that would be reality for a while. So I switch again, I escape, barely conscious of where or who I am, I jump some stairs, a dog is chasing me, but I know he knows me and wants to play, I get out of the building, pretend to be a PTSD affected veteran to get clothes and stuff, including guns, until someone asks me where I served. So I just have to take out the guns and commandeer a vehicle. The fact that the people in the car are sexy women who can't help feeling terrified and also strangely excited by this display of violence is surely coincidence. And then cops show up and the girls run away. I shoot after them until the bullets run out, while the cops are weirdly apathetic, standing next to me on the hood of their car. "Are you done?" they ask, and I sigh and acknowledge and give up, allowing to be handcuffed and thrown into a car that doesn't seem to be a police car. And a woman is there, old, crow feet eyes, one of those people who can laugh at anything, you know, smoking nonchalantly.

I realize it is all part of the great machine that revolves reality, like one of those game machines that gives you a prize on TV when they rotate it, only it seems the real good prizes are never chosen. And I know now what this is and I look into her eyes and I know that she knows I know, but maybe she could stop smoking, since it irritates me, and she laughs. Told you she could laugh at anything. I am proud of not panicking, of taking it all in and being cool with it, I can see the old woman nodding appreciatively, too. "So what now?", I ask, but I already know the answer.

It is clear to me that anything could happen, and it does happen, the whole world dies and I get that fast talking graphic that explains why everything alive is not alive anymore except one thing, me. And it doesn't make any sense at all other than what if it could happen and if it could happen why wouldn't it and I am it, the thing that can breathe what nothing else can and still draw fancy pictures of what happened while explaining itself how it survived. But then surely I could animate one of the dead, just for fun, so it can be irritated (as I was) at how fast I am talking when depicting my inner monologue. And I try variations on the same theme, all wonderful and terrifying and apparently dangerous, only that I can change them even after something bad happened to me, so they're not. I especially enjoy the ones where I am enjoying what I am doing, even if it doesn't seem like something anyone would enjoy. I congratulate myself for choosing a reality I enjoy what I am doing so much that I need to congratulate myself about it.

I am trying to describe the experience as accurately as possible while fully knowing that the memory of it is fading and that even if I would still be part of it I couldn't express it fully. It stank of multidimensionality, it purposely lacked any purpose, anything at all was possible and it was, overlapping and existing at the same time and space. It had a soundtrack, and even if I knew, for example, that Come Together was taken directly from my recent viewing of Justice League, I also knew that it had a completely different meaning in this context, except maybe for the YouTube bots who would flag my whole life as copyrighted. There was no moral to it, no catharsis, no epiphany. It refused definition and I relished it. It was the polar opposite of a spiritual experience: no hope, but infinite potential, no lessons to be learned, but filled to the brim with experience, no gods other than myself.

I could have been anyone, anything, everything, but I chose the reality where I would wake up, recognize the room, the laptop, and blog about it. Maybe only then see life extinguished, just for the kicks of knowing that everything I spent horrible confused lonely moments (while aware of the singleminded and boring nature of this chosen reality) typing was pointless, no one would read it, even attempt to understand it and fail miserably, because the Internet would still work for a bit, but everybody would be dead. Fortunately it was all a dream, and you will read and fail to understand this post, not even the least bit grateful for being all alive and shit and not the punchline to a joke that I alone (pardon the pun) would find funny.