Good to go: Simplifying communication for engineers

There is a human side to programming that doesn’t often come up in textbooks or blog posts, but is one of my favorite aspects of being a software engineer. When writing code, it is obvious to make sure that it solves the problem at hand, and that it will run without crashing, and that it works at scale. It is not as obvious to ensure that the person reading your code after you’ve left will be able to keep this system running and add new features to it.

This is the human side of programming that I love to solve for, and the one that I got to talk about today at the Grace Hopper Celebration for Women in Computing.

As someone that studied Computer Science, Psychology, and Engineering Leadership & Development — and someone that has worked in plenty of very large, very old code bases — I always had a natural tendency to think about these things. But I never had the impression that the programming language I was writing in thought about these things, too.

That is, until I met Go. Go is a programming language that has become increasingly popular since it was first developed at Google and released as Go 1.0 in 2012. It started as a response to the complexities of C++ and other language created decades earlier — the ramp up period for new developers joining codebases was too long, and too often programmers would ship code littered with vulnerabilities.

This response resulted in a coding language with one third the keywords of C++, one half the keywords of Java, and a language specification that fits on 40 pages. From an engineering standpoint, Go is fast and can run on any machine. On Windows, Mac, or Linux, you are good to Go with a binary — it means you don’t have the same headaches you have with Java, where you have to run through the JVM.

The other popular feature of the language is its built-in concurrency support. Learning how to handle more than one task at a time is a huge concept that can be super frustrating for early-career engineers. In Go, you can fire off a new thread with the simple syntax of `go func()` — there is no need to import anything. Extending the functionality to listen for messages can be done easily with waitgroups or channels, drastically simplifying an intimidating topic of concurrency.

I started writing in Go when I was just out of college and couldn’t believe how quickly I picked it up, especially compared to other languages. I had spent months learning about how to build APIs in other languages (and mostly failing), but after a week of writing Go, I had completed my first API that integrated with Slack. Within two months, I had shipped a backend system handling event registration for when we went to hackathons, complete with offline sync capabilities that handled thousands of requests at a time. Not only did Go work flawlessly for me, but I was able to pass the project on to newer Capital One hires that seamlessly continued the project without me.

The community we have of Go developers internally replicates the Go community at large: welcoming and excited to work with those that are new to the language.

This experience turned me into something of a Go evangelist here at Capital One, along with a few other early adopters — you might be surprised to learn how much we love the language around here! The community we have of Go developers internally replicates the Go community at large: welcoming and excited to work with those that are new to the language. If you’re interested in checking out the language — and I hope you are — I encourage you to join our Slack community and find out how fast you can Go.