I use Go off and on. I’ve recently had the opportunity to use it again. I feel comfortable now with a handful of languages including Go. More importantly I’ve fought fires in production, developed new services, and tried to refactor balls of mud in a handful of languages. Out of them all no language is more kind to it’s user then Go. That fact is on display in this talk Go at Google: Language Design in the Service of Software Engineering. #

There is a book. Called “In The Beginning Was the Command Line” written by Neal Stephenson. 1 You might know him from such books as Snowcrash or Cryptonomicon, but he’s written some non-fiction as well. It’s hard to describe but it’s about the act of computing and the choices that surround folks who computed, especially in the late 90’s. It’s compelling for many reasons, but I think I can point to at least one reason what I was so fascinated by the command line and by linux. #

I think about this sometimes. Like, people used to punch holes in cards to program. That’s insane to me, but I can only imagine what it will look like in the future. I think the biggest questions is like, will we even write code? Or, will we train, direct, or work with some … thing. Here’s an interesting post that talks about near to far future: “Programming: 50, 100 years from now”. #

I have worked on projects that missed the deadline by years. It’s soul-crushing. Whats worse is that it sounds like it’s endemic. Big projects are failing all over the place. Most IT experts agree that such failures occur far more often than they should. What’s more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. #

Conventional Wisdom can be a bunch of BS. It can be a bludgeon to keep the troops in line. When it goes unexamined it can create group think that prevents healthy discourse. #

I like most people am deathly afraid of crypto. There are just too many gotchas. Therefor I appreciate posts like these where smart folks break down the answers. We’re less interested in empowering developers and a lot more pessimistic about the prospects of getting this stuff right. https://latacora.singles/2018/04/03/cryptographic-right-answers.html

It’s easy to see Kubernetes as “a way to run containerized workloads”. If you look at the comparisons that’s what they all do: ECS, Docker, and Mesos, etc. But, I don’t think that’s the vision for Kubernetes. Here are a few tweets from Kelsey Hightower: The future where Kubernetes clusters disappear and we just leverage Kubernetes style APIs to deploy workloads is fast approaching. 1 The cloud made the hypervisor disappear. #

I’m torn between two axes. The first is being user-oriented. Thinking about the problems from their perspective and ensuring you are always working on something that improves value. The second is that good software is often fast software. While it’s hard to make a case that keeping a service at a p99 of 500ms will increase the value to your users, I’ve found that trying to make it is important. The reality of the situation is always that it depends. #

DevOps, at least as I understand it, is about delivering value. It sounds simple, but delivering that value happens via a pipeline. The stages of that pipeline often represent whole groupes of people. Ofthen those groups can have competing priorities. Thus increasing friction in the pipeline and slowing down the deliver of value. That’s where DevOps comes to the rescue. By working with everyone in the pipeline and building a shared vision of how to deliver value, you can get everyone to optimize for the shared global goal of value delivery. #

The biggest irony in dev work is that we all want to build easy to use systems, but that’s hard to impossible to do. Easy is hard. Rich Hickey in his talk “Simple Made Easy” walks us through this irony and why its so important that we continue to try and build easy to use systems. 1 Here is a transcript of the talk as well. ↩︎