Diego Pacheco Tech blog

Have you ever tought about the difference between a Senior and a Junior? IMHO, the best definition is that the Senior can figure out things by himself, deliver his work on time, and even teach others. A junior requires much more help and takes much longer to deliver. It's very common for companies at scale to not hire juniors. Usually, managers expect only to receive senior engineers. That works well until you start hiring juniors, because now, the things that were working just stop working. Have you ever thought about the key thing that would make the junior more productive and start getting more senior? IMHO, it's understanding. In the technology field, we think we can hack things, but in reality, we can only do a decent job when we understand what we are doing. It's impossible to make sense of software if we do not understand what's going on. What about AI and LLMs? They might allow juniors to finish narrow and straightforward tasks, but they will likely not be learn...

Let me remove the obvious issues before I make my point. Ignoring problems is bad; ignoring problems at scale is even worse. If we have a network effect of ignoring things at scale, that's the worst thing we can do. Ignoring problems leads to Ignoring culture . Being aggressive with problems is not being reckless; it's not about moving so fast that we break things by doing it so. When applying for software, we ask some apparent questions but sometimes forget to apply for people. In software, we don't want to discover all the bugs in production; we want to shift left and find as many problems as possible before going to production. We must apply the shift left to people and address the issues immediately. The sooner we find problems, the sooner we fix them, and the sooner things improve. 

July 2024: I wrote the first blog post about The Dark Side of LLMs . During these 7 months, many things have changed; the usage of AI and LLMs in engineering has kept growing. LLMs and AI are cool. However, they are not a free lunch and have consequences. If you have not read the first blog post of this series, go there and read it because it will be relevant to this one. One significant open-source development in LLM was  DeepSeek .DeepSeek is interesting for two factors: one that is considerably cheaper and second that is open source. Deepseek introduced a series of optimizations like parallelism, chain of thought (COT), which step by step so we can fix the model where is wrong and usage of Reinforcement Learning (RL) along side with Destilation. RL is how robots roll and self-driving cars also move in a city.  Deepseek's being open source is great for the community; however, we also see interesting moves from big tech companies like  Meta ,  Microsoft ,  Goog...

I have been doing practical and real software architecture for more than 20+ years. Software architecture is a great passion of mine, close to my heart and even to my identity or just id function if we think about functional programming :-). I have mentored and coached many architects during the last two decades. Today, I want to share some thoughts on something that represents the complexity and duality of the software architect role. Being an architect is not easy, it requires a lot of sound judgment, trade-offs analysis, design skills, research, requirements extraction, trend prediction, futurology, and lots of non-obvious skills. Architects must code, be practical, and make very good calls, resulting in better positioning for the future. Doing such a task is not easy and requires a lot of hard work; it's demanding and requires constant improvement and attention to detail. What is essential to extrapolate an architect's non-obvious antagonistic skill set, which the architect...

I love feedback. I believe in feedback a lot. However, not all feedback is good, not all feedback is applicable, and not all feedback is fair. Feedback is critical for course correction and growth. However feedback can be manifested in a variety of shapes, forms and intentions. I believe in creating several mechanisms for feedback because, eventually, what needs to be found will be found. Feedback is a signal; sometimes, it tells more about who is giving the feedback than the person receiving it. Other times, feedback is just wrong. Whether feedback is written or bad, it's an important signal. I believe in being more effective and in the speed of change and improvements. However, can you go fast if you dont understand what you are doing? That's my issue with feedback. Oftentimes, feedback is poorly constructed and missing essential details. So, dealing with feedback is not so different than handling high-priority, difficult production bugs. Requires deep tought, introspection, ...

Quality often means something different to each person. My definition of quality revolves around technical excellence. To achieve this, we need good architecture, sound design based on strong principles, good code, tests in a wide variety and diversity, and proper observability. To get there, we need refactoring(a lot), and I would also include good troubleshooting and review sessions.  Quality involves not only delivering automated product deployments but also ensuring the software is maintainable. Delivering software on time is not enough, and delivering value to the customer is not enough either because people and software are expensive. We need to do better.  Quality needs to be built-in, a strong, solid lean principle. However, we don't have as many incentives to built-in quality as we do for finishing projects on time. Projects are always associated with direct value to the company, and quality is often optional and mismanaged. Quality does not mean QA, and it's way beyo...

