In this post, let’s explore a bit more of this idea. Keep in mind this is much more than testing. It’s about good design!

The title is a bit broad and would be hard to explain in detail and compare dependency injection (DI) and inversion of control (IoC) like in other languages/frameworks.

Talking dependencies, I prefer to be explicit as I’ve had experience working in codebases where things were instantiated all over the code, being hard to test and understand.

Let’s begin with an example in Ruby. Think of a class, in this case, a Person. This class has a method that uses a third-party service that, given a place, returns geolocation data.

Suppose I live in Sao Paulo/Brazil and I want to find its latitude and longitude.

There are two different ways of achieving the same result for this example, so let’s dive in.

First, it’s possible to declare a dependency using a class method:

class Person
  def self.geo_data(geo_service: GoogleMapsService.new, address:)
    lat, long = geo_service.find_by(address)

    [lat, long]
  end
end

A class method receives its dependency and the address parameter, just that. I usually try to think more in OOP terms in Ruby, so I must have good reasons to use class methods, but keep in mind they’re helpful occasionally.

The other option that I find particularly interesting is declaring the dependency explicitly via constructor using a named parameter with a default value:

class Person
  def initialize(geo_service: GoogleMapsService.new)
    @geo_service = geo_service
  end

  def geo_data(address)
    lat, long = @geo_service.find_by(address)

    [lat, long]
  end
end

person = Person.new
geo_data = person.geo_data('Avenida Paulista - Bela Vista, São Paulo - SP')
puts geo_data # [-23.533773, -23.533773]

Both choices are valid, and depending on how the service is used, favor one or another. It’s a matter of style that your codebase is very likely already using, so try to stick with it.

In my opinion, now the code has a better explicit design. By looking at the constructor, we can see its dependencies.

Good, but let’s try to look at how it can make our tests more testable now. As you can imagine, calling an external service on your tests can make it slower and error-prone, like in the example where we need to invoke @geo_service.find_by. Before we see the alternative, notice that it’s possible to use the always interesting VCR gem for this, but not always needed.

We usually want our tests leaner and faster, so let’s implement the FakeMapsService that could replace GoogleMapsService:

class FakeMapsService
  def find_by(address)
    # Notice that it has the same signature and return type as the real service method
    [1, 2]
  end
end

person = Person.new(geo_service: FakeMapsService.new)
geo_data = person.geo_data('Avenida Paulista - Bela Vista, São Paulo - SP')
puts geo_data # [1, 2]

It’s a class that respects the same contract as the real service, having an instance method find_by(address) that returns the same array containing latitude and longitude. Even though a contrived example, FakeMapsService makes it easier to test now, avoiding the whole mockery we get used to:

require 'test/unit'
require 'test/unit/assertions'
require_relative './person'

class PersonTest < Test::Unit::TestCase
  def test_geo_data
    # When creating our scenario, we change the real service for the fake one
    person = Person.new(geo_service: FakeMapsService.new)
    assert_equal person.geo_data('Wonderland, Nowhere'), [1, 2]
  end
end

So, that’s it for now. It’s a simple yet powerful idea that I’ve used many times in Ruby and also Go! In the next post, I’ll cover a different example in Go about using the same approach for another problem.

I hope you enjoyed it, and thanks for reading!

The opinions change, also the perspectives and the experience, but the discussion was and always will be present.

In this post, I hope to bring light to the discussion. Don’t expect easy answers. I will ask much more than pretend I know the answers.

I use language and programming language interchangeably.

We have to think!

Overview

• Your mileage may vary
• Behind the choices
  • High invested
  • Why so many options
  • Ecossystem
  • Hard to measure aspects
  • Productivity
  • Simple vs Easy
• Wrapping up

Your mileage may vary

When we start developing it’s relatively common to learn programming languages from the C family. Those are the languages that have a characteristic if, followed by {} and code in between. They usually have strong typing and good performance.

For example, a C program that checks if a number is even or odd (harvested from Internet):

