Have feedback or want to request a topic?

We would love to hear from you! Send us an email at thinkbigcodesmall@gmail.com

Don’t forget to subscribe to us on our YouTube channel

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at thinkbigcodesmall@gmail.com

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

Coding assistants have been around for around two years and have generated more hype than just about anything in the past twenty years. The first mainstream model, ChatGPT, was released in 2022, and many other variants have followed. There have been promises of 30-50% productivity gains and even full replacement of engineers. Let's dig into the details and see if we can get an answer to a very complex question: Do genAI tools drive better productivity?

What are coding assistants (LLMs)?

If you haven't heard of coding assistants in 2024, then you must have been under a rock for the previous couple of years. While most have heard of them, there is still quite a bit of confusion about what they actually are. This is not a deep dive into the technical nature of LLMs so let’s just call them what they are, excellent text predictors.

They have the ability to answer questions, summarize data, and provide code for certain tasks. At first glance, they can seem to be magical with seemingly great answers to lots of different questions across many different languages and tasks. This ability has immense use cases across software engineering and the broader employment landscape.

We have built a worse calculator

For all of the technological age, we have worked on written logic. Regardless of how many times you run an application, you will get the same results. This is no longer the case with LLMs, they don’t work on this logic based system. They work similar to how a human would, taking in a bunch of inputs and then producing a response that makes the most sense based on that input.

Just like humans, LLMs have an error rate or hallucinations, as they are commonly referenced. This is due to a few different things, but a key problem is that it is language based. It is “searching” through its training data to find the next logical word to respond to you with. There is a fuzziness to language, the training data, and how familiar the training data is with the question. All of these factors contribute to the error rate of bad responses.

That said, we can’t forget that they are great text predictors and they don’t actually understand any of these actual concepts. For example, you can teach a LLM to answer questions around Calculus but not teach it Algebra. This doesn’t make any sense from a human perspective since you have to know Algebra to understand Calculus.

But since an LLM is a language-based text predictor… it doesn’t care if it knows the fundamental underlying knowledge. It just knows what you teach it via language, and it will respond accordingly.

This is the fundamental understanding that we need to take when considering how and when to leverage LLMs or coding assistants.

Treat them like an intern or junior developer

I remember back in my early career, when I knew everything and these senior Developers were just blowhards giving me trouble about doing things their way. Looking back, it was clear how much I didn’t know and how confident I was in my half-baked solutions.

The seniors and other mentors I had kept a good eye on me while I learned and matured into a better developer over time. As I grew and matured in my craft, I was given more and more leniency to take on bigger and bigger projects. After time, I was the one mentoring juniors and seeing so many of the same mistakes I made along the way.

While this is a great pattern to help juniors in their career, this is NOT how you should treat LLMs and coding assistants. They will very, very confidently lie to you after getting it right many times in a row. You should always treat them like the first day a junior joined your team. They can be helpful, but don’t let them control too much, or you may end up paying the price.

Haven’t we seen this before?

Since the release of CoPilot and others, the burning question has been what are we trying to do with these tools? There are many that would say they are going to completely replace developers… To that I say good luck. Though there is a lot of fear across the industry of people being replaced by LLMs or coding assistants, I have yet to see an example where this is remotely possible.

You don’t have to look to hard find other historical examples of monumental change, like when typewriters emerged in the late 1800s. People feared losing their jobs, particularly scribes, clerks, and professional penmen who made their living through handwriting.

However, what actually happened is quite interesting: rather than eliminating jobs, typewriters transformed them and created new opportunities, especially for women entering the workforce. The role of "typist" or "typewriter" (as the operators were initially called) became a new professional category. Business schools began offering typing courses, and many women found employment opportunities as secretaries and stenographers - positions that previously had been largely held by men.

There are some fascinating parallels with today's AI and automation concerns. Just as typewriters didn't eliminate the need for written communication but rather changed how it was done, many technologies end up transforming jobs rather than completely eliminating them. That said, the impact on individual workers who had specialized in handwriting was very real - particularly professional penmen who had made their living through calligraphy and handwritten documents.

How are teams successfully leveraging AI?

To me, the best benefit they had is around code generation for solved problems. For example, I want to integrate my app with Google Maps API, integrate Stripe using React, or scaffolding a new Java application. These are common problems that have been solved many, many times over and yet are things people struggle with on a day to day basis. Code assistants can absoltely help with these types of tasks including scaffolding tests, functions, methods, or just about any common block of code.

Another benefit is being able to document code, but this one I had a bit more of a problem with. Yes, you can ask CoPilot or any other coding assistant to “document” your code but this is far from trustworthy. The better pattern is to have it help you scaffold your documentation and then rewriting or editing the content based upon your knowledge of the code and what you were trying to solve with it. This can be very helpful while mitigating the downsides that can come from this type of use case.

