Dependencies in Knowledge and Practices

Don't race from the finish line backwards

Knowledge and practices have dependencies.

Knowing this and thinking about them will allow to grow your knowledge and practices in a more comfortable manner

In this article I would like to examine and exemplify them separately in order to better understand their consequences.

The dependencies of Knowledge

Learning has dependencies, there is no point in trying to teach advanced algorithms to someone who has not a clue about recursion or that does not understand control flow.

And if you try to do so, you will quickly discover that you will have to take the time to teach those concepts.

This applies to most knowledge we need as engineers, and learning or teaching them in the "correct" order matters.

Another example that comes to mind is languages and frameworks. You can learn JavaScript by learning React, but your knowledge of both React and JavaScript will suffer from it. (Substitute JavaScript and React with CSS and Tailwind, Ruby and Rails, etc).

This affects both individuals and teams:

  • Individuals because they should be conscious of it when learning, to see that if something is "too difficult" it might be because they are trying to learn it out of order.

  • Teams because if you want to upskill a team, you need everyone to get on the same 'stem' of the tree of knowledge or be prepared to tailor the growth of each individual.

The dependencies of Practices

As with knowledge, Practices have dependencies. The clearer example of that is CI(Continuous Integration)/TBD(Trunk Based Development). In order to apply it, you must, as a minimum:

  • Have good test practices

  • Pair/mob regularly

  • Be comfortable with separating integration from release

A similar story goes for test practices, let's take TDD(Test Driven Development) for example. In order to acquire that practice, you must already:

  • Be comfortable with the practice of testing.

These dependencies are somewhat overlooked by proponents of the 'more advanced' practices and that can be problematic.

This has the same consequences both for individuals and teams:

Individuals and teams should understand the dependencies in the practices they wish to embrace in order to adopt their prerequisites.

A small out of bounds note on practices

The dependencies in practices also reveal themselves in the fact that some practices are anathema to others. I won't delve deep into this subject, but let me exemplify it by saying that you will struggle making git flow and TBD work at the same time.

Conclusion

  • Know the dependencies that exist in what you want to learn or do.

  • Go about reaching the destination in order of dependencies.

  • Validate that as a team or individual you have satisfied the dependencies before moving to higher subjects