#include<stdio.h>
int main()
{
   // This variable is to store the input number
   int num;

   printf("Enter an integer: ");
   scanf("%d",&num);

   // Modulus (%) returns remainder
   if ( num%2 == 0 )
      printf("%d is an even number", num);
   else
      printf("%d is an odd number", num);

   return 0;
}

After 1 or 2 years of writing code in the same language, it seems to be the only option.

You may have started from a different family of languages, that’s not the point though.

Before learning C/C++ at college I had the opportunity to learn Clipper, Pascal, Visual Basic, and Delphi. Those were the first languages I learned that helped form a critical sense over it, each one with its pros and cons.

The lesson here is: every programming language brings together someone else’s experience.

Behind the choices

Unfortunately, it’s common to ignore an important aspect of our choices:

• What is the motivation for creating a new programming language or tool?
• Who created it?
• What’s the creator’s background?

You may not need to know it, but if you’re the person responsible for deciding it, you better go look for it. This is probably the research which is gonna give you an interesting background. It’s a good exercise that I recommend. The history behind the choices used to be fascinating!

Try to reflect on the following aspects:

• Was the language created in the ‘60s? The ‘70s?
• If it’s older, what was the hardware?
• What did the language’s creator choose to add and to remove from the design?

As I promised, there are a lot of questions. Those are important inquiries you’ll have to think about when you decide to create your language.

Let’s suppose it’s your time. You could ask yourself:

• Should my language be multi-paradigm or not? Functional, logic, imperative?
• Compiled or interpreted?
• Should I run on a Virtual Machine?
• What about the type system…
• Concurrency and parallelism
• Do I have hardware limitations? Multiplatform?
• Should I optimize for…
• Should the compiler generate an intermediate language…

It’s your choices the same way someone has to think when creating the language you’re using today. Every question leads to another one and has its consequences.

When I started I’d never ask these questions. There’re things I had no idea I didn’t know. My baggage came through the years by exploring by using programming languages as a tool, exploring their usabilities and differences.

High invested

For every choice, there’s a level of investment of time and sometimes money. It doesn’t matter if you’re self-learned or not, you at least spent time learning it.

Let’s suppose a new programming language is fresh over the web. As people are learning, other people are experimenting with their job, making it bigger, one step at a time. New books start being written, the publishers go look for them as the interest grows.

Naturally, you’re inclined to appreciate it, you’re growing together. Now, you can change jobs, apply your knowledge, and receive money for that.

New conferences appear then you can travel. The new language in the block shines, leverages your career, people ask for your help and you’re seen as a reference.

There’s a big factor that motivates these choices. For every investment, you naturally build a bias towards it.

Biases exist in different areas. Another example is when you buy a product and you’re temporarily blind. You can’t think of missing characteristics or points of failures, you’re biased!

You’re not ready to listen to your friend say:

Wow, that’s too expensive! Product A is much better in terms of…”

Good, one more step on establishing our feet on the ground!

Why so many options?

Programming languages can be classified into two larger groups: general-purpose or domain-specific.

For general-purpose languages, it tends to be more complicated. It’s not always possible to add new features that were not thought by-design. Simply add a new feature might look foreign, out of context. We use to say it’s not idiomatic.

Let’s reflect on a few examples:

The Ruby language after +25 years decided that the language needed to adapt to modern hardware to stay relevant in terms of concurrency and parallelism. Wow! At least to me, that doesn’t look pretty simple.

How to think this change for a language that, until then, hadn’t this as a priority? We could say it’s a matter of OCP (Open-Closed Principle), but it’s far harder for programming languages than for applications.

To break or not break compatibility? Should we create primitives based on keywords or think in terms of a different abstraction? The designers have to think in the lifetime of the language, community, and its use from here on. What a huge effort is required!

Java itself, that year after has been changing. It’s been a few releases since you can write Java code on a REPL too! JShell gives that flexibility tool existent for years on interpreted languages. In terms of functional programming, Java’s brought too many options now.

I have no empirical reference, but I think Kotlin made Java open its eyes for evolution.

Go, after years of criticism and a divided community over generics, have finally materialized it for the next versions. Draft after draft, the designers have moved to a common goal with the help of the community.