After 7+ months of hard work, my third book is out. Introducing:  Continuous Modernization : The never-ending discipline of improving microservices, monoliths, distributed monoliths, individuals, and teams at scale. Modernization is something I have done over and over in my life. Modernization is something that all companies need and will always need. The need for modernization will never go away, even with LLMs and AI. Technical debt, Anti-patterns, and bad decisions do not take days off. Complexity never shirks and continually grows. Companies do not stop getting bigger and doing more and more software critical to growth, delivering value to customers, and staying competitive and relevant in the market. We need a better way of doing software to drive the best outcomes out of us. Continuous modernization is the counterforce to technical debt and anti-patterns. Continuous modernization is how to continually improve, even when you think it's impossible and nothing can be done. We ca...

IF you did not watch the Netflix show: Downfall the case against boing . Please drop everything, go watch it, then come back to my blog post. You really need to watch it. I've been following the 737-MAX drama closely since 2019. Now if you watch the Netflix show and read this link . You will see why I'm doing this blog post. Because I believe there are valuable lessons we can learn from software engineering. Let's first review the technology industry's state of affairs: Waterfall projects are everywhere, thanks to SAFE. Technical debt is never so high, and the tendency is to get even worse over time. LLMs are great but also a great way to add more technical debt faster into the systems. Now, if you think this is a rant, you are wrong. IF you think I'm overstating that SAFE is evil, go read this about what the Agile co-creators said about SAFE .

Today career frameworks are a thing, they are pretty popular along with culture handbooks. Career frameworks are an interesting compass no not only to grow up on a company ladder but also to understand what the culture is and how to be effective. Of course, the paper accepts anything and you might write down beautiful things and have a completely different culture in reality. Besides that the fact that your writing down helps to achieve clarity and spread the word. Especially in REMOTE times like we live today where we have little to zero physical contact. Today I want to comment on 3 career frameworks and also see some similarities and opportunities for us to learn.

Holacracy is an organization system where authority is distributed with self-organizing groups. I first heard about these ideas back in 2013 through Zappos's book . Culture is delicate and often moves much slower than technology. As generations are changing some values are slowly changing. Even COVID-19 is shaping how we live and do business. Holacracy has interesting properties, IMHO is all about the people, having the right talent might work in almost of forms of management systems, of course, the lots of great engineers don't care about what management systems they are in but others do. Today I want to share a slidecast I made sharing some ideas about Holacracy.

I want to share my cents about the post: " On the Diverse And Fantastical Shapes of Testing ". First of all, I believe this is a very interesting subject and yet still see very few engineers talking about it. People mostly take tests for granted. Secondly, I would like to acknowledge the parts I agree with on this post mainly around the concept of Sociable and Solitary Unit Tests are quite useful and show be widespread. Also with the need for teams to have reliable, fast, Bounded(Isolated) and not Flacky on Justin tweet . Now that I acknowledge that, let me elaborate on what I think we are missing and why IMHO the pyramid is dated and we need a mentality shift. I have 4 points I want to elaborate on and give more context.

Security is the new black. Years ago Tests were not widespread as they are today and the same happened with DevOps where automation, Infra as Code, Versioning become the norm today. However, for security, we are not there yet. I believe this will change in the next years and more and more security is a concern where the teams need to care about and understand more about. Security can be pretty scary but at the same time is not rocket science and you can learn it for sure. Today I made a slidecast which I want to share with you guys and go over the security principles, common vulnerabilities and attack vectors, culture, trends, and much more. So Let's get started!

Every company has a legacy code. Often we confuse legacy with multiple different concepts, and this confusion makes improvements harder to happen. Most engineers don’t like to deal with legacy code-we all like shiny new things. Unfortunately, most of the time, there is no easy way out. It is possible to replace a legacy system with a brand new system because it is easier and faster than fixing all the legacy’s problems. We can’t get out of legacy systems because they have old languages, old databases, and often messy. Is that so? However, there are 2 kinds of old languages. The ones who are dying and dated like Delphi or Clipper and the other ones are old but are perfectly fine to use C++ or Java. I’m not defending legacy systems; however, I believe several essential aspects need to be considered. Old: Mature vs. Dated Commonly, we confuse mature software with dated.  Boring technology  is full of good arguments there. Old technology not necessarily means it is terrible. ...

