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

What is the one metric for sucess in your career? Lately I’ve been thinking about what it means to grow in my career. Like, How do I know I am doing a good job? Is there a metric I can track? It turns out there’s people way smarter than me that have already thought about that and written about it. Tanya Reilly wrote an excellent book on that subject The Staff Engineer’s Path which I reference a lot, specially when I try to figure out how I should approach my career path. I am clear in the fact that I want to stay technical, I don’t want to be a manager, not because there’s anything wrong with being a manager. The thing is: I don’t want to stop writing sofware. I want to design, implement, test, deploy, maintain and deprecate software systems. I don’t want to stop doing that, at least, not for now. So anyway, there’s a lot of good advice out there, there’s a lot of things you can optimize for. If you want to go from software engineer to senior you need to know things, you need to be responsible and reliable. If you want to grow in your career then you need to be a leader, a role model, you need to be the glue that facilitates collaboration. Since there’s so much to know, so many different ways to help a team. There are so many rabbit holes one can go down in depth: Business Domains, Customers, new fields developments. There’s so many good people to meet. So, you can’t know and do everyting. You have a limitied amount of time and everything counts. So then, how do you know you are doing a good job? What is the North Star? ...

I’m lucky that I get to work with people who are good at what they do. The corporate-speak term we use at Amazon is the Leadership Principle of “Right A Lot” For me it’s about having a scientific mindset, or more plainly, constantly wondering, “how does this work?” “Why are things working this way, instead of that way?” or my favority “What would happen if I do this” but wondering and inquiring is not the whole thing, is actively working to disconfirm your beliefs. It’s about being open to the possibility that you might be wrong. I love that. ...

Practical Engineering by Peng Zhang I want to give a quick shout out to Peng’s blog peng.fyi Peng works with me writing software for AWS Fargate’s Dataplane. I have been following his posts the last few days and I really like this blog because: Technical topics that apply to most folks in my team His posts are short and to the point. He illustrates his points with code. The code is formatted with beautifcul syntax highlits that makes it easy to read. I get inspired myself to share my insights in writing. Thanks Peng! ...

Book Review I’m almost finished with The Siren’s Call by Chris Hayes and it’s interesting enough to call out here. The book starts with an excellent explanation of what attention is and how it works. Then the book presents two analogies to use when thinking about attention. The first one is to think of Attention as a resource that drives the economy, like labor, it is commodified, it can be monetized, marketed bought and sold. Since information is now pletiful, (there’s too much of it, really) attention is scarce, we have a limit of how much information we consume, how much we can pay attention to. So now market forces, tech companies, politicians they are all competing for our attention. Our attention has value, it yields money, power and fame. ...

This week I had an Eureka moment at work. You see, there are many things I see at work that I would like to improve. Technical debt in our codebase. Inefficient processes. Communication silos across teams. The list of things one can improve never ends, this is true in all software shops. System complixity grows as new functionality gets added, inefficiencies optimized, bugs fixed. Secuirty hardened, etc. How do you increase the quality of your system without interrupting the flow? Well, obviously, you break it up, one tiny thing at time. That’s how. Yeah it’s obvious but (this is embarrasing to admit) I get the urge to make BIG changes, I’d like to rewrite whole chuncks of the codebase, I’d like to build a brand new release pipeline, and we might do that someday, but not today. When you have a team that’s busy doing the work, tidying up gets deprioritized. After all, that bug in prod needs to get fixed yesterday, that new feature needs to ship on time. Oh, by the way, the developer that was working on that thing your system depends on quit last week. ...

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