Tag Archives: tech culture

Work

Is it worth speaking at conferences?

I have been reading Twitter more often recently due to Brexit and I came across this mini-controversy that resonated with me.

Should you talk at conferences?

No, it’s a lot of effort that could be better spent on achieving your goals.

Yes you should if you’re from an under-represented background you should because it gives you visibility that is useful for developing your career.

Yes because it’s helpful for consolidating your understanding of a topic.

I certainly recognise this one, until you have to explain something its hard to say to prove that you really understand rather than having a strong intuition as to how something works

Yes because otherwise conferences are all-white boozy brofests.

The interesting point here being the idea that inclusion inherently leads to a loss of prestige in an activity because exclusion and prestige are related.

My lived experience

I did do conference talks to help build my “personal brand”. When I worked at ThoughtWorks it did help my career to be able to point that I was involved in community activity. At Wazoku I did talks simply to make people aware of the company.

At the Guardian doing talks was also important for your career because talking about our work was important to the organisation. In my early years there people at recruitment events were surprised to discover the Guardian had a in-house development team. I’m not sure that is was necessarily expected of everyone but at a senior level it was certainly an important part of the job not just to do the technical work but to ensure people outside the building understood what as a group we were doing.

At GDS doing talks was a complete pain because you had to get clearance for everything you were going to say and also there were various rules about the type of events and the representation at the events you could speak at. The level of bureaucracy around something that was already by this point a bit of a chore meant that I did one prior commitment and then basically stopped doing technical talks.

Stepping out of the cycle of trying to create and pitch talks was great. I just bought my ticket to events like a normal person and it was interesting to look at what value conferences were providing to me.

Relapsing

Recently though I did try doing some talks again. One of them about pop psychology concepts that are wrong was a very personal hobby horse. I don’t want to attend another talk where someone talks about various brain types (neuro-diverse, left-right, female-male, emotional intelligence) so I thought I do a talk about what is currently known about the mind and psychology.

Preparing was easy as I just needed to record various interesting bits and pieces as I came across them. Giving the talk was intense though. After a while not doing this kind of thing, getting up in front of people and aiming to entertain and inform them was a crushing pressure. Proper hand-trembling, mouth-dry, stage terror stuff.

The feedback was generally positive and I thought that while it had been a baptism of fire I was going to get back in the swing of things.

The next talk was to help a friend get their conference going in the North of England. It related to work activity so again preparation was not too hard… until the venue organisers said they needed the talk in Powerpoint format, which is not a program I own. They also needed the talk slides a month in advance whereas normally I will only finalise my content a couple of days before I am due to give the talk.

But I went ahead and cut a version of the slide deck via Google Docs. Fortunately I prefer to try and talk around my presentations and not heavily use slides so I just needed to try and sort out my tentpole slides and submit those.

The talk was reasonably well-attended and I was able to get a few questions going rather than presenting slides (a third of the deck ended up not being used). I genuinely prefer the Q&A format to the normal talk format. I was gratified to hear my talk referenced by other speakers later in the conference. However later in a vote on the most popular talk, my talk came last. I’m not sure anyone voted for it. I knew I hadn’t really gone for an entertaining format but I hadn’t thought it was that bad.

Later in the year I gave another version of that same talk. This time cut down to a running time of 20 minutes which required two weeks of practice. I was able to reuse the slides from the abortive earlier version but they still needed heavy restructuring to fit the new shorter format.

The talk got very little feedback on its second outing, no-one walked out though, which is positive. After the event the conference feedback system provided a score of 3.5 out 4, which I feel might be good or at least some proof that some people found value in it or possibly only a handful of people provided feedback.

The talk came at a particularly busy business time of year workwise and I don’t think I’d volunteer to do such a thing again due to the pressure of having to manage both preparation and regular work things.

Is it worth giving talks?

Giving talks for “personal brand” is essentially about making yourself feel like a known quantity to other people in your industry who you want to influence or have good relationships with. That might be clients you want to sell to, people you may wish to hire or employers who might hire you.

The truth is you want to achieve this as simply as you can with as least effort expended on your part. Talks, unless you are good at extemporising off the cuff, are probably more effort than the value they return.

A lightning talk, well-executed, might well have the same effect as a longer, more involved talk.

Giving a talk about something you care about or what to change in your industry is almost certainly worth it. Although it is the same amount of work, putting together your thoughts and arguments has value to you even if no-one ever hears the talk.

Also to some extent I think passion talks are easier to deliver. You are not really trying to entertain the audience beyond establishing enough rapport to get your message heard.

In terms of career development though I don’t think talks and conferences ever really helped because I’m simply not a good enough networker.

Many people have said that they enjoy talking at conferences because the talk serves as an icebreaker for meeting and talking to new people (as long as it is early in the programme). That has definitely been true for me in the past, and I totally recognise how much easier people find it to talk to me when they can hook it onto something that I’ve presented about.

If you are that kind of extroverted introvert then doing talks makes attending the conference more enjoyable and it makes sense to put in the work they require. Although again you want to limit the amount of effort you put in because the outcome you want is facilitated by the talk but the talk is not the point. You are giving the talk to help you to meet new people and find it easier to build a relationship with them; that’s where the effort should be spent.

So should I still be giving talks? Well at this point I think they do consume more effort from me than say, writing this blog post.

In terms of community or career-opportunities getting into roundtable discussions and breakfast meetings with senior technical people has more impact than talking at conferences with a general developer audience.

But talking and engaging audiences is a skill and a hard one to acquire and maintaining it requires practice. Therefore I probably should keep my hand in, but I should try to choose topics that I feel excited about and I should think about the format and make sure the effort involved is proportionate.

I should also think about the nature of the conferences I am pitching to so that I have a decent chance of succeeding in the selection while having the greatest chance of actually enjoying attending the conference and learning something as a result.

It’s also important who else is attending due to the networking effect. Beginner-friendly conferences while valuable are not going to fulfil my needs.

Therefore I think talking at conferences is valuable but you need to understand what you’re trying to get out of it rather than pursuing it as an abstract good in itself.

Standard
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