Diego Pacheco Tech blog

I'm a performance aficionado. I always will be :-). However, performance is a tricky thing. It always depends on the use case. There are several things could affect a benchmark like: * Hardware * Payload size * Kind of Operation * Time * Configurations / Tunings * Warm-Up * What the code does and how I never like the blind discussions saying this server is always better than that server because I knew use cases are everything. Performance is important and in the cloud, it leads to other things like Scalability and Costs. Great performance allows better scalability, therefore it reduces costs because you do more with fewer resources(machines or containers).

Rust is an amazing language. If you follow my blog activity and know me in person you might know I'm really invested in rust on the last +12 months and also blogging a lot about Rust. Now I want to do something different. I do not want to paint a rosy picture of Rust. I do believe trade-offs matter and you only know something true when you know the cons. There are some problems I will expose in this blog post and not related to rust only but related in fact about two other factors. A) "New" languages. Rust has +10 years however still not mainstream and I still consider it a new language. B) New Paradigm / Approach - everything you deviate from standard C/OOP you will face resistance, I saw it happens a lot with other languages like Scala and Clojure. These problems happen in rust but I want to make it absolutely clear they are not unique to rust. So Let's get started, let's start with the Good things.

I believe a lot in Agile and Lean Principles. Agile movement historically often focused too much on teams and really left Software Design and Architecture behind it. Regular Engineers often belive a lot in Clean code and take it as a dogmatic bible and only source of truth. Clean code has some good stuff like the Boy Scout Rules(Alway left the code better than you found it). However lots of clean code "truths" are not so "true" at the end of the day. I've found considering the code without a Design and Architecture, extremely dangerous.  Most of the time I saw the worst codebases ever was related to very poor Software Design and very poor Architecture. Having a Good Architecture and Good Design does not mean you will have Good code, however, if the Architecture and the design write the code is very simple and easy to change. However, if the Architecture and the Design are wrong it might be impossible or very hard to change the code.

Rust is a great language, currently was the language that I most study in 2019 and in 2020(so far). Rust has interoperability with any language pretty much. Rust is also great for containers and to run in Kubernetes. Today I want to show how to build a simple microservice. We will use Actix , Tokio-Postgress , and other libraries. We will use Postgress as our source of truth and we will run it in docker(for development sake). We also will use Barrel + some customs migration structure I created. The code will be all async and non-blocking IO. I hope you have fun, let's get started.

Organizations need Lean more than ever. IT became a huge waste factory. Software scale works backward, the more money you throw in, the bigger the project the bigger your risk and bigger the waste you have. The technology work backward because If you think about Milk, the bigger the scale the cheap is the price. I was wondering how did we get into the position we are. Tech debt does not describe debt anymore, we are dealing with a totally bigger order of magnitude scale of debt. Tech debt can be big but I'm talking something beyond big. Maybe at the scale that some governments have debts with the  IMF . Why did we go south without noticing? I have some theories. Technology is like a time bomb, companies might start breaking because of it at some point. The debt become so high that multiple 3-5 years of investments might not be able to pay then off and business might start failing because of the bad technology practices. You might think I'm crazy. Because of business operates ...

As Software Engineers we write code all day long(when we are not into meetings). Writing is how we get things done, shape the world with better solutions. Writing is old around ~3K BC, Egypt's believed knowledge was power. I believe writing can go way beyond expressing the current knowledge but also helps to shape future knowledge. Writing is not made only for journalists, teachers, and historians like I said engineers write a lot. For the last +10 years, Agile Software development becomes mainstream and it's very often to get teams with anti-writing feeling. Writing can be expressed in several different ways: Code, Design, Architecture, UX Personas, Ux Research, Business Rule, User Story, Use Case, Blog Post, Code Review, Documentation. Almost everything is related to writing.

During AWS RE:Invent 2019 amazon release Amazon Builder's library . Which are world-class Distributed Systems, Engineering, Cloud-Architecture, DevOps class and lessons learned through experience on how to build reliable and scalable systems. The library is really great, some articles are a bit extensive like 30min read but they are really well crafted and provide great insight on amazon best practices. Today I want to share my review notes on the Library. I highly recommend you read the library. Amazon content has links with their products and also links to further readings in the sense of theory & tools. It took me a weekend to go through all the articles(13 so far) and this time was well invested I had lots of fun and learn a lot.

Amazon Aurora is a very interesting piece of engineering. I want to share my review notes on 2 papers related to amazon aurora. I was wondering for a long time, 2 years if I should start publishing my reviews or not. I do structure learning and study for a long time for more than 15+ years, however, I often take notes on the papers and videos I see in my Evernote. After 2 years of thinking I decided to share my papers review notes. I believe this decision will improve my learnings because I will write even more about the things I study and read and often do in my day-by-day work. I don't work at Amazon however I like amazon a lot, they are a reference for me in regards of SOA(Service Oriented Architecture), DevOps, Cloud, and NoSQL/NewSQL databases now, which aurora they proved to me that cloud-native database it's a real thing and its not BS marketing.

Getting more things done is something everyone wants. However, some people are better than others and can do more. Experience and Deep Technical knowledge play a hugely important role in this equation however there are other mindsets and tricks you can do to boost your productivity. Today I want to hare some of the tricks I'm doing over the years to boost my delivery hopefully it will help you do get more things done.  First of all, you need to understand the top 3 enemies of productivity: (A) Meetings / Interruptions, (B) Self-Pressure, (C) Lack of Clear Goals. First of all, meetings need to be bounded, you really should carefully pick how many meetings you do per week because meetings often can be very low on value because people often dont have a clear shared agenda, do not prepare well for the meeting and dont have a clear outcome or list of clear actions, having said so, meetings tend to proliferate, you really need to avoid meetings proliferation and get more outcome if you...