Another common pattern that I have seen is using coding assistants during the PR process. This is not dissimilar to the documentation aspect listed above, just used in a different way. When you submit a PR, leveraging a coding assistant to write up the PR commit message can be very helpful. While this is useful, care really needs to be taken to ensure the accuracy of the write and also including the other context that could not be derived from the code itself.

Can you trust the output?

It is imperative to not forget the fact that they don’t actually know how to code and the output is just the best prediction of words based on your input. Is this something that you can trust? The answer is kind-of… or to state it a little more usefully… trust but verify.

This can be a challenge, especially when they seem so smart and get it right a lot of the time. The big question you need to ask, what will happen if it gets it wrong? Maybe there will be a production outage, cause other rework or dependency issues, or maybe something worse.

Going all the way back to the first autonomous cars when they were just starting to be tested on real road, people started to trust them very quickly. It didn’t take long until there were videos of people sleeping in the cars while they were driving down the road.

This same pattern can be seen across the usage of coding assistants. I recently helped a client do an analysis of this coding assistant usage to see if they were being more productive because of coding assistant usage. This is not an easy question to answer for most people because I believe it has a false dichotomy in it.

The Development or Iron Triangle

I recently posted a full article on this topic but as a quick recap, the development triangle is comprised of cost, quality, and speed. As with any triangle, you get to dictate two sides and the other is determined for you. The only other option you have is to make the triangle bigger but you can check out the full article for the deeper details.

But back to measuring coding assistants, you can’t just look at speed. You have to look through the lens of the triangle and understand its broader impact. For the client I worked with, they had very clear “productivity” gain when looking at the number of PRs submitted for the group that used coding assistants. It was almost double the amount for the same sample size.

But from the quality lens, they had 4x more PRs merged without review with 80% less comments on PRs overall. These are staggering stats which also coincide with recent study from Uplevel that showed a 41% increase in bugs for teams using coding assistants. In their study, they also showed little change in PR cycle time, time to merge, or PR throughput.

The problem is not needing faster typers

The biggest issue I have with coding assistants and the challenges they claim to tackle is that they assume the need to type faster is the problem. In a recent study from Haystack Analytics, ~75% of developers suffer from burnout, yet the vast majority of them code on the weekend. The most common reason for burnout is inefficient processes.

This flies directly into the face of the coding assistant hype. That coding assistants can deliver 30, 40, or even 50% productivity gains. On the surface, this sounds ridiculous… and it is. Consider that developers only spend 30-40% of their time coding (State of DevOps report). The rest of the time is spent dealing with all of the other organizational nonsense that is so common across enterprises.

Context is the key to success

The problem is that knowledge has and always will be the differentiator for humans, and with the new breed of computer, the same holds true. How much data has the model been trained on, and is the problem you are trying to solve in the training data? Here is an interesting comment from a Reddit post focused on coding assistants and if people are using them.

There are many that will read this is say something like, “These models are just going to keep getting smarter and will have more training data to help solve this problem”. While that might be true for commonly solved problems. Will an LLM really understand your companies inner workings? Will it understand the context in your code base of 100k lines? Does it understand the 20 years of legacy code and tech debt that has built up over time? I would say the answer to most of those is no.

It will get better, there is not doubt about that. But I would say that we are a long, long way from some of this coming to fruition. Why? Economics.

There have been burger flipping robots for at least 25 years but do we see them running every fast food joint. Not we don’t and it’s really easy to see why. They still need a lot of humans around to do all of the other work. They can help to make one part of the process easier and faster but the cost savings just doesn’t make sense financial over time. When you add in the cost of the machine, its maitanence costs, what happens when it breaks, and still needing humans around to handle a lot of the problems, it just doesn’t make sense.

To me, the same problem exists with coding assistants. If you can have a code base that is completely controlled by an LLM, then you could make a case that the costs and quality problems could be easily overcome. Actually, we already have that in low/no code solutions and I don’t see those taking over software development any time soon.

So, are coding assistants friend or foe?

Now that we understand a bit more about coding assistants, let’s consider the main question, are they a friend or foe? Like with most things in life, it depends on the implementation.

Are you using them in a way that brings out their best qualities?

Are you aware of the quality, cost, speed triangle?

Are you validating results?

As you can see, it’s up to you to decide. They can be very helpful for some (usually more senior) and a hinderence for other (usually more junior). My general advice is to allow people to use them when they want too, have good quality metrics, and don’t expect more out of them than they are good for.

