Programming

After having checked our privilege, how shall we continue?

I’ve been privileged enough to go to a number of development conferences last year (2018). I know that I’m privileged because almost every conference had a talk or many talks making clear my privilege in attending them.

I have a job where attending conferences makes sense as part of my work and I make enough money to be able to buy my own tickets and pay for my travel and accommodation. I’m often able to combine attending a conference with catching up with friends and family. I have the ability to choose which conferences I attend based on whether they allow me to achieve other things I value in my life.

I’m lucky and well-placed in life, and if I was unaware of that then fortunately every conference will have a speaker willing to point that out to me. Sometimes for as long as an hour.

An hour that I’m not unaware that I have paid a lot of money for, an hour that I have chosen to spend listening to this talk instead of doing something that I might enjoy instead.

Often these conferences talks have no particular point they want to make beside how privileged people in tech are and how little we understand people outside our tech bubble. They have no clear or sensible strategy as to how to change what they regard as disagreeable.

Often they feel very unclear about what exactly is wrong with the privilege enjoyed by their audience. Perhaps eliminating it a worthy goal in itself.

Its certainly not clear what audience the speakers would be happy to address about the topics that might be related to the notional agenda of subject of the conference they are speaking at.

The vagaries of conference programming committee means that there will often be another talk taking about how difficult it is to be a programmer: how prone to stress and burnout we are and how we need to prioritise self-care.

We are self-absorbed and toxic, while also being fragile and in need of nurture. No talk has addressed this contradiction.

Topics such as privilege and the self-absorption of tech are potentially worthy subjects but at the end of a year, having heard variations of these talks many, many times I want to stop.

I’m happy to nurture my privilege checking and think about the technology needs of the emerging world while taking steps to create an inclusive workforce.

In return, what I would like from the conferences that I pay to attend is some attempt to deliver a programme that reflects the prospectus that is laid out when you buy a ticket to say a Javascript conference or a Python conference.

The minimum I would like to have is that in every timetable slot there is a strong technology talk that will be relevant to my work and interests, preferably something informative and provided by a technology practitioner.

If this can happen then I’ll feel as if attending the conference was a good thing in itself rather than the peg on which to hang the chance to visit places and people.

Standard
Programming

Why developers love the shiny

Developers are notorious neophiles who love adopting new technologies and designs. There is a natural bias between interest in working in emerging sectors and a general interest in novelty.

Technology as an industry also emphasises change and novelty as part of its identity with concepts like “disruption” and “innovation” being fundamental to the self-identity of the sector.

I also believe that developers are perversely incentivised to value the new over the established.

Perverse incentives

If you choose to learn an emerging language you have less history to deal with.

If you learn Java you have access to lambdas but you also have to deal with a decades worth of code that was written before lambdas were available. You’ll have to learn about interfaces, with and without implementations; inner classes; anonymous classes; dependency injection and inheritance.

If you choose to learn an emerging technology then chances are you won’t be told to RTFM as it won’t have been written yet.

Instead you’ll have the chance to interact with the technologies creators. If you make a mistake then it will be a learning experience not just for you but for the community as a whole. You’ll be united in your discovery and collaborators instead of an ignorant johnny-come-lately.

And if you learn emerging technologies you will find that conferences are eager to offer you a chance to talk about your experience. Employers will value your knowledge more than the people who added another year of experience with C#.

In every way you will find life easier and more enjoyable if you focus on emerging technology.

Falling out of love

Programmers are often like ardent lovers, in the first flush of their crush they see their new discovery as the answer to all their problems. They are evangelists and poets for their new discovery.

But over time familiarity replaces enchantment and soon we are all too aware of the flaws of tools and take for granted their utility.

Zac Tellman recently put this beautifully in a more general post about open source governance.

When our sense of possibility of what we can do with our tools is exceeded by our understanding of the constraints they have, we start to look elsewhere.

A mature legacy

Legacy is a funny word in technology. As has already been observed most of the time people are delighted to receive a legacy and the word generally has positive conotations.

For developers though the term is loaded with fear as what we are inheriting in the form of a legacy codebase is not a valuable treasure that is being handed down for safekeeping, to be enhanced and handed on to the next generation of stewards.

Instead the legacy codebase is seen as troublesome, an unwanted timebomb that is to be kept in some kind of running order and passed off to someone else as soon as possible.

Maintainers of legacy codebases are also unvalued by organisations. They are often seen as less skilled and less important than developers creating new systems. After all what they are doing is simply keeping a successful system running, they don’t need to use much imagination and they are dealing with solved problems.

Maintaining a legacy codebase often means being overlooked for promotion, pay rises or new opportunities.

In fact this view extends beyond developers, organisations do not tend to value their legacy codebases either. Product managers are equally incentivised to value the new over the old. If they add features to an existing system they are seen as less imaginative than those who create brand new systems or approaches to existing problems.

I have seen product managers deliberately sabotage legacy products so that the performance of the new solution looks better. Management often fails to look at the absolute performance of new system, just the relative numbers. People exploit that tendancy ruthlessly.

Love the new

There are more examples, however they might be better suited for dedicated blog posts in their own right. Overall though I hope I’ve illustrated that how as a profession we are encouraging people to jump on every bandwagon that is passing by.

I want to try and avoid passing a moral judgement on this. I too am a neophile, I too love novelty and would prefer to do something that I haven’t done before over perfecting my skills in a domain I know.

I just want to try and highlight the issue and move it from our unconscious to our conscious minds. Is this what we want for ourselves?

Should we rewarding maintainers of the software that pays our wages less than “rockstars” building prototypes?

Should we value simplification of our existing tools over maintaining backwards compatibility?

These are all inherently cultural issues, not technical ones. Currently we have a culture of novelty and literal innovation. I’m not sure how well it is serving us.

Standard