Intro

We are all still figuring this out. Every developer I talk to seems to have a slightly different ritual when it comes to working with AI coding agents. Some treat the AI like a junior intern, others like a stack overflow search bar on steroids.

I’ve spent the last few months refining my own process. It is certainly not the "best" workflow out there, and it might even seem a little heavy-handed to those who prefer to just fire off a prompt and hope for the best. But I’ve found that by front-loading the effort and treating the AI as a collaborator rather than just a code generator, I save myself a massive amount of debugging time later.

Here is the 16-step workflow I use to go from a vague idea to shipped feature.

Phase 1: Alignment and Interrogation

The biggest mistake I used to make was jumping straight to code. Now, I spend a significant amount of time just talking.

1. The Spark

It starts with a feature idea. It might be messy or incomplete, but it’s there.

2. The "Ask" Mode

I open a context with a custom "Ask" persona. This isn't configured to write code; it’s configured to be a critical thinker. I bounce the idea, details, and constraints back and forth.

3. The Sanity Check

I explicitly ask the AI: “Do you understand the idea and the requirements?” It’s a simple step, but it forces the model to synthesize the conversation

4. The Reverse Interrogation

This is the most important step in the beginning. I ask the AI: “What questions do you have? Do you see any logical gaps or edge cases?” I don’t proceed until the AI has poked holes in my logic.

Phase 2: The Specification (The Contract)

Once we "feel" aligned, I don't ask it to code. I ask it to write.

5. The "Doc Writer" Mode

I switch to a different custom persona focused solely on technical documentation.

6. Drafting the Spec

I instruct the writer to create a feature specification based on our previous chat. I enforce a declarative style (describing what should happen, not just how). The spec must include:

*   The current state (and the state after changes).
*   Goals and desired outcomes.
*   Security concerns.
*   Relevant code locations

7. Fact Checking

I open a new context and ask the agent to fact check the assumptions made in the spec using web search and documentation (e.g. Context7)

8. The Peer Review

I open a new context with a different "smart" model (often a different LLM entirely). I feed it the spec and ask it to review and improve it.

9. Human Review

I scan through the polished spec. If something feels off or unclear, I loop back to the AI to fix the text. I never move to code until the words are right.

Phase 3: The Implementation (and The Break)

Now that we have a solid "contract" of what needs to be built, the coding is actually the easiest part.

10. The Handoff

I open a new context and give the spec to a smart coding agent. I tell it: “Implement this specification.”

11. Touch Grass

This is where the workflow pays off. Because the spec is detailed, I don’t need to hover. I go read Hacker News, grab a coffee, or actually step outside. I let the machine do the heavy lifting.

Phase 4: The Loop and The Polish

12. The QA Loop:

When I come back, I test the implementation. It’s rarely perfect on the first shot. I enter a feedback loop, pointing out bugs or UI issues, and the agent iterates.

13. The AI Code Review

Once it seems to work, I’m still not done. I open a fresh context with another smart AI. I feed it the original specification and the current git changes (the `diff`). I ask it to review the code specifically against the spec, looking for:

*   Logical consistency.
*   Security vulnerabilities.
*   Performance bottlenecks.
*   Project structure consistency.

14. Refinement

I have the agent implement the recommended improvements from the review.

15. Final Human Review

I do one last pass of QA and code review myself.

16. Ship It

When I’m happy, I commit the code. Crucially, I also commit the specification file. It serves as documentation for the future. Then, I push and ship.

Why this works for me

Is 15 steps overkill? Maybe. I know plenty of developers who can move much faster than this.

However, I’ve learned that I am prone to getting lost in the weeds if I don't have a clear plan. This workflow essentially forces me to slow down. By treating the AI as a partner that needs clear instructions rather than a magic wand, I find I spend less time untangling confused code later on.

It’s definitely a bit process-heavy, and I’m sure I’ll tweak it again next month. But for now, this structure gives me the confidence to ship features without constantly worrying that I missed something obvious. Plus, the coffee breaks are a nice bonus.

Provide as much context as possible

Describe what you want in clear, concrete detail. Include examples. Link to relevant files, standards, and conventions the agent should follow.

Before you let the agent write code, ask it to restate your requirements. Read the response. If it captured your intent, proceed. If not, clarify what it missed.

Tell it what to do—not what not to do

“Don’t do X” rarely produces good results. Positive instructions are far more reliable. Specify the desired outcome, constraints, and acceptance criteria.

Get the architecture right

Tuning a function is easy; reworking an architecture is not. Invest in the design upfront and verify that the agent is implementing your architecture. How it writes small helpers matters less than whether the system boundaries and data flows are correct.

Ask questions to gather context

If you’re not yet sure what you want, use the agent as a thinking partner. Discuss the project, the stack, the docs, even Reddit threads. This both sharpens your own understanding and gives the agent richer context.

Ground the model in facts

Training cutoffs and hallucinations are real. LLMs aren’t omniscient—and they do make mistakes. Counteract this by grounding the agent with up-to-date, verifiable facts: documentation, specs, tickets, code comments, scientific papers, web search results, etc.

Keep task scope tight

As prompts and context grow, signal can get diluted. Break work into small, well-bounded tasks so the context contains only what’s relevant. Smaller tasks make it easier to review, test, and course-correct.

Refresh the context regularly

Think “one task, one context.” If the current thread gets noisy or off track, shelve the partial changes and start a fresh context with a narrower scope and cleaner prompt.

Sync state with git diff

If you like the current code but the conversation has drifted, open a new context and have the agent run git diff (or paste the diff) to catch up without reintroducing the old noise.

Let LLMs review each other’s code

Create a “review mode” prompt describing what you care about: correctness, readability, performance, security, edge cases, etc. Run reviews with a second model—or the same model in review mode—and ask targeted questions like:

“What risks or failure modes do you see?”

“Which assumptions should be documented?”

“What important details might be missing?”

Use TDD

Once the architecture is solid, start with tests. Have the agent draft end-to-end or unit tests, review them yourself, then let the agent implement the feature and iterate against the tests. This keeps development anchored to real behavior.

Summary

AI coding agents aren’t replacing software engineers anytime soon—and that’s a good thing. They still need thoughtful direction, review, and course correction to produce great work.

What they do offer is speed on well-defined tasks. Offload the mechanical, boilerplate, and repetitive work so you can spend more time on design, problem-solving, and asking better questions. Used this way, LLMs and agents make development faster and often higher quality—because you can iterate more, learn faster, and keep your focus on the hard parts.

What Do I Want To Achieve With The Architecture?

Future Proofing / Optionality

Times, requirements, technology changes constantly. If we are not able to catch up in a timely manner, we are putting the business under increasing risk. That's why it's important to make an effort and keep as many options open as possible for the future this is assuming we want to be in business long-term.

Modularity

I want to be able to deal and manage ever increasing complexity in an effective way. Breaking the system down into smaller self-contained parts is crucial for this purpose.

Separate concerns

