Reviewing code the wrong way   Leave a comment

Most companies today mandate a code review. It makes sense: while writing a substantial feature might take a week, reviewing it might take an hour; with a fraction of the time investment, you could in theory double the number of eyeballs that approve of the change, all the while focusing on eradicating new bugs or rewriting the change so as to avoid future bugs. Moreover, the reviewer could be a much more experienced engineer, which might not have the time to code this feature by herself, though it would have probably taken her less time.

Only at Google (I love calling out positive experiences) I ran into a thorough, thoughtful, positive, exact code review process [with the exception of code styling]. Once everyone’s in agreement on how to do reviews well, it’s easy to make sure a new engineer falls in line. However, it’s so much easier to not do them well. Let me categorize the reasons for having a sub-optimal code review process into three types:

1) Hard to track code changes – the developer did something wonderful, perhaps solved a really complex bug in a single line of code change; however, he then went and refactored a bunch of files and renamed some methods, all in the same change. Now, the reviewer cannot really appreciate the beautiful bug resolution; on top of that, the reviewer might actually focus on making sense of and approving the refactoring, totally missing the complex bug situation. Actually, it’s more likely to be the reverse — you wrote some piece of code, introducing a rather complex bug, which might have been discovered by a fresh pair of [professional] eyes, were it not for you adding many other trivial changes, causing the reviewer to miss the important mishap. This category also includes misuses of tools, such as doing git rebase during a code review — simply put, git rebase rewrites your changes, causing the reviewer to lose track of what she already reviewed last time; don’t blame her if she doesn’t invest the same amount of effort re-reviewing the same change again. Lastly, sometimes the difficulty to thoroughly review the important parts comes from your current coding practices. Let’s say a test needs a fixture, which is, say, ~ 200 lines of a json file; don’t expect engineers to actually review this fixture; and the more such fixture files you collect, the less confidence you should have in the tests; I’d recommend thinking how to change the tests to not have to rely on such occasional haphazard code drops.

2) Superficial reviews – maybe it’s ego, maybe it’s being vocal, maybe it’s being too green, but many people devolve code reviews into nit-picking about code style (as an extreme example). Obviously, this is not why we’re investing precious time going over code changes. In fact, such tasks should be automated: code style ⇒ automatic code formatting, common mistakes ⇒ lint checks. Instead, one should focus on the crux of a change — is it needed? is the solution sound? is it written in a maintainable way? is it well tested? Commenting about smaller issues is okay too, but start with the big things; if you drop 20 comments on minute things and once on an important part in the same code review, the developer might spend a lot of time fixing up the small things, only to discover later that they have to throw it all away because of the big problem; frustration is how you get people to stop caring about or even avoiding code reviews. What’s worse, the developer might miss or down play the importance of the one big thing, which is likely to come back to bite your future selves.

3) Not taking feedback seriously – a senior engineer reviewed your changes and left one comment: “this will blow up in production”; you read it and comment back: “I will fix it in a follow-up change”; silence ensues. It’s really difficult to know whether you really meant what you said. If the reviewer is adamant, they might make you do it now. But there’s a chance this will slip up. There are other permutations of this situation: “I will add tests later”, “great idea, I’ll create a ticket for it”, “I have added a TODO comment“, etc. This is endemic of putting too much power, the power to take shortcuts, in new engineers’ hands; you should nip this behavior in the bud — it could lead to senior engineers losing trust in code reviews. Making code changes without test coverage and then following up with tests is okay once or twice if business deadlines deem so; but this shouldn’t be the norm; it’s really difficult to anticipate whether the test will eventually be coded; or perhaps having the test now would discover a big problem before users run into it. Like in our financial lives, technical debt accrues with vengeance. If this behavior comes from veterans in the organization, you have an even bigger problem.

On the other hand, it is also important to know when to skip code reviews. For instance, when someone reformats the entire codebase, let her do it as a separate change and only skim the changes (you should probably put more time into reviewing the formatting rules and not the outcome of invoking them). Finally, doing good code reviews is not in all companies’ interest — perhaps for a start up making mistakes carries less weight than to a more established company as there’s less financial implications, less user’s trust at stake, etc.

Epilogue: Do code reviews, but do them well. If you see problems, bring them up to decision makers, for hopefully investing the time in fixing these. Much of this is education, which should be an utmost priority, especially for the low price of reviewing code (i.e. 1 hour of review for 40 hours of coding). Lastly, when you see something, say something. Till next time.


