Blog posts

Samman technical coaching improves learning by applying the knowledge in a familiar environment as a team. Everyone learns together and can validate the new skills where they will be applied.

Teams perform better when dividing talking time and recognizing each others emotions. Working in an ensemble facilitates both of them, when done right.

Ensemble programming does with developers what the machine learning model random forest does with decision trees. The combination is far better than the parts, if independent enough.

Multiple processing units in a computer can provide speed, validation, redundancy and specialization. The same is true for software developers working in an ensemble.

The Goal teaches us to optimize for 'touch time'. Coding in an ensemble, all time is touch time, and the batch size is one. That optimizes for throughput.

Use questions when delivering constructive criticism on something complex. Questions leave room for the possibility that you are wrong.

When we feel comfortable there is room to try new and uncomfortable things. Then we can take (calculated) risks, collaborate and create. Value real comfort zones.

IT-stress has gotten into the top list of problems in the workplace. This is a text about coping with it.

The glyphs in the Latin alphabet are based on shapes that we evolved to recognize, not the figures our hands evolved to draw. Code should also always be easier to read than it was to write.

Teams perform better when dividing talking time and recognizing each others emotions. Working in an ensemble facilitates both of them, when done right.

The Westrum model for company culture distinguishes between pathological, bureaucratic and generative. To remember the model it is presented as ways to deal with a common restroom.

Ensemble programming does with developers what the machine learning model random forest does with decision trees. The combination is far better than the parts, if independent enough.

It is easy to forget what you once did not know. Be kind to new developers and create an environment for learning.

The agile manifesto states things that are valued over others. If that is drawn to an extremes, we don't pass on information to the future, making maintaining a system harder. Be aware of your tradeoffs, always.

A wish for connection can sometimes be disguised as a request. By focusing on the needs and emotions of the requester we learn more about the request and build relationships.

The agile manifesto is written as a reaction to the IT-industry of its time. As it wins ground it also slowly destroys its original context. If we lose sight of the heart of agile, we might end up in the other ditch. People growing up with agile will sound like waterfall evangelists, but only since they take the agile manifesto for granted.

The subjective contains information that is not expressed, just taken for granted. To solve problems we need access to all relevant information.

Non violent communication (NVC) and Theory Of Constraints (ToC) might look very different, but they have multiple similarities. Some of the common principles are listed here.

A personal book review of "Getting Naked : A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty" by Patrick Lencioni.

Our mind also has ergonomics. Software interior design is about designing our code, and our systems around it, to make our work easier.

A brief description of three tools for personal improvement: acceptance, meta cognition and growth mindset.

When you fear the codebase it creates the code smells of 'Braces, belt and duct tape' and 'Every line has to be read'. Use common design principles to build trust in the code again.

Use a linter for your code! And fix all(!) errors and warnings. Your brain will thank you.

If you lose your voice when gaining access to a new world, that world has also lost something. We have to avoid that in the software industry.

The Goal teaches us to optimize for 'touch time'. Coding in an ensemble, all time is touch time, and the batch size is one. That optimizes for throughput.

The most important thing to learn is improvement. Copying someone is not enough for true excellence. That is true for clothing and organizations.

Software development today share problems with the first bigger software projects, but unnecessarily so. To take advantage of a new technology we must unlearn what we did to manage without it. Then we can learn the skills needed to fully utilize our tools.

The subjective contains information that is not expressed, just taken for granted. To solve problems we need access to all relevant information.

Non violent communication (NVC) and Theory Of Constraints (ToC) might look very different, but they have multiple similarities. Some of the common principles are listed here.

How Theory of Constraints leads us to move the verification step in front of the production step, and keep shrinking the batch size.

We want to build less inventory, limit cognitive waste and practise continuous improvement. This applies also when working on the project backlog.

User research can save as much effort in the IT-industry as QA before a bottleneck does in manufacturing.

The Goal teaches us to optimize for 'touch time'. Coding in an ensemble, all time is touch time, and the batch size is one. That optimizes for throughput.

When we feel comfortable there is room to try new and uncomfortable things. Then we can take (calculated) risks, collaborate and create. Value real comfort zones.

IT-stress has gotten into the top list of problems in the workplace. This is a text about coping with it.

Anti-work in an organization will spread to its customers. No defect is too small to lower the quality of life for people a bit, and combined it is an unnecessary burden for the often already disadvantaged.

If you lose your voice when gaining access to a new world, that world has also lost something. We have to avoid that in the software industry.

How is Law of Demeter related to reference counting? It manages how parts of a software system is connected. Few languages today manage memory manually. But we can still use the same ways of thinking, to support a loosely coupled architecture.

Unit tests define the collaborators and the purpose of a piece of code. When reading code with unit tests, we can read the tests first, and focus on how the unit interacts with the system. Then reading the computational code is only about the implementation of that unit. Separating concerns like that lightens the cognitive load.

Some testing frameworks are so powerful that they take away all the design pressure. They have a place in a codebase that stinks so much you can't work in it without some perfume. In all other cases they disturb your nose for well designed code.

Use questions when delivering constructive criticism on something complex. Questions leave room for the possibility that you are wrong.

When you want your test to make sure that the code does not even try to call a collaborator with side effects, use a dynamite double, that explodes when touched.

In mathematics the definition of a function contains the set of valid input values, the domain. Test Driven Development can help us adapt that mindset and implement the boundaries of our domain in code.

IT-stress has gotten into the top list of problems in the workplace. This is a text about changing that.

Is "clean code" important for successful software development? It depends on the life expectancy of the software, if it needs to follow changes in the business and how well the user reacts to defects.

When talking about software quality we should separate internal and external quality. Internal quality makes it easy to write software that do what we expect. External quality is software that does what the end users expect.

Useworthiness is the combination of usability and utility. How well it works is weighted with how valuable the function is. Both impact how the user interacts with software.

It is not always possible to write pure functions. Still, the properties of pure functions can help us write testable code.

Don't let frameworks interlace with the domain code. Keep them separate and working with the codebase won't require super powers.

Unit tests are the playground where code learns to behave. If the code is both easy to test and easy to use, it has shown to be reusable.

Design the code so that as little as possible needs to change when the world changes.

Anti-work in an organization will spread to its customers. No defect is too small to lower the quality of life for people a bit, and combined it is an unnecessary burden for the often already disadvantaged.

What does too many stakeholders do to a piece of code?

Learning to refactor instead of rewriting preserves the domain knowledge build into the old codebase while it can keep making money. The skill of continuous improvement is important for developers, and might be neglected in a "rewrite" culture.

Being good at things nobody should ever have to do is a tricky thing. This is a text about wishing for a better world, also when you don't yet have the skills needed to perform well in that world.

A cognitive tool in shape of a list of things that often go wrong when writing code. Nice to have when you get stuck.

Test Driven Development (and unit testing in general) is easier when some things are avoided or encapsulated. Here are four problems faced when unit testing and their solutoins.

A list of aspects to consider when getting to know a new software project and assessing how easy it will be to work with.

Our mind also has ergonomics. Software interior design is about designing our code, and our systems around it, to make our work easier.

Three benefits from doing test first, one test at the time are: specific feedback, design guidance and finding the right amount of tests.

How Theory of Constraints leads us to move the verification step in front of the production step, and keep shrinking the batch size.

In test driven development the tests, even before they even test something, guides our steps. The trick is to take really small steps, and let code and tests evolve together.

Use a linter for your code! And fix all(!) errors and warnings. Your brain will thank you.

User research can save as much effort in the IT-industry as QA before a bottleneck does in manufacturing.

Estimation is a place for quick assessments that everyone agree on the scope. It is also a way to discover technical knowledge that needs to be shared in the team.

IT-stress has gotten into the top list of problems in the workplace. This is a text about changing that.

IT-stress has gotten into the top list of problems in the workplace. This is a text about coping with it.

Is "clean code" important for successful software development? It depends on the life expectancy of the software, if it needs to follow changes in the business and how well the user reacts to defects.

Useworthiness is the combination of usability and utility. How well it works is weighted with how valuable the function is. Both impact how the user interacts with software.

The software quality suffers when a team, and their code, try to satisfy conflicting needs. Communication overhead, and hard dependencies on work by other teams, make it worse. This is a compilation of some things commonly done to limit this.

Creatures with an innate need to solve problems, like octopuses and software developers, will look for problems to solve. Invite the development team to be a part of solving the business problems, and provide octopuses in captivity with puzzle boxes.

Anti-work in an organization will spread to its customers. No defect is too small to lower the quality of life for people a bit, and combined it is an unnecessary burden for the often already disadvantaged.

A wish for connection can sometimes be disguised as a request. By focusing on the needs and emotions of the requester we learn more about the request and build relationships.

We want to build less inventory, limit cognitive waste and practise continuous improvement. This applies also when working on the project backlog.

User research can save as much effort in the IT-industry as QA before a bottleneck does in manufacturing.

Unit tests define the collaborators and the purpose of a piece of code. When reading code with unit tests, we can read the tests first, and focus on how the unit interacts with the system. Then reading the computational code is only about the implementation of that unit. Separating concerns like that lightens the cognitive load.

Some testing frameworks are so powerful that they take away all the design pressure. They have a place in a codebase that stinks so much you can't work in it without some perfume. In all other cases they disturb your nose for well designed code.

Code needs something to make sure it works as intended. Using asynchronous code reviews for that will slow the team down. Reviewing code as a group is a good tool for knowledge sharing, but do it on production code.

Estimation is a place for quick assessments that everyone agree on the scope. It is also a way to discover technical knowledge that needs to be shared in the team.

Samman technical coaching improves learning by applying the knowledge in a familiar environment as a team. Everyone learns together and can validate the new skills where they will be applied.

IT-stress has gotten into the top list of problems in the workplace. This is a text about changing that.

When talking about software quality we should separate internal and external quality. Internal quality makes it easy to write software that do what we expect. External quality is software that does what the end users expect.

DevOps and FullStack are orthogonal concepts. One is about technology and the other is about the software lifecycle.

The software quality suffers when a team, and their code, try to satisfy conflicting needs. Communication overhead, and hard dependencies on work by other teams, make it worse. This is a compilation of some things commonly done to limit this.

The SOLID principles help us write loosely coupled code. We also know that the structure of the organization is reflected in the resulting code. So how can we translate SOLID to help with a loosely coupled organization?

Creatures with an innate need to solve problems, like octopuses and software developers, will look for problems to solve. Invite the development team to be a part of solving the business problems, and provide octopuses in captivity with puzzle boxes.

The most important thing to learn is improvement. Copying someone is not enough for true excellence. That is true for clothing and organizations.

Your retros will be more productive if you do them right. Read this post, "Agile retrospectives, making good teams great", and/or get someone who facilitates your retrospective.

The agile manifesto states things that are valued over others. If that is drawn to an extremes, we don't pass on information to the future, making maintaining a system harder. Be aware of your tradeoffs, always.

The agile manifesto is written as a reaction to the IT-industry of its time. As it wins ground it also slowly destroys its original context. If we lose sight of the heart of agile, we might end up in the other ditch. People growing up with agile will sound like waterfall evangelists, but only since they take the agile manifesto for granted.

A personal book review of "Getting Naked : A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty" by Patrick Lencioni.

A brief description of three tools for personal improvement: acceptance, meta cognition and growth mindset.

As Tolkien puts it in *The fellowship of the ring* “Not all those who wander are lost.” and "even the very wise cannot see all ends.” This is a text about agile software development and adventures.

We want to build less inventory, limit cognitive waste and practise continuous improvement. This applies also when working on the project backlog.

How is Law of Demeter related to reference counting? It manages how parts of a software system is connected. Few languages today manage memory manually. But we can still use the same ways of thinking, to support a loosely coupled architecture.

Unit tests define the collaborators and the purpose of a piece of code. When reading code with unit tests, we can read the tests first, and focus on how the unit interacts with the system. Then reading the computational code is only about the implementation of that unit. Separating concerns like that lightens the cognitive load.

Some testing frameworks are so powerful that they take away all the design pressure. They have a place in a codebase that stinks so much you can't work in it without some perfume. In all other cases they disturb your nose for well designed code.

Code needs something to make sure it works as intended. Using asynchronous code reviews for that will slow the team down. Reviewing code as a group is a good tool for knowledge sharing, but do it on production code.

Use questions when delivering constructive criticism on something complex. Questions leave room for the possibility that you are wrong.

When you want your test to make sure that the code does not even try to call a collaborator with side effects, use a dynamite double, that explodes when touched.

One way to construct a workshop is to think of it as a series of data transformations. Each step has to filter or transform the input in a way that it matches the input of the next exercise, until we have reached the requested result. This helps in controlling the format, and quality, of the results, without controlling its content.

In mathematics the definition of a function contains the set of valid input values, the domain. Test Driven Development can help us adapt that mindset and implement the boundaries of our domain in code.

Estimation is a place for quick assessments that everyone agree on the scope. It is also a way to discover technical knowledge that needs to be shared in the team.

Samman technical coaching improves learning by applying the knowledge in a familiar environment as a team. Everyone learns together and can validate the new skills where they will be applied.

Is "clean code" important for successful software development? It depends on the life expectancy of the software, if it needs to follow changes in the business and how well the user reacts to defects.

When talking about software quality we should separate internal and external quality. Internal quality makes it easy to write software that do what we expect. External quality is software that does what the end users expect.

Useworthiness is the combination of usability and utility. How well it works is weighted with how valuable the function is. Both impact how the user interacts with software.

DevOps and FullStack are orthogonal concepts. One is about technology and the other is about the software lifecycle.

The software quality suffers when a team, and their code, try to satisfy conflicting needs. Communication overhead, and hard dependencies on work by other teams, make it worse. This is a compilation of some things commonly done to limit this.

The SOLID principles help us write loosely coupled code. We also know that the structure of the organization is reflected in the resulting code. So how can we translate SOLID to help with a loosely coupled organization?

Creatures with an innate need to solve problems, like octopuses and software developers, will look for problems to solve. Invite the development team to be a part of solving the business problems, and provide octopuses in captivity with puzzle boxes.

The glyphs in the Latin alphabet are based on shapes that we evolved to recognize, not the figures our hands evolved to draw. Code should also always be easier to read than it was to write.

It is not always possible to write pure functions. Still, the properties of pure functions can help us write testable code.

Don't let frameworks interlace with the domain code. Keep them separate and working with the codebase won't require super powers.

Unit tests are the playground where code learns to behave. If the code is both easy to test and easy to use, it has shown to be reusable.

Design the code so that as little as possible needs to change when the world changes.

Conditionals in the code can come from rules in the domain, or from how we constructed the solution. Make sure to know the differance.

Verbose and descriptive naming can be ugly, but if the code is messy it is better to show that in the names. Then the names can be a tool for further re-design.

What does too many stakeholders do to a piece of code?

Ensemble programming does with developers what the machine learning model random forest does with decision trees. The combination is far better than the parts, if independent enough.

It is easy to forget what you once did not know. Be kind to new developers and create an environment for learning.

This is a meta text about how this site is build using Jekyll.

Learning to refactor instead of rewriting preserves the domain knowledge build into the old codebase while it can keep making money. The skill of continuous improvement is important for developers, and might be neglected in a "rewrite" culture.

Being good at things nobody should ever have to do is a tricky thing. This is a text about wishing for a better world, also when you don't yet have the skills needed to perform well in that world.

Get the benefits from abstractions by turning each signature into a curiosity barrier. When looking at the signature, a developer should know what the piece of code does, without needing to read the implementation.

Languages and frameworks will be part of a larger context. Consider the existing environment when choosing a language or framework.

Code never written, code never read, code never changed and code telling a story

A cognitive tool in shape of a list of things that often go wrong when writing code. Nice to have when you get stuck.

We have to practise new skills in a setting where everything else is easy. Getting to a point where the sustainable way to write software is done by reflex, also on the easier tasks.

Test Driven Development (and unit testing in general) is easier when some things are avoided or encapsulated. Here are four problems faced when unit testing and their solutoins.

A list of aspects to consider when getting to know a new software project and assessing how easy it will be to work with.

Our mind also has ergonomics. Software interior design is about designing our code, and our systems around it, to make our work easier.

Three benefits from doing test first, one test at the time are: specific feedback, design guidance and finding the right amount of tests.

How Theory of Constraints leads us to move the verification step in front of the production step, and keep shrinking the batch size.

In test driven development the tests, even before they even test something, guides our steps. The trick is to take really small steps, and let code and tests evolve together.

When you fear the codebase it creates the code smells of 'Braces, belt and duct tape' and 'Every line has to be read'. Use common design principles to build trust in the code again.

This text has one reason to exist. I want you to write smaller and simpler units of code. I want each unit of code to have only one reason to exist.

Use a linter for your code! And fix all(!) errors and warnings. Your brain will thank you.

Languages and frameworks will be part of a larger context. Consider the existing environment when choosing a language or framework.

Code never written, code never read, code never changed and code telling a story

A cognitive tool in shape of a list of things that often go wrong when writing code. Nice to have when you get stuck.

Test Driven Development (and unit testing in general) is easier when some things are avoided or encapsulated. Here are four problems faced when unit testing and their solutoins.

A list of aspects to consider when getting to know a new software project and assessing how easy it will be to work with.

Code needs something to make sure it works as intended. Using asynchronous code reviews for that will slow the team down. Reviewing code as a group is a good tool for knowledge sharing, but do it on production code.

When we feel comfortable there is room to try new and uncomfortable things. Then we can take (calculated) risks, collaborate and create. Value real comfort zones.

DevOps and FullStack are orthogonal concepts. One is about technology and the other is about the software lifecycle.

The SOLID principles help us write loosely coupled code. We also know that the structure of the organization is reflected in the resulting code. So how can we translate SOLID to help with a loosely coupled organization?

Don't let frameworks interlace with the domain code. Keep them separate and working with the codebase won't require super powers.

Design the code so that as little as possible needs to change when the world changes.

The Westrum model for company culture distinguishes between pathological, bureaucratic and generative. To remember the model it is presented as ways to deal with a common restroom.

Systems thinking helps us understand why DevOps happens in the joining of dev and ops. It can not be bottled and sold separately.

Self contradictions are things with a built in logical conflict. A DevOps person is not possible, since DevOps is about collaboration and shared responsibility. It can not be contained by a person.

There is a scientifically better way to write software. It is all available in the DORA DevOps report and learning about it will save lives, for real.

The software industry has to dream bigger when it comes to excellence, and use research available to improve. We need to dare to imagine a world where writing code is fun and pain free. It is possible!

Software development today share problems with the first bigger software projects, but unnecessarily so. To take advantage of a new technology we must unlearn what we did to manage without it. Then we can learn the skills needed to fully utilize our tools.

One way to construct a workshop is to think of it as a series of data transformations. Each step has to filter or transform the input in a way that it matches the input of the next exercise, until we have reached the requested result. This helps in controlling the format, and quality, of the results, without controlling its content.

Teams perform better when dividing talking time and recognizing each others emotions. Working in an ensemble facilitates both of them, when done right.

The most important thing to learn is improvement. Copying someone is not enough for true excellence. That is true for clothing and organizations.

Your retros will be more productive if you do them right. Read this post, "Agile retrospectives, making good teams great", and/or get someone who facilitates your retrospective.

Verbose and descriptive naming can be ugly, but if the code is messy it is better to show that in the names. Then the names can be a tool for further re-design.

What does too many stakeholders do to a piece of code?

Code never written, code never read, code never changed and code telling a story

The software industry has to dream bigger when it comes to excellence, and use research available to improve. We need to dare to imagine a world where writing code is fun and pain free. It is possible!

We have to practise new skills in a setting where everything else is easy. Getting to a point where the sustainable way to write software is done by reflex, also on the easier tasks.

When we feel comfortable there is room to try new and uncomfortable things. Then we can take (calculated) risks, collaborate and create. Value real comfort zones.

When you want your test to make sure that the code does not even try to call a collaborator with side effects, use a dynamite double, that explodes when touched.

In mathematics the definition of a function contains the set of valid input values, the domain. Test Driven Development can help us adapt that mindset and implement the boundaries of our domain in code.

Estimation is a place for quick assessments that everyone agree on the scope. It is also a way to discover technical knowledge that needs to be shared in the team.

When talking about software quality we should separate internal and external quality. Internal quality makes it easy to write software that do what we expect. External quality is software that does what the end users expect.

DevOps and FullStack are orthogonal concepts. One is about technology and the other is about the software lifecycle.

The glyphs in the Latin alphabet are based on shapes that we evolved to recognize, not the figures our hands evolved to draw. Code should also always be easier to read than it was to write.

It is not always possible to write pure functions. Still, the properties of pure functions can help us write testable code.

Don't let frameworks interlace with the domain code. Keep them separate and working with the codebase won't require super powers.

Unit tests are the playground where code learns to behave. If the code is both easy to test and easy to use, it has shown to be reusable.

Ensemble programming does with developers what the machine learning model random forest does with decision trees. The combination is far better than the parts, if independent enough.

It is easy to forget what you once did not know. Be kind to new developers and create an environment for learning.

Being good at things nobody should ever have to do is a tricky thing. This is a text about wishing for a better world, also when you don't yet have the skills needed to perform well in that world.

Code never written, code never read, code never changed and code telling a story

We have to practise new skills in a setting where everything else is easy. Getting to a point where the sustainable way to write software is done by reflex, also on the easier tasks.

How Theory of Constraints leads us to move the verification step in front of the production step, and keep shrinking the batch size.

The Goal teaches us to optimize for 'touch time'. Coding in an ensemble, all time is touch time, and the batch size is one. That optimizes for throughput.

How is Law of Demeter related to reference counting? It manages how parts of a software system is connected. Few languages today manage memory manually. But we can still use the same ways of thinking, to support a loosely coupled architecture.

Unit tests define the collaborators and the purpose of a piece of code. When reading code with unit tests, we can read the tests first, and focus on how the unit interacts with the system. Then reading the computational code is only about the implementation of that unit. Separating concerns like that lightens the cognitive load.

Some testing frameworks are so powerful that they take away all the design pressure. They have a place in a codebase that stinks so much you can't work in it without some perfume. In all other cases they disturb your nose for well designed code.

Code needs something to make sure it works as intended. Using asynchronous code reviews for that will slow the team down. Reviewing code as a group is a good tool for knowledge sharing, but do it on production code.

Use questions when delivering constructive criticism on something complex. Questions leave room for the possibility that you are wrong.

Samman technical coaching improves learning by applying the knowledge in a familiar environment as a team. Everyone learns together and can validate the new skills where they will be applied.

IT-stress has gotten into the top list of problems in the workplace. This is a text about changing that.

IT-stress has gotten into the top list of problems in the workplace. This is a text about coping with it.

Is "clean code" important for successful software development? It depends on the life expectancy of the software, if it needs to follow changes in the business and how well the user reacts to defects.

Useworthiness is the combination of usability and utility. How well it works is weighted with how valuable the function is. Both impact how the user interacts with software.

The SOLID principles help us write loosely coupled code. We also know that the structure of the organization is reflected in the resulting code. So how can we translate SOLID to help with a loosely coupled organization?

Creatures with an innate need to solve problems, like octopuses and software developers, will look for problems to solve. Invite the development team to be a part of solving the business problems, and provide octopuses in captivity with puzzle boxes.

Teams perform better when dividing talking time and recognizing each others emotions. Working in an ensemble facilitates both of them, when done right.

Design the code so that as little as possible needs to change when the world changes.

Anti-work in an organization will spread to its customers. No defect is too small to lower the quality of life for people a bit, and combined it is an unnecessary burden for the often already disadvantaged.

Conditionals in the code can come from rules in the domain, or from how we constructed the solution. Make sure to know the differance.

Verbose and descriptive naming can be ugly, but if the code is messy it is better to show that in the names. Then the names can be a tool for further re-design.

What does too many stakeholders do to a piece of code?

The Westrum model for company culture distinguishes between pathological, bureaucratic and generative. To remember the model it is presented as ways to deal with a common restroom.

Systems thinking helps us understand why DevOps happens in the joining of dev and ops. It can not be bottled and sold separately.

