Category Archives: Tech

The github code review problem / Product before code

The remote / GitHub code review problem:

A part of any developer’s workflow is the code review, the main tool these days to do that in a team is the great feature of the code review with GitHub. (Usually, with the pull request).
The feature is amazing. Code comparison view, line by line comments, tagging, mentioning – it’s like fucking developer’s social media. It’s great, but we have lost an important part in this new workflow tool – we lost the product.

We have three well-known methods to review a code:

  1. Not to review a code.

Next:

2.   The pair programming:
Our code is great, and we know how it can be even better, when having a second eye on it in a pair programming session. It is really the best way. Some love it, some hate it (I personally, know that it will achieve the best results, but most of the time still prefer to fire keyboard signals with my headphones, in my “zone”).
It is also known that it’s something that not all companies or developers will accept. Most of them won’t. It’s costing more money on dev-time and does not save the same 50% of fewer bugs.
It is also not comfortable. You need to sync time. Sometimes somebody is sick. Sometimes you’re better alone. It’s perfectly fine. I am sure that most of the beautiful pieces of code in the world were written first by a lonely developer. (I hope that he/she was sitting in an airplane, avoiding screaming children, noises with earphones full with Volbeat music, which is exactly what I am doing now).

3.  The code review:
The middle way, between the pair programming and the no review, is the good old code review.
In this way, you don’t waste money on double dev-time. You get your “zone”, but you still get a second eye on your code.
You both look at the branch / PR, but also look at the feature, as it is already open in the developer’s browser. You try it, and play with it to understand what the code should do. You have immediate communication with the developer so you can ask/react to the feature and get a reaction back immediately.
Reviewing a code without seeing the feature/bugfix at work, is just testing a car only by its blueprint. No practical test before passing it to QA or even – pushing toward an acceptance test.

Now we got lazy. We check the pull request, we don’t sit together and explain. It is rare for people to actually pull the branch to their computer. They don’t need to anymore, so they won’t try the feature. This is how we lose the best power of the review – deploying a great, working feature. A beautiful code is great, but worth nothing without a working product.
I see this change and how it hurt us. Open source projects and private projects, getting more and more bugs that would never happen with a real feature review. It costs money, and it’s a downgrade to a dev-process that advanced so well in the last years. We have such great tools – don’t let them lead the human brain. They are just tools.

I say – review, with your locale tool. Try the feature, or a feature that uses this piece of code.
We should not become just coders, masters of beautiful abstractions and a code that looks like a poem. We should also never forget the reason we write it – the product is paying our salary – the final result of our masterpiece.

3 lessons learned from the establishing of an in-house growth hacking team

3 lessons learned from the establishing of an in-house growth hacking team

In this article I’m going to talk about the “hacking” part, too many posts are there for the growth:

After doing some research on this new buzzword – “Growth Hacking”, we agreed this was something we needed. The problem was, that most of the articles and experienced guidebooks about building this kind of a team were directed at content centered companies, blogs, shops etc. We needed a growth team for a well-established product, big and full of features – We needed something between an onboarding team and a marketing team.

Looking back, once we established the team, gained some losses and earned some wins, I can summarize my conclusions of the process into 3 main lessons that focus on the ideas and developing part of the growth hacking team:

“Hacking” is not about code. It isn’t code you are hacking. I repeat – hacking, is not code hacking.

We know that a crucial part of this type of a team is the existence of a well-experienced developer who knows the code – but this doesn’t mean he hacks code.

What he does, is hack the product.

You find a hack to the user journey. You “hack” through the everyday thought process of your product team who define “what is our product”. You hack thought processes, you take an idea and put a “what if” after it.

Your code, as a proud developer, as an expert, senior, veteran or a superhero developer – should always be perfect.

The implementation process can have shortcuts, they’re even necessary. You don’t need instructions, controllers and angular philosophy kind of code for each new testing feature, but your code should be perfect.

No need for “doSomthing()” named functions please, but this is necessary for EVERY feature that you haven’t tried yet. Every new feature is a test. And building huge perfect architecture for something you don’t even know how will behave, is a waste of time and money.

A growth hacking company is a company that thinks of a feature -> hacks it -> tests it -> builds it -> and improves its features. But that’s an entire different subject for a different post.

Growth isn’t marketing, its product.

This is extremely important. Especially when you “sell” the idea and need of this team to management:

A good amount of money is spent on this team, and it’s expected to bring quick results. Easy money. And where is the best place to look for this money? At the cashier’s table.

Our natural go-to strategy is the checkout pages, homepage and the packages pages, all and all – they’re just versions of landing pages and should be tested by marketing teams. If your marketing teams are busy with acquiring traffic for landing pages via facebook, twitter and Linkedin campaigns but don’t test internal pages on your website as a testing ground, your hacking team can do some tests there to inspire them – but this is not where you can help.

You also don’t need developers to create blog posts.

Your hackers are product people, not marketing:

  • They should be looking for ways to make the user convert, after using the product, but first – make the user use the product.
  • Make the user understand that he might get more if he pays, but while using it.
  • Create the WOW moment a paying moment also.
  • Look at the graphs of user behaviors while using the product and assume things they can try.
  • Go back to the graph. Make it grow, use unconventional ideas to do that.
  • The team should fail. fail and fail again.

When we just bootstrapped the team, one of our first tests, was a simple, stupid “share your results on facebook / twitter”. It is not a new, or brilliant idea.  But we needed to test it ourselves. It was fast and easy.

The success we got from this “in product” non-designed test, was better than any result we got from similar tests we ran on checkout pages than our growth hacking team did. The added value of more traffic, branding awareness, and user satisfaction is just a side dish to the sales.

We didn’t use the traffic we already had and try to convert it – we brought more, gave them good onboarding, invited their friends.

Growth hacking is not online marketing – Test the product.

Create a test, not products. A growth hacker shall not maintain a feature

Here is the tricky part for a developer:

A developer in a growth hacking team is a product enthusiast guy or a girl. Seriously, it’s the developer who will give up some dev happiness (e.g. – building some nonstandard stuff), for the sake of a great product.

But as long as a growth hacking team doesn’t have a clone team that will continue maintaining their work, it cannot assume that its features will be maintained. They should be built in the easiest way to plug out of the system once the test is over. After that, maintaining a good test that should become a feature is a company decision.

It is tragic to see something you worked on go down. Especially when it shows good results, but that’s something you need to accept, and wave goodbye to it, giving it to somebody else and just hoping he / she will treat your feature with respect and love as you did.

There are some exceptions to the above. If a test performs really well, if it’s a really simple and non-maintainable code (does that exist?) or if it is your domain (no one should have only one job in a company, narrow responsibilities are narrow-minded) – all the above can be maintained features after testing.

All in all, it is important to know that even the goals and the ways of the growth hacking team is, in fact, a hack. A good one, an out of the box thinking to do things differently than the company has been doing until now. And that’s all it is – an out of the box team, and so should be each one of its members.

And remember: First rule of growth hacking – always talk about growth hacking.

CSS nesting html elements limitation – ~~useless info

It appears that different browsers are limiting the number of nesting elements in an HTML page that a single CSS rule can use.
It looks like each browser has its very own different limitation.

While testing performance I tried to nest big amount of divs, 1000 of them. I gave each a following number (yeah, produced with javascript i++ and copied the result from the devtool), and tried to apply a single rule to it.

div .div998 { color: blue;}

It didn’t work. I tried to debug the HTML, thinking that I might have some problems with not closing elements or a wrong class, then began to change the class in the CSS rule to a higher container.I reached to the point from which the CSS won’t apply, the browser limitation.

Look at the following jsfiddler (looks like this is too heavy for embedding, so I removed the embedded code, please use the url).
Please leave a clean playground:

http://jsfiddle.net/Lhd8ny8w/5/

You can play with the class number to find your browser’s limitation.

With chrome (chrome OS version 41.0.2272.41) the limit is 509. With my Firefox 30 the limit is 198. If you change the rule to 510 or higher, you will see that the rule won’t apply. change it back to a lower class, and it will apply.

I am afraid to check IE’s limitation.

You can play with that on different browsers, there is no standard defined that I could find in the specs, and each browser has its very different limitation.

As its a bad use to have so many nested elements, it is still good to know, since lots of markup today is generated aoutomagically, by js or magic backend and sometimes we won’t notice that its so big, and try to understand, frustrating, why our style rules won’t work.