Take life with a pinch of salt   Leave a comment

As I look at my daughters learning about the world by watching and mimicking what others do, think, react, and say about the world, it strikes me that this is how we get settled in our ways. While they are both small and would alter their thinking time and again, nonetheless some actions get calcified in them as they grow and focus on more complex subjects ahead.

It is much easier not having to think hard and justify every thought and action on a daily basis. Things are so ingrained in me that I just can’t think of what might I be doing differently. Inertia sucks. You have to be driven to extreme situations in order to challenge your ways. And I have two amazing examples from my life, so not judging please.

First one: I love Coffee. I am originally from Israel and used to enjoy instant coffee (e.g. Starbucks Via, like about half of the people in the world) from when I was 18 years old, then as I made good money, I mostly switched to espresso-based drinks, mainly espresso and cappuccino. I usually drink two to three cups a day. Then six year ago, my parents bought me a Nespresso CitiZ machine, which was A-M-A-Z-I-N-G (FYI: now I almost never use it, mainly for knowing more about Nestle). I also received a jumbo pack of many flavors of coffee to choose from, with about 20 pods each. Acknowledging my crappy memory, I devised a plan: I’ll drink all pods of a single flavor and if I like it I’ll put aside one pod before I move to the next flavor. After a few months of tastings, I finished the box of pods and left with four favorite flavors. Curiously, I looked up online what they were. To my astonishment, two were medium roast coffee and two were medium roast *decafs*. Thinking back about my long experiment, what happened is I went weeks consuming no caffeine day and night. Then it hit me, if I dispel my own misconceptions about coffee for a minute, I do not really need caffeine. You might be different, but I learnt something new about myself. I brushed off my pride and since then I drink decaf almost exclusively.

Second story. I always hated my hair as it grows wild. I usually cut it 3 or 4 millimeters long, prolonging the time till I’ll look at the mirror and see my hair going to every direction yet again. This two months cycle of cutting, growing hair, hating it, and back again, has been happening to me since when I was about 8 years old. Fast forward to four years ago. I was in Edinborough, Scotland and I had a few hours to kill on a Sunday after all my friends caught their flights back home. I noticed my hair being quite long and messy so I went into a random barber shop — quick aside, I hate going to barber shops and have been cutting my own hair for a about eight years now. The guy who cut my hair told me my hair looked ten years older than I am. He said I had no oil in my hair and that I should try to limit my shampoo usage to twice a week; I don’t think I ever took showers without shampooing and I didn’t know I can control the oil in my hair except by using hair products. As I flew back home I started questioning my daily shampooing ritual. I stopped shampooing for a few days and my hair actually became softer and easier to make sense of. I kept on and it kinda stayed the same. So…. I stopped using shampoos. At all. It has been four years now. I only shampoo after cutting my hair, to get rid of the small hair pieces, and sometimes after I go to the pool (only sometimes!).

If you are a normal person, you most likely felt disgusted twice during this post. It wasn’t easy for me either. However, as I look back and analyze these two situations I come to the same conclusion: in both cases I started doing something regularly, at an early age, without a conscious need, probably copying my parents or other people around me. There are probably many more things I can question in my life. And probably so can you.

Posted February 25, 2018 by Ohad Kravchick (myok12) in Life

Living in an Uncertain World: Keeping Your Options Open   Leave a comment