I want to improve maintainability, scalability, and reusability by allowing me and others to focus on individual parts without affecting the entire system.

Independent Magic

When we write software, we usually want to solve a particular problem for our customers. This solution is what I call the "Magic". We want to keep this magic part as independent as possible from secondary concerns.

What Does It Look like?

The Three Parts

From a birds-eye view, I like to separate the software architecture into three main parts: entry points, the magic and supporting infrastructure.

Entry Points

This is the surface our users interact with, the application program interface (API) of our software.

The Magic

This is where the magic happens. This is our primary concern where we deal with solving the particular problems of our domain of interest. Here we don't want to deal with http, database particularities, etc. This where we want to implement inversion of control.

Supporting Infrastructure

This is the roads, the vehicles, the buildings that we need to run our business. In the world of software these are called databases, caches, queues, object storage, etc.

What Is The Folder Structure?

This is roughly what the folder structure might look like:

Model
|_ User
|_ Product
|_ ...

UseCase
|_ Register
|_ Login
|_ AddToCart
|_ ...

EntryPoint
|_ Http
|   |_ Register
|   |_ Login
|   |_ AddToCart
|   |_ ...
|_ Queue
   |_ SendActivationEmail
   |_ SendOrderSummary
   |_ ...

Container
|_ Database
|_ Queue
|_ Cache

Summary

We call it domain-driven design, hexagonal architecture and so on which is great. Bottom line is, we want to support the business i.e. customers long-term and be able to respond to change in the most effective and nimble way possible. To achieve this we have to think about optionality, modularity, separations of concerns, cohesion, coupling and so on when designing the architecture of our systems.

The age old question, what is a "Bounded Context" in Domain-Driven Design?

- A bounded context is where terms have clear and unambiguous meaning and rules associated with it.

Where do you draw the border of a bounded context?

- The moment a term starts to have more than meaning.

Example Term - Order

Imagine you have a magic word "Order" that means different things in different playrooms of your big online store.

1. Sales Context (The Shopping Room)

• What it means: In this room, "Order" is when a customer picks their favorite toy, puts it in their cart, and pays for it.
• Why it's special: Here, "Order" captures everything about buying something—like which toy was chosen, the price, and the customer’s details.

2. Fulfillment Context (The Shipping Room)

• What it means: In another room, "Order" becomes a list that helps workers pack the toy, choose a box, and send it out the door.
• Why it's special: This room cares more about how to get the toy from the store to the customer's home, including things like shipping addresses and delivery dates.

3. Customer Service Context (The Help Room)

• What it means: In this room, "Order" helps when someone needs a little extra help—like fixing a mistake in the address or returning a toy.
• Why it's special: The details here are used to help the customer and answer questions, rather than to sell or ship the toy.

4. Billing/Payment Context (The Money Room)

• What it means: In another playroom, "Order" is more about checking that the money paid is right and that all the receipts and invoices are in order.
• Why it's special: This context focuses on making sure every cent is accounted for and the financial records are correct.

How Do We Decide Where to Draw the Boundaries?

We create these separate rooms—or bounded contexts—when we notice that the same word "Order" has different rules and details in different parts of our business. By drawing these boundaries, each team (like Sales, Shipping, Customer Service, and Billing) can work in their own room without mixing up their special rules.

Each room uses "Order" in a way that makes sense for that part of the business. This keeps everything neat and helps everyone understand exactly what they need to do, just like keeping different LEGO sets in separate boxes makes it easier to build a spaceship and a castle without getting the pieces mixed up.

As usual, it's about splitting responsibilities to make complex systems simpler and easier manage

Introduction

The phrase "best practices" is often thrown around in software engineering, serving as a reassuring beacon of correctness. However, in the realm of software architecture, its application is far more nuanced. Unlike development tasks where established patterns often apply universally, architecture is inherently contextual, requiring careful trade-off analysis rather than rigid adherence to predefined "best" solutions. In this article, we’ll explore why architecture demands a different approach, the importance of evaluating trade-offs, and how data management plays a crucial role in shaping long-term decisions.

The Unique Challenges of Software Architecture

Software development, at a small scale, is filled with well-documented solutions. Need to parse a JSON file? There are libraries for that. Implementing authentication? Frameworks provide well-established patterns. However, architecture is a dimension where solutions are not so easily transplanted. Each decision has broad implications that extend beyond code implementation, impacting scalability, maintainability, and business agility.

Unlike coding where we can find answers to small scale challenges relatively easily  via LLMs or documentation, architecture is a problems space rarely identical across organizations. The structure of teams, business priorities, regulatory concerns, and existing technology stacks all shape architectural decisions. As a result, architecture cannot rely on generic "best practices"—it must be tailored to the specific needs and constraints of a given environment.

Trade-offs Over "Best" Solutions

Rather than searching for the "best" architecture, effective architects focus on identifying the least problematic design given a set of constraints. Every architectural decision involves trade-offs, and a successful architecture is one that makes informed compromises rather than blindly following industry trends.

For example, microservices are often touted as a best practice for scalability and flexibility. However, adopting microservices introduces significant complexity in areas like service discovery, observability, and distributed data consistency. In many cases, a monolithic architecture may be the better choice for reducing operational overhead and accelerating development speed. The key is to understand the trade-offs and make decisions that align with the organization’s current and future needs.

Architects must constantly ask:

• What are the long-term maintenance implications of this choice?
• How does this decision impact system performance and reliability?
• Are we optimizing for the right constraints, or just following industry trends?

The Fluid Nature of Architecture

Technology is constantly evolving, and architectural paradigms shift accordingly. A decade ago, Service-Oriented Architecture (SOA) was the gold standard for enterprise systems. Today, many organizations have embraced microservices, and some are now reconsidering them in favor of monolithic or modular monolith approaches due to the challenges of distributed systems.

Architects must recognize that today’s "best practice" may become tomorrow’s legacy burden. Rather than dogmatically adhering to trends, successful architects embrace change and design systems that can evolve over time. This means:

• Avoiding premature optimization for scale if the business doesn’t require it.
• Prioritizing modularity and well-defined boundaries over rigid adherence to architectural dogma.
• Designing for adaptability, ensuring that future changes can be made without excessive refactoring.

The Overlooked Importance of Data Architecture

One of the most critical yet often overlooked aspects of software architecture is data. Unlike application logic, which can be refactored relatively easily, data models and storage decisions are far more challenging to change once they are in production.

Effective architects understand that:

• Data consistency and integrity are foundational to system reliability.
• Choosing the right database model (relational vs. NoSQL, event sourcing, etc.) has long-term implications.
• Data governance and security must be factored into architectural decisions early on.
• Scalability and query patterns should be considered when designing schemas, ensuring that the chosen approach aligns with expected data access patterns.

Ignoring data architecture in favor of purely focusing on service design can lead to significant challenges down the road, including performance bottlenecks, data fragmentation, and costly migrations.

Conclusion

