SPA Conference Report
Between the 2nd and 4th of July I attended the SPA Conference (Software in Practice). It was a great conference, with a lot of emphasis on practice – more workshops than talks and more interactive than passive. Audience participation was encouraged by default.
It was great to have the space and time to set aside for intentional practice within a supportive framework. A lot of conferences leave me with a flock of ideas fluttering around my head, but then I get sucked in the daily flow of things and never set aside the time to start practicing. Getting a head start with practice on the same day that the ideas are planted makes it more likely to have something to pick up later.
There were two sessions that made me choose this conference to begin with: “Typing isn’t the hard part – Developing a Culture of Pair Programming” and “Muddling through the Middle Bits – What comes after Junior but before Senior?”
The first sessions I attended were:
DAY 1
Writing slow regexp is easier than you think (and want it to be) – Maciej Rzasa
Outputs:
Exercises and references: https://regex-performance.github.io/exercises
Regexes are definitely one of my favourite hammers, so it was great to peek deeper behind the scenes and think about performance implications of their concrete implementations in various languages.
The practical parts went a bit too fast to digest it all – greedy matching, backtracking, repetition, and why they can lead to factorial increases in processing to the point of crashing a browser or even a CPU!
I hadn’t heard of Regex DDOSing – definitely something to be careful about when allowing users to input regexes.
How to hack your own apps! – Tanya Janca
I had a bit of a bumpy start – in order to use the full extent of the provided learning resources, the workshop required us to download them from a USB stick. This contravened our company policy, and since I was using my company laptop, I had to say no to the metaphorical plague rat being proffered!
I did follow along with running Zap, configuring it in the most useful way for our purposes, and interpreting the results.
Definitely, something to start doing as part of testing our own apps. Remember, always ask permission before attempting to hack someone’s app! Even if it’s your own team’s, and definitely inform your devops folks before you start scanning! 😀
This workshop deserved a bigger time slot, and alternative means of transferring a large amount of data… ;D
Pairing is one of the things I’m trying to get better at. By its very nature, one can’t get better at it on their own, so learning about it goes hand in hand with learning how to help others improve their pairing skills as well.
Asking for your needs and ensuring that your pair has their needs met, including but not limited to; accessibility, comfort, familiarity with editing tools, pace, and the level of questions asked. It’s also important to know what can be considered implied and what should be explicitly said (when in doubt, choose more communication!) When pairing with a junior or someone you don’t know very well, ask more and assume less. Once on the same page with someone, you can skip some steps.
Learning how to articulate while I’m thinking is not easy.
Ping-pong pairing
For the first session, we were meant to use the “ping-pong” style, where one person writes a test and the other one the code required to make the test pass, then the roles are swapped.
For the second one, we were encouraged to use the “strict” style, where one person is only allowed to explain their idea, in as much detail as the pair requires, but not to type any code, while the person typing is only allowed to type the code resulting from this interaction.
I noticed I have a tendency to run along with my ideas. I tried learning how to sit on my hands and define my ideas by verbalising them to my pair, until they could write the code I was thinking of. I also noticed my keyboard-grabbing tendencies – that’s okay: notice it, stop doing it, stay aware of it.
Physical comfort is something I’m acutely aware of. Having some non-obvious physical disabilities means I have to articulate my needs whenever pairing at someone else’s desk. This has also made me more mindful of other people’s needs. For example, I try to ensure that the theme colours that are comfortable for me are not uncomfortable for my pair. (There’s a difference between “aesthetic choice” and “eye-ache prevention”.)
We also discussed how much pairing is good pairing – there is, of course, no one true answer. Whether it’s because of neurological differences or personality differences, some of us would never benefit from or agree to, full time pairing. However, some objections such as “the delivery slows down” are mitigated long-term by better code quality, earlier catching of bugs, and spreading of knowledge.
Visit our blog next week to read more about Days 2 and 3.