When I was a little girl, I lived for a year in El Salvador. I went to a private school and generally lived a life of privilege. Our house was smaller than the one outside of Boston, and we didn’t have air-conditioning or a fancy compound like other members of the British-American club where we went swimming. My brother and I could go down to the corner store and buy firecrackers, and we would go across the street to a soccer field and find spots in the nearby trees where we could blow up piles of sticks. From there we could see where some folks lived: shacks with no running water, tin roofs, and painfully thin children.

In fifth grade, I’m sure I had no real idea of what was happening, but I knew I had privilege. Things were scary, but I did not fear for myself (although perhaps I should have). The poor would routinely get shot by the police and it was accepted as the way things are. Corruption and bribes were status quo. My home government (the United States) supported the government in El Salvador with arms to defeat the influence of Russian communism, despite no real evidence of that — this was a civil war with casualties on both sides. I remember when the dad of a kid in my class was kidnapped, and the family paid the ransom and the guerillas returned the dad, except his head was in a garbage bag, separated from his body.

I don’t mean to be gruesome, I just think about these things, when I hear about the violence by police in America today. This feels spookily familiar… I’ve been watching things get worse for over three decades. It is a good sign that people can take videos and speak out on twitter and express outrage #AltonSterling #PhilandoCastille #EssenceBowman #BlackLivesMatter

“It’s not what you see that should cause outrage, it’s what you have not seen.” —@shaft calling in Black to work tomorrow

I know for every video and photo there are those who were driving alone or where there were no bystanders with cell-phones.

passiflora-july-2016Digging in the dirt, pulling weeds, planting flowers… these things make me feel at peace. There are some activities in my life that I have discovered are symptoms of happiness. My garden blooms, I write, I do the dishes in the morning, and I take longer walks with my dog.

I don’t know that they actually make me happy. I don’t particularly like to write, it’s a way of thinking through things and connecting with other people in quiet, unexpected ways. Writing makes me just a little uncomfortable, but it helps somehow to send these thoughts outside of my head.

I can’t say I always love gardening. It’s kind of boring, but more interesting than meditation and with some similar positive effects. I like how I feel afterwards, and it makes me happy every time I walk by and see colorful splashes of color and so many shades of green.

These small acts of taking care of myself and being present in my surroundings are indicators. I try to notice when they stop, when the weeds grow wild, when I don’t take time to write and the coffee cups pile up in the sink. Today I noticed that I was gardening and it wasn’t even necessary, and I’ve been taking longer walks in the morning. I still struggle and have doubts and there’s all sorts of awful in the world, but when we go out there to face the world, I think we all need a couple of leading indicators of happiness.

Rob Pike’s Go Proverbs convey many elements of the Go programming language philosphy in a way that is approachable and fun. He compares with the game of Go, which is “easy to learn, and hard to master.” Inspired by the “Go Proverbs Illustrated” book about patterns in playing the game of Go, he crafted a set of proverbs about the Go programming language. His goal is that proverbs should be “short, poetic, general, about more than the Go programming language. Contradictory is OK. Life and programming are full of contradictions.” These are ideas to explain to beginners or maybe in a code review. He notes that there are probably many more. These proverbs seek to capture the ideas that make programming in Go different.

The proverbs with my notes from the talk are listed below. I also found a lovely post with code illustrations by Greg Osuri, as well as graphically illustrated deck with nice icons chosen from the noun project and if you have additional proverbs to suggest, there’s now a github repo.

“Don’t communicate by sharing memory, share memory by communicating”
Passing on a channel enables safe concurrent, even parallel operations.

“Concurrency is not parallelism.”
These are often confused by beginners. How these are thought of in the Go community is that they are important to keep separate. Concurrency is a way that you structure your program to make it easier to understand and scalable, and parallelism is simply the execution of multiple Go routines in parallel — somewhat a less interesting topic than concurrency.

“Channels orchestrate; mutexes serialize”
Mutexes are fine-grained and very small, and they tend to serialize execution. If you put a mutex on a variable, then only one thing can ever happen to that variable at any one time (and that is often very important, and sometimes exactly what you want). In the big picture of your program, channels give you a way to structure your program and arrange how the pieces work. As an example, how the “Select for loop” uses channels to orchestrate your program.

“The bigger the interface, the weaker the abstraction”
In Java, you think about interfaces having lots of methods. In Go, we have interfaces which are not declared to be satisfied, they are satisfied implicitly, but even more important is the culture around interfaces that is captured by this proverb. The smaller the interface is the more useful it is. This is a Go-specific idea, we want to make little interfaces, so that we can build components that share them.

“Make the zero value useful”
You want to make it so that you can use a type without initializing it (if you can).
For example: Bytes buffer or sync mutex — you don’t have to call an init function, you don’t have to call any methods. There is nothing wrong with calling a constructor, sometimes you need that; however, if you can avoid it to make the program nicer, it just means there’s less API there which is always a good thing.

“interface{} says nothing.”
When you are programming and have an empty interface, think very hard about whether that is really what you want…or whether there is just a little something that is really necessary to capture what you need. Sometimes you do need an empty interface, but it is rare. It is overused, especially by beginners. You see this in almost any question on stackoverflow in Go.

“Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite.”
Experienced Go Programmers will say “I don’t like how it formats, but I really like that it formats.”
“A little copying is better than a little dependency.”
You can make your programs compile faster and be simpler if you keep the dependency tree really, really small. Sometimes you don’t need that whole library, you just need those three lines of code, that you can just copy and it’s fine.

“Syscall must always be guarded with build tags.”
Syscall isn’t portable — that is the point. If you import it, you must have a build tag for the architecture and operating system that syscall invocation is valid for. If you think you have a portable thing you are using the wrong package. Check out ‘os’ or something else.

“Cgo must always be guarded with build tags.”
Same as above. If you are calling C, god knows what it does! It’s very non-portable. It needs to be built for specific architectures and operating systems.

“Cgo is not Go.”
A lot of people in the early days would write about how a favorite feature of Go was how easily it connected to C, but lots of times it shouldn’t be necessary, it takes you out of the Go universe and you lose the benefits of Go if you are coding in C.

“With the unsafe package there are no guarantees.”
A lot of people use “unsafe” and then complain that things don’t work… that’s the point, don’t use “unsafe” unless you are prepared to have your program break one day.

“Clear is better than clever.”
Amen. There are languages that celebrate cleverness. Go celebrates simple clear code. The Go philosophy values code readability.

“Reflection is never clear.”
Common Stackoverflow question of people wanting to use reflect and complaining that it doesn’t work. It doesn’t work, because it is not for you. Very, very few people should be playing with this. Powerful, yet very difficult to use. We should encourage beginners to step away from using reflection and use the language proper.

“Errors are values.”
Beginners struggle with this. Too often people write “err != nil” — they think about substituting try/catch. Errors are just values…

“Don’t just check errors, handle them gracefully.”
Think about whether you should be doing something with errors. People are too quick to just return an error up the tree, instead of designing how it should work. A big part of writing good Go code is getting the error handling right up front. Of any program really, but its easier to program with errors as just values, and easier to do it gracefully.

“Design the architecture, name the components, document the details.”
Think of really good names for the pieces. If the names are good, the code will be easy to understand and the design will be clear inside your pogram, and programming your system will feel natural. Names should express your design.

“Documentation is for users.”
Think about what the function is for, not what it does. You want to write something that the programmer using your function will find helpful.