Half-life (t1/2) is the amount of time required for the amount of something to fall to half its initial value. The term is very commonly used in nuclear physics to describe how quickly unstable atoms undergo radioactive decay, but it is also used more generally for discussing any type of exponential decay.
I had this almost random idea of when a programmer hits his or hers career half-life.
Tangents
First a few points that need explaining: almost random is in the sense that next year this time I'll be hitting thirty (Faith No More track is already playing in my head).
The next point is how one should understand the word "career" in the context of the field I'm working in. The word itself makes me think of a reductionist fifties like view of how one works and/or deals with work.
This begets the question "What does 'career' mean for a programmer?" - tricky question and interesting tangent: methinks it refers to that period of time when one starts to work professionally (getting paid) to the point in time when one stops doing that.
Let's jump on another tangent: "Why is the end of a programming career when one stops writing code?" - clearly one could easily jump on a management position and still call oneself a programmer - that for me is not programming any more, maybe I'm a purist and yes I'm not fond of labels like "team leader", "CTO", "lead developer", "senior developer" and all that paraphernalia that in the end is just utter non-sense.
Relation to age
If one looks around the "average" age or more likely the anecdotal age (yes this is not even proper empiric data) of developers in shiny start-ups is around twenty seven, I reckon. And it makes sense - they're relatively fresh out of university programmers with a decent experience on that hi(y)ppie new programming language or paradigm.
I don't want to turn this into a rant, methinks I was also in that situation and it's a sane approach as long as one doesn't go into extremes (like using MongoDB, OrientDB, InfluxDB, etc. for a problem's domain where a relational DB is eye melting clear).
In any case, years pass, one gets experience and more importantly, experience at a higher level i.e. when one can much more easily understand the inner-workings of complex systems. The problem that stems out of this is that at some point work gets repetitive (if you let it) and one can easily get entrenched in a tool-chain.
The half-life of a programmer
I'm starting to feel this is the crux of the problem: a programmer hits half-life when he realizes that most of the work he does is repetitive and he or she gets entrenched in a tool-chain. Clearly, if one cannot overcome these slight issues then we have a problem that might lead to a non-programming career or an illusory one: "team leader", "CTO", "lead developer", "senior developer", "consultant" etc.
The issue with those terms is that some programmers start to take it way too seriously whilst completely ignoring what I like to call referential humility.
Most of my heroes: the likes of Jim Weirich , Sandi Metz and more seem to be in for life (the career) and I find that very reassuring.
Referential humility
What does that mean in the end? - just a play of words from referential integrity:
Referential integrity is a property of data which, when satisfied, requires every value of one attribute (column) of a relation (table) to exist as a value of another attribute in a different (or the same) relation (table).
In other words: there's always something "new" or something we still don't have a grasp of - hence the end of the road in a programmer's career is virtually non-existent.
Conclusion
Once you hit this half-life - choose wisely, work in the end is just another distraction from death, it's in our best interest to make that distraction authentic.
Vaguely related to the distraction from death tangent: