In my professional roles the word engineer is in the title somewhere. For instance I’m currently a Principal Engineer at Stitch Fix, but I’ve been a Software Engineer, Front-end Engineer and so fourth over the years. The word engineer isn’t really apt for what I do though. In the last year I found a new promising word: Symmathecist. I learned about it from this post “The Origins of Opera and the Future of Programming” by Jessica Kerr. #

The infrastructure of my productivity is a set of tools that revolve around plain text files. Try as I might it doesn’t work any other way. I’ve tried tools with more “stuff” in them. Often when I try and import my modest1 set of files they grind to a halt. So, I go back to my tried and true tools. I’m thankful they exist and continue to work. It’s a patchwork of folks and tools that keep this stuff running. #

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. #