Nothing is static. It’s always time to adapt and move forward. Everyone learns. The tool of today might not be great for a problem of tomorrow.

Ecossystem

A language gains relevance, mainly in terms of industry, if there’re libraries, tools, and things happening around. It’s innate that, as humans, we need innovation. We need to see things evolving and vibrant.

If it grows too much, is natural that more code is produced (good and bad). The language’s affordance naturally brings curious people. Nothing wrong with dummy libraries, code for the sake of code. That job of curation, to harvest repos and extract meaning is essential.

One more time, I don’t have a point to prove this. It’s something backed by my own experience.

Hard to measure aspects

I decided to write this post after reading a lot of discussions about it. The good, the bad, the evil. We, the people.

We’re hooked by:

My code is elegant

My code is beautiful

I prefer…

It’s authentic to assume:

I’ve adopted the language X because it looks different. It’s the hype, I want to try it.

The process of experimentation is quite common, but for more experienced developers, it goes differently. If you’re being paid, working on a team, documenting your choices and decisions are very important. Train people and make progress. If you can, give contributions back to the community.

I remember a video series from professor Barry Burd) about functional programming, where he talks about the famous goto keyword. It gained new forms but the levels of indirection still exist. Think in terms of if.

Productivity

This is a very broad term. I still don’t know exactly what it means What does it mean to be productive? Is it when I create more LOC? If I create keyboard bindings to expand into code snippets, does it mean productivity? Your experience can have a total influence here.

You might be productive after years of writing code in the same language, mas is biased towards it. If you learn a new language, how long does it take to teach your brain the new semantics? What about the idiomatic way of writing it?

What if instead of productivity you mean familiarity? Naturally, the first encounter with a new programming language might feel weird. It happened to me when I first met Clojure. A different family of language that initially hurts, but helped me think differently.

See the Clojure code below that finds the greatest common divisor of a and b (harvested from the Internet):

(defn gcd
  "(gcd a b) computes the greatest common divisor of a and b."
  [a b]
  (if (zero? b)
    a
    (recur b (mod a b))))

Nothing to compare here with the C code, isn’t it?

Simple vs Easy

This goes far.

I write a lot of code in language X.

What does it mean? If you write more code but the reading is easy, it’s organized, what’s the problem?

Do you write a lot of code because the language does not offer constructions and/or abstractions that make reuse possible? Notice that, everything is a tradeoff. The language may be raw and even though you write more code, the learning curve could be lower.

Every language allows us to write low cohesion code, with bad legibility. It’s always possible to ignore the design purpose and deviate broadly from the ideas behind it. Non-idiomatic code is not an exclusivity of language X or Z. One more time you need to understand the choices and try to follow the best constructs.

I’ve been there when I started learning Ruby. My code sounded like Java. It took me time to adapt and learn Ruby idioms. I read books on it and made progress. I read a lot of code. People helped me review my code and show the Ruby way of writing it.

Another aspect that looks foreign to me was the boom of one-liners methods — methods exclusively with one-single-line! It took me time to get used to those levels of indirections. Nowadays I use one-liners carefully and discuss their validity on code reviews.

Never buy an opinion based on a Hello, world! example. It’s not a fair comparison that does not reflect reality. I’m tired of seeing contrived examples comparisons trying to guide decisions. It’s much better to migrate a project of yours to a new language, try it and see if the model behind it is what you expect or not. Sometimes the exercise is worth doing just by doing. You might not need to prove anything and that’s ok.

If you need examples and things to compare, Rosetta Code is better than a mere hello_world.rb vs HelloWorld.java.

Wrapping up

Without further ado, let’s sum up the idea. It all depends!

Always I can, I try to look for papers and old books. So many ideas we think are new, comes from the ‘70s, ‘80s. It’s nothing new, it’s just possible to materialize it. New hardware, better usability, knowledge sharing. As the idea of concurrency seems to be something new, but CSP ideas were proposed by Sir Tony Hoare in the late ‘70s.