Software architecture is not about applying "best practices" but about making informed decisions based on trade-offs, organizational context, and long-term sustainability. The most effective architects understand that no two problems are identical and that flexibility is crucial in an ever-evolving technological landscape. By prioritizing trade-off analysis and paying close attention to data architecture, architects can build systems that are not only functional today but adaptable for the future.

To make it short, just forget about it. Work is too dynamic to be able to predict a schedule and consistently live up to it. You will fail and you will feel bad about it.

What to do instead?

Focus on what needs to be done. Duh. :D

So what you need to do is to keep a list of things, regularly update the list and if you are lagging behind in getting things done, put more effort in to catch up with all the tasks. I'm kidding, DON'T do this. It's a trap.

If you are like most people, then you know, that things to do are always abundant contrary to our time, which there is never enough of.

There is a conflict here, between the things that need to be done and our time. Our job is to find a way to reconcile this conflict.

Now let's share the secret here.

1. You can't and you don't need to do all things.

2. Counter to intuition, you need to focus most of your time on things with the highest ROI instead of the things you think are "time sensitive"

The Eisenhower Matrix

"I have two kinds of problems, the urgent and the important. The urgent are not important and the important are never urgent" - Eisenhower

Let tasks go through the pipeline:

1. This important? No! This urgent? No! - Throw it away!
2. This important? No! This urgent? Yes! - Delegate!
3. This important? Yes! This urgent? No! - Work on this most of the time for the highest impact and most reward!
4. This important? Yes! This urgent? Yes! - Briefly pause #3 for this and do it now. Find ways of avoiding similar instances of this in the future.

You might not get the hang of it immediately but internalizing and optimizing this over time, will give you an immense progress boost in the long run.

Intro

Software development is a non-trivial endeavour. The goal is to deliver value to customers as fast as possible while staying in line with business goals and keeping quality at a high level. As we know from experience, fast and high quality usually don't work well together. Let's see what we can do about it.

What Is Lead Time?

Lead time in software development refers to the total time elapsed from when a requirement or feature is initially identified until it is successfully delivered and deployed into production for end users.

Lead time encompasses the entire value stream, including time spent in backlogs or waiting for resources, coding, testing, approvals, and deployment.

Shorter lead times indicate higher agility and responsiveness to customer needs and market changes.

Long lead times can signify bottlenecks, inefficiencies, or constraints in the development workflow that need to be addressed.

Tracking and optimizing lead time is crucial for software teams as it directly impacts their ability to rapidly deliver value to customers and stay competitive. Reducing lead time is a key goal of DevOps and agile methodologies.

How To Optimize Lead Time?

Since lead time involves many steps and stages, we first have to look at all these steps and try to identify where to start. To optimize lead time we can use the "theory of constraints" to help us identify bottlenecks.

What Is The "Theory of Constraints"?

The theory of constraints (TOC) is a management philosophy and methodology developed by Eliyahu M. Goldratt. It is based on the principle that every system has at least one constraint that limits its performance relative to its goal.

The throughput of the entire system is limited by its constraint. Improving non-constraints will not increase throughput.

What Is The Constraint?

Lead time in software development can have many constraints like:

• Policy constraints like unnecessary approval gates or handoffs between siloed teams (dev, testing, ops)
• Lack of team expertise or having too small/large a team size
• Unclear requirements or frequent scope changes leading to scope creep
• Resource constraints like insufficient hardware, tools or development environments
• Dependencies on external services, APIs or components that cause integration delays
• Poor communication and collaboration within the team or with stakeholders

As usual, every organization is unique and should analyze their specific context to understand what the constraint is they should focus on.

But in this article I will focus on one particular constraint - batch size.

What Is Batch Size?

The batch size in software development is the amount of code changes going through and waiting in the pipeline (review, approval, acceptance, QA) before being deployed into production.

What Is Bandwidth?

Bandwidth is a measure of the maximum data transfer capacity of a network or internet connection. It refers to the amount of data that can be transmitted over a network in a given time period.

If you try to send more data than the available bandwidth can handle, it will result in packet loss and degraded performance.

The Analogy

The simple analogy I will use here is that the software development value stream has a certain amount of bandwidth.

If you try to push more through the stream than the available bandwidth can handle, it will result in slow and degraded performance, less agility, more bugs, etc.

Less Is More

This is one of those problems where the solution is counter-intuitive. This means that if we want to be more agile, deliver value to the customer faster without compromising on quality, we have to deliver less at a time.

By delivering less at a time we gain the following benefits:

• Easier writing of automated tests
• Increased automated test coverage
• Faster code reviews
• Easier catching of issues during reviews
• Higher code quality
• Faster feedback cycles
• Faster response to information
• Less technical debt
• Lower cognitive load
• Increased developer satisfaction
• Actual continues integration
• Easier refactorings
• and more ...

How To Implement Smaller Batch Sizes?

Unfortunately, we cannot implement this over night and with only good will. It requires change in mindset and some new ground rules i.e. constraints.

Some recommendations are:

• Start small on a fresh smaller size project
• Do smaller projects in general
• Split user stories and tasks
• Pair Programming
• Write automated tests (easier since changes much smaller)
• Use red-green-refactor cycle
• Use the "branch by abstraction" pattern
• Do synchronous code reviews
• Deploy changes every day or morning as a rule
• Decouple deployment from release through feature flags
• Use trunk-based development

Conclusion

Sometimes less is more and this is the case for many software development teams. To deliver value to the customer faster and with a higher quality, we need to understand that the value stream pipeline has a limited bandwidth and we need to act accordingly. Maybe this is not the solution for your team, but maybe it's worth a try.

Intro

If you did any kind of software development, you hopefully also wrote some automated tests before. Unit tests are amazing and blazing fast (or at least they should be). Integration or E2E tests are a bit more difficult because you might need to prepare the appropriate environment and components the tests depend on. But still, setting up that environment and components once should last you a long time until you might need another component in the future. If you ran some plans and applies with Terraform in the past, you know that they don't always work as expected. Question is how do we increase the reliability of Terraform tasks in advance with automated tests?

Built-In Terraform Testing And QA

Terraform provides built-in testing features so let's look at those first.

Terraform fmt

We all know that consistent formatting tremendously improves readability. For this purpose we can and should use the terraform fmt command.

terraform fmt

Terraform Validate Command

One of the simplest things we can do is running the Terraform validate command which will validate that our syntax is valid and that our code is internally consistent.

terraform validate

Terraform validate is the least QA you should add to your CI.

Input Validation

Next thing we can do is validate that our inputs meet desired conditions.

variable "aws_private_subnet_ids" {  
  description = "VPC private subnet ids."  
  type        = list(string)  

  validation {    
    condition     = length(var.aws_private_subnet_ids) > 1    
    error_message = "This application requires at least two private subnets."  
  }
}

This will help you validate inputs upon running Terraform plan.

Preconditions

Introduced in Terraform 1.2, preconditions, as the name suggests, can help you validate that desired conditions are met when running Terraform plan.

data "aws_ec2_instance_type" "app" {
  instance_type = var.aws_instance_type
}

resource "aws_instance" "app" {
  count = var.aws_instance_count

  instance_type = var.aws_instance_type
  ami           = var.aws_ami_id

  subnet_id              = var.aws_private_subnet_ids[count.index % length(var.aws_private_subnet_ids)]
  vpc_security_group_ids = [module.app_security_group.security_group_id]

  lifecycle {
    precondition {
      condition     = var.aws_instance_count % length(var.aws_private_subnet_ids) == 0
      error_message = "The number of instances (${var.aws_instance_count}) must be evenly divisible by the number of private subnets (${length(var.aws_private_subnet_ids)})."
    }

    precondition {
      condition     = data.aws_ec2_instance_type.app.ebs_optimized_support != "unsupported"
      error_message = "The EC2 instance type (${var.aws_instance_type}) must support EBS optimization."      
    }
  }
}

Postconditions

Use postconditions to validate that desired conditions are met after we run apply.

data "aws_vpc" "app" {
  id = var.aws_vpc_id

  lifecycle {
    postcondition {
      condition     = self.enable_dns_support == true
      error_message = "The selected VPC must have DNS support enabled."      
    }
  }
}

Pre/Postconditions

Pre and postconditions are great for intercepting errors that would be thrown with generic error messages that might not be so helpful to users. Instead you can use pre/postconditions to intercept those errors and provide more useful, context specific error messages.

Checks And Assertions

Available from Terraform version 1.5, we have checks and assertions at our disposal.

check "health_check" {
  data "http" "terraform_io" {
    url = "https://www.example.com/some/api"
  }

  assert {
    condition = data.http.terraform_io.status_code == 200
    error_message = "${data.http.terraform_io.url} returned an unhealthy status code"
  }
}

Use checks to perform custom checks that will be executed at the end of plan and apply and warn you through error messages of failed checks.

The Terraform Testing Framework

NOTE:
This one is available from Terrafrom version 1.6 which with the new BSL licence instead of the previous MPL 2.0 licence. You should read about it online and see if and how it matters to you.

The Terraform test framework was introduced in version 1.6. It allows you to run tests on real, short lived, resources. Running the tests on real resources is equivalent to integration testing (command = apply) which is the default behavior. You can also run the tests without actual resources as unit tests (command = plan).

# main.tf

provider "aws" {
    region = "eu-central-1"
}

variable "bucket_prefix" {
  type = string
}

resource "aws_s3_bucket" "bucket" {
  bucket = "${var.bucket_prefix}-bucket"
}

output "bucket_name" {
  value = aws_s3_bucket.bucket.bucket
}

# valid_string_concat.tftest.hcl

variables {
  bucket_prefix = "test"
}

run "valid_string_concat" {

  command = plan

  assert {
    condition     = aws_s3_bucket.bucket.bucket == "test-bucket"
    error_message = "S3 bucket name did not match expected"
  }

}

Third-Party Testing and QA

After exploring the built-in testing and QA capabilities of Terraform, let's look at some third-party tools.

Terratest

Terratest is GoLang library that enables us to write tests for our Terraform IaC in the form of Go tests (_test.go). This means you can enjoy a high-level language and all its features with built-in Terraform capabilities like init, plan, apply, reading outputs, etc.

package test

import (
	"testing"

	"github.com/gruntwork-io/terratest/modules/terraform"
	"github.com/stretchr/testify/assert"
)

func TestTerraformHelloWorldExample(t *testing.T) {
	// Construct the terraform options with default retryable errors to handle the most common
	// retryable errors in terraform testing.
	terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
		// Set the path to the Terraform code that will be tested.
		TerraformDir: "../examples/terraform-hello-world-example",
	})

	// Clean up resources with "terraform destroy" at the end of the test.
	defer terraform.Destroy(t, terraformOptions)

	// Run "terraform init" and "terraform apply". Fail the test if there are any errors.
	terraform.InitAndApply(t, terraformOptions)

	// Run `terraform output` to get the values of output variables and check they have the expected values.
	output := terraform.Output(t, terraformOptions, "hello_world")
	assert.Equal(t, "Hello, World!", output)
}

In addition to Terraform, Terratest also enables you to write tests for Dockerfiles, Kubernetes and a few other.

TFLint

TFLint is a Terraform linter that focuses on possible errors, best practices, and style conventions in Terraform code. It enforces coding standards, naming conventions, and checks for deprecated syntax or unused declarations.

docker run --rm -v /my/terraform/code:/data -t ghcr.io/terraform-linters/tflint

Trivy (TFSec)

Trivy is a comprehensive and versatile security scanner. Trivy has scanners that look for security issues, and targets where it can find those issues.

TFSec will continue to remain available for the time being, although our engineering attention will be directed at Trivy going forward.

docker run -v /my/terraform/code:/data aquasec/trivy config /data

Terrascan

Terrascan is a static code analyzer for Infrastructure as Code. Terrascan allows you to seamlessly scan infrastructure as code for misconfigurations, monitor provisioned cloud infrastructure for configuration changes that introduce posture drift, and enables reverting to a secure posture.

docker run -v /my/terraform/code:/data accurics/terrascan scan /data

Chekov

Checkov is a static code analysis tool focused on detecting security misconfigurations and compliance violations in Terraform code. It scans Terraform configurations and evaluates them against a comprehensive set of predefined security and compliance policies.

docker run --rm -v /my/terraform/code:/data bridgecrew/checkov -d /data

Conclusion

You want to increase the code quality, security and compliance of your Terraform IaC? You want to make your IaC deployments more reliable? Great tools are available and, if not already the case, you should be integrating the tools and practices into your Terraform IaC game.

References

• https://developer.hashicorp.com/terraform/language/expressions/custom-conditions
• https://developer.hashicorp.com/terraform/cli/commands/validate
• https://developer.hashicorp.com/terraform/language/tests
• https://terratest.gruntwork.io/docs/getting-started/quick-start/
• https://github.com/terraform-linters/tflint
• https://github.com/aquasecurity/trivy
• https://github.com/aquasecurity/tfsec
• https://hub.docker.com/r/tenable/terrascan
• https://github.com/bridgecrewio/checkov

Intro

We hear these terms flying around, DevOps, SRE, Platform, etc. But what is it all about? How did they come to be? How can we use them?

Note

You already know this but the topics below are relevant only after software teams reach a certain scale. If it's only one or two of you starting from scratch, don't waste time on these topics and use the fastest and most pragmatic way to get your product out of the door.

History

Development & Operations

Once upon a time in a galaxy far, far away, there was a civilization divided into two classes - development and operations. They were supposed to work on a common goal but somewhere along the way they got isolated from each other and tensions grew. Operations did not know how to troubleshoot issues with the instructions given by development and development was not aware of the challenges operations faced. Eventually, progress came to a halt and this civilization collapsed.

DevOps

Learning from the problems previous civilizations faced, a new civilization emerged - DevOps. They understood that if they want to be successful, the different trades will need to work together and cover the whole process, from idea to delivering the value to society. Instead of development and operations being separated, the DevOps civilization was structured into smaller independent groups with members from both trades, development and operations. This civilization was quite successful and continues to exist.

Site Reliability Engineering

After some time of development and operations working closely together, a new trade emerged - the site reliability engineer. This started when someone asked a simple question - "What if we treat operations as a development i.e. a software problem?". Soon we had members of society that were good at both, development and operations. These members were tasked with taking care of the critical parts of the infrastructure and services since they had good command and understanding of all the parts.

Platform Engineering

If you are a software engineer, you know that we love to build abstractions. Well, after operations and development were merged together into one, we started seeing abstractions being created everywhere. Over time, the good abstractions crystalized at the top. The DevOps and SRE teams started using those abstractions so they could move faster instead of reinventing the wheel over and over again. A new trade emerged - the platform engineer. Software engineers building products for other software engineers.

What Is A Platform?

So platform engineering teams build products for software engineering teams but what are those products? What products make up the platform? Well, you have to ask your customers these questions. But what it's usually about is the following:

• a place to run applications,
• a way to deploy applications,
• a way to deploy supporting infrastructure
• a way to monitor applications,
• a way to develop and spin up test environments,
• supporting CLI tools, API's and UI's where appropriate

Aren't we already doing this?

Yes, we are, but as you might have seen and experienced, building and maintaining these things can be somewhat complex and time consuming. If possible, I, as an engineer working on a product for the end customer, would love to spend more time on that product instead of building and maintaining the supporting platform.

Well, what if we applied software engineering principles to this problem? Welcome to the problem space of platform engineers.

Platform engineers apply software engineering principles like reusability, modularization, simplicity, security, resilience, etc. combined with product design principles in order to deliver easy to use products and services that other engineers can use to deliver value to end customers faster, easier and safer.

Is Platform Engineering A New Thing?

Other than the terminology itself, I don't think there there is much new here. I think it heavily depends on the scale of the organization. Amazon, Google, Facebook, etc. had internal teams building products for other internal teams for a long time. What is new is that the idea is going mainstream.

Note

I won't talk about it in this article, but a strong feedback and collaboration loop between product builders and customers is assumed. Otherwise the product will probably fail.

Conclusion

Is platform engineering really a thing? I think it is. Staying competitive in the market is getting ever more difficult and complex. Software development, DevOps, site reliability engineering and now, platform engineering are all adjustments triggered by us trying to deal with the complexity, stay competitive and deliver value to customers faster.

Is platform engineering a good thing? Yes, but only if the platform products stay focused on the customer, remove obstacles, make them move faster, etc.

Intro

There are many things a software developer could think of and spend their time with but there are only a few really important ones. These are some I think are important.

Find The Purpose

If you don't have a goal, then you can never reach it. Before doing any work, you need to be clear about what it is you want to achieve, what is the purpose of the piece of software you want to write?

Look For Clarity

If you are not completely clear about the goal, you have to ask questions until you reach clarity and understanding of the problem i.e. the goal. Very often, grasping the problem correctly is 90% of the task.

Focus

Now that you have a solid grasp of the goal, you need to focus on the solution. Don't start other tasks in between. Don't work on anything else other than your task except if there is a high priority emergency.

Be Empathic

Always have the customer / user in mind. What do they want to achieve? How are they going to use the feature you are building? Try to put yourself in their shoes and see things from their perspective. This also applies to yourself in the future and your colleagues. Can I write my code a bit more descriptive so it's easier to understand?

Break It Down

The vast majority of solutions consist of more than one line of code i.e. they consist of multiple steps. You cannot swallow a whole apple at once. In the same sense, you cannot not finish a task in one step. That's why your first task is to try and break things down into smaller steps.

Find The Shortest Distance

The shortest distance between two points is a straight line. Your line might not be exactly straight but you have to focus on connecting A and B in the fastest way you can. Don't bother with elegance, best practices, design patterns, etc. Just connect the dots in the fastest way possible even if it's "dirty".

Be Pragmatic

Software has a lifecycle and is not finished in X amount of days. Rather, software is written in iterations. Pragmatism is about getting the job done in the simplest and fastest way without bothering about theoretical purity. Get the job done first then you can make it better in future iterations.

Keep It Simple, Stupid

Sometimes, our brains lead us to weird places and we start writing overly complicated solutions. We have to stay vigilant, try and notice when this happens. In case it happens, we need to stop and think about the problem again and ask "Is this really the simplest solution"?

Ask For Help

If you are stuck and not sure how to continue, ask for help and guidance. Find someone you think might be able to help you, tell them about your task and what you are trying to achieve. Tell them what you tried already and ask if they have an idea. Often, you will solve the issue just by describing it to someone.

Think About Things That Could Go Wrong

Murphy's law states: "Anything that can go wrong will go wrong". And it will probably go wrong at the worst possible time. Unlimited things can go wrong and we cannot think nor defend against all of them but being aware of them and tackling some of them, can make our software much more resilient and our customers happier.

Review Your Code

After you connected A and B and you have validated that your idea / solution works, go back and read what you wrote. I bet you will find mistakes, or things you might have forgotten to consider.

Ask Others To Review Your Code

No matter how smart you might be, your brain can never encompass the complexity of the world. But adding a few more brains might help in making our solution a bit better and catch missing pieces.

Be Open Minded

Your ideas and solutions might seem amazing to you, and maybe they really are, but no matter how much you might love your idea, you have to leave some space for the possibility of other ideas being better. Also, your idea might have a critical flaw that you didn't think of yet and someone will point it out to you. In that case you should be thankful.

Consider Trade-Offs

Trade-offs are situations where you have multiple, mutually exclusive, choices. One choice gives you a certain benefit but also comes with certain downsides. Another choice might not have the downsides of the first one, but then it also doesn't have the benefit. For example, one solution has very high performance, but not many features. Another solution has many features, but low performance. Which one you will choose, depends on your context, and what is important for your project at that time. Often, software development is balancing act.

Always Stay A "Junior"

A junior developer doesn't have an ego that might prevent them from asking questions, asking for help, asking about and listening to other peoples opinions and advice. A junior developer knows that there is so much they don't know yet and thus they are always ready to learn and expand their knowledge. By staying a junior in this way, you will never stop getting better at what you do.

Don't Reinvent The Wheel

Don't waste time solving problems that are already solved. If your business is selling flowers, don't be inveting a new JavaScript Framework. Work on providing your customer with the best choice of flowers and the easiest and most compfortable way for them to have the flowers delivered to them.

Separate Concerns

Imagine one person in a company being responsible for, sales, marketing, accounting, software development, shipping, etc. Does that make sense? Is that possible? Not really. That's why companies have departments and roles with different concerns and responsibilities. You need to break down your software in pretty much the same way and while working on new features, keep those concerns in mind.

Think, Ask, Research ...

