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

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.

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.

This is not a geography post. However, software architecture and code also suffer from erosion. People come and go, teams get created and destroyed by the project mindset. The result is an ownership problem. Ownership problem is just another form of a Governance issue; Governance is a bad world and often associated with bureaucracy and old ideas, and bad stuff. Ownership issues exist because teams touch a higher number of resources such as Code, Database Schemas, Dashboards, Alerts, Wiki pages, S3 Buckets, Kubernetes clusters, Ec2 instances, and much more assets. So why AWS TAGS are not enough? 

So this is not a post about Slack(IRC/Chat application) - there is nothing about instant group messaging here. Slack also means LOOSE which is the opposite of tight. We all know Debit as bad. We all know Debit slows down execution and increases maintained cost. So why do we still suffer too much about it? IMHO there are several reasons that go from Bad management, Lack of Vision, Poor Tech Talent Pool, Lack of Software Ownership and Culture. Recently I finish Upstream from Dan Heath, which is an amazing book about product discovery but also about Software Architecture and Team Organization(Because both are the same :-) ). Dan has other amazing books like Switch . Which I highly recommend it. 

Dependencies are natural in big software solutions. However, dealing effectively with dependencies is critical in order to scale and reduce maintenance costs. Team dependencies are not a simple problem so will not be fixed with one simple answer. This is an old problem with most organizations suffers from it either in different degrees or different maturities but the problem is pretty much the same. Architecture is more than technology. Architecture and team organization work closely together and together can provide important mechanisms to scale, maintain, and better deal with team dependencies at Scale.  The Video The Slides Dealing with dependencies de Diego Pacheco Cheers, Diego Pacheco

