Go Language

It’s a relatively new language that came out of Google a few years ago. I’ve been playing around with it and trying to learn some of the basics. There some things that are very attractive about Go, not the least of which are the ability to get out of dependency hell and being able to distribute a single binary. Concurrency features are interesting as well.

Recently I came across a post from one of the Go authors and why he sees more people coming to go from Ruby & Python rather than C++, which is at least true for myself and it rings very true. No one ever wants to feel like things are being taken away from them. Not to pile on C++, especially since my experience with it is limited to a few intro courses in college (which were pretty bad and probably scared me away from it), but a few years ago, Linus also had a few choice words (as usual) about C++ as well.

Rich Hickey’s talk titled “Simple Made Easy” also has some relevance to this concept and I can’t help but think of this Exupery quote:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away



10x engineers

Almost every company that I know is looking for engineers like this. Bad recruiters call them “rockstars” and “ninjas”. This article talks about some of the history and myths associated with the concept.

I think they most certainly do exist in engineering and in other professions as well, though it may be the most explicit in engineering. But it is a pretty elusive concept which is not easily measured and it’s often used to justify really destructive behavior. I would classify someone as “10x” who is has enough depth and breadth to be able to make connections and see perspectives that others can’t. It’s not the efficiency of a specific algorithm or a productivity multiplier even though that might be a consequence. It’s the ability to see a problem in a different light and come up with a novel solution that results in improvements that are measured in orders of magnitude.

 P.S. This is also a relevant post by John Cook.


I knew that honey doesn’t spoil, but here is the science behind it.



This is about spread of innovation. He talks about anesthesia and antisepsis, but you can easily see parallels to technology. He talks about understanding existing norms and barriers to change and how neither incentives nor penalties really work. Very interesting. I’ve been thinking a lot recently about how to best institute change in the organization and why certain teams fail, even though they produce great products from an engineering perspective. This offers some insight into that. If you’re attacking a big, but a mostly invisible problem, it is very hard to get other people bought in.

Do Things that Don’t Scale

I was reading the latest Paul Graham essay: “Do Things That Don’t Scale” and it got me thinking about devops, infrastructure automation and why “tools” teams fail. I am sure I am suffering through a bit of a confirmation bias here, but this article can easily be applied to a team or a culture within a company. If you see yourself as a startup, you have to think who are going to be the users/customers/stakeholders of your product and what you need to do to delight them. That’s a path to success.

The quote that jumped out to me the most was this:

If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be a little frightening to be solving users’ problems in a way that wasn’t yet automatic, but less frightening than the far more common case of having something automatic that doesn’t yet solve anyone’s problems.

I think that ties right back into the devops philosophy of people over process over tools and why a simple “automate all the things” approach is sometimes not enough.




© 2017 Mind End

Theme by Anders NorenUp ↑