Programming for personal growth

Originally published on: Medium

Introduction

Before I became a software developer professionally, I worked at a company with a tech department that I, as a mere Javascript-dabbler at the time, longed to become a part of. I was a recent uni graduate, still a little naive to the various archetypes that make up a business, and one of the things that struck me was the difference in attitude of the programmers relative to the remainder of the organisation. Mostly, the company culture seemed (to me) to be characterised by sycophancy and poorly-defined roles. Requirements were made with a sense of urgency and fulfilled with a sense of stress. Getting flustered was a fantastic way to show that you were working hard. Despite spoken pretences to the contrary, deep-down there was a suspicion that saying ‘I don’t know’ was a flag for incompetency that would be frowned upon by higher-ups.

The programmers though, they seemed different. Someone would frantically come to someone’s desk and report a bug. “Why is this happening?!!”, they would demand. The person who was responsible for it would sit there, unnerved.

‘Log a ticket’ he or she would say. ‘We’ll have to investigate that.’

Wow, I thought. We’ll have to investigate that. No attempt to please authority whatsoever? No hurried psychological scramble for an explanation or an answer? I want some of that!

What was impressive to me, although perhaps I wouldn’t have been able to put it in such words at the time, was the confidence in efficacy shown by the tech department. These folks were smart, so the confidence was justified, but there was more to it than that. I had a feeling at the time, perhaps unfair to those in the office with other job titles, that the work of a software developer was somehow connected to reality in a way that some other roles weren’t. That these developers were playing a game in which there were very well-defined standards for success and failure, and in which they had total deterministic power to meet them.

I don’t mean the unrealistic standards imposed by business. I mean simple things: ‘do my unit tests pass?’ ‘does my app crash when it loads?’ ‘did I fix the bug that everyone is worried about?’ These standards are entirely objective, apolitical. An antithetical type of game responds to poorly defined criteria for success by devaluing success— it involves outsourcing your beliefs to an influential Other without any allegiance to what might actually be true; an emphasis on affectation and talk rather than sincerity and action. If the grass seemed greener on the other side of the office, I think it was because of the relative lack of bullshit (although I now recognise that 1] the dynamic I describe above is very much peculiar to the particular company I happened to work for at the time, 2] these beliefs might have said more about my dissatisfaction with my role at the time than any general truths about the ‘objectivity’ of professions, 3] if other professions have standards for success that are harder to define, it doesn’t always imply the complete absence of such standards, and 4] I’ve also since learned that the field of software development, whilst theoretically bullshit-free, isn’t always devoid of it in practice).

After I had successfully made the career transition I had so desired (thanks to a few people who I still feel incredibly grateful towards to this day), I soon learned a couple of tricks for developing that sense of efficacy and self-reliance that I had until then only admired in others.

Firstly, I realised how, if programmers seem like the calmest people in the office, it is that physiological arousal is like kryptonite for writing good code. Being stressed constricts your focus, which is maladaptive in a pursuit that, at its core, requires the ability to jump mentally up and down ladders of abstraction. In case of any urgency, I needed to learn how to kickstart my mind without kickstarting my heart-rate. I needed to learn how not to imitate other people’s stress.

A second thing I learned was the importance of hypothesis testing versus trial and error.

Let’s say you need to initialise a variable with a value and you know that the correct value is one of a set of possible options. You could either:

Simulate the system in your mind until you know what the correct value should be (hypothesising)
Try each option in turn until your program works (trial and error)

The latter approach may be quicker and ‘easier’, but it’s obvious which one contributes better to your feeling of genuine mastery and control over what you are doing — not to mention your long-term growth as a developer and your ability to solve such problems in the future. There is a certain ‘delight’ in creating a hypothesis concerning the correct answer and verifying it, versus the quite sterile and un-empowering experience of trying a few options and randomly stumbling upon the right one. You want to avoid feeling alienated from your own code. The job of a developer is to tell machines what to do, not to act like one.

Instead, the aim should be to develop your ideas and mental models to a point where you feel ‘compelled’ to write code as a form of expression, just as Orwell advocated something similar regarding the writing of prose.

But the words, ‘delight’ and ‘alienation’ — I want to talk about these a bit more.

Years ago I read ‘Towards a Psychology of Being’ by Abraham Maslow, in which he describes a fundamental antagonism between safety and growth. His theory contends that personal growth in a child, or anyone for that matter, is based on an accumulation of ‘delight’ experiences. These can sometimes be the result of having successfully manipulated some minor aspect of the world through a spontaneous action that hitherto seemed outside the sphere of possibility. As such, growth is partly an expansion of horizons, a mapping of uncharted territory, and a gradual development of a sense of efficacy.

