Ylan Segal

The REPL: Issue 35 - June 2017

You Are Not Google

Ozan Onay reminds us that Google, Amazon and other tech giants have problems at scales that most in the industry don’t have. Adopting their practices might not suit your organization or project. As with most things in Engineering, choosing a good solution depends on deep understanding of the problem.

The Many Meanings of Event-Driven Architecture

Event-Driven Architecture means different things to different people. In this talk, Martin Fowler dives in to the nuances of what it means and provides a framework to talk about event drive in a meaningful way.

Postgres EXPLAIN Visualizer (pev)

This tool provides a handy way to visualize the results of an EXPLAIN query in Postgres. I found this very useful. I hope this would exists for other databases as well.

Book Review: 99 Bottles of OOP

99 Bottles of OOP bills itself as a practical guide to writing cost-effective, maintainable and pleasing object-oriented code – otherwise known as “good” code. It delivers on that promise.

Sandi Metz (often mentioned in this blog) and Katrina Owen (also previously mentioned) team up to write this highly instructive guide. They use a simple coding exercise – print out the lyrics to the 99 bottles of beer song – to illustrate several different implementations and provide some critiques of them.

They go much father, though. By introducing a new requirement, they embark on a fascinating and painstaking refactoring process. By changing one – and only one – line at the time, they use their test suite as a safety net to discover abstraction hidding in the code. Slowly, they improve the code bit by bit, following Kent Beck’s advice:

for each desired change, make the change easy (warning: this may be hard), then make the easy change

Often, refactoring and coming up with abstractions seems esoteric. Experienced engineers know how to do it, but often can’t explain their process to more junior engineers. Worse, it’s hard to express why one design is better than another. Sandi and Katrina provide some relief from the paralysis that can result from starting at a piece of code without knowing which is the correct abstraction that it needs. The prescribe to follow the Flocking Rules:

  1. Select the things that are more alike.
  2. Find the smallest difference between them.
  3. Make the simplest changes that will remove the difference.

By example, the authors apply these rules to extract one abstraction after another. Naming is still hard, but is easier once the extraction has been made. Along they way they should how to judge code with facts (like cyclomatic complexity and the ABC metric), as opposed of just on opinion.

Overall, I learned a lot from this book. The examples are written in Ruby, but the syntax is so simple, that it can be easily understood by anyone already familiar with another programming language.

On the Pomodoro Technique

The Pomodoro technique is a popular time management method. I tried using for a few weeks at work. I am not planning on sticking with it, but I did learn some valuable lessons from the exercise.

The technique itself is simple. It prescribes using a timer to enforce work and rest intervals. Typically, for every 25 minute interval of work there is a corresponding 5 minutes of break time. After a few cycles, there is usually a longer break.

One of the benefits of time boxing work is that it promotes resting often. Sitting at a desk for long periods of time can be detrimental to your health. It is known to correlate with back and joint pain, and eye strain. Anecdotally, many software engineers tell me of hours-long stretches at the keyboard. I don’t struggle with that. My natural thirst and bladder cycles naturally prompt me to leave my desk often.

In fact, the I found the constant interruption to be annoying. I have a very good capacity to concentrate on work, usually with the aid of noise-cancellation headphones. The time-base interruptions constantly broke my “flow”.

On the positive side, I found that the planning aspect of each iteration to be a really good way of breaking down work. It encourages to split the next piece of work into small chunks, that are inherently more approachable. It makes it easier to approach uninteresting tasks – which I procrastinate on often. Committing “only” to a small interval of work makes them more palatable.

I won’t continue using Pomodoro. However, I am now more aware of my procrastination. I continue to plan my work in small steps. When I start working on a task, I let the natural stopping points guide me on when to take breaks.

The REPL: Issue 34 - May 2017

Base CS: Exploring the basics of computer science, every Monday, for a year.

Vaidehi Joshi, embarked on an the admirable journey of writing a weekly post about computer science topics. She is calling the series BaseCS. I’ve found the content to be well written, concise and full of clear explanations and beautiful illustrations. As advertised, some of this content is basic computer science. I’ve enjoyed all the articles published so far.

Five Factor Testing

Sarah Mei lays out five practical reasons to write tests:

  1. Verify the code is working correctly
  2. Prevent future regressions
  3. Document the code’s behavior
  4. Provide design guidance
  5. Support refactoring

Sara correctly points out that our individual approach to testing is a result of the importance that we give to each of these factors. Excellent post.

Writing English as a Second Language

As a Software Engineer I spend a good amount of my time writing emails, commenting on pull requests, Jira tickets, Slack, etc. In this transcript of a talk given to international journalism students, William Zinsser talks about what is good writing and in particular what is good writing in English. As I learned, it’s not necessarily the same as good writing in other languages. Since English is not my first language, I fall often into some of the traps outlined in the talk. Now I know how to fix them!

The REPL: Issue 33 - April 2017

A Visual Introduction to Machine Learning

This stunning presentation will give you a quick introduction to machine learning and how it applies statistical learning techniques to identify patterns in data. In turn, those patterns are then used to make highly accurate predictions. The visualization are beautiful and explain intuitively the concepts described. I commend the R2D3 team behind this work and look forward to the second installment.

On-call at Any Size

This article is part of the first issue of Increment, a new digital magazine about how teams build and operate software at scale. The post is a report on what they found after interviewing teams of many sizes. There are some commonalities and best-practices that emerged from their interviews, some of which only apply at certain scales.

One of the things I love about being in software is the current environment of openness that a lot of companies operate in. They publish how they work, what they have tried. Everyone benefits.

Moneyball Teams

Brian Graham takes on hiring at software teams and makes an analogy to Moneyball (book and movie). His concept is that hiring only “the best” is hardly an effective strategy. The focus should be on building a team that can deliver on needs. Each developer brings different capabilities and are rarely interchangeable with each other. By looking at the needs of your team, your are in a better position to make good hiring choices.