Also, books, that I particularly really appreciate. Their format in which the authors needed to dig deeper before writing and exploring concepts. I wholeheartedly disagree with people that say that book is merely a theory. The books materialize the experience lived by someone else that you can reuse. It works like a shortcut in the great sense of the word. It opens doors.

Be wary of your choices. Stay alert to no be the one-size-fits-all of programming languages. General-purpose languages make it possible and that’s ok. If you need optimizations, go ahead with a specific purpose language, try them. No programming language can help with a problem you don’t understand.

As I get older in terms of code, the more I realized it all depends. Maturity comes in great shape.

Try different flavors of languages, experiment with them, and make decisions.

Thanks for reading!

It’s been years since Remote and Rework from Basecamp were released. Quite often, while discussing these books people complained about been so extreme that a lot of companies would never adapt to.

All the companies I’d worked until 2018, remote was kind of uncommon. Communication worked like “Tomorrow I’ll work from home, ok?”. It was a matter of reporting statuses, killing tasks and moving forward. But… not today. Things have changed in 2019 and I have almost entirely working from home. In this post I talk a bit about being constructive and contributing effectively with your company and teammates.

How things appear to be evolved

You’ll probably see through different lens, but let’s try to list a few reasons things have changed. Remote work became feasible these days, if not the norm, for multiple reasons:

• Better Internet connections
• Better computers
• Better tools (wikis, chat, project management and video conference)
• Talented people around the world
• Work/life balance
• A boom in renting prices
• Crowded regions (more traffic, higher prices, etc)

Today I live in the countryside of Brazil, having a 100 Mb/s fiber optical connection for R$89,00/month (~ US$18.00). It’s fast, very fast and it rarely annoys me.

I work on a 13” MacBook Pro 2017, 8GB RAM and 128GB of disk. It’s not the high-end dream machine but works fine with Ruby most of the time. Almost nothing to complain, except Docker, that is a memory hog!

For the communication part, we keep things on Slack and the meetings occur on Hangouts Meet. These are good tools (not for privacy I suppose), but allows me to effectively communicate. I will talk more about the tools below, stay with me.

Among the reasons I decided to work remotely is the better balance between work and life. This might be a controversial point since a few people don’t see this separation. Well, for me it’s been good. I don’t need an alarm or someone calling me “It’s time to leave!”. My biological clock seems to be perfectly adjusted considering bed and wake time. No more commuting!

By working remotely I can have amazing teammates working with me no matter the location. They can simply do their best job. To be precise, code is something virtual, so the Internet is the main platform :P

The last point I suppose impacts me and people around the world is the cost of living. How many posts have you read about San Francisco, CA or New York, NY? Even here in Brazil, Sao Paulo has very expensive regions. It’s curious how things got disturbed by the industry — the economics of the whole thing.

If you have higher salaries, the prices raise. Groceries, renting, healthcare, everything adjust accordingly. Believe it or not, it’s very hard, maybe impossible, to change this dynamics.

Async work

It’s very easy to engage in a conversation when you have a friend next to you. It happens synchronously and anyone can start it. In some rare occasions someone tells “Could you please reach out in 2h?”. When you’re at the comfort of your home or wherever you choose to work, things work differently.

Before working remotely I had an urge to immediately help, removing blocks and moving forward. I have to say it’s different when you’re at a distance. As most of the remote communications happen this way, you’ll probably have a feeling of multitasking. You’ll be effectively changing context the same way a single core processor does. Maybe using a time slice mode. Do something while others await.

While my code keeps waiting to be reviewed, I try to write down a better README or document situations my team might find.

In the beginning I had a sense of emergency to jot down something on Slack and keep an eye on it. Will the reactions come? Will people start a thread? This seemed so similar to a social network (is it?). After a few months I calmed down and forgot this feeling. I put things down and interested people would take turns interacting.

Particularly, everybody in my team is on the same timezone (UTC-03:00). If we had people working around the world, this would add a bigger weight on async communication. I have an idea of how this could work but I have no experience to write yet.

Written communication