Don’t expect 30 or 50% productivity gains as coding assistants will never get you there. Instead focus on the big problems your developers are facing and how you can improve those value streams. This is where the big gains can be found, not in an easy button.

Until next time,

Chris

Join us for another great episode of Think Big Code Small

Wanting to learn how to code or improve your coding skills?

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at thinkbigcodesmall@gmail.com

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

Wanting to learn how to code or improve your coding skills?

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at thinkbigcodesmall@gmail.com

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

Why haven’t we seen a new software development problem in three decades? In his article, “I Haven’t Seen a New Software Development Problem in Thirty Years,” Ray Carnes suggests that the challenges plaguing software development have remained the same for three decades. At first, this claim seems almost absurd—haven’t we witnessed extraordinary technological advancements, from cloud computing to AI?

Yet, as we delve deeper, it becomes clear that the core issues persist. Effectiveness, efficiency, and robustness continue to haunt developers, rooted in the unchanging realities of human error, process flaws, and technological limitations. Let's explore why these problems remain so stubborn and what it might take to move beyond them.

Fred Brooks, in his seminal work The Mythical Man-Month, famously declared that "there is no silver bullet" for software development. His observation holds as true today as it did in the 1970s. The core issues developers face—ensuring that software is effective, efficient, and robust—have not fundamentally changed because they are not purely technological problems but human ones. Brooks’ insight points to the heart of the issue: our challenges persist because they are deeply intertwined with the limitations of human cognition, communication, and collaboration.

Effectiveness: Are We Building What Matters?

Effectiveness in software development is about building the right thing—ensuring that the product aligns with real user needs. This challenge isn’t new; it’s been at the forefront of software engineering since the beginning. The difficulty lies in truly understanding what those needs are and translating them into functional, user-centered software. As DeMarco and Lister point out in _Peopleware: Productive Projects and Teams_, that the most critical failures in software development are often social rather than technical. Misaligned communication between developers and stakeholders leads to software that may be technically sound but misses the mark in terms of usability and relevance.

Carnes’ reflection on effectiveness highlights a recurring problem: developers often focus on building features rather than solving problems. This issue is exacerbated by the “feature factory” mentality, where teams measure success by the number of features delivered rather than the value those features provide. As Design Thinking advocates argue, actual effectiveness comes from a deep understanding of the user’s context, allowing teams to build products that truly matter.

However, effectiveness isn’t just about the end product but also the process. In Extreme Programming Explained, Kent Beck emphasizes the importance of continuous feedback and iterative development. By involving users and stakeholders early and often, teams can ensure they build software that aligns with real needs rather than just cranking out code that ticks off a list of requirements.

Efficiency: The Silent Killer of Software Projects

Efficiency in software development is about maximizing output while minimizing wasted effort. Yet, inefficiencies drain project time and resources through technical debt, rework, or poor communication. This problem, too, has been introduced previously. In The Phoenix Project, Gene Kim, Kevin Behr, and George Spafford detail how inefficiencies often arise from organizational silos and misaligned incentives, leading to a cycle of rushed processes, technical debt, and ever-increasing workloads.

Technical debt, a term popularized by Ward Cunningham, refers to the cost of choosing a quick and easy solution now instead of a better, more time-consuming approach that could pay off in the future. Over time, this debt accumulates, leading to inefficiencies that slow down development and increase the cost of future changes. As Martin Fowler notes in Refactoring: Improving the Design of Existing Code, addressing technical debt early through continuous refactoring is essential to maintaining long-term efficiency.

Methodologies like Agile and DevOps have been championed to solve these efficiency problems. Agile, with its emphasis on iterative development and continuous improvement, helps teams maintain focus on delivering value quickly without sacrificing quality. Meanwhile, DevOps bridges the gap between development and operations, streamlining workflows and reducing the friction that often hinders efficiency. However, as Ries points out in The Lean Startup, even these methodologies can fall short if they are not implemented thoughtfully, with a focus on learning and adaptation.

Robustness: Building Systems That Don’t Break

Robustness is the ability of software to withstand failures, handle unexpected inputs, and operate under adverse conditions. Despite all our advances, creating robust systems remains a challenge. In Designing Data-Intensive Applications, Martin Kleppmann underscores the importance of building systems that are not only scalable and efficient but also resilient to failure. Robustness, however, requires more than just good code; it demands a mindset that anticipates failure and designs for it.

As developed at Google, Site Reliability Engineering (SRE) offers a framework for achieving this robustness. As detailed in Site Reliability Engineering: How Google Runs Production Systems, SRE blends software engineering with IT operations to create scalable and reliable systems. It emphasizes the need for automated recovery processes, rigorous testing, and a focus on reliability from the outset. Similarly, Test-Driven Development (TDD), as promoted by Kent Beck, ensures that code is reliable and maintainable by requiring developers to write tests before the code itself. This approach not only catches bugs early but also enforces a discipline that leads to more resilient software.