Every company out there works with teams. There are all sorts of teams such as teams specialized in technology stack like Hadoop or teams which are domain-driven and have cross disciplines( Cross-Functional Team ) inside such as backend, frontend, QA, UX, Architecture, and more. People don't leave companies they leave teams, also it would be accurate to say that people don't join companies and they join teams. So should we have dynamic or static teams? Should teams self-assemble or should we have PMO doing that? Should the teams be stable or should we allow dynamic reteaming? Is work always fitting well in our team's structure? What about Platform vs product teams, which one is best? Should we just pick one model or should we use different models? Should engineers organize around managers or managers organized around engineers? Teams affect Architecture and our perception of ownership. Teams should be a people organization but often is just a grouping of people where everyb...

Like we say in Brazil (Todo Carnaval tem seu fim) all carnival has an end. This is the end, my friend. It's the final slidecast on the series. If you did not watch  part 1 and part 2 I highly recommend you do. Part 1and 2 I covered +40 books, 20 each slidecast, and today I will cover +20 more. Total +60 books. Even if you dont agree with all ideas here I recommend you watch them because you will see common patterns and connections between books and might get some insights or reading recommendations. So Let's get started! 

Lean / Kanban was always about managing work instead of managing people. Often mention as Manage the flow. Organizations are about organizing people, but they should be about organizing work instead. As organizations grow, it's harder to make an impact and easier to get benefits. Safi Bahcall, the Loonshots book, says that as organizations are growing, the perks become much easier to get rather than impact(outcomes). That's why politics and empire-building strike. Leaders need to be explicit about managing flow. Otherwise, organizations tend to focus on local hierarchies and produce local optimization(classical Lean issue).  If we should manage work/flow instead of people(Some coachs also called it to manage the system). Should we have teams? Are teams silos? Are silos always bad and wrong? When should we create a team? When should we decommission a team? Work often happens on teams, people leave and join companies because of teams, but would teams get into the way sometimes? ...

This is the second post on the series of management the non-obvious. I highly recommend you check out the first post . For the first post, I shared +20 books which was the base of the ideas of the first slidecast. This is the second slidecast. In this second slidecast, we will continue covering some non-traditional ideas and I will recommend +20 books again. Books are portals to other dimensions. We have several cognitive biases in our brains that work against us. We also live in a world that the bad things are repeat over and over and the good things are faiding. So it's really important to spot and think about it. Often we think we have all the answers and just need to execute something, is that so? They allow us to see things we were not seeing before. So I hope you guys like it. Let's get started.

I had experiences where every single service had to be a ticket with an architect document in order to be able to start using every new technology or service. So every engineer hates to work like that. I personally dont think thats the why to roll because thats means that process wins.  Netflix is famous to have a culture where they threaten people like grown-ups. So if you have grown-ups why do you need to review every single thing people do all the time? For sure reviews are a good thing but architects as Gate Keepers are not a good thing. In general Gate Keepers(DevOps Engineers) as well is as bad as Arch as Gate Keepers. I have mixed feelings but personally, I dont think there is value in having Gate Keepers which is a very poor solution and IMHO a poor usage of people's times. So Why gate Keepers exist? 

This is a pretty interesting book. I really love this kind of book where the author challenges the common sense and traditionally established truths that are not so true actually. Work is something we all do and I often think differently about it. Nine Lies about work sound arrogant but actually is not. The book is full of examples and scientific studies and argues very well on the spot. We are living a global pandemic(COVI-19) and that changed all our lives, that shows how fragile we can be. I personally was always into Lean/Agile and never was a fan of traditional management culture. So buckle up this book might shake up you a lot since will challenge traditional things like People to need Feedback. I often like feedback and worked a long time(~11 years) living strong and daily feedback however even that being a strong truth for me, the author managed to show me a different point of view(wit studies of course) and I still like feedback and strong feedback cultures but I see there are...

Social media is about attention. Real-time chat apps like Messenger, Whatsapp, slack are about attention. 101 meetings are about attention. We live in an attention economy. Everybody whats a time-share of you. A long time ago I disable ALL notifications from Slack, Skype, Whatsapp, Facebook(is closed most of the time of my day) and that is one of the best things you can do too. Not only for your mental health but also to put you in control of your time and therefore your happiness. Interruption is the ultimate killer of deep and meaningful work. However, we also need attention and we might need positive attention much more than feedback(Nine Lies about work).  Humans' attention is a very scarce commodity. I'm not judging anyone: Some people cannot read articles bigger than 5min or videos bigger than 10min. Not for accident Twitter originally had a limit of 140 chars(I miss that :-) ). Attention economy is about information management which threatens human attention as a resourc...