Writing the actual code takes up, maybe, somewhere between 1%-10% of our job. The other 90%+ are about talking with team members, asking questions, sitting there, looking into the void, thinking and researching. The more you do of this, the better you will be at software development.

Be A Team Player

Talk with your colleagues, be honest, say what's on your mind, be effective and clear in your communication, be someone your colleagues can rely on, be open-minded, be kind, be respectful, give credit where it's due, etc.

Conclusion

These are some fundamental things I think are important to keep in mind while developing software. There are, of course, many more depending on your role and context.

Intro

If we want to write or work with almost any web application today, we will have to implement or deal with authentication and authorization. How do we authenticate users? How to make it secure and scalable?

There is a lot of confusing information online about these topics. This article is my attempt at clarifying the confusion.

Heads-Up

I assume some familiarity with topics related to authentication.

I am not explaining individual token structures in detail. For that you can refer to this (JWT), this (access/refresh tokens) and this (openid token).

When I refer to a "client" in this article, I mostly mean a web browser, not a mobile device. If you are interested in storing tokens securely on mobile devices, consider looking into KeyStore (android) or KeyChain (iOS).

What are the available solutions?

There are a few options for auth on the web but we'll take a look at a couple popular ones:

• Session based
• Token based

Security Measures

Some security measures should be in-place for any auth architecture:

• HTTP-only cookies
• Strict / Lax same-site cookies
• Encrypted communication / HTTPS (secure)
• CSRF tokens

What is session based authentication?

Session based authentication is a process where a user exchanges login credentials for a session ID with a server / backend. The process looks something like this:

How does it work?

1. The user fills a form with login credentials e.g. email and password and clicks on a submit button.
2. The backend receives the request and validates if a user with that email and password (hashed) exists in the database.
3. If the user exists, an ID is generated and stored as a record in the database with additional details like expiry, the associated user, etc.
4. This ID is then sent back to the client, usually as an HTTP set-cookie response header.
5. The browser then stores that ID as a cookie in its cookies storage and uses it for subsequent requests to the backend.
6. The backend then authenticates subsequent requests using the session ID and its associated record in the database instead of an email and password.

Security considerations

When using session based authentication you should be aware of potential security issues like:

• XSS
• CSRF
• Session Hijacking

For mitigation and prevention of these refer to the section above - "Security Measures"

Pros

• Simple and easy to implement
• Most backend languages and frameworks do most of the work for you
• Automatic expiration
• Easy way of blocking / revoking / restricting access for specific users
• Battle tested

Cons

• Requires some sort of persistence
• Cookies (sessions) bound to one domain
• Requires optimization and scaling out of storage at large scale, but what solution doesn't?! :D

Summary

Session based authentication has been used successfully for a long time and securely for those who had security on their minds. It's simple and also works great up to a certain scale (covers probably 99.9% of use cases). However, when you reach a certain scale, session persistence might become a bottleneck and you will have to start optimizing and scaling it out.

What is token based authentication?

What if I told you, you can authenticate users at massive scale without having a session storage? I'd probably be lying. But if you need an extremely complicated solution that will still need persistence then tokens might be a good fit.

How does basic JWT auth work?

Step 3 is where the path changes compared to session auth.

1. The user fills a form with login credentials e.g. email and password and clicks on a submit button.
2. The auth service receives the request and validates if a user with that email and password (hashed) exists in the database.
3. The auth service generates a JWT (JSON web token) that contains basic user information of our choosing and optionally an expiration timestamp.
4. The auth service signs the JWT with a private token / secret that is used across the distributed system to validate JWT authenticity.
5. The auth service sends the token back to the client via an HTTP-only cookie (up to 4096 bytes in size).
6. All subsequent requests will contain the cookie i.e. JWT token so the backend will be able to appropriately authenticate and authorize the request based on data contained in the JWT token.

Voila! We have distributed authentication and authorization that can be used across a distributed system without checking the database every time we do the auth.

This is the most basic auth flow using JWT tokens.

...

Colleague: "I see suspicious activity in the logs coming from a specific user... Can we block this user?"

Me who implemented basic JWT auth: "Sure we can! We delete the user in the user database and just change the secret we use in all the services to verify JWT tokens."

Colleague: "Oh, great! But won't that force all other users to re-login?"

Me: "Yes. Is that a problem?"

It might not be an issue in your use case but if it is ... Well, this is where the fun part begins :D

The Problem of Token Invalidation / Revocation

As you  can see, in case of malicious user activity or compromised tokens, we are not able to block or limit a targeted user without invalidating tokens of all other users forcing them to re-login.

We cannot solve this issue without introducing additional state and checks.

The Problem of Stale Tokens

As mentioned previously, JWT tokens contain a small amount of data related to the user like email, age, role etc. But if the JWT token never expires or has long validity, how do we update the JWT token data?

We cannot update the data if we don't ask for the JWT token again with our username and password.

What are refresh and access tokens?

Now we are aware of a couple shortcomings of basic JWT token auth. Are there solutions?

If you thought, "Wait, I think we need more tokens!", you thought right.

To solve the issues of revocation, stale data and long lived (insecure) tokens we will split our basic JWT token mentioned above, into two tokens - the refresh token and the access token defined in the OAuth 2.0 spec.

The access token is short lived (e.g. 10 min) and will be used for protected resource requests (e.g. /orders)

The refresh token is used solely for obtaining new access tokens and cannot be used to access protected resources.

How do refresh and access tokens work?

1. The user fills a form with login credentials e.g. email and password and clicks on a submit button.
2. The auth service receives the request and validates if a user with that email and password (hashed) exists in the database.
3. The auth service generates a refresh JWT token and a access JWT token and sends them back to the client.
4. The client uses the short lived (e.g. 10 min) access token for subsequent protected resource requests.
5. The client uses the refresh token to get another access token after the current one expires.

What are the benefits of a refresh / access token flow

• Forcing the client to ask for access tokens every e.g. 10 min, solves both the revocation and stale data issue.
• After we block or limit a specific user, the next access token request will fail stopping or limiting the users activity.
• Data contained in the tokens can also not really become stale since we are asking for it every 10 min.
• We still keep the stateless benefit of our tokens when using it with the other services in the distributed system since they

Note On Refresh Token Expiration

With a dedicated, full-featured auth service and clients are forced to ask for access tokens periodically, I don't see a reason to have long-lived refresh tokens.

Instead I recommend invalidating and issuing new refresh tokens every time the client asks for a new access token.

Voila! Problems solved.

...

Worried and puzzled colleague: "Multiple panicked customers contacted us saying that someone else gained access to their accounts and deleted all their data."

Me who suggested we use refresh and access tokens: "OMG! That's a nightmare for our business. How could they gain access? Wait ... Where are we storing the tokens on the client side?"

Colleague: "Yes, I asked the same question. We are storing the tokens in local browser storage."

Me: "Local storage!? That's a severe security risk!"

Where to store tokens securely?

There are a few options for storing tokens:

