Hi folks! I’m Jose. Welcome to my page

I have been an official Go programmer for three years now. Unlike many people in my team, I remember the day Google announced go. I don’t remember if it was in Hacker News or /programming reddit, but I do remember watching the go math package compiling in less than a second, at the time, I was writing C++ for an embedded system. Building the whole model as we used to say took 45 minutes, this compiled our C/C++ project into a .out file for an ARM9 and a C55 DSP. When I saw how quickly Go built I was like, wow. To be fair, our build was for a Real Time OS so it didn’t even include the C++ standard library. Most of the time, if I remember right, was spent linking everything. THe linker was getting it’s poor butt kicked. Anyyway, I looked at Rob Pike (?) on YouTube and I was like, ...

A curated list of falsehoods programmers believe in. The Code we write is a representation of the things we believe are true about the world. Every one has just one name, right? Well, most of the time, yes. All of the time? No. If you write an app for yourself, or your small business most of these assumptions are fine. If you write code for millions of users, you are going to find exceptions. Some of them surprise me. Dealing with Time sucks, dealing with addresses, names, supporting multiple languages it’s really hard to get it right 100% of the time. ...

Book Summary: Thinking in Systems Let’s say you want to build the perfect self-driving vehicle. This thing you want to make is composed of many parts. There’s the car itself made up of many subparts (engine, tires, transmission, etc) as well as the AI tech. Realistically you will need a bunch of speciallized embedded systems as well as a central computer to orchestrate everything. There’s sensors, actuators, orchestrators, etc. In short, how does one person know if a design is good? How do you know how fast the visual recognition needs to be to handle controlling a car going 60 mph? ...

The Top 3 Podcasts for Software Developers Go Time by Changelog link This is the podcast to keep up-to-date with all things Go. The jokes are nerdy and the hosts are sometimes not as funny as they think they are, but the content is great and they have a wide set of guests in the show that make it a must for all people who write go for a living ...

Article: Lessons Learned from Twenty Years of Site Reliability Engineering Link to article The site realibility team at Google put together a summary of the lessons they have learned over the years. I am glad they decided to share. The best way to learn is by trial and error. Want your product or service to be better? Launch it, monitor it, and learn from the mistakes. It nice to learn from others, but there is no substitue to first hand experience. This is the list they came up with: ...

Book Review: The Staff Engineer’s Path by Tanya Reilly Tanya Reilly gives a guide for individual contributor software engineers who wish to grow their career but do not want to become managers. It gives insights about what a staff engineer does, and what you need to do to perform at that level. This is a technology-agnostic book. It gives the reader a high level view of the functional areas that matter. ...

Go Russ Cox put out an article yesteday about adding the abilities to run coroutines in go. Today I learned the difference between a goroutine and a coroutine. Coroutine is a concurrency pattern in which only one runs at a time. Say we have coroutine A and B. B waits while A runs then A yields to B and A waits while B runs. It turns out this is useful in a few scenarios. ...

Lately I have been learning about File Systems from the book “Operating Systems. Three Easy Pieces” by Remzi Arpaci-Dusseau. I used to think that I knew how file systems worked because the interface open, read and write is so straight forward, what else could there be to it? But then at work some weird issues come up where some weird behaviour happens, like, du says the disk has space but df says the disk is full, what could make that happen? Or when an issue mounting a volume occurs and you realize that you don’t know the difference between mounting a block device versus mounting a file system. Are they both the same thing? I need to have a mental model of what the system is doing in order to debug it. Knowing the data structures in the file system and having an idea of what happens when you open a file, how does the operating system find the file? how does it traverse the file tree? What is in memory versus disk? I must confess I am still in the dark when it comes to container images and union file systems. I understand how a container is made up of many layers over imposed on top of each other. An image is essentially a tar file of different file systems on top of each other. But, how is it implemented? how do you, can you just put a whole other /proc and other system files on top of a kernel? So anyway, that’s what I have been up to. ...

I’m trying to get through all my technical books that I’ve adquired, and never gotten around to. Not going to lie, the Knuth books are intimidating. They are actually not that bad to get through, but they are books that I pick up, read a few pages on a specfic project, try to do a problem or two, and that’s it. The other books are less intimidating, more doable, I’m pretty sure al but one of these books were lying around the Amazon campus just sitting on shelves. ...

Link to Paper This paper, published in July 1974 is remarkable because the design decisions that were made back then by these guys working at Bell Labs on an operating system for the PDP-11 are still relevant. I am still struggling to create a mental model of the unix file system, the fact that it looks like a single tree with the root at the top while simultaneously you can have multiple devices mounted dates back to these guys at Bell Labs. ...