In my thoughts about formalising my CSS methodology, I preempted the question "Why not just use an established method?", saying there are two answers. I gave one answer at the time; here I want to give the other.
This struck a chord with me, and made me reflect on why autonomy in my work is important. I think intuitively it makes sense that we would feel more satisfaction, when we have more autonomy. Looking at this in the broader sense, research bears it out.
I'm thinking here though specifically about how we write code. This is about choosing to do something one way rather than another; and the motivation for doing so. How autonomous are these motivations? Why does it matter?
In self determination theory (SDT), the idea of autonomy in this context is closely related to the concept of intrinsic and extrinsic motivations. When you are intrinsically motivated you are acting on your volition, e.g. doing something because you enjoy it. You are propelled by interest in the activity itself, as apposed to an extrinsic motivation. Extrinsic factors such as money or competition have been found to be detrimental to creativity, cognitive flexibility, and problem solving. Pretty key processes for this line of work, which are said to be associated with intrinsic motivation.
The motivation to follow a coding methodology or framework is probably going to be extrinsic. It's a means to an end. The feeling of autonomy while following a methodology however, can vary greatly. To the extent that it makes your life easier, or your work better, you are going to enjoy using it, thus feel like you are doing so because you want to. If on the other hand there are aspects of the methodology that you only follow because someone says you should, then you are beginning to act less on your own volition. So to be happy, motivated, and creative while following a methodology, you need to believe in it. To "buy into" it. In SDT, this idea of buy-in is broken into three levels: introjection, identification, and integration.
Introjection describes the state of a regulation that has been adopted by a person, but not accepted as their own. So for example, you follow the rule because you understand that it is the correct thing to do, but that concept of "correct" is someone else's.
An identified regulation is one that you feel reflects your own goals. You can follow this rule and still feel that you are acting on your own volition.
A regulation is said to be integrated when it becomes autonomous. You do not feel like you are following a regulation, but acting in a self-determined way.
While these are all technically extrinsic motivations, they graduate towards autonomous motivations.
I think you can draw a useful parallel for coding practices.
Introjected coding practice #
We're using Bootstrap, so I'm following its conventions; but it feels a bit horrible.
Identified coding practice #
BEM makes perfect sense to me, and is a great fit for this project.
Integrated coding practice #
I need to make this code perform the agreed function.
In terms of something like a CSS methodology, it's probably not useful to think about integration. Part of the point is being aware of the rules. We certainly need to be aware of them in order to decide whether they are appropriate for a given project. I think it is useful however to consider the rules in terms of introjected and identified. Aiming for an identified methodology should result in happier coders, after all. So how can we make identification more likely? One way, surely, is to have wider selection of methodologies to choose from; and if nothing fits, make something that does.
Any steps towards heteronomy in coding practice comes from reasonable, and practical objectives. So steps towards autonomy will probably bring tradeoffs. If everybody who wrote code, followed the same practices and methodologies, that would probably be optimal for maintenance and collaboration. It would however, I suspect, be terrible for creativity and diversity.
Gagné, M. and Deci, E. (2005). Self-determination theory and work motivation. Journal of Organizational Behavior, 26(4), pp.331-362 ↩︎
Thanks to torchlight.dev for the syntax highlighting in this post.