After a few months I noticed ideas vanishing. A lot things happened but it didn’t stick. It was when I decided to read more about the topic. That was when I realized that, if you’re working alone, you have to think collectively. If I write down my ideas, documentation or whatever, I’m not only helping myself but the company as whole.

We’ve been using Confluence for this even though I don’t like it much. It feels slow. The features I like in Confluence is a change history, notifications and a comments section. It’s not my dream tool but it’s the default tool for documentation, so I embraced it. :P

We’ve been using an effective approach for good communication. After the meetings we write down the date and what happened. This is a good way to address things and name people to address the issues/ideas. It works like a diary.

Before we advance to the next topics, I’d like to explain how writing have helped me to express better the ideas.

I write anything, without revision. A crude text, bad punctuation and a lot of ideas. I invoke my writer soul, let things flow on my keyboard, then the async comes into play. I leave the text alone, maturing and when I my gut screams, I come back and invoke my editor soul.

You won’t be perfect initially, but it’s important to release the writer’s hand, wander and come back later. Depending on the topic it’s possible it will generate warm discussions. I believe it’s where emojis work nice. The decrease the pressure, giving a ton of friendship and camaraderie.

Code reviews

I’m a developer. What better way to communicate than using code reviews? We’ve been using GitHub for this, so let’s call it the right way — Pull Requests. You probably know, but GitHub is a service hosted on the web. It’s like a bridge, it doesn’t matter if you and your teammates are at the same space. You’ll be using it or a similar tool.

Code reviews reaffirm the importance of written communication. Not in general terms, but in terms of code. By working remotely the first thing I considered was a PR template with the following:

• Describe the main idea behind it
• You can create check lists
• Describe the changes you’re doing
• If it’s a breaking change, describe it
• Describe steps to deploy, if needed

GitHub have recently added very interesting features. You can mark as reviewed, select multiple lines for comment, change the code directly to the web interface and more. You can even open a draft PR for appreciation.

The tone you define during the review is what makes it good or not. Don’t forget to have empathy and always be constructive. It’s a great way to learn and help people learn new techniques. If you want more details and best practices on code reviews, go check a post I wrote a few months ago.

GitHub notifications

Nowadays, my team is responsible for 7 services. Ruby/Rails, Python and a Vue.js frontend. Can you image how many commits my teammates are pushing daily? I can’t handle this through e-mail, so I try to keep sane by using GitHub notifications. It’s still in beta but it already helped me by showing assigned issues, mentions, reviews requested and more.

Connections (people and Internet)

In the beginning, we tried to talk only during the meetings. It worked, but it lacked quality. As more people joined the team, it became crucial to see each other in video. Besides showing expression, it help us to establish a conversation tone. It’s made the difference by bringing each other closer, to a more personal communication.

Not everything works smoothly as expected. The quality of connections varies for different reasons: a specific problem in the region or an overload in atypical days. When that happens, as a last resort we turn the video off. Not ideal, but it helps.

A downside I can feel sometimes is the human interaction. Being with your friends at work, having a lunch together, but is something I can overcome by traveling once in a while. If you really works in a distributed team, with different timezones, things may be worse.

Conclusion

It’s been a great experience working full time remote. I can focus a bit better without losing interactions. I still have the added benefit of not living far from the office. When things are more urgent or I need a personal approach, I can travel to meet people.

If you can learn two things from this post is:

1. Take it easy (async is the way)
2. Write more

I’d like to thank my company CargoX for trusting me as one of the first 100% remote workers they hired. It’s been amazing, effective and less stressful than I ever thought.

I hope you enjoyed reading this post as much as I did writing it! Enjoy :)

Open source is something we use every day, even though giving nothing or just a few in return. I had already contributed with money. I helped individual developers, donated to Mozilla, Wikipedia and add-on creators. I even bought swags to help oh-my-zsh and more. I even paid US$80 for the great Sublime Text, a proprietary text editor in which people accept a pop up once in a while for the free version.

You probably know the philosophy and all the benefits of open source, so I’ll skip more of this. In this post, I want to focus on how chatting with a friend on a Friday evening, inspired by Linux philosophy of small tools and our love for Go, we created something interesting.