We all have these moments when we say, “It’s raining :( I wish I would have taken my jacket with me”, “I wished I had filled gas in that last gas station”, “I wish I had bought another bed sheet for my in-potty-training daughter’s new bed”, etc. What’s common to all these self-proclaimed verdicts is that these unfortunate situations are avoidable by better pre-planning, in particular in what I call: Keeping Your Options Open.

The premise of Keeping Your Options Open is simple: when you have several similar options, choose the one which leaves the most unlocked doors. For example, imagine you want to replace a burned out light bulb at home. You go to Home Depot and can either buy a single bulb for $1 or a 4-pack for $3. Maybe you really only need one, so you might buy just one without overly thinking about the options. Or maybe because of the price you are tempted to buy the 4-pack. According to Keeping Your Options Open, you should buy the 4-pack, not because of the price or because you will use the other three eventually, but because if you buy one and it fails — it was broken, you broke it, there’s a bad circuit, etc. — you end up with no light and will need another trip to Home Depot. Unless going to Home Depot is your definition of leisure time, you should probably pay the extra $2 to have four attempts at fixing your lighting situation. Then you can also consider you will likely end up using the other bulbs eventually. Buying two single light bulbs is also a good solution, if four are too many. If the numbers were different, say the store only had a 10-pack for $7, buying a few single bulbs might be a great answer.

Maybe you are an expert in changing lightbulbs and do it for a living. In such circumstances, you might know for sure one bulb will do. Or maybe an expert knows that 50% of the lightbulb installations fail and having two or three bulbs makes more sense. Unless you are an expert, you have a modest intuition as to whether one would suffice. Thus, you shouldn’t bet too much on buying just one bulb and instead easily make the decision to shell out two more dollars, due to the uncertainty of the situation. The same level of uncertainty might exhibit in less controlled environments. A good example is when weather is involved. Should I take a jacket to a trip to Seattle or London? Probably yes. Should I take one to Death Valley or Morocco? Probably not. Should I take one to Prague? I don’t know, so probably yes, or maybe I should do more research. This is also true when people are involved: as I’m making a cup of coffee for myself, should I ask my spouse or roommate if they want too? I should. If she wants coffee but I didn’t ask, I’ll likely end up making another trip to the kitchen, having to wait for the water to boil again, collecting all ingredients again, using another spoon, etc. I’d rather make two drinks up front. If she doesn’t want coffee, asking the question doesn’t hurt. And there are many more random events, in contrast with the more skill based one from before, for example: should I count on the bus being on time? Do I really need to take my purse/wallet with me tonight? You can’t really be expert in these situations, so if given multiple options, choose whatever is safer.

In some cases, it’s not necessarily that you have to decide in advance, but can rather postpone making the decision to later, when hopefully you’ll have better intuition or maybe even facts. Packing a jacket doesn’t mean you have to carry one on you throughout the trip; if the sun is up, it is then that you can decide to leave the jacket at the hotel. Not bringing your jacket removes such future options (let’s say buying another jacket is not a good outcome due to the price). That’s why I have a spare jacket in my car, and a picnic blanket, a child’s scooter, and a ball. Obviously many of us arrive to the same conclusion intuitively, but using your frontal cortex rather than your cerebellum helps you avoid the situations where your intuition is incorrect. Listening to the inner voice saying “but I don’t need four light bulbs” might be a hasty decision, whereas looking at the price difference might tilt the balance.

These situations are maybe too simplistic — the options before are almost equivalent. Having a spare jacket in the car doesn’t “cost” you too much. So is paying $2 more for the extra bulbs. But as the cost becomes higher, it is harder to commit to an option that you might not need. Perhaps packing an jacket is a tough decision if you were planning to bring only a carry-on. And what if each bulb cost $10? $20? $100? Obviously you wouldn’t want to bet too much. I’ll save discussing statistics based decisions for another day.

The thing is that our lives are filled with these almost-identical choices. This leads us to our last example. You want to replace your glass of lukewarm Coke — Coca Cola, for those outside of the US — with a colder one; you walk to the kitchen and pour the useless drink down the drain, only to discover there’s no more Coke in the fridge — too bad; if only you kept your options open by fetching the new drink before disposing of the previous one, you might have used ice instead to cool down the last glass of Coke. The more you practice this skill, the better you notice these opportunities, which elude most people, leaving them to arbitrarily pick the seemingly easiest path. By bringing more and more situations into light, you get better at avoiding the pitfalls and will be a much happier person.

Posted September 13, 2017 by Ohad Kravchick (myok12) in Life

Tagged with , , , ,

A more equal union   Leave a comment

I am the first to admit I do not have the BEST relationship, but I try every day to make it as equal as I can. I sometimes ponder my life before having kids and after. Before, life was SO easy – I mostly did what I wanted: going here, buying this, meeting that person, but also going shopping with my spouse, going to a romantic movie together, and to sundry activities that I wouldn’t have gone to otherwise. These days are long gone. Today, and two daughters deep, things are really different. I now almost exclusively do things I wouldn’t have chosen to do: go watch Cars 3, go to the restroom for a whole 5 minutes in the middle of the movie (no intermission in movies in the US), prepare dinner, pick it up from the floor afterwards, do the dishes, brush my kids’ teeth, change diapers (thankfully these days are over for me), wake up in the middle of the night to put a baby back to sleep, give a pacifier, etc.

I know way too many friends, all of them well raised, well intentioned, avoiding many of these or other tasks at home. I’m not sure what other men are telling themselves as they avoid these, maybe some kind of white lies: there’s no need for me to wake up in the night – the kid wants mommy anyway, they can go to the park without me – she loves going to the park with them, etc. I sometimes say these too, mostly when I’m tired, overwhelmed, or hungry. But many times, I hear men put these “walls” around them to protect themselves from these chores: I have to put the hours at work, I can’t change diapers or I can’t stand the smell, I don’t know how to prepare dinner, do the laundry, do dishes, etc. While this might be true for some, these excuses are just excuses, temporary ones at most. This might sounds funny, but if you had to make dinner at your workplace, would you have said you can’t? You might say “it’s better that at least one of us sleeps well at night”, but did you ask her what she really wants, without pressure, in a frank discussion? Just as you have done before the kids, you should now do even more. I know you have zero time for yourself, for maintaining sanity, for relaxing, but think about your wife – she is doing MUCH more, giving up WAY MORE than you. Or you might say to yourself “she wanted kids, I just agreed”; while that might be the case, that’s not how partnerships work. When you buy a house, maybe she wants it more, but BOTH OF YOU agree to pay for it for the next 30 years. It was the same when you agreed to go to the ballet – once you said yes, you tagging along with a sad face isn’t really doing your part; you have to bite the bullet and actually participate. Same for kids, house, chores – you should make time for these. It is all about bearing the burden equally. If you like to go watch a game over with friends, make sure she has similar time going out with her girlfriends. If you like staying in bed in the weekend, do it on Saturday, then clear out Sunday morning for her, taking the kids out, making breakfast, etc. If you don’t like taking them to classes, take them to the park instead. If she took a day off to join your child’s field trip, you should join to the next one. How many nights or weekends did you stay alone with the kids and how many did she?

Volunteering is an important aspect. Without you suggesting, there’s so much your wife can push you to do. Why should she have to ”boss” you around? Aren’t you a consenting adult? I don’t say you have to give up a 100% of your time; conversely, take as much time as you want, but make sure she takes similar time.

Lastly, I want to make a point about work: it’s really easy to use it as an excuse for having to stay longer, for staying at home working while everyone else go to the zoo, etc. This is your choosing. Especially if you are the main breadwinner, it’s easy to use this excuse to have your way. But again, this is you choosing to persist the imbalance between you and your spouse. You can choose to say to yourself “I’ll do it first thing on Monday morning” instead. You can choose to not have to reply at evenings. You can choose to take the day off when school is out or your kid is sick. You should be a better role model to your friends and colleagues — I will appreciate not being in the minority when it comes to work-life balance —  a better role model to your wife, to your kids, and to yourself. You can do it — to a more equal union!


Posted July 10, 2017 by Ohad Kravchick (myok12) in Life

Tagged with , , , ,

Building an almighty data retrieval system for all HTML5 webapps   Leave a comment

Download ExampleDifficulty: easy moderate challenging

As discussed in my previous article here, data retrieval is at the heart of every informatory HTML5 web application. Because of this reason, it is important to thoroughly consider and devise a scalable solution for data retrieval, which collectively deals with caching and network retrieval. This is mandatory if you want your app to be functional both online and offline, by retrieving data from network when possible, or from the stored cache otherwise. Considering a good design is also important as any solution you come up with, good or bad, will be used everywhere in the app and thus difficult to modify.

Read the rest of this entry »

What does building an HTML5 web application entails?   Leave a comment

Difficulty: easy moderate challenging

We all understand what HTML is, but how is an HTML5 app different? Before we go into the different components we use in an HTML5 app, let’s try to comprehend the major difference between a web site and a web app. While web sites can only be used when the user is online, web apps can be used when offline as well. To do just that – to allow a web app to work offline, you have to use either HTML5’s Offline Web Applications feature or a mobile application framework, such as PhoneGap.

Read the rest of this entry »

Posted July 1, 2011 by Ohad Kravchick (myok12) in HTML5 Development

Tagged with , , , , ,

Native vs. HTML5 Application Development   Leave a comment

Difficulty: easy moderate challenging

I imagine that many developers and even more entrepreneurs on the verge of creating a mobile application are contemplating whether to build it using native SDKs or using only HTML5. If you are having the same doubts, this article might help you. I will explain what both options mean, what are the implications of each, the pros and cons of each, and even some hybrid options.

Read the rest of this entry »

%d bloggers like this: