ONBOARDING SUPPORT

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.