We Become What We Repeatedly Do (And Your CI Pipeline Knows It)
Your CI pipeline isn't just running tests. It's training your developers. The question is: what is it teaching them?
Every morning, a developer on your team does the same thing. They pull main, start a feature, write some code, push a commit, and wait.
That wait? That's a lesson.
If the build takes 3 minutes, they watch it. They see the tests run. They catch the failure immediately. They fix it while the context is fresh. Lesson learned: feedback is fast, mistakes are cheap, iterate quickly.
If the build takes 35 minutes, they don't watch it. They context-switch to Slack, check email, maybe start another task. When it fails, they've lost the thread. They spend 10 minutes remembering what they were trying to do. Lesson learned: feedback is slow, protect yourself by batching, don't run the build unless you have to.
Same developer. Same code. Different habit formed.
Aristotle was right: we become what we repeatedly do. And your CI pipeline knows exactly what your developers repeatedly do—because it's the one making them do it.
The Hidden Curriculum
Every school has two curricula. There's the official curriculum—what's in the syllabus, what teachers intend to teach. And there's the hidden curriculum—what students actually learn from how the school operates.
A school that says "curiosity matters" but only tests memorization teaches students that curiosity doesn't actually matter. A school that says "creativity is valued" but punishes wrong answers teaches students to play it safe.
Your development environment has a hidden curriculum too.
What you say: "We value code quality." What your 45-minute build teaches: "Don't bother running tests locally. Push and pray." What you say: "We want psychological safety." What your blame-laden error messages teach: "When things break, find someone to blame." What you say: "We encourage experimentation." What your rigid approval process teaches: "Trying new things is painful. Stick to the proven path."
The hidden curriculum always wins. Your developers aren't listening to your documentation. They're learning from their daily experience.
The Habit Loop in Code
Charles Duhigg popularized the habit loop: cue, routine, reward. Habits form when a cue triggers a routine that delivers a reward. Repeat enough times, and the routine becomes automatic.
Software development is nothing but habit loops.
Cue: Test fails Routine: Read error message, find problem, fix it Reward: Green build, dopamine hit, move on
That's a healthy loop. Now watch it degrade:
Cue: Test fails Routine: Error message is useless, dig through logs, guess at cause, try random fixes Reward: Eventually passes (maybe?), exhaustion, move on grudgingly
Same cue. Worse routine. Weaker reward. After enough repetitions, the developer learns: "Tests are unreliable. Don't trust them. Write fewer of them."
Your tooling didn't just fail to help. It actively trained a bad habit.
What Your Tools Are Teaching
Let's audit some common DX decisions through the habit lens:
Fast builds (< 5 min) teach: "Run builds often. Catch errors early. Iterate quickly." Slow builds (> 20 min) teach: "Avoid running builds. Batch changes. Cross fingers." Clear error messages teach: "Errors are information. Investigate calmly. Fix systematically." Cryptic error messages teach: "Errors are punishment. Panic. Add print statements everywhere." Quick PR reviews teach: "Code review is part of the workflow. Submit early, get feedback, iterate." Slow PR reviews teach: "Code review is a bottleneck. Hoard changes. Submit large PRs reluctantly." Good defaults teach: "The right thing is easy. Follow the path. Trust the system." Bad defaults teach: "The system fights you. Work around it. Develop your own patterns."
None of these lessons are in your documentation. All of them are being taught, every day, through repeated experience.
The Compound Effect
Here's where it gets scary: habits compound.
A developer who learns "tests are unreliable" writes fewer tests. Fewer tests means more bugs in production. More production bugs means more firefighting. More firefighting means less time for tests. The habit reinforces itself.
A developer who learns "feedback is fast" runs tests constantly. More tests means catching bugs early. Fewer production bugs means more time for quality work. More quality work means better habits. The habit reinforces itself.
Small differences in daily tooling experience create massive differences in developer capability over years. Your 30-minute build isn't just slow. It's training developers to be worse—every single day, every single build.
The DX Team's Real Job
If habits are formed through repeated action, then the DX team's job isn't primarily documentation or tooling or advocacy.
The DX team's job is to design the habit loops.
What cues do developers encounter daily? What routines do those cues trigger? What rewards (or punishments) reinforce those routines? Are the resulting habits making developers better or worse?
This is legislative work. You're not writing laws, but you're shaping the environment that shapes behavior. Every tooling decision, every default, every process is a vote for what kind of habits your developers will form.
The Question That Matters
Tomorrow morning, a developer on your team will pull main, start a feature, write some code, push a commit, and wait.
What lesson will they learn?
Next in series: "The Doctrine of the Mean: Why 'Best Practices' Is a Lie"