Blog posts

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.

Agile is a reaction to problems that it is now slowly trying to fix. 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.

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.

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.

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.

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.

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.

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.

Agile is a reaction to problems that it is now slowly trying to fix. 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.

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.

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.

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?