Security is another crucial aspect of robustness. As Bruce Schneier argues in Secrets and Lies: Digital Security in a Networked World, the increasing complexity of software systems makes them more vulnerable to attacks. Robust software must, therefore, be designed with security in mind from the beginning, not as an afterthought. This involves regular security audits, proactive threat modeling, and a culture of security awareness throughout the development process.

A Holistic Approach

So why do these problems persist? The answer lies in our approach. As Ray Carnes suggests, we have been trying to solve these issues in isolation—focusing on business strategies and architectural frameworks while neglecting the more operational, human-centric aspects of software development. But to truly break free from these recurring problems, we must adopt a holistic approach that considers people, processes, and technology in tandem.

As Conway’s Law reminds us, the structure of a system reflects the structure of the organization that built it. If we want to solve these long-standing problems, we must look beyond the code and consider how our teams are structured, communicate, and work together. By focusing on the operational realities of software development—ensuring that our teams are aligned, our processes are efficient, and our technology is reliable—we can finally begin to overcome the challenges that have haunted us for 30 years.

Leave a comment

A Path Forward

The 30-year-old problems that continue to haunt developers aren’t going away anytime soon. But by shifting our focus to a more holistic, operational approach—one that balances strategy with execution, people with processes, and technology with foresight—we can begin to build software that is not only effective, efficient, and robust but also adaptable to the ever-changing landscape of the industry. As Carnes reminds us, the next 30 years don’t have to look like the last 30, but only if we are willing to evolve our approach and learn from the lessons of the past.

Article Link - https://medium.com/illumination/i-havent-seen-a-new-software-development-problem-in-thirty-years-e9bddfe73838

Wanting to learn how to code or improve your coding skills?

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at thinkbigcodesmall@gmail.com

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

Imagine you’re handed a treasure map, but the landmarks are vague, the directions are muddled, and some paths lead you straight into quicksand.

Frustrating, right?

Developer documentation can feel like that when done wrong. But when done right, it's a clear guide through the codebase wilderness, helping seasoned coders and new recruits navigate easily.

Let's examine the common pitfalls of developer documentation and how to avoid them to create a robust, user-friendly resource.

Lack of Clarity and Conciseness

Mistake: Overly complex or verbose documentation can bewilder rather than assist. According to a study by the Nielsen Norman Group, 79% of users scan web pages instead of reading word-for-word. So, if your documentation is dense and convoluted, it's likely to be skipped over.

Solution: Write with the reader in mind. Use clear, simple language and break information into digestible chunks. Utilize headings, bullet points, and code examples to enhance clarity. Think of it as crafting a narrative – each section should flow logically to the next, guiding the reader effortlessly.

Outdated Information

Mistake: Outdated documentation can lead to frustration and wasted time as developers attempt to follow obsolete instructions. GitHub's 2017 Open Source Survey revealed that incomplete or outdated documentation is the top pain point for users of open-source projects.

Solution: Review and update documentation regularly. Implement a version control system for your documents and encourage developers to update the documentation alongside the code. Treat your documentation like a living document, evolving alongside your project.

Assuming Prior Knowledge

Mistake: Assuming all users have the same level of expertise can alienate beginners and render the documentation less useful. This is akin to speaking a foreign language to someone who only knows the basics.

Solution: Include sections tailored for different skill levels. Provide basic overviews for beginners and advanced sections for experienced developers. Always explain acronyms and jargon. This inclusive approach ensures that everyone can benefit from your documentation regardless of their starting point.

Lack of Practical Examples

Mistake: Purely theoretical documentation can be difficult to apply in real-world scenarios. Imagine trying to bake a cake with only the chemical breakdown of ingredients and no recipe.

Solution: Include practical examples and use cases. Show how the code can be used in real projects and provide step-by-step guides to common tasks. This helps users see the code's direct application and understand its functionality in context.

Inconsistent Style and Formatting

Mistake: Inconsistent formatting can make documentation hard to follow and appear unprofessional. It’s like reading a novel where the font and style change every other paragraph – distracting and disorienting.

Solution: Establish and adhere to a style guide for your documentation. Use consistent formatting, terminology, and tone throughout. Tools like linters can help enforce these rules. Consistency not only improves readability but also enhances the professionalism of your documentation.

Conclusion

You can craft clear, up-to-date, inclusive, practical, and consistent documentation by avoiding these common mistakes. Good documentation not only aids developers but also enhances your project's overall quality and maintainability. Remember, effective documentation is an ongoing process that demands regular attention and improvement. As Albert Einstein once said, "If you can't explain it simply, you don't understand it well enough."

