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.

There is a tremendous sea of good will in the public to volunteer their time, energy, and services to support Veterans and their families. The Department of Veterans Innovators Network has a lengthy list of potential innovation opportunities to serve Veterans, ranging from developing reimagined service journeys for Veterans seeking mental health services to designing 3D printed personalized assistive technologies for Veterans with disabilities to developing a machine learning algorithm to scan retinal images to detect blindness in Veterans.

The question becomes: how to match the talents and spirit to serve of citizens of the United States with the opportunities and needs of employees within the Department of Veteran Affairs?

Our goal is to harness the ingenuity and brainpower of the public and pair this talent with projects in need across the Department of Veterans Affairs (VA). On the platform “Serving Those Who Served Us”, the public will be able to come for an “innovation volunteer tour” and collaborate with VA employees, Veterans, and Veterans supporters on a portfolio of innovation-related projects across the Department. These are short term projects ranging from activities that could take a couple hours to a couple months and are in need of the brain power + talent of innovators, such as designers, engineers, developers, entrepreneurs, and data scientists! Most volunteer activities can happen virtually with volunteers and staff collaborating from different locations.

This is how it will work:

  • VA employees will post innovation project opportunities on to the “Serving Those Who Served Us” platform. These projects will list out their problem statement, a short summary of the project, and the potential tasks for the project and skillsets needed.
  • External innovators can create a profile and browse opportunities to volunteer.
  • When the external innovator finds a project of interest, they can then contact the VA employee through the platform and they can begin conversations to work together!
  • External innovators can earn “badges” and recognition for volunteering their efforts to serve our Nation’s Veterans and their families! Also volunteers who volunteer often (and earn the most badges!) or get nominated from their VA employee will earn a special award from VA leadership!

To help accomplish this goal, the VA is partnering with the Open Opportunities team to develop this platform and working with a local high school to build this platform as part of a STEM student project. We are looking for a team of developer mentors to help provide guidance to this team of high school students in leveraging the open source code of the open opportunities platform to build this platform to serve Veterans!

Anyone interested in volunteering to mentor the kids? It could be completely remote, though if you are in DC, we could probably set up time for you to meet the students in person too. We’re kicking off the project on Monday, but the kids don’t start for two weeks. We’re looking for a few more Javascript developers to help. Feel free to contact me directly or reply on our mailing list.

The Open Opportunities project is supported by:

eagle image within a seal and golden banner
Presidential Innovation Fellows Foundation

blue cloud with number 9
Cloud9 IDE