I’d finished writing Ruby code and decided to explore a bit deeper Go’s tooling and how to improve the workflow of my tests. I wanted faster feedbacks, but after exploring docs and more docs, I noticed Go had nothing similar. Back then, in 2014, when I was working with Ruby (I’m back with Ruby!), I used Guard to receive constant feedback of passing and breaking tests. Wow, why not in Go?!

The beginning

Before I got into analysis paralysis I called my friend Victor to tell him about this idea. He was just starting with Go and could give an unbiased feedback of how he felt writing tests. He liked the proposal, so I decided to try. I wrote a very minimal idea of how it should work. We chatted over Telegram to discuss a usable tool we could develop, with as few as possible code. You might call it a “MVP”. A few interactions and the following list emerged:

- It should be focused on Go developers
- It should monitor *.go files
- It should be simple
- It should belong to the community

Small is better, so we embraced our initial philosophy of Linux small tools and stuck with it. We relied on Go’s file, filepath and os packages. Initially, anything beyond that we judged as a waste of time. At this point, the tool didn’t have a name. It wasn’t the right time to worry about it. Commit by commit we learned how this tool could help us. The first interaction was nothing but background notifications.

How it works

As we made the tool stable, before pushing to GitHub, we found a name: snitch.

Given a certain path, snitch watches Go files. If you don’t pass the path param, it assumes the current directory. Defaults are great! Particularly, snitch came to me by helping with TDD. You can write your tests or save my Go files and it tells you the current state of successes and failures.

As a good snitch person, it tells the good and bad news! The name sounds good and people on Reddit said it was the best name for a tool like that!

Why Go?

Snitch was born in the ecosystem. It was created for Go developers by Go developers. I won’t praise Go again :P

Lessons learned

This was that project that, with a few LOC, gave us a very interesting in return. With the help of GitHub, people interact, love star the project, fork it and open pull requests. It’s beyond the code. To make it work, I have a few advices:

- Start small
- Don't be so ambitious
- Iterate and improve
- Don't be afraid of criticism
- Write down your ideas
- Use "what if..." to play with new ideas
- Ask for honest feedback and go grab a coffee

The current state

The story be told, I think now it’s time to see the code and try snitch. You can collaborate on GitHub by opening issues, suggesting features and showing love.

I believe snitch has reached a stable state with interesting features. We love beautiful code, but there’s always room for improvements. The most recent PR added a colorized terminal output. I loved it and it was easy to write with the help of color package. I must say that Go enabled us to write clear and legible code very fast!

Nerd stats

The repo has no more than 310 LOCs today, including tests:

find . -name '*.go' | xargs wc -l
      61 ./platform/notifier.go
      52 ./parser/result_test.go
      20 ./parser/result.go
     177 ./main.go
     310 total

I’d like to thank people on Telegram, GitHub and Victor for the code and support!

Thanks for reading!

Overview

• What is a code review?
• Why
• General aspects
• Best practices
  • As the author
  • As a reviewer
• Biases
• Conclusion

What is a code review?

If you are a developer, no matter how experienced you are, you’ll make mistakes. Code reviews are a practice in Software Engineering that in general, help developers to find defects, design problems, assure best practices compliance and apply knowledge transfer before delivering code.

I really enjoy code review sessions, so I always try to bring this practice to every company I work for. It’s great for learning new things, share opinions and give great feedback!

Why

We want the best code as possible to be delivered. Code that can grow organically, following the good principles of Software Engineering.

• Defects: During a code review, we can find if something was misunderstood, even communication issues.

• Design problems: it’s quite common to think in solutions and forget dark parts of the problem. This is a good time to find design issues that, maybe not now, but in the near future can cause problems. This is quite common with non-functional requirements.

• Best practices: each programming language has its quirks, so we look for adherence to the idiomatic code. Static analysis tool can help here.

• Knowledge transfer: everybody learns. Senior or junior, we make mistakes and write beautiful code!

General aspects

Leading a code review session requires a few things to keep in mind in order to avoid biases and preconceived ideas. A session usually takes many minutes of interactions through code acceptance.