But this concept is also related to a discovery of values and innate preferences. For example, in Maslow’s words, perhaps ‘kissing one person gives more delight than kissing the other’. He goes on to describe the consequences of such growth-through-delight:

In this way, we learn what we are good at, what we really like or dislike, what our tastes and judgements and capacities are. In a word, this is the way in which we discover the Self and answer the ultimate questions Who am I? What am I?

As for alienation, Maslow has this to say (emphasis mine):

The opposite of the subjective experience of delight (trusting himself), so far as the the child is concerned, is the opinion of other people (love, respect, approval, admiration, reward from others, trusting others rather than himself). Since others are so important and vital for the helpless baby and child, fear of losing them (as providers of safety, food, love, respect etc.) is a primal, terrifying danger. Therefore, the child, faced with a difficult choice between his own delight experiences and the experience of approval from others, must generally choose approval from others, and then handle his delight by repression or letting it die, or not noticing it or controlling it by will-power. In general, along with this will develop a disapproval of the delight experience, or shame and embarrassment and secretiveness about it, with finally, the inability even to experience it.

I think it was exactly this antagonism between the esteem of others (especially those in authority), and the allegiance to one’s own personal truth that led me to be so impressed by the calm self-reliance I saw among technologists before I joined their ranks. The development of the self, including a sense of self-competency, is seen as a compounding of ‘delight’ experiences, each developing upon the discoveries of the last, just like a mound of earth gradually growing as new layers of soil build upon the compacted layers below it. And this necessarily occurs through direct perception of the world, uncorrupted and unmediated by the perceptions and values of others.

And perhaps it was my perception of failure in this regard that pushed me in the direction of programming. My stunted ability to use my own eyes and ears; my ‘inability even to experience’ delight. It reminds me of this verse from Psalm 135:

The idols of the heathen are silver and gold, the work of men’s hands. They have mouths, but they speak not; eyes have they, but they see not;

Programming offered me a neat, deterministic microcosm in which to achieve a sense of control, mastery, and direct perception of the world that for some reason had eluded me thus far in my life. The newfound ability to trust my own judgement is what initiated a shift in my centre of gravity from others’ judgments (a state of high ‘self-monitoring’), to my own.

I found that what could be considered by some to be a cold, abstract discipline could be quite meaningful so long as I engaged in the ‘hypothesis testing’ approach I describe above. Knowledge about how a program (or indeed, anything) behaves is more memorable, has far greater salience and ‘delight’ when it is related to a prior hypothesis you have made. In this way, the art of manipulating text on a screen, though probably not ‘delightful’ for an infant, can become a vehicle for personal growth and confidence in an adult. It certainly was for me.

An ability to use your own eyes and brain to determine what you consider to be a ‘good software program’ can give rise to less ‘other-mediated’ beliefs about what constitutes a good life i.e. your values. Taking responsibility for what you consider to be True can extend to taking responsibility for what you consider to be Good. I find the ‘lifestyle design’ movement a great example of the growth mindset. It encourages you to ignore convention, to evaluate your style of living critically and adjust it according to what you have come to know about both yourself and your preferences, and allowing these learnings to influence the choices you make now and in the future.

I have one final thing to say on this topic. Central to Maslow’s theory, and the main impediment to growth as he sees it, is the fear of abandonment. In order to venture into the playground, the child needs to be sure that Mother is waiting, ready to be returned to. One more time from Maslow:

If the only way to maintain the self is to lose others, then the ordinary child will give up the self.

This passage would suggest that the ultimate trick for getting closer to what Emerson had in mind when he wrote Self-Reliance, is not for all of us to become programmers. That’s certainly not the message I want to leave you with in this post, although Steve Jobs apparently did recommend that. A feeling of self-competency can be achieved in all sorts of ways - programming just so happened to be my way. It’s more important, whilst on your journey, to remind yourself of one thing:

Your full, valid, irrevocable membership of the human family, with zero threat of expulsion.

It is this belief that allows you to go about your life without a sense of threat. It confers the ability to explore the unknown and give in to your innate spontaneity and the growth that naturally results, all with the assurance that:

You are not an outsider
Banishment is an impossibility

Armed with this belief, it becomes safe for a person to follow ‘that gleam of light which flashes across his mind from within’, to maintain the ‘independence of solitude’ in the midst of a crowd. I also think that this belief is strongly related to what we mean by ‘self-acceptance’ (but that’s for another time). As a daily affirmation, it can help free you from one of your deepest and most primal fears.

Try it. The results could be delightful.