#ACCU2018 Day 1. From Gender Equality to (kinda-)Quantum Computing, with Threads and C++ copy/move in between

	Author:	“No Bugs” Hare  Follow:
	Job Title:	Sarcastic Architect
	Hobbies:	Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek

As #ACCU2018 is underway, and as I am here, it would be strange if I wouldn’t use the opportunity to tell about what I like (and don’t like ;-)) here.

Diversity in Tech – What Can We Do?

Gen Ashley was opening the conference with a keynote speech on “Diversity & Inclusivity in Tech”. Main point: we have way too few women in programming (to prove it, it was sufficient to look around).

What can be done about it – is a different story. In particular, I am not sure that I agree with Gen that educating specifically girls and women is “the way to go”; to me, it is more like trying to fix the problem after it has already happened, rather than to prevent it from happening in the first place. I can very easily be very wrong, but for me, trying to educate (all) children earlier, when they do not have this bias yet, would be a better and more sustainable solution (in particualr, it would be an approach which unites people, instead of differentiating them because of their gender).

OTOH, from my perspective this is NOT what I (or most of the developers around there for that matter) can realistically affect. As a down-to-earth person, I tried to look for those things which I can do while staying within my current job position, and managed to take out a few very simple things which we can (and SHOULD) do to make this field just a tiny bit better:

• let’s try to avoid bias at the working place. In other words, let’s treat all our fellow developers as equal, regardless of their gender. This means that a “compliment” of “oh, you’re doing extremely well… for a girl” is NOT a good thing (and yes, there are guys out there who think they’re making a compliment). We are all here for one simple thing – to develop software, so any kind of special treatment based on gender SHOULD NOT happen.¹
• let’s try to avoid unconscious bias when hiring. In this regard, I’ve learned of two simple but hopefully all-important techniques (which are more for HR, but well, some of us MIGHT be able to tell our HRs “what we want” – especially as it will go along their other tasks such as ensuring gender equality):
  • to have resumes anonymized before reviewing them
    • thinking aloud (was NOT mentioned in the keynote): in theory, we could even try to have the first phone interview anonymized – while being awkward, it might work in the long run (hint: for almost-every female name out there, there is a similarly-sounding male one, so we can try giving this “substitute” name to the over-the-phone interviewer, and to warn the woman-being-interviewed, about it in advance).
  • (was NOT mentioned during the keynote, but is mentioned here, and IMO looks reasonable):
    • have multiple people involved in the decision-making; not only they should tell who they prefer, but also why. While it is not a guarantee (there is always a chance of bias being systemic), it might help to reduce bias a little bit.
  • as for standardizing the hiring process (which was proposed as one of the ways to deal with bias) – I have to say am against it; not because I want to promote bias, but because any kind of formalism is incompatible with creative processes (see, for example, my article on it), and we do agree that software development is creative process, right?

Overall, I think it is long overdue that every one of us starts making small but important steps when doing things which are already doing (such as development, or hiring, etc. etc.). I do not want to go as far as saying that we should aim for any specific gender ratio (this is much more controversial, in particular, because according to Goodhart’s Law, at the very moment we start to aiming something, it ceases to be a metric); however, eliminating existing biases is certainly a Good Thing(tm) from any possible point of view. 

Multithreading and C++ copy/move

Then I went to “Designing multithreaded code for scalability” talk by Anthony Williams, and to “Nothing is better than copy or move” by Roger Orr. Coming from two top experts in their respective fields, both were great talks, with significant takeouts. My only complaint about Anthony’s talk was that it should have come with a big fat disclaimer in the very beginning: “If you’re writing app-level code, DON’T EVEN THINK about using any of this!” (I spoke to Anthony after the talk, and he said that he never thought that somebody will try to do it, so we don’t have any disagreements on this point). As for Roger’s talk – I cannot find anything to complain about, and trust me, I tried hard 😉 (seriously, when it is out on video – make sure to watch it).

Quantum Computing for C++ Devs? Well, not 100% so

The last talk I attended on Wednesday, was “A Quantum Data Structure For Classical Computers” by Charley Bay. It was quite an interesting talk, however, a word of caution:

• while it WAS a talk on the history of quantum computing (and quantum mechanics in general), and on very generic principles behind it,
• it WAS NOT a talk on “how to do practical quantum computing programming” in any way. This is not to say the talk should have included it, but is to say that if you’re looking for anything of practical value (beyond an understanding of the very very basics, such as “if you read your quantum state – some information in the state gets destroyed”) – it is not the talk you really want 🙁 .

Post-Mortem Debugging

My report of the 1st day of the ACCU2018 wouldn’t be complete if I don’t mention one of the sponsor’s exhibits which managed to impress me (it is not an easy feat, BTW 😉 ). I do NOT normally comment on sponsor’s exhibits (it would be too detrimental for most of the sponsors out there <sad-wink />), and no, I am not getting paid for mentioning them here, but this exhibit really stood out by being (IMNSHO) both clever and (potentially) useful.

I am speaking about the exhibit by Undo company. Their main idea is (a) to instrument your existing (compiled) program to be deterministic, (b) to record all the inputs (including returns from system calls and instructions such as RDTSC) into a log, and (c) to allow you replaying this log in the comfort of your own developer’s box – which run is guaranteed to exhibit exactly the same behaviour as it happened in production. In other words, we get not just a core dump (which usually contains memory which is FUBAR and therefore useless), but we can see which series of events has brought our system from normal state to crashed one.

Of course, the technology is not without its limitations, in particular:

• in many cases, you cannot possibly record all the history for years your program is running; it means that there is a chance that the problem has started to develop before that log we have. This is “toough luck”, but from my experience with similar systems – it is relatively rare.
• performance hit due to instrumentation. Depends on your code, but MAY lead to your code becoming unusable in production.
  • In particular, to ensure determinism – they serialize multithreading, so if your program is essentially multithreaded (opposed to being multithreaded only accidentally) – it is likely to have troubles.

BTW, if you noticed similarities with my own talk on ACCU2017 about determinism in (Re)Actors – it is because the principles behind are indeed the same; the main differences between the two are the following:

• (Re)Actor-based systems provide determinism from the very beginning; Undo tries to implement it as an afterthought (that’s not because THEM didn’t think about it in advance, but because WE as developers didn’t think about it in advance). And while I have deep sympathy for the hurdles Undo is facing, I have to say that I still strongly prefer to have determinism to be built into the system from the very behinning. OTOH, for existing non-(Re)Actor-based systems – Undo can happen to be just the ticket.
• the performance hit is inherently smaller for (Re)Actor-based determinism (at least because we do know about our threading model, and we do have the luxury to restrict system calls to those-absolutely-necessary).
• Overall:
  • if you have to run a serious existing distributed system (the one which was NOT developed with (Re)Actors in mind) – DO try Undo (while I cannot vouch whether they really work, they certainly look good enough to give them a try).
  • however, for NEW development – I still strongly suggest to go the route of deterministic (Re)Actors, which would provide all of this (almost-)for-free – and with TONS of other goodies too…

Phew, it was a long day – and there is another one coming. I hope to continue my reports from ACCU2018 tomorrow.