About Tuple

Tuple is remote pair programming app for macOS and Windows, designed to make you feel like you're collaborating in person. It’s got loads of developer-specific touches you just don’t see with generic screen sharing tools.

If you are interested in learning more, check them out at their website, here.

Wanting to learn how to code or improve your coding skills?

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at thinkbigcodesmall@gmail.com

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

Wanting to learn how to code or improve your coding skills?

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at thinkbigcodesmall@gmail.com

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

"Security is a process, not a product." — Bruce Schneier

The recent CrowdStrike issue demonstrates that even robust cybersecurity solutions can face challenges disrupting global operations. This incident highlights the need for organizations to review their resiliency strategies and implement chaos engineering and resilience testing to ensure their systems can withstand unforeseen disruptions.

The Incident

CrowdStrike encountered a significant issue with its Falcon Sensor software, leading to widespread outages and the notorious 'Blue Screen of Death' (BSOD) across numerous systems. This incident, coupled with a major Microsoft outage, underscores the complexity of the IT ecosystem and the potential for cascading failures.

Microsoft Outage

This week, Microsoft faced an unplanned widespread outage, causing disruptions across multiple services and leaving users worldwide grappling with the BSOD. The root cause was an issue with CrowdStrike's Falcon Sensor software, a tool designed to protect systems from cyberattacks. Despite attempts to roll back the update, many machines remained affected.

The outage had a global impact, affecting various platforms, including Microsoft 365, Azure, Amazon Web Services, and even social media sites like Instagram and eBay. It grounded flights, disrupted live broadcasts, and caused supermarket payment processing issues.

Response and Resolution

CrowdStrike's CEO, George Kurtz, provided an update stating that the issue had been identified and isolated, and a fix had been deployed.

While resolved, this incident highlights the risks associated with heavy reliance on cloud services and the necessity for robust resiliency strategies.

Chaos Engineering vs. Resilience Testing

Chaos Engineering

Popularized by Netflix, chaos engineering involves deliberately introducing failures into a system to uncover unknown issues in production-like environments. This practice helps identify vulnerabilities and strengthen system resilience against real-world disruptions.

• Chaos Experiments: Conduct controlled experiments to simulate failures and observe system responses, as detailed in "Chaos Engineering" by Casey Rosenthal and Nora Jones.

• Continuous Testing: Regularly test systems under various failure scenarios to ensure continuous resiliency, echoing the continuous improvement ethos in "Lean Startup" by Eric Ries.

Resilience Testing

Resilience testing focuses on validating known failure scenarios and the system's ability to recover from them. This ensures that systems can handle anticipated disruptions and maintain operational integrity.

• Scenario Validation: Test systems against predefined failure scenarios to ensure they can recover effectively.

• Recovery Verification: Ensure that recovery mechanisms function correctly, maintaining system availability and performance.

Principles of Chaos Engineering

Drawing from PhoenixNAP, here are some principles to guide effective chaos engineering:

1. Define the Steady State: Establish normal system behavior metrics as a baseline.

2. Formulate Hypotheses: Predict how the system will react to specific disruptions.

3. Plan Experiments: Design detailed failure simulations targeting critical components.

4. Execute Experiments: Implement disruptions and monitor system responses.

5. Analyze Results: Compare outcomes against the baseline to identify weaknesses.

6. Improve and Iterate: Use insights to enhance system resilience continuously.

Best Practices for Chaos Engineering

Based on the Medium article by The Cloud Architect, here are some best practices for a successful chaos engineering journey:

• Start Small: Begin with small-scale experiments to build confidence and understanding.

• Automate: Use automation tools to implement and monitor chaos experiments.

• Collaborate: Foster a culture of collaboration among teams to address discovered issues.

• Document: Keep detailed records of experiments, outcomes, and improvements.

• Scale Gradually: Expand the scope of experiments gradually to encompass more significant parts of the system.

DevOps/SRE Strategy Integration

Chaos engineering and resilience testing are crucial components of a comprehensive DevOps and Site Reliability Engineering (SRE) strategy. These practices should be integrated with existing engineering practices like automated testing and environment management to ensure robust system reliability and performance.

Automated Testing

Automated testing ensures that code changes do not introduce new failures. Integrating chaos engineering with automated testing helps identify potential disruptions early in the development lifecycle, improving overall system resilience.

Environment Management

Effective environment management includes maintaining consistent development, testing, and production environments. Chaos engineering can validate that these environments can withstand disruptions, ensuring reliable deployments and operations.

Types of Chaos Engineering Tests

• Infrastructure Failure Tests: Simulate failures in the underlying infrastructure, like instance terminations.

• Application Failure Tests: Force shutdowns of critical services to identify single points of failure.

• Dependency Failure Tests: Assess how the system handles failures in third-party services.

• Network Failure Tests: Introduce latency or packet loss to test network robustness.

• Security Chaos Engineering Tests: Simulate cyber-attacks to evaluate system defenses.

• Operational Failure Tests: Test response to routine maintenance and unexpected operational issues.

Conclusion

The CrowdStrike incident is a powerful reminder that even top-tier cybersecurity solutions are not immune to issues that can cause widespread disruption. Organizations must adopt comprehensive resiliency strategies, including chaos engineering and resilience testing, to ensure robust defenses and operational efficiency.

As Bruce Schneier aptly puts it, "Security is a process, not a product," underscoring the ongoing journey toward true resiliency. By learning from these disruptions and proactively strengthening their systems, organizations can better navigate the complexities of the digital age.

Additional Resources

• Verify the resilience of your workloads using Chaos Engineering - AWS Blog

• Resilience and Chaos Engineering - Microsoft Blog

• Chaos Engineering: Definition, Principles, Best Practices - PhoenixNAP Blog

• Best Practices for a Successful Chaos Engineering Journey - Medium

Time is a precious commodity in software development, and prioritizing it will make a difference. We explore the balance between developer autonomy and the necessary boundaries to maintain that order. Simplicity and clarity in the process and tools are critical in maintaining high productivity. Moreover, we'll examine why focusing on outcomes over processes is critical and how measuring the right metrics can lead to significant improvements.

Join us as we uncover strategies to enhance the developer's experience, drive better outcomes, and transform how you build software.

Wanting to learn how to code or improve your coding skills?

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at thinkbigcodesmall@gmail.com

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

At least once a week, I hear someone say they “wish they had time to get their work done,” had fewer meetings and interruptions, and did not feel they needed to work overtime just to finish their work. According to the 2020 Stack Overflow Survey, more than 75 percent of developers work overtime occasionally, while 25 percent work overtime at least once weekly. Moreover, about one-third of developers code on the weekend.

This is a real issue. It creates a caustic working environment, destroys the culture, eliminates productivity, and can ultimately hurt the organization's growth as all the good people leave.

When we worked in the office, we could go to a meeting room, close our door, or even just put on headphones.

We seem to believe we must attend every meeting we are asked to attend.

Here's a question we need to ask ourselves: is this a process problem that needs to be addressed at the project and leadership level, or is it a personal problem because we find it difficult to say no?

Maybe Both!

Carl Jung once said, 'The creative mind plays with the objects it loves. That’s why it’s so important to find a space where you can be alone and uninterrupted to immerse yourself in your work.' Imagine a workspace where you can think clearly, focus on the task at hand, and let your creativity flow. This is the potential of an uninterrupted workspace.

Share Think Big Code Small

The Power of Deep Work

Content switching is a mind-killer. Developers face constant interruptions and distractions —emails pinging, meetings beckoning, and colleagues dropping by with "quick questions." True productivity is impossible.

True productivity happens at a deeper level, below the surface of all this noise, in the tranquil depths of uninterrupted concentration.

Blocked-out time allows developers to plunge into these depths, achieving what state psychologist Mihaly Csikszentmihalyi calls "flow."

Time dissolves, creativity flourishes in this flow state, and complex problems unravel with elegant simplicity.

Here, developers transform lines of code into robust applications and innovative solutions.

Interruptions: The Silent Productivity Killer

Developers lose a significant amount of time due to interruptions while coding. According to research, it can take up to 23 minutes to regain full concentration after an interruption.

This disruption is particularly costly for developers whose work demands intricate problem-solving and deep focus.

The frequent need to switch contexts can derail progress, decreasing productivity and efficiency. Each interruption is like tossing a wrench into its gears, derailing thoughts and fracturing focus.

These interruptions are particularly costly to the organization.

Without blocked-out time, developers find themselves in a perpetual cycle of context switching, akin to a car stuck in stop-and-go traffic—always moving but never quite reaching full speed.

Crafting a Fortress of Focus

Creating blocked-out time is like building a fortress around one’s focus. Here are the secrets to constructing that fortress:

• Set Clear Boundaries: Communicate with your team about your blocked-out time. Use tools like Slack statuses or calendar blocks to signal when you’re in deep work mode.

  • Teams need to define working hours.

  • Leaders must be careful to manage project meetings and support heads down time.

  • Google and others have no meeting days.

• Optimize Your Environment: Design a workspace that minimizes distractions. Noise-canceling headphones, tidy desks, and dedicated workspaces can help maintain concentration.

  • Create a team rule for the office: headphones are the same as a closet door.

  • Virtually — use the out-of-office settings or another process to communicate the same status.

  • How to Optimize your Workspace

• Leverage Technology: Utilize productivity apps and tools that support focus.

  • Leverage tools to block notifications.

  • Turn off the phone and other social media apps.

  • One idea is to create another image or set up another laptop only for deep work—without distractions.

  • 10 Ways to Increase Productivity by Improving Your Developer Experience

• Prioritize Tasks: Not all tasks require deep work. Reserve your blocked-out time for the most challenging and creative tasks, leaving routine activities for less focused periods.

  • Learn about the Lee Method or Eisenhower Matrix.

The Ripple Effect of Productivity

Blocked-out time benefits developers and has a ripple effect throughout the organization. When developers operate at peak productivity, projects advance more swiftly, innovation blossoms and the quality of work elevates.

Teams sync more efficiently, deadlines become less daunting, and overall morale boosts as everyone rides the wave of collective progress.

This helps teams move closer to high-performing teams requiring less management and oversight.

Embracing the Future of Work

Blocked-out time is more than just a productivity hack —it’s a profound shift in how we approach work.

It acknowledges that developers, like all creative professionals, need undisturbed stretches to dive deep, think critically, and create innovatively.

Wanting to learn how to code or improve your coding skills?

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at podcast@thinkbigcodesmall.co

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

It was a pleasure to go out to Estes Park, CO, for this wonderful conference. Check out my talk below.

Engineering leadership is hard, there are few that would argue that fact. Its even harder when you don’t have any telemetry on how well your organization is operating. This is the root of the metrics frameworks that are out there today like Dora, SPACE, or DevEx.

Today we are not going to argue the merit of any of these frameworks but instead talk about the data itself. I have seen many organizations get absolutely lost in gathering the data, with initiatives to track certain sets of data taking months or even years.

I spoke with a company not to long ago that spent 12M to gather an implement the Dora metrics!

While getting your data in order is very valuable, is that the highest value problem you have? Are you looking to track metrics or actually make changes?

Don’t fall in love with your dashboards!

There are two ways to try and collect data, through qualitative surveys and through quantitative system data. They both come with their challenges but you need to figure out which one is better for a given scenario.

Lets take a look at how to gather Time to Value through quantitative methods. This isn’t the most complicated metric to calculate but it paints a good picture of some challenges. I asked my ChatGPT friend to describe how to calculate this metric.

• Identify Key Stages:

  • Commit Time: When code is committed to the repository.

  • Build Time: When the build process starts and completes.

  • Testing Time: When automated tests are run and completed.

  • Deployment Time: When code is deployed to production and available for use.

• Use CI/CD Tools:

  • Tools like Jenkins, GitLab CI, CircleCI, or GitHub Actions can help you track the time from commit to build completion.

  • Use these tools to capture timestamps for when a commit is made, when the build starts, and when the build completes.

• Version Control Systems:

  • Use your version control system (e.g., Git) to pull commit timestamps.

• Automated Testing Frameworks:

  • Integrate automated testing frameworks that log timestamps when tests start and finish.

• Deployment Tools:

  • Deployment tools like Spinnaker, ArgoCD, or custom deployment scripts should log when deployments start and finish.

• Monitoring and Logging Tools:

  • Use monitoring and logging tools (e.g., Splunk, ELK stack, Datadog) to track when new deployments go live and are accessible to users.

• Aggregating Data:

  • Aggregate the collected timestamps from different tools and stages. You can use a data visualization or analysis tool like Grafana, Kibana, or even a custom dashboard.

• Calculating Time to Value:

  • Calculate the duration between the commit time and the deployment time to get the "time to value" metric.

• Automating the Process:

  • Set up a pipeline that automatically logs and aggregates these metrics after each deployment.

  • Use tools like Prometheus to scrape these metrics and Grafana to visualize them.

All you need to do is connect all of these systems together, have a ID that can be passes around, build a data model, and a few reports. Simple!

When considering how to track a given metric, what is the fidelity that you need to get the job done? Is this a metric that you will be tracking across teams indefinitely? Considering this is one of the Dora metrics it might be worth going through the task of creating this dataset or leveraging engineering insights tools like DX to do the hard work for you.

The point here is that the fidelity of the information you gather really matters and should depend on what you are trying to accomplish. 

So how else can you track some of these metrics? Qualitative surveys? Thats correct, they can get you to an answer pretty quickly and at a useful fidelity.

Let’s look at another metric like Time to first commit. This is far easier to track than Time to Value but still has its complexity. If you tracked this via survey, it could be a few simple questions for anyone that is new to a team.