The most important thing to learn is improvement. Copying someone is not enough for true excellence. That is true for clothing and organizations.

Your retros will be more productive if you do them right. Read this post, "Agile retrospectives, making good teams great", and/or get someone who facilitates your retrospective.

This is a meta text about how this site is build using Jekyll.

Learning to refactor instead of rewriting preserves the domain knowledge build into the old codebase while it can keep making money. The skill of continuous improvement is important for developers, and might be neglected in a "rewrite" culture.

Multiple processing units in a computer can provide speed, validation, redundancy and specialization. The same is true for software developers working in an ensemble.

Get the benefits from abstractions by turning each signature into a curiosity barrier. When looking at the signature, a developer should know what the piece of code does, without needing to read the implementation.

The agile manifesto states things that are valued over others. If that is drawn to an extremes, we don't pass on information to the future, making maintaining a system harder. Be aware of your tradeoffs, always.

Self contradictions are things with a built in logical conflict. A DevOps person is not possible, since DevOps is about collaboration and shared responsibility. It can not be contained by a person.

There is a scientifically better way to write software. It is all available in the DORA DevOps report and learning about it will save lives, for real.

Test Driven Development (and unit testing in general) is easier when some things are avoided or encapsulated. Here are four problems faced when unit testing and their solutoins.

A wish for connection can sometimes be disguised as a request. By focusing on the needs and emotions of the requester we learn more about the request and build relationships.

The agile manifesto is written as a reaction to the IT-industry of its time. As it wins ground it also slowly destroys its original context. If we lose sight of the heart of agile, we might end up in the other ditch. People growing up with agile will sound like waterfall evangelists, but only since they take the agile manifesto for granted.

The subjective contains information that is not expressed, just taken for granted. To solve problems we need access to all relevant information.

A list of aspects to consider when getting to know a new software project and assessing how easy it will be to work with.

Our mind also has ergonomics. Software interior design is about designing our code, and our systems around it, to make our work easier.

Three benefits from doing test first, one test at the time are: specific feedback, design guidance and finding the right amount of tests.

In test driven development the tests, even before they even test something, guides our steps. The trick is to take really small steps, and let code and tests evolve together.

As Tolkien puts it in *The fellowship of the ring* “Not all those who wander are lost.” and "even the very wise cannot see all ends.” This is a text about agile software development and adventures.

When you fear the codebase it creates the code smells of 'Braces, belt and duct tape' and 'Every line has to be read'. Use common design principles to build trust in the code again.

This text has one reason to exist. I want you to write smaller and simpler units of code. I want each unit of code to have only one reason to exist.

Use a linter for your code! And fix all(!) errors and warnings. Your brain will thank you.

We want to build less inventory, limit cognitive waste and practise continuous improvement. This applies also when working on the project backlog.

User research can save as much effort in the IT-industry as QA before a bottleneck does in manufacturing.

If you lose your voice when gaining access to a new world, that world has also lost something. We have to avoid that in the software industry.

One way to construct a workshop is to think of it as a series of data transformations. Each step has to filter or transform the input in a way that it matches the input of the next exercise, until we have reached the requested result. This helps in controlling the format, and quality, of the results, without controlling its content.

The software quality suffers when a team, and their code, try to satisfy conflicting needs. Communication overhead, and hard dependencies on work by other teams, make it worse. This is a compilation of some things commonly done to limit this.

Languages and frameworks will be part of a larger context. Consider the existing environment when choosing a language or framework.

A cognitive tool in shape of a list of things that often go wrong when writing code. Nice to have when you get stuck.

The software industry has to dream bigger when it comes to excellence, and use research available to improve. We need to dare to imagine a world where writing code is fun and pain free. It is possible!

Software development today share problems with the first bigger software projects, but unnecessarily so. To take advantage of a new technology we must unlearn what we did to manage without it. Then we can learn the skills needed to fully utilize our tools.

Non violent communication (NVC) and Theory Of Constraints (ToC) might look very different, but they have multiple similarities. Some of the common principles are listed here.

A personal book review of "Getting Naked : A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty" by Patrick Lencioni.

A brief description of three tools for personal improvement: acceptance, meta cognition and growth mindset.