Code reviews are independent of programming languages. Scripts, build and automation code can also be reviewed. Recently, I also recommended my peers to review infrastructure code, an area whose is known to neglect code before the DevOps culture appeared. Things are changing and for the best!

The code review is only possible because of the VCS software like git. There are services that integrate with git and make it possible to have a centralized place, where you and your team members can establish a conversation and give feedback. Services like GitLab, GitHub and BitBucket are examples of that.

How it happens

This is a way to review code, with your team you should define what is best and adapt if something doesn’t work.

Developers are responsible for frequently committing their code and when it’s ready or even when they feel feedback is needed, it is a good time to start a code review. If you’re on GitLab, reviews are called Merge Request. If it’s GitHub - Pull Request.

There are different ways of starting a review according to the git flow of your choice. My team currently works with a master branch - a known place for stable code. In this case, everything we develop must pass the review before being added back to master.

After three days, you finished your so expected feature. Tests are all green, static analysis ran, no issues found. You’re ready to start a review before finally shipping your code.

It’s time to choose one or more members of your team to subscribe to the review, give suggestions and receive notifications of interactions.

Best practices

No matter if you’re opening a review or you’ll act as a reviewer, empathy must guide both of them. Respect, help and contribute with your peers. It’s a rule good manner.

As the author

Having your code reviewed demands empathy overall. Don’t try to look so smart. Let’s see a few practices that guide your good code:

• Small commits: try to reduce the number of commits. Git squash may help!

• Descriptive review: write a near-perfect title for it, with a detailed description (Is it a bug? A feature? Dark details, etc)

• Scope: keep the scope of your changes limited. Your peers will thank you.

• Explain your decisions: if there’s something a bit more complicated, algorithms choice, explain it.

• Choose the reviewers: sometimes, people are very busy, so choose wisely who can collaborate more with your review. Be by subject expertise or availability, don’t choose just your friends.

• Don’t take it too personally. Don’t be offended you received constructive critics.

As a reviewer

There are different things to look for while reviewing. I really enjoy the design aspects of the code. If we are in review session of Go code, I’ll look for the lack of idiomatic Go. Now, let’s see how to lead the review by the reviewer’s perspective:

• Purpose: does the author followed the best practices, tested and write good documentation? Does this review follow the guidelines your team established?

• Ask: this is very important. If you see code that’s is confusing, hard to understand, non-idiomatic, please ask! You’re helping not only yourself but your coworker.

• Non-function requirements: if there’s something that smells bad, ask! Let’s suppose you found a piece of good that could cause bad performance, leave a question. You may not see something your co-worker wrote or it’s justified.

• Look for unnecessary code: developers enjoy writing code, even when it’s not necessary. If you found something a lib solves better or it’s faulty, ask, suggest.

• Is this code extensible? If not, give ideas on how to make it extensible.

• Is this code clear enough for all the team members understand?

• Does this code leave a future change? The infamous technical debts. If yes, create an issue and add a due date to it.

• Are the unit/integration tests given the same care as the code itself? Test code is code.

• Security: it goes deeper, look for potential security breaches and raise questions.

• For bigger reviews (too many files, classes/methods, functions, etc), I highly recommend to checkout the branch locally and use your editor/ide to navigate the code. If you use a static analysis tool, it’ll help by warning about problems.

Biases

I’ve worked in places where people were code review fanatics. It was bad. No good conversations, just nitty pick details and a lot of egos. Please, don’t do that! I believe in teaching, educating people and feedback is priceless in this case. Why, instead of pointing your finger, don’t you show how and why your suggestions would be better?

Conclusion

Code review is an essential practice for professionals. It dramatically improves the quality of the code, decreases the number of bugs and shares knowledge. The adoption of reviewing code is part of a transition from Software Development to Software Engineering. It’s when you learn to work on a team, divide work and iterate into small steps to delivery well-engineered code.

It’s time well spent. Apparently, it isn’t generating value, but if you look closer, all your users want is software that works. It’s only possible with good practices of real engineering.

Thanks for reading!

• What is Go?
• Characteristics
• Syntax and use-cases
• The learning path

Don’t expect that Go will save the world, but I must say it’s a pleasure to work with!

What is Go?

Go is programming language born inside Google, created aiming software engineers and looking to solve problems Google faced at that time (conceived in 2007 and officially released in 2009). The main design goals for the language were:

• Productivity
• Multicore processors
• Networking
• Large codebases

If you’re gonna look for more resources about Go, you better look for Golang/golang. I consider the word “Go” not very searchable. As you may know, naming things is one of the hardest things in Computer Science.

Go creators (Robert Griesemer, Rob Pike and Ken Thompson) are a mix of academia and industry. They looked for performance and low-level details without neglecting ease of use and bootstrapping.

Characteristics

Among the many features the language has, those who catch my eyes are:

• Static typing but a bit relaxed
• Concurrency
• Productivity
• Web servers
• Multi-platform binary
• Great tools: test, coverage and performance
• Code formatter
• Great documentation
• Amazing for CLI apps and APIs (my opinion of course!)

Syntax and use-cases

Go is in many aspects, similar to C, but also different of C. It favors brevity, simplicity and safety.

I consider very important to learn new paradigms and programming languages. To look at a problem and see how it can be solved with the proper technology is something quite interesting. There are a lot of specialized things, created to solve very specific problems and we must know that!

With Go I find it particularly very useful for distributed systems. The language was created with multicores in mind, so it’s a feature you already have when choosing it.

In 2017 a coworker was starting a new project at my previous company. It was a CI/CD container platform. One day he came to me and asked for an opinion: “What do you think of Go?” He’d started to write it in Python and was happy with the result, but he’d like to try something new. The first aspects I came to mention was - how the language is very readable and explicit, two things I judge essential for big codebases and complex software.

As we were using Docker and they provide, besides Python, a Go SDK, we decided to try it. Let’s see a bit of code to illustrate the syntax:

 1package main
 2
 3import (
 4	"fmt"
 5)
 6
 7func main() {
 8	hoursInADay := 24
 9	fmt.Printf("A day has %d hours", hoursInADay)
10}

Notice that, every Go code lives inside a package. A package is nothing more than a dir inside your project. If your code is executable, it necessarily must have a main function in the main package. This function works as the starting point of your application.

Every function call in Go is preceded by the package: fmt.Printf(...). fmt is the package and Printf(...) an exported function from this package. Functions beginning with an uppercase letter are is visible to other packages, while functions beginning with a lowercase letter are visible only inside its own package.

The support for tests is really nice too. No frameworks, libs or whatever. The language has the test tools built-in. Let’s see an example:

 1package main
 2
 3import "testing"
 4
 5func TestReverse(t *testing.T) {
 6	tests := []struct {
 7		in  string
 8		out string
 9	}{
10		{"apple", "elppa"},
11		{"banana", "ananab"},
12		{"mango", "ognam"},
13	}
14
15	for _, tt := range tests {
16		t.Run(tt.in, func(t *testing.T) {
17			str := Reverse(tt.in)
18			if str != tt.out {
19				t.Errorf("got %q, want %q", str, tt.out)
20			}
21		})
22	}
23}

This test validates if a string is reversed. As it’s a table test, we can pass multiple values of input and output and see if it works. Go also has a specific kind of test to validate performance, known as benchmark tests.

The learning path

As the language is concise and its syntax is kind of familiar for people who’ve learned programming languages or have been in a CS course, no big surprises.

I first started learning with A Tour of Go. It covers all the features and better yet, with lots of exercises to practice. After that, I read Introducing Go and today I use The Bible for reference. Both are great books and rest assured there are a lot of advanced books on the topic. I’ll talk about them in future posts.

The best way to try Go is the Go Playground. It’s a REPL (read, eval, print and loop) on the web! No installation, no headaches, just code.

It’s been almost 3 years since I started working and playing with Go and I must say that I really enjoy it.

Well, that’s it. I hope you enjoy this overview and in the next post, I’ll go deeper with code. Thanks for reading!