• How long did it take for you to make your first commit?

• How comfortable are you in making another commit?

Considering you would use this metric to help improve and track onboarding, is there a difference between 1.337 days (quantitative) and 1.5 days (qualitative)? I would say that it doesn’t really matter at all, especially when considering the time, energy, and effort that was saved.

Another consideration is the additional information you can gather from surveys, like sentiment. It can be very easy to game the system when it comes to 1st or 10th commits to a codebase but when you overlay that with a sentiment question you can get some additional insights. For example, someone might have done their first commit on the first day on the team… but the codebase was so complicated and the deployment process so flakey… that it was terrifying.

This is another great mechanism to gather information on how well a given team or organization is doing.

Don’t get me wrong, there is a ton of great uses for quantitative system data. The point is to consider the best way to gather data to help provide insights to a given problem or set of problems. As you go on you metrics and data journey, I would consider the collection costs and the fidelity of information that you need to get the job done.

Gathering feedback from the development community and making them apart of the process will improve culture and lead to better outcomes. Care just need to be taken on how to do it… because no one wants to be micro-managed or micro-measured.

Any thoughts or questions? Let me know!

Chris

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at podcast@thinkbigcodesmall.co

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at podcast@thinkbigcodesmall.co

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X

The Role of a Technical Principal

Strategic Advisor

Technical Principals act as strategic advisors to client leadership teams, intertwining technology, and business strategies to address various organizational challenges, from business architecture to technical management. Their primary goal is to build and maintain trusted relationships with senior stakeholders, including C-suite executives.

Broad Focus

This role intricately blends deep technical expertise with strategic business insights, ensuring seamless alignment of technological and business objectives. Technical Principals guide and mentor engineering teams, fostering continuous improvement and maintaining high-quality standards. They engage strategically with clients, offer solutions, contribute to pre-sales activities, shape winning proposals, and represent the company at industry events.

Leadership

Technical Principals provide leadership by guiding technical delivery and fostering a culture of growth and continuous improvement. They handle various responsibilities, including client engagement, mentorship, and strategic communication, driving successful client engagements by balancing strategic vision with technical execution.

The Role of a Solution Architect

Technical Design

Solution Architects focus primarily on designing and implementing specific technology solutions. Their expertise lies in creating and managing architectural frameworks that meet functional and non-functional project requirements. They are responsible for defining the overall architecture, selecting appropriate technologies, and ensuring integration with existing systems. Key deliverables include architectural blueprints, technical specifications, and detailed design documents. They also address performance, scalability, and security concerns, ensuring the solutions are robust and sustainable.

Project-Based

Unlike Technical Principals, Solution Architects focus on specific projects or systems. They collaborate closely with technical and business stakeholders to ensure solutions align with project requirements and organizational goals.

Implementation Focus

Solution Architects are deeply involved in a project's technical aspects, from initial design to final implementation. They ensure that technical solutions are sound, scalable, and meet the project's needs.

Is this how you define these roles? Add a comment and share your experience and understanding.

Leave a comment

Why Both Roles Are Essential

Strategic Alignment and Execution

The presence of both roles in a consulting engagement ensures that strategic alignment and technical execution are managed effectively. The Technical Principal provides high-level strategic oversight and client relationship management, while the Solution Architect ensures that the technical solutions are designed and implemented correctly.

Complementary Skill Sets

The skill sets of Technical Principals and Solution Architects complement each other. The Technical Principal's broad focus on strategy, leadership, and client engagement is balanced by the Solution Architect's deep technical expertise and project-specific focus. This balance is crucial for addressing large consulting projects' complex and multifaceted nature.

Enhanced Project Outcomes

By leveraging the strengths of both roles, consulting firms can deliver more comprehensive and practical solutions. The Technical Principal's strategic insights and leadership, combined with the Solution Architect's technical acumen, lead to better project outcomes and higher client satisfaction.

Parting Thoughts

Both Technical Principals and Solution Architects are essential for the success of large consulting engagements. Understanding their distinct roles and how they complement each other is vital to maximizing their contributions and ensuring project success.

Together, they provide the strategic oversight and technical expertise to navigate complex projects and deliver exceptional results.

Wanting to learn how to code or improve your coding skills?

We have a deal with CodeCrafters to save you 40% off their service. With CodeCrafters you get to learn by writing real complex software. Recreate Redis, Git, Docker — with your own hands. Gain expert-level confidence by taking action and
diving deep, learning from the world's best.

Get your savings here!

Have feedback or want to request a topic?

We would love to hear from you! Send us an email at podcast@thinkbigcodesmall.co

Don’t forget to subscribe to us on our new YouTube channel

Follow us on socials

Instagram - TikTok - X