I'm doing retrospectives for more than 10 years. I saw it all, the good, the bad, and the ugly. Retrospectives are fundamental and instrumental part of Agile. Even if you are not doing Agile or is not agile-ish in our way of work I would 100% you need o to have some form of retrospective. Retrospectives are an important mechanism to introduce improvements. Pretty much all companies spend lots of time in planings sessions. Long planing sessions are pretty normal(4h or more). However long retrospectives are not popular at all. It's possible to work without classical retrospectives however you would need some form of Reflection and Guilds/Chapters might be a place to have retrospectives. IMHO Retrospectives is something you want to do without mercy(Maybe I'm watching too much Cobra Kai ). Meaning you should do lots of retrospectives. Retrospectives have different flavors and styles however I believe there are 2 important ones: Big & Micro. Retrospectives help to change t...

Often successful companies have significant growth. Meaning: grow in structure. More people, more departments, more managers, more coordination and often more overlaps. Enterprise companies always end up having some form or governance issue. I remember at the beginning of the SOA world "Governance" was a very bad word and there was abuse. After 3 waves of Agile manifestation, we are with much less "Governance" look like we still have plenty of abuse. Abuse can be also called WASTE(Lean Concept). Some rules can really promote best practices and better software like: Do not share your internal data stores, Expose data via Common Interfaces like (HTTP / gRPC).  Systems tend to grow and get more complex as companies grow with them. Every single improvement(refactoring) often means more investment($$$) which also can be saying as business entropy as the time passes it only gets worst(more complex and more expensive). When we analyze refactorings individually(business imp...

Building products(software) is hard. There are so many things that can go wrong. At Scale, everything becomes more laborious. More people, more coordination needed, more things that can go wrong and more pieces and more dependencies. To scale, we create team structure and software, often in the form of SOA Services. Any architecture or Design should survive a set of hard questions; otherwise, the idea or solution might not be good enough. Having people thinking into different dimensions, with varying points of view and various schools of touch, would create disagreement with could be an excellent and healthy thing. However, not always thats is the case.

Github is an amazing platform. Today I want to show in a video 2 super killer features which is: Pull Request Template and also Branch protection with CODEOWNERS. This feature makes the PR Reviewer life much better and improves documentation, learning, save time, and just push the team to a much better direction. Sometimes people might create too much bureaucracy, however, the other extreme to have no comments in chaos and not good. So we need to look for some sweet middle ground. So Let's get started. 

So this is a hot-button issue for many people. I',m by any means not trying to be preachy and say what's right or what's wrong, this is just some of my perspectives on the matter.  Many people don't like to work more than 6h and thats fine. Given the level of execution I like to play I really think I need more hours. Working as a consultant you really do not have holidays or day offs, you work you get to pay, do not work dont get paid. Even as you get raises and progress in your career as consultant hours will always be a thing. I have that. You easily could call me a workaholic, a victim of the system, or simply someone who gets things done. I'm not saying that people who work fewer hours get fewer things done. Every one was a different moment and whatever works best for you it might not work for me at all or vice-versa. So do not see this as a workaholic-apology. At the end of the day what matters is: (A) Are you getting things done?, (B) Are you healthy or sust...

Right now, everything is different due to COVID-19. Even before the COVID-19 meetings were often seen as the one tool to fix all sorts of problems. Meetings can have value if you have a clear agenda and people get prepared before the meeting which never happens so meetings tend to bring lots of waste and kill engineering productivity because it becomes flow killer. The reason why meetings are a goto tool for every kind of problem because it's easier, however, the price is high: Affects Engineering productivity because it's an interruption and often things dont get done and you need more meetings. So you might be wondering what we can do about it, well there is plenty of things we can do about but in order for any solution to work we need to have Discipline which is hard, that's why lots of meetings continue to happen. I'm and always was a huge Chat fan. In the past, I used Skype, Atlassian Hipchat, Teams, and Slack for the last 6 years these tools are great because t...

So this is the second video about my thoughts on Estimates. The first video is here if you did not watch it. I end up doing a second video because I realized there was more stuff I want to say and elaborate more like: Estimates not being reliable and liner. Moscow is really helpful to increase the success chance and also small things like XP Simple Design, Metrics, Team Layout, Branching Model, Architecture and so many other things which I cover on this video. So this video is a bit bigger than the first one(8 min) but not that big(12min) so I hope you guys like it.

Remote work was kind of the default for me. I'm a Gypsy, always traveling, 6 months home in Brazil, 6 months in Europe / USA. Doing that for +10 years makes me feel remote native :-). Even in Brazil, I travel a lot to Santa Catarina and S ao Paulo states. I go to standard office 1-2 times per week maximum. So remote was a default for me a long time. Now we are facing dangerous and different times because of the COVID-19 .  So remote becomes the default for everybody. Remote work has several advantages like You dont loose commute time, I used to lose 2h per day in a traffic jam. Also, you can have your meals with your family and you can work with much more comfort and focus. IMHO I always worked much more from HOME rather in the office for basic 3 reasons. First of all, I felt much more obligated to produce more results since I was working from home. Second I have much fewer interruptions in HOME than in a formal office. Unfortunately, there are tons of people who do not know h...

Building Digital Products is HARD. Doing Hard things is hard but it's what we need to do. Mindset is everything. Teamwork it's critical to achieve true innovation and avoid silos. I Deeply believe it is Blameless culture and Psychological Safety environments. Trust is the foundation of any high performant team. However there is a tricky thing, you really want to have trust because you want to have people being able to DISAGREE. Disagreement is really important nowadays, it's like a network of layers and layers of testing. Everybody wants to succeed, more validations the better. Everything we do is complex, lots of different roles: UX Designer, UX Researcher, Lean BA, Discovery Architect, Delivery Architect, Foundation Architect, Agile Coach and much more. As we look to technology we have an explosion of languages, stacks, libraries, and frameworks just to have the right tool for the job, get the better performance and best user experience we can provide. Cloud computing i...

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

Estimates are lies, estimates are not reliable. It's super common to have companies doing estimates completely wrong. There is no way to do estimates right, however there are ways they can be even worse than usual like: A) Having managers doing estimating for engineers. B) Not accounting holidays, Refactorings and Bugs. C) Not comparing working items D) Ignoring variation: Different sizes, complexities, technologies, needs. E) Not understand when the system is stable or not. Very often estimates are done before the project or product start and where variation and uncertain is sky high. When we take a look into PMI, which is based on bridges and buildings we still see buildings and bridges with extreme delays, extreme over budget and poo quality. If this is true for construction engineering why the hell would not be true for software engineering where we barely have 50 years of experience as a industry compared with the +2K years in construction engineering. Project after pr...