• 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.

    Read on →

  • 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.

    Read on →

  • 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.

    Read on →

  • 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!

    Read on →

  • 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.

    Read on →