• Local storage
• Session storage
• Regular cookies
• Browser memory
• HTTP-only / secure / lax same-site cookies (spoiler: this is the best one)

So we have 2 or more types of tokens and 4 options for storage of the tokens. Let's go over the options ...

Storing Sensitive Tokens In Local Storage (Spoiler: DON'T)

Local storage is accessible by all JavaScript running in all browser tabs. This is horrific from a security perspective and disqualifying for sensitive data such as refresh and access tokens.

Storing Sensitive Tokens In Session Storage (Spoiler: DON'T)

Session storage is accessible by all JavaScript running in the same tab / page making it a little less horrific compared to local storage but still disqualifying as it is accessible by vendor JavaScript.

Storing Sensitive Tokens As Regular Cookies (Spoiler: DON'T)

Regular cookies (non-http-only) are accessible by all JavaScript running on the page. This is disqualifying for sensitive data such as refresh and access tokens.

Storing Sensitive Tokens In Memory

Storing the access tokens in memory might be acceptable if your website is a single page application i.e. users are not changing/refreshing the page every minute.

Refresh tokens on the other hand cannot be stored in memory since we have to provide our credentials to get a refresh token i.e. we would have to re-login every time we change/refresh the page.

Storing Tokens As HTTP-Only Cookies

Finally we arrive at the most secure option and my recommendation for optimal security.

Refresh and access tokens should be stored as HTTP-only / secure / strict (or lax) same-site cookies and not be accessible to JavaScript at all instead only allow us to call an endpoint for access token rotation.

Storing refresh and access tokens as HTTP-only cookies prohibits accessing data stored in the tokens e.g. username, email, role, expiration etc. But that is what we have ID tokens for.

What are ID tokens?

"An ID token contains information about what happened when a user authenticated, and is intended to be read by the OAuth client. The ID token may also contain information about the user such as their name or email address, although that is not a requirement of an ID token." - OAuth 2.0 Spec

The ID token is not used for auth against protected API resources.

Since this token is intended to be read by the client, contains information about the auth request and can contain basic user information, it is perfect for at least a couple use cases:

• Enhance user experience with e.g. a username displayed somewhere on the page or display a basic user profile / card on the page
• Store access token expiration so the client can request a new one on time

If your page is a SPA I'd recommend storing the ID token in memory and refreshing it every time you request a new access token from the auth service.

In case of a classical server rendered page, let the server deal with it and render the page with all relevant data on the server.

Pros

• Services, other than auth, don't need to make database calls to authenticate users
• Allows for auth decoupling
• Allows the auth service to pick the fastest and most scalable DB technology

Cons

• High level of complexity

What About Cookies And The Multi-Domain Problem?

Let's get the easy solution out of the way, for sub-domains you can use the cookie domain attribute.

The cookie domain attribute is, unfortunately, not a solution for different root domains e.g. sharing a cookies between xyz.com and zyx.com. This is not possible.

To solve this issue our auth service needs to be able to create very short-lived tokens (e.g. 10s) that can be consumed / authenticated by a different domain using a shared secret.

The Flow

1. User authenticates with credentials on auth.xyz.com
2. auth.xyz.com responds with refresh/access token as HTTP-only / strict (or lax) same site / secure cookies
3. The user is now able to access protected resources under the domain xyz.com
4. The user can now call an endpoint on the auth.xyz.com service e.g. /domain/zyx.com
5. auth.xyz.com will generate a very short-lived (10s) JWT token containing user identification information
6. auth.xyz.com will respond with a redirect pointing to e.g. auth.zyx.com/auth/token/[JWT-token]
7. auth.zyx.com will receive the authentication request with the token attached
8. auth.zyx.com will authenticate the token using a shared secret
9. auth.zyx.com will use the user identification contained in the token to generate a refresh and access token for that user
10. auth.zyx.com will return the refresh/access token as HTTP-only / strict (or lax) same site / secure cookies
11. The user is now able to access protected resources under zyx.com

Note: The auth service doesn't have to be a completely different service. It can be one service that responds on multiple domains.

Note: The token that is used between two domains doesn't have to be a JWT token. However, the auth service receiving the token must be able to find the user based on the token.

Conclusion

Maybe you have more questions about auth now than you had at the beginning. This indicates the complexity of the topic. But I hope I was able to shed some light on at least a few points.

Regarding security, there is no compromise here. We need to understand our security and it has to be as air-tight as possible.

Regarding complexity, that depends, as always, on your context and point in the journey. If you are starting off from zero, keep it as simple as possible without compromising security and adapt as requirements change.

PS: Apologies for spelling mistakes.

References

• OAuth 2.0 Specification
• OpenID Specification
• OWASP Cheatsheets
• JWT Introduction

Books

Patterns of Enterprise Application Architecture - Martin Fowler

Working Effectively with Legacy Code - Michael C. Feathers

Domain-Driven Design - Eric Evans

Refactoring - Martin Fowler, Kent Beck

Designing Data-Intensive Applications - Martin Kleppmann

Site Reliability Engineering - Google

Introduction to Algorithms - Thomas H. Cormen, Charles E. Leiserson, ...

99 Bottles of OOP - Sandi Metz

Inside The Machine - Jon Stokes

The Design Of Everyday Things - Donald A. Norman

Extreme Programming - Kent Beck

Peopleware - Tom DeMarco, Timothy Lister

Team Topologies - Matthew Skelton, Manuel Pais

Staff Engineer's Path - Tanya Reilly

Accelerate - Nicole Forsgren, Jez Humble, Gene Kim

The Language of Emotions - Karla McLaren

Blogs

AWS Blog

Google for Developers

GitHub Engineering Blog

MartinFowler.com

Kent Beck

Stack Overflow Blog

Cloudflare Engineering Blog

Slack Engineering

Netflix Tech Blog

Uber Engineering

Zalando Engineering

Podcasts

Software Engineering Daily

SRE Prodcast

AWS Developers

SuperManagers

Changelog

Go Time (Golang)

Intro / Motivation / Why

The code, functions and algorithms we write are not all the same. One very important aspect in which they differ is the complexity and efficiency. In order to produce quality solutions and improve existing ones, it would be great if there was a way to measure this somehow. Is there a way to measure this difference mathematically? Yes! We do this using the "Big O Notation"

What is "Big O Notation"?

Now that we have the why out of the way, let's look at the "what". Skipping the, usually, confusing wikipedia definition, let's try something simpler...

Big O notation is a mathematical description of algorithmic complexity relative to time and space i.e. a description of how much time or resources an algorithm will consume with increasing input size.

How Does Big O Break Down Complexity?

Big O notation breaks complexity down by the amount of time and space an algorithm uses relative to the input. An algorithm then falls into one of the following notations:

So our algorithms can be have one of the following complexities:

1. O(1)

Time or space is independent of input size e.g.:

- input 2 - time 1
- input 4 - time 1
- input 8 - time 1

2. O(log n)

Time or space increases based on every doubling of input size e.g.:

- input 2 - time 2,
- input 4 - time 3,
- input 8 - time 4

3. O(n)

Time or space increase is directly tied the input size e.g.:

- input 2 - time 2,
- input 4 - time 4,
- input 8 - time 8

4. O(n log n)

Time or space doubles as input size increases e.g.:

- input 2 - time 4,
- input 4 - time 8,
- input 8 - time 16

5. O(n^2)

Time or space increases quadratically as input size increases e.g.:

- input 2 - time 4,
- input 4 - time 16,
- input 8 - time 64

6. O(2^n)

Time or space increases exponentially as input size increases e.g.:

- input 2 - time 4,
- input 4 - time 16,
- input 8 - time 256

7. O(n!)

Time or space increases factorially as input size increases e.g.:

- input 2 - time 2,
- input 4 - time 24,
- input 8 - time 40320

As we can see, the different complexities can have dramatic impact.

NOTE: Algorithms are not limited to one of the above but can have multiple complexities depending on the input. This means they can have a best case, an average and a worst case scenario.

Show Me The Code!

First Element

Let's take the following example (Javascript) ...

function getFirstElement(array) {
  return array[0];
}

This is an O(1) complexity because the time required for the execution is independent of the input array length. Unfortunately, only a few algorithms can be this fast.

Bubble Sort

Let's take another example (Javascript) ...

function bubbleSort(array) {
  while (true) {
    let swapped = false;
    for (let i = 0; i < array.length; i++) {
      // if next element is bigger swap
      // the current with the next
      const nextElement = array[i+1]
      if(nextElement != undefined && array[i] > nextElement) {
        const temp = array[i]
        array[i] = nextElement;
        array[i+1] = temp;
        swapped = true;
      }
    }
    
    // finish if there was no swap after
    // a full traversal over all elements
    if (! swapped) {
      break;
    }
  }
  
  return array;
}

This bubble sort algorithm iterates over an array over and over again comparing the current and next element in the array. If the current is bigger than the next, it swaps the two. It does this until it doesn't detect a swap after a full input array iteration.

Let's visualize it for better understanding ...

First full traversal of the input array:

[6, 4, 5, 3, 2, 1] → [4, 6, 5, 3, 2, 1] - swap
[4, 6, 5, 3, 2, 1] → [4, 5, 6, 3, 2, 1] - swap
[4, 5, 6, 3, 2, 1] → [4, 5, 3, 6, 2, 1] - swap
[4, 5, 3, 6, 2, 1] → [4, 5, 3, 2, 6, 1] - swap
[4, 5, 3, 2, 6, 1] → [4, 5, 3, 2, 1, 6] - swap

swapped = true

Second full traversal of the input array:

[4, 5, 3, 2, 1, 6] → [4, 5, 3, 2, 1, 6]
[4, 5, 3, 2, 1, 6] → [4, 3, 5, 2, 1, 6] - swap
[4, 3, 5, 2, 1, 6] → [4, 3, 2, 5, 1, 6] - swap
[4, 3, 2, 5, 1, 6] → [4, 3, 2, 1, 5, 6] - swap
[4, 3, 2, 1, 5, 6] → [4, 3, 2, 1, 5, 6]

swapped = true

...

This goes on until we have a full traversal without any swaps ...

[1, 2, 3, 4, 5, 6] → [1, 2, 3, 4, 5, 6]
[1, 2, 3, 4, 5, 6] → [1, 2, 3, 4, 5, 6]
[1, 2, 3, 4, 5, 6] → [1, 2, 3, 4, 5, 6]
[1, 2, 3, 4, 5, 6] → [1, 2, 3, 4, 5, 6]
[1, 2, 3, 4, 5, 6] → [1, 2, 3, 4, 5, 6]

swapped = false

So what is the complexity of this? For the sake of brevity we'll only determine the worst case scenario.

If we use the input [8, 7, 6, 5, 4, 3, 2, 1] and build in an iterations counter we will see that for an input of 8 we the algorithm uses 64 iterations.

If we check the previously mentioned big O notations we will see that O(n^2) gives us a time complexity of 64 for an input of 8.

Is Big O Always Decisive?

You know how our physics rules don't work on the quantum scale? Well Big O is kinda similar i.e. for small inputs one algorithm can seemingly be much faster than another but do we really care if something took 1ms or 5ms? We might, in rare cases but what really matters for the vast majority of us is the difference between e.g. 500ms and 4s. So Big O is much more useful for the bigger scale and larger inputs rather then small inputs where some algorithms can be faster than others but then break down and take much more time for larger inputs.

Conclusion

The Big O notation is a good tool that every software engineer should be aware of. It helps us describe algorithm complexity and as such it can be beneficial to keep it in mind when writing and optimizing our solutions.

We all heard that naming is one of the hardest problems in software development. Whoever did some HTML/CSS, OOP, etc. can attest to the struggle of coming up with good names for classes, functions, variables, etc.

Question is why do we need good names? Well we need good names so we are able to reason easier about the code which in turn makes modification and extension much easier.

Unfortunately, because it is a hard problem, we often get it wrong. One of the ways we get it wrong, in my opinion, is when we are giving fake nouns to things instead of proper nouns.

Without going into a big discussion and detail, I will just try to illustrate the issue in the shortest most obvious way and let you decide.

Let's take this example ...

If I gave you these boxes and told you "build me something", will you be able to easily reason about the boxes and very quickly be able to build something that makes sense using them?

Another example ...

Will you be able to easily reason about these objects and come up with ideas of how to build something that makes sense with them and also easily find what other objects might be needed?

My prediction is that the answers to the questions above is "Yes. I will be able to easily reason about and work with these objects"

Now let's look at another example ...

Now the same question, If I gave you these boxes and told you "build me something", will you be able to easily reason about the boxes and very quickly be able to build something using them?

My prediction is you will not be able to easily reason about these objects and you will have very hard and uncomfortable time building something that makes sense with them. There are, of course, some exception to this but I hope that I got the point across.

There you go. That's my beef with "ER/OR" classes in OOP.

There are many opinions and articles on this topic but I would say if you are interested and have some spare time on your hands you can read through this delightful article / story ...

Stevey’s Blog Rants: Execution in the Kingdom of Nouns

Stevey's Blog RantsSteve Yegge

The Problem

While communicating with other people, we might say a lot or hear a lot. Despite a large amount of available information during communication, a lot is still left out leaving gaps in the picture.

We often fill these gaps with assumptions. This might rarely be a problem with people close to us that we spend a lot of time with but what about new people, groups, topics, projects, tasks etc. ? In these cases our assumptions might be off more often leading to misunderstandings and wasted time.

The Solution

The solution for problems in communication is, who could've guessed it, communication :D .

To avoid other people misunderstanding us, we need to continually practice and get better at our communication and better at ways of getting our point across as precisely and concisely as possible.

To avoid making wrong assumptions we have to continually practice careful listening, ponder about what is being said and while doing so ask questions or reiterate if in doubt or lacking understanding.