How I Use Flexbox

Display Flex is a css style that is used to position stacks of elements horizontally or vertically.
I use the following for centering text inside a div, which is usually to make it look like a button.

display: flex
align-items: center;
justify-content: center;

The alternative I have been using before flexbox for a 50px height div and a p tag for text. I would use:

text-align: center:
padding-top: 14px;

This involves some trial and error, if the height of the button/font size changes, the padding-top won’t work anymore.

jsFiddle: https://jsfiddle.net/w2pybzad

For lining up elements side by side, I usually stick with display: inline-block and a width. I find it easier to understand with than providing a grow/shrink/basis for flexbox.

How I do Pair Programming

I am going to start by saying I only pair program if I know how I am going to write the feature like an parsing a feed file, a CRUD feature. If I am not sure how to do something like using a new API, my partner and I would gather information about the topic, we call that spiking.
It’s very frustrating to watch the driver look up documentation as a navigator. Part of spiking might also require building a prototype to prove the approach does work/convince my partner the proposed solution works. This is of course time boxed to a certain length of time for time management. Once both parties agree on the general approach. Then we pair program.

A way I pair program is called ping pong pairing. There is no driver/navigator. Each person takes turns writing the unit test/passing implementation So person A starts by writing a failing test. Then person B writes the implementation to pass the test plus the next failing unit test. Person A then does the same thing as person B. This is less extreme than having a navigator that doesn’t write production code for an hour. This will build rapport between the 2 programmers. I did this with each new hire that came to Yroo.com and it has worked pretty well.

The next progression is to be a navigator/driver for an hour or two at a time. It is important to note that I am trunk based programming so I am constantly pushing code to the master. I won’t elaborate on the merits of trunk based programming, just that I am not sitting on days old code waiting to merge with master. So it’s possible to constantly change computers. As navigators, I have my own computer to either navigate the existing code base or look up documentation for the driver. I would also speak up if I am unsure what the driver is currently implementing specifically tied to a unit test. As a driver I am communicating to the navigator, what unit test I am about to write and then my implementation to pass the test. One step at a time so the navigator does not get lost. I would even stop typing code to bounce an idea off the navigator at times.

The important thing here is one step at a time, meaning: 1) one unit test 2) one quick implementation to just pass the test 3) refactor the code if necessary

A good sign to look for is when the pair is constantly communicating with each other.

Pros of Pair Programming

A little background: I have been doing pair programming in Retailcommon (yroo.com) for more than 2 years, everyday.
When I started, there was only 1 pair, me and another developer. Since we have grown the team to 8 developers/4 pairs. Pairs are rotated every week where an incomplete task is left with one developer that was on it in the previous week and joined by a new developer.

Here are some of the pro’s:

1) Knowledge Transfer In Retailcommon, we have taken new hires and be able to get them caught up in 1-2 months. There is no separate training program.
The developer that was in the company longer will hand hold the new hire through a few features and by the end of it, they will end up with actual experience. Usual plan is start with Rails so a few features controllers/models for Rails. Once he/she is comfortable with Rails, we move on to Javascript/React for Frontend. Big features are susceptible of being a bus factor of 1. With pair programmer, all important features will have at least 2 developers.

2) Less Stress Yes, it’s actually hard to constantly talk with another person. But the opposite is also true, I have had experience where I was responsible for a feature alone, but I have no idea how to do it and all senior developers are too busy with their own work to give guidance. If you are working someone else, the responsibility of the feature is shared. It also does not so bad, if both developers don’t know how to accomplish a task.

3) Programming Faster Having someone to exchange ideas on how to approach a problem is very nice. Also when researching a problem like what API to use or library to use. It’s nice to have a second person researching (separately )the same thing so there is a less chance of finding the optimal solution. The person not on the keyboard (navigator) can look up how to do something if the driver does not know .