Next up in the Wizard Zines set is an odd one, not being particularly technical, and I think one of the earlier ones: Help! I Have a Manager, which is all about building good relationships with your manager.
Like Julia, I’ve had several good or great managers, and a few not so much. I have found them all very different, so page 16, which is all about this, really resonated. Other than that, this was pretty much all advice I’d seen elsewhere and/or picked up naturally. For someone really early career, this might be worthwhile, but I’d skip it otherwise.
Unlike the other zines, this one (at least the PDFs, when viewed in Apple Books) had weird spacing issues where text had odd gaps and sometimes had overlaid characters. Not enough to prevent reading the zine, but enough that it doesn’t feel polished like the others.
As mentioned previously, I purchased the set of Wizard Zines via my annual training budget, and am working through them. Current reading: Bite Size Bash.
The first 20 pages surprised me – I don’t consider myself particularly knowledgeable in terms of bash (or similar shell scripting) but pretty much everything in the basics I’ve managed to somehow pick up over the last couple of decades, despite usually jumping pretty quickly into another tool whenever my needs get above simple. It is a great intro, though, and I would have benefited having this at hand years back.
On page 20, parameter expansion is introduced. Most of this was either new to me, or I think I’ve seen but certainly wouldn’t remember to use. I’m not sure how to make this stick, though – the syntax is so odd. Maybe I should just jump to this page next time I’m writing bash, or maybe I’ll remember that it can be done and that will be enough to look it up or remember. I do wonder if LLM will replace this sort of learned syntax, though.
After that, it was background processes and subshells, both of which were again surprisingly familiar. After that is trapping signals – I knew this could be done, but I’m pretty sure by the time I have something that needs to do this, I’ve already moved to another language, and I don’t see that changing. Errors and debugging were also mostly things I knew, except for ‘trap x DEBUG’, which seems pretty handy.
Overall, this zine surprised me: I expected to learn a lot, and instead recognised a lot. In some ways, this is great: I feel more confident that I do actually know the most useful core of shell scripting (even though certainly not the vast area beyond that). I’d definitely recommend it for shell scripting beginners (especially bash) but likely not for others.
As part of my training allowance for 2024, I purchased all 14 of Julia Evan‘s zines. There are definitely ones I expect to learn from more than others, but having the pack appealed, and one of the things I really enjoy about her posts is finding little tidbits of information that I didn’t know, even though I would have said I know the topic fairly well in general.
First up: Become a SELECT Star, which, as you’d guess from the title, is all about the SELECT statement in SQL. The first dozen pages are a really good summary of the fundamentals: things that I gradually absorbed over the last 20 or so years, and probably would have been better off with having a summary like this rather than a bunch of more traditional reference material.
I really like how the examples work through the query in the logical order rather than the syntax order. It makes it much simpler to follow what’s happening.
On pages 14-16, it covers window functions, which I didn’t really know at all. I would normally just do this by getting a bunch of the data down into something like Python and calculating there. I’m a big fan of moving computation left where possible, so these seems super useful, and something I hope I remember (although I don’t do a huge amount of SQL these days).
The zine continues on to cover NULL and COALESCE, which we used a lot at SpamExperts, so those were pretty familiar, but again a good summary that I could have used many years back! It then covers CASE, and I don’t remember if I knew that or not, but also don’t think I can think of times I would have wanted it directly in SQL.
After a straightforward page on counting rows, it moves into subqueries. I’ve used these quite often (I’ve often had situations where subquery performance was better than joining, for various reasons). However, common table expressions (naming sub queries) is new to me, and look super useful.
It wraps up with a few more useful tips, most of which were things I already knew.
I’d definitely recommend this to anyone that’s just starting with SQL. If you’re a SQL expert, it’s likely not going to be useful, but if you’re a casual querier like myself, then there are good tips to pick up, and given how small and inexpensive the zine is, I’d highly recommend picking it up.
Posting because I’ve hit this three times now and each time not remembered the solution until I figured it out again, in the hopes that writing it down will prompt my memory next time and avoid a fourth “figure it out fresh” cycle.
At work (in the team I’m on), we develop in the open using public Github repositories. To introduce a change, we fork the repo, create a branch, and submit pull requests to the upstream main branch.
As changes make their way into main, it’s handy to be branching off an up-to-date fork, and GitHub has a convenient “sync fork” tool in the web UI to do this. Most of the time, this works perfectly. Unfortunately, a few times I’ve tried to sync and it silently fails (the cause is user error, but the silent nature of the fail is very poor UX from GitHub, and I feel like they could actually make the whole process work, which would be ideal UX).
The reason it has failed (each time it has happened to me) is that branch protection is enabled for the main branch on the fork. I’ve enabled this to avoid accidentally pushing changes to main (forgetting to create a branch first), which I never want to do – except for pulling in upstream changes.
There might be a simpler way to work around this (other than opening a PR from upstream main to the fork main) but I just disable the protection, sync, then enable it again.
This is a copy of the feedback I provided to Mahurangi College in response to this consultation request:
The Government has introduced regulations that require all state schools to have student phone rules in use. Rules must be in use as soon as possible in Term 1 2024 and no later than Term 2.
Many countries around the world have successfully banned mobile phones in classrooms, or are in the process of doing so. A solid body of evidence is emerging that supports the banning of phones in schools.
Our draft policy and notes are included here, as well as a space for you to provide some feedback.
So far this term our approach has been to educate – students have had the rules clearly explained, and lots of reminders and warnings have been given. The vast majority of students have adapted very well.
Following your feedback, we will finalise and publish our final policy.
Mahurangi College, February 2024
I understand that the requirement to have a policy has come from the central government, which puts some constraints on what the school can do. However, I had hope that the school would show more courage and defy poor decision making as much as possible. Given that ERO is responsible for monitoring the implementation of these policies, at worst the school would receive a negative comment in a rarely-read review, and by the time the next review cycle came around, it’s likely that a government less interested in pandering to racist, anti-science, scared, old people would be in power.
Any form of defiance would suffice, but I like following the letter of the regulation rather than the intent. The iPhone is famously “an iPod, a phone, and an Internet communicator”, and Android phones are widely recognised as being functionally equivalent to iPhones. Students must not be allowed to use or access a phone – but there are no rules about iPods or internet communicators. The answer is clearly that the Phone app on mobile devices must be banned, but using the rest of the device is fine (you could even use a device management profile to disable the Phone app while at school).
This is logically consistent, since students are not only allowed but expected to have other digital devices (such as a laptop), which has exactly the same internet communication functionality (indeed: the permitted smart watches, laptops, tablets, and other devices are essentially the same device as a phone – often running variants of the same operating system on the same chips – just in a different form factor).
Under no circumstances should phones be used to photograph or film any student or member of staff without their permission, or to film any fights or skirmishes.
Mahurangi College Draft Policy
For the record, I have no objection to this as a policy statement, although I would suggest that it’s mistakenly placed in a “mobile phone” policy, given that there are many other devices (and a class that is specifically focused on learning how to use them well) that are capable of photographing or filming a student, and the choice of device is entirely irrelevant.
Headphones & earbuds also cannot be used at school (apart from on buses) as they require connection to a mobile phone.
Mahurangi College Draft Policy
It’s hard to believe that this passed any sort of quality control. Did you have a junior student write it? I would expect that anyone old enough to work at the school would be familiar with a multitude of devices with which headphones (whether in earbud form or otherwise) can be used. Perhaps the staff might remember using headphones with a record player, Walkman, or Discman? Perhaps some of the staff are familiar with the school’s own requirement that students do have headphones so that they can consume media during class without disturbing other students? Was the author of this policy aware that the school offers classes in music, dance, and media studies, and that film is studied in many of the English classes? Did they know that the laptops that the school requires students have almost universally work with headphones? Given the conflicting policies, which one wins out?
Perhaps you’d consider looking at the actual science? For example, a 2023 study that showed that students using smartphones outperformed those without (Wang, J.C., Hsieh, CY. & Kung, SH. The impact of smartphone use on learning effectiveness: A case study of primary school students. Educ Inf Technol28, 6287–6320 (2023). https://doi.org/10.1007/s10639-022-11430-9), or the Harvard Graduate School of Education who say that more thought needs to be applied rather than simple bans. Closer to home, Massey University educators clearly state that bans are not the right choice. Or look at meta-studies (for example: Calderón-Garrido, Diego & Ramos-Pardo, Francisco & Suárez-Guerrero, C.. (2022). The Use of Mobile Phones in Classrooms: A Systematic Review. International Journal of Emerging Technologies in Learning (iJET). 17. 194-209. 10.3991/ijet.v17i06.29181), which show benefits in the use of phones at school.
It should be obvious that the ability to have at hand a device that is a calculator, a compass, an e-book reader, a still and video camera, a research tool that would be considered magical even a few decades ago that provides access to nearly all the world’s information, that tracks and provides advice for improvement of health, a torch, a measuring tape, a glimpse into virtual and augmented reality, that receives emergency alerts, and much more is of huge value to a student. Instead of harming their educational development (and providing an environment irrationally different from the world they will enter at the conclusion of secondary school) you should be figuring out ways to make sure that those students who do not have phones are able to use one.
I have no objection to behaviour management, whether during class time or during breaks on the school property or on school trips. If someone is misusing a phone – or anything else – in a way that disrupts their or other students’ learning, then that should be remedied appropriately.
I’m also tolerant of prohibiting access to specific internet properties (TikTok, Instagram, Snapchat, and so on), although I do believe that in time prohibition will be demonstrated to a poor approach to the problems that these sites exacerbate.
I have no hope at all that the school will reconsider this policy (although a little hope that someone will realise that headphones can be used with devices other than phones), particularly given the numerous other policies that are clearly either anti-learning or irrelevant to learning. However, I offer this feedback anyway, so that at least you will have heard how wrong you are.
At work, our book club is reading Code Complete, and had our first discussion session today. I first read this in early 2011 – roughly 6 years into professional software development – and remember thinking quite positively of it at the time. We’re only three chapters in, but I’m decidedly more mixed on it this time around – I’ve had a lot more varied experience with development projects than in those early years, and a lot of the book lands quite differently (I do suspect that the later chapters will have stood the test of time better).
The second chapter of the book is focused on the importance of choosing a metaphor for software development – it ends strongly suggesting that building construction is an elegant metaphor. I agree that metaphor can be useful (but is also easily overused, and people get fixated with the imperfection of the chosen metaphor – “But if you extend them too far or in the wrong direction, they’ll mislead you”, as the author says) and that construction can work as one for software development.
However, the author, says:
For an individual’s work or for small-scale projects, the letter-writing metaphor works adequately, but for other purposes it leaves the party early—it doesn’t describe software development fully or adequately.
Steve McConnell, Code Complete, Chapter 2 “Software Penmanship: Writing Code”
This struck me as deeply ironic. Writing is an excellent metaphor for software development, and the author of a book – especially a large technical one – should be extremely aware of this.
The author seems to only consider the analogy of the metaphor to be of “writing a casual letter”, rather than writing in general. This is unfair to the metaphor and not applied to that of construction (which covers all sizes, not just flat-pack assembly). Writing ranges from a succinct social media post to a collection of textbooks or connected story that ranges over dozens over books by multiple authors (Wild Cards, Cosmere, Marvel, Riftwar, to name a few). This is hardly unique to writing – construction, farming, and other metaphors the chapter explore all range in sizes.
Writing is usually a one-person activity, whereas a software project will most likely involve many people with many different responsibilities.
Steve McConnell, Code Complete, Chapter 2
This quote was particularly interesting, as one of my colleagues brought it up in our discussion as an example of how McConnell was correct about writing being a poor metaphor, whereas I read it as an example of how wrong he was.
The “many people with many different responsibilities” absolutely applies to (non letter!) writing – you have editors, alpha and beta readers, illustrators, publicists, and many more. A lot of these work well in the software development metaphor – early readers are code reviewers, illustrators are designers, publicists are, well, publicists, and so on. This is the aspect that I was focused on when I read it.
My colleague, however, saw the truth in the “one-person activity”. It’s true that a lot of writing is done by one person. There are a lot of examples where this is not the case (co-authoring, anthologies, shared universes, ghostwriting, a lot of journalism, etc), but it’s probably safe to say that there’s less cowriting (particularly of the same block of text, however you define “block”) in code than other writing. I think where we differ is that I see this as one area where the metaphor is weak, but the rest is so strong that it outweighs that.
I also do suspect that that there’s an awful lot of software that is written by a single person. This isn’t just sole-developer products, but also components of large, multi-person, systems where there’s a single person that does nearly all the writing and maintenance of that one component (or module or library or micro-service or …). This isn’t good software development, but in my experience it is, unfortunately, fairly common. Often there are other people involved, but only lightly, in the same way that an editor or sub-editor might be with other writing.
In writing, a high premium is placed on originality. In software construction, trying to create truly original work is often less effective than focusing on the reuse of design ideas, code, and test cases from previous projects.
Steve McConnell, Code Complete, Chapter 2
I’m not sure that originality is that much of a premium in letter writing – but then I never did much of that. More broadly, originality has a “premium” in some forms of writing, but not in others – people are generally looking for the same broad style in a new romance novel, they find it easiest to read news articles that are structured in the same way, the latest Reacher novel is not that different from the previous one (or the last Will Robie, or the last Alex Cross, and so on)1.
There’s a concept in software development that you get three “innovation tokens”. Similarly, when writing a novel or series of novels, you can have a truly original character, or world, or plot, or theme, but you almost always need to have the majority of the work be fairly familiar to the reader (particularly a reader who is familiar with the genre). Just as with software development, you can go wild with innovation and originality, but it’s high risk and makes it harder for readers/users.
When you finish writing a letter, you stuff it into an envelope and mail it. You can’t change it anymore, and for all intents and purposes it’s complete.
Steve McConnell, Code Complete, Chapter 2
This is true of a letter, but untrue of most modern writing. Pushing the irony more, this is a quote from the second edition of Code Complete. Writing that ends up in print often is in a final form – but there’s also a lot of software out there that just runs without any updates.
To be fair to McConnell, 30 years ago there was a lot less revision of writing – no editing Wikipedia, pushing out ebook updates, rapidly revised news articles, or tweaked blog posts. On the other hand, there was also a lot of “finalised” software back then too, where you’d buy a box with a disk or cartridge and, unless you did buy an updated version, you’d have that same version forever.
But extending the metaphor of “writing” software to a plan to throw one away is poor advice for software development, where a major system already costs as much as a 10-story office building or an ocean liner.
Steve McConnell, Code Complete, Chapter 2
I’m very much in favour of a reasonable level of well-executed planning and design, but beginning a software project without being willing to throw away any dead ends would strike me as a huge red flag. Defining the role of a software architect is complicated (see also this great Charity Majors post) but I maintain that the core task of an architect is working with people to minimise the number of decisions that are regretted in the future. That might be a wonderful design where almost nothing is thrown away. It might also be settings things up so that throwing things away is inexpensive and experimentation leads to market success.
I’d argue that with the really huge projects, we have plenty of examples (Novopay, INCIS, and others just in Aotearoa New Zealand) that show that big upfront planning with a reluctance to throw anything away leads to terrible cost overruns and missed deadlines.
Building software implies various stages of planning, preparation, and execution that vary in kind and degree depending on what’s being built.
Steve McConnell, Code Complete, Chapter 2
This is exactly what writing is like. Just like when writing a small “throw-away” software script, almost no planning goes into a social media post. When writing a novel, there’s a huge amount of planning, preparation, and execution (here’s a series going into it from one author – there are many, many, others – books on how to write books are almost as common as podcasts about making podcasts!). I find it difficult to believe that this was not the case for writing Code Complete itself.
McConnell extends that argument to compare the cost of making a mistake on a small project with one on a large project (ignoring any learning that may have come from making the mistake) – this equally applies in writing. If I end up rewriting a section of a blog post, that’s fairly trivial. If I have to restructure the entire third act of a novel, that’s a bigger issue, and if I have already finished two books in a trilogy and need to make changes to them to make the final volume complete, that’s very expensive to fix.
In building a house, you won’t try to build things you can buy already built. You’ll buy a washer and dryer, dishwasher, refrigerator, and freezer. Unless you’re a mechanical wizard, you won’t consider building them yourself. You’ll also buy prefabricated cabinets, counters, windows, doors, and bathroom fixtures. If you’re building a software system, you’ll do the same thing. You’ll make extensive use of high-level language features rather than writing your own operating-system-level code.
Steve McConnell, Code Complete, Chapter 2
When writing a novel, you don’t start from first principles. You’ll probably have a three-act structure, your story probably fits – at least somewhat – into one of seven basic plots, and you’ll build on top of whatever tropes are appropriate to the world you’re writing about. You don’t need to explain enemies-to-lovers or the misdirects in a mystery story, and you can call your Hobbits “halflings” and most readers will immediately have the right characteristics to mind. Just as in McConnell’s example of luxury housing having some of these fittings custom-made, the highest quality novels often deviate from the norms in a few specific areas (an imaginative magic system, a innovative take on local history, an unusual prediction about the future, and so on).
Finally, the construction analogy provides insight into extremely large software projects. … [Builders] build in margins of safety; it’s better to pay 10 percent more for stronger material than to have a skyscraper fall over. A great deal of attention is paid to timing. When the Empire State Building was built, each delivery truck had a 15-minute margin in which to make its delivery. If a truck wasn’t in place at the right time, the whole project was delayed.
Steve McConnell, Code Complete, Chapter 2
Cost and timing are important in extremely large writing projects too. Delays in editing or proofing or illustration or printing or many other things can delay an entire book launch (the Potter books have apparently reached nearly US$8B in sales, the Empire State Building cost under US$1B to build, adjusted for inflation). When a book is very high profile, it’s worth spending extra to have additional early readers and editors, just as you build with stronger material (obviously an unsuccessful book is less significant than a collapsing building).
Overall, I do agree with some of the core takeaways of the second chapter – that there’s value in metaphor, that they are “a little sloppy”, and that you should use the best (mix) of metaphors that work in the context. I just can’t agree that construction is a better metaphor for writing code than writing (non-code) is.
This chapter might have hit the sweet spot for me – the combination of reading/writing and software development – but I’m hopeful that the upcoming ones will also be as thought-provoking and enjoyable to discuss with my colleagues. If you don’t have a work book club, I highly recommend starting one! (Non-work book clubs are great too!).
To be clear: I really enjoy a good romance novel and all of the book series listed there. The familiarity has the same comfort as a good TV procedural or film sequel. ↩︎
I renewed my driver’s license last week (having turned 45 recently) and it was striking how different the experience was to the other common government-issued identification: a passport. New Zealand’s passport service, Te Mata Uruwhenua, (run by Te Tari Taiwhenua the Department of Internal Affairs) is remarkably efficient – everything from the application process through to delivery is handled extremely well. They promise reasonable process times, and almost always better them.
Last Friday, on the other hand, despite arriving less than 15 minutes after they opened, I had a 30 minute wait for someone to spend less than five minutes reviewing a form, take a photo, and provide an image of a signature.
There are a lot of flaws in the system, such as:
Why not have the form available online? Presumably someone is going to be entering the relevant details into a digital system anyway. The passport renewal process is entirely digital.
What benefit is there in requiring physical possession of the expiring license? They have all this data in the system, obviously, so if they wanted to check that I looked like the 10-year-old photo, they have that already. No-one checked my signature. Having the card doesn’t prove identity – I could have picked it up off the street. I didn’t have to go anywhere or show my old passport to renew it. Sadly, an elderly lady in front of me in the queue, who had travelled almost an hour to get there, had forgotten her old license and had to get rejected at the counter.
Why take the photo there rather than just providing one? That works for passports, where the requirements are much more strict. This could easily be part of the submission process.
I’m not particularly convinced that the written signature provides much value, but even if it’s needed, this is done on some sort of digital system anyway, so could also easily be done as part of a submission.
My expiring license was invalidated (it had about 6 weeks left) and replaced with a paper temporary license that lasts for 3 weeks (which will be tight to get the new one in the post, but that’s a separate rural post issue). Why not just leave me with the old one until the new one arrives?
Why is someone manually checking a form anyway? The address checks were making sure they matched the ones on file (both inaccurate anyway, with the regular address wrongly including the rural delivery number, and the mailing one not matching the form NZ Post likes), which is trivially automated. The other details would similarly be simple to check by a system.
It’s strange to have one service work so well and one so poorly but easily improved. Can’t we just loan some people from Te Mata Uruwhenua to Waka Kotahi NZTA to get things improved?
People (at lunch) at Kiwi PyCon were praising ChatGPT as a tool to help write code more efficiently, so I had another go.
I recently moved a Django project to use Whitenoise, and more specifically to have manifest files, where the version is appended to the collected file names. This all works great, except that there are a few files that users download, and instead of getting, for example, template.xlsx, they were getting template.{md5hash}.xlsx.
To be fair, it then did give the correct answer, that the download attribute of the a tag should be used. So I guess I’d give this a B- grade, for getting the solution but confusing it with a bunch of irrelevant info first.
I don’t particularly love this (although I do feel you should match the style of an existing code base and should avoid changes that don’t meet a reasonable level of value-add). I would generally leave out the else (and dedent the second return). It seemed likely that these generate the same opcodes so this is purely about readability, but it was worth checking that:
Interestingly, there is one difference out of those four variants, where instead of a second RETURN_VALUE op, there’s a JUMP_FORWARD to the single RETURN_VALUE. I assume that means that it’s slower in a way that’s so imperceptible that it’s not worth caring about, but let’s check:
>>> timeit.Timer("f(random.random())", setup="import random\ndef f(x): 'a' if x > 0.5 else 'b'").timeit(10000000)
1.4031157046556473
>>> timeit.Timer("f(random.random())", setup="import random\ndef f(x):\n if x > 0.5:\n return 'a'\n else:\n return 'b'").timeit(10000000)
1.326032117009163
I feel this does land in the expected place, where it’s about style & readability. I suppose f1() explicitly shows that it’s making a choice between two cases, but I feel that’s countered by f2() and f3() showing that the function returns a value. In general, it’s nice to have the smallest amount of indentation, so I would not choose to use f1().
Between f2() and f3(), I would generally choose the single-line approach of f3() if the line didn’t wrap (or exceed whatever the wrapping length is for the project, e.g. 100 characters). I would not do this:
def f3_alt():
return (
really_really_really_really_really_really_really_long_val
if another_very_very_very_very_long_condition
else also_quite_long_here_and_now_we_wrap
)
If you’re doing this, then there’s no benefit over the f2() style (and, as it turns out, there is a very tiny performance penalty).
Python has an implicit return None at the end of a method that doesn’t otherwise return. This means that for this specific case, where one of the values is None, there’s also the choice between f2() and f4(). In reality, f4() would be slightly better than it is here, in that it would probably have a return type (with |None) and a docstring that explains that None is a possible return value. However, I still (weakly) prefer f2() where it’s called out explicitly rather than f4() where you need to know that this is what Python does.
Kiwi PyCon had two days of scheduled talks followed by one day of lighting talks and unconference sessions, held over a Friday plus weekend in mid September in Waihōpai Invercargill. I’ve attended Kiwi PyCon once before, but ten years ago.
The talks were almost all at a beginner level, with a few reaching intermediate. I would have preferred a mix with at least a couple at a more expert level. Some were well done but even for novice level talks not all were great quality.
I thought these talks were good (details below):
Moving from unittest to pytest
A practical guide to using OpenTelemetry in Python
Using React as a template language in Flask
DuckDB: Supercharging Your Data Crunching
Sometimes this is a pipe, or close enough
You’re Doing Great! The underappreciated art of appreciation
Automating Victory: Beating browser games with accessible Python
Building Kubernetes Operators with Python and Kopf
Several lightning talks
The venue was good, and the conference was generally well organised (despite several hurdles), although had significant microphone issues. There was minimal organisation of any social activity (just a quiz night), although obviously the usual meal break socialising took place. There were strong anti-COVID meaasures in place, and a lot of work on diversity & inclusion (but not great gender/ethnic diversity of speakers). They have a good Code of Conduct, but ruined that by ignoring it.
I’m glad I attended for non-conference reasons (the surrounding travel and an induction session I tacked on), and to re-evaluate my opinion of the conference. However, I can’t recommend attending it, unless you’re very early in your Python journey, or are attending strictly for the socialising/networking aspect.
Note that for the last 14 years, Kiwi Pycon has moved around AoNZ (normally alternating between the north and south) but from 2024 will be permanently held in Wellington.
This was the second time I’ve attended Kiwi Pycon (the first was 10 years ago in Auckland), and the first time I’ve travelled for one.
I re-read my notes from attending in 2013 and my recollections of being underwhelmed seem accurate. A lot of this is that conferences in general aren’t that appealing to me (much of the value is in the social aspect and that is extremely unappealing for me, particularly attending solo), rather than anything specific to Kiwi PyCon. This is one of the reasons that I haven’t attended one since, but it’s also partly typically on dates that are personally difficult (close to my son’s birthday, right at the end of the sports season, not coinciding with school holidays or any other natural holiday point). Working more on the product side in the last few years also made it a more difficult sell, although I’m pretty sure I could have managed (or just taken personal time) if I had felt it would be worth it.
(I see that all the links in that post to the schedule are, sadly, now invalid, although the wayback machine appears to have them.)
This year, when I initially decided to attend, I wasn’t sure what I would be doing in September – I knew I would not be with N-able any more, but I didn’t know at that point that I’d have started with Canonical. There was some risk, since asking for time off just after starting a job isn’t a straightforward proposition, but the ticket was inexpensive and I held off booking accomodation and travel until after I’d accepted the offer from Canonical and discussed attending with the hiring lead and hiring manager in advance of actually starting.
(Canonical has a really great policy around travel to relevant Conferences, so even though I’m only just finishing up my second week, I didn’t need to use up my brand-new leave allotment to attend, and probably could have even claimed some of the cost (I felt that wasn’t necessary, since I made the decision to attend prior to even applying at Canonical)).
Last time, I wrote up my experience in prose; this time it’s more bullet-pointed – I’m not sure what that says about how I have changed over the last decade 😀
The conference is more polished than (what I recall of) the last time, which you’d expect being the 12th iteration (Auckland was maybe 4th or 5th?), although it was still pretty good in 2013. In my post at the time, I wrote a lot about how inaccurate I thought the “intended audience” labels were. Interestingly, those do not exist now (I’m not sure for how long). I wonder if that was because of the accuracy issues, or for other reasons. I do think a label (if accurate against some fairly agreed scale) does provide value.
(Amusingly, in 2013 I was keen on being able to attend virtually. That’s very dated now, given both the rise of streaming and making video available and then also the last few COVID years).
(Also amusingly: I applied for a position with Kraken earlier in the year, and literally never heard anything back, not even a “thanks but you’re not what we’re after”. So while they had a lot of cute swag on offer, I recommend against applying to work for them).
Friday was more lightly attended than Saturday. I assume this must be people that can’t/don’t want to arrange time off a Monday-Friday job, but can/will do a weekend. It’s interesting because I would much rather have the entire conference during the Monday-Friday period and ‘save’ my weekend (even if I was using a general leave allowance rather than conference leave). Sunday morning was the lightest of all (at least the half I was there for) – probably to be expected given that it was the unstructured part of the conference.
Single track: no need to choose which talks to attend, no awkward talks with minimal attenance, no distractions from people moving from room to room (particularly when tracks get out of timing sync)
Less Good
Waihōpai Invercargill seems like a nice place, but it’s not just far away from the rest of the world, it’s far from pretty much all of AoNZ (intestingly this is changing from 2024 – more on that below) – bad weather can happen anywhere, but this was extra noticeable at the end of the conference when many people got stuck after flights were cancelled and diverted
Single track: some talks are very basic, and it’s awkward to skip
Not a very diverse group of speakers (in terms of gender & ethnicity), with quite a lot from sponsoring organisations
Whoever was doing the AV was very impatient with the speakers and spoke condescendingly and briskly to them – some people are giving a talk for the first time or inexperienced with mics, and it doesn’t take much effort to be patient and a bit kind
Poor mic’ing
The Saturday start almost clashed with the second pool game for the All Blacks in the men’s Rugby World Cup 2023 (I left my room less than a minute after the final whistle, walked through to the main room, and arrived 2 minutes before the opening). Maybe the expectation is that the percentage of people wanting to watch a rugby game is lower at a Python conference than for the wider population, and that this wasn’t likely to be an amazing match, given the history, but this is AoNZ, and it’s the All Blacks, and it’s a World Cup game. There was a Slack ‘#rug-py-con’ channel but there was only two of us there – some sort of communal viewing and starting 30m later would have been nice (there was also a critical Warriors game on the Saturday, with kick-off was 30 minutes after the end of the day’s sessions, so I suppose shifting to be a little later would have hit that)
Bad
Good CoC, social/employment stickets, etc. But the CoC was ignored!
The CoC is a bit messy (it’s confused about what colour t-shirts people will be wearing, and I don’t believe there was a phone number offered as it says) but generally ok. However, I reached out to the CoC team via the provided email, and never received any response at all. It was a minor issue (although from an influential person) but if they ignore reports that are minor, I have to assume they ignore everything. A “thanks for your report – we don’t agree this is a CoC breach, but please discuss more if you wish” type response would have been sufficient, but complete silence is unacceptable.
There are many possible reasons:
Deliberating ignoring messages – this seems very unlikely
Ignoring this specific message because it didn’t seem important – this seems possible, and if so it’s not ok
Ignoring this specific message because of who the subject was – this seems possible, and if so it’s not ok
Getting distracted with the conference and forgetting about the safety channels – this seems most likely to me, and if so it’s maybe the least bad, but still not ok
The best action I could take would be to volunteer to help in 2024 and ensure that it was handled better. If I was considering attending then I would do this. However, since I’m not, I have to recommend that unless you are willing to do this yourself, or unless the organisers publicly address the shortcomings and how they will fix them, you don’t attend.
Value
(For reference, attending Kiwi Pycon 2013 cost me around $400 ($509 in 2013 dollars, although I had no accomodation costs since I lived locally).
My travel was a bit indirect – I took the opportunity to spend 3 days in Christchurch with my new colleague & manager Ben on my way, so flew to Christchurch, then flew to Invercargill the day before the conference (those 3 days were really great). Rather than immediately flying home, I took up a kind offer from Bernie to drive me to Queenstown (checking off another one of the scenic AoNZ drives I had on my list) and stayed a night there before flying home from Queenstown. Canonical kindly paid for my flight from Christchurch to Invercargill (approximately the delta of going directly) as well as some of my accomodation cost in Christchurch.
Flights: $650 (I actually have a lot of AirNZ credit to consume, so in some ways this was ‘free’, and also meant I didn’t take much care in selecting cheaper flights)
Accomodation: $510 (I paid for a nice room; not really necessary given how much it was used, but since I was paying rather than a company I figured I might as well)
Food: $31.50 (dinner Thursday), $24.50 (breakfast Friday), $31 (dinner Friday), $24.50 (breakfast Saturday), $33.20 (dinner Saturday), $24.50 (breakfast Sunday). Morning/afternoon tea and lunch were included with the conference ticket, although I generally skipped morning & afternoon tea (if I was being cost-conscious, I would have skipped buying breakfast and eaten the included food instead). I ate from the restaurant at the accomodation (Thursday it was too late in the evening to be trying to find something else, and Friday I was too tired to bother and the weather wasn’t great) – I’m sure I could have found much better value meals elsewhere
Airport travel: none in Invercargill (courtesy shuttle when arriving, a lift from a friend when departing); I drove to/from the Auckland Airport, roughly 80km/75min (it would take 30 minutes to drive to the closest PT, and I would have multiple transfers, so it’s not particularly viable, unfortunately) – at IRD rates this would be roughly $150; parking at Auckland Airport $107 (this is cheaper than having someone drop me off and pick me up, as well as being considerably more convenient); I was given a lift to Queenstown Airport
Ticket: $296 (early pricing, including a t-shirt – late was $330 plus ~$70 for a shirt)
In total, approximtely: $1,890 (note that this was entirely a personal expense, not paid by Canonical or anyone else)
Conference swag: t-shirt (included in early ticket purpose price); socks & a mini octopus plush, and a large octopus plush (from Octopus Energy); a “gentle steam eye mask” (Japan has such weird cool things that we don’t have!), foldable hand fan, ‘erasable’ pen, and screen & keyboard cleaning tool from Hennge; a small booklet about Te Reo & one promoting Waihōpai Invercargill & Murihiku Southland; post-its and note paper from Hype & Dexter; (cheap) pens from Google; assorted stickers; and a pack of COVID RATs & a mask (not really swag – intended to replace the ones used getting to the conference, although I ended up 5 RATs ahead and 2 masks down).
Venue
As a hotel, the venue was nice – perhaps a little dated, and not amazing, but certainly comfortable. My room had two nicely sized desks, a comfortable bed, and plenty of space. The conference room was large and looked nice, and was generally well set up. The food (both conference and food service) was average at best.
The mic’ing setup was very problematic (surprisingly poor for 2023). There were considerable issues with the signal dropping out (to a receiver that was a few meters away, so definitely should not have been the case), almost always a light echo, and several talks where it was even worse. I’m not sure how this will turn out in the videos.
Session Summaries
Opening 0907-0920
Started 7 minutes late 😦
Paired experienced (Tom) and inexperienced (Jordan?) MCs (and also throughout the conference) – good sustainability/training approach
Conference Director (Carlos) got sick 2 days before the event, so taken over by a new volunteer (who is volunteering at a conference for the first time) at that point!
spaceops is one of the conference sponsors (presumably that came with this speaking opportunity)
Nice tying of space to the (Earth) environment (and environmentalism, climate, etc)
Bit of general space history, NZ space history (William Pickering onwards through to Rocket Lab etc)
Covered what spaceops do (owned by local govt, indirectly), and so forth, tangentially related to dev (they have devs, but only offhand mentions)
Good speaker
Several oblique references to Apple 🙂
Some talk about the Warkworth satellite station (very close to where I live)
Very good introduction to space (particularly radio & space) and particularly where AoNZ and especially Southland fit into that picture
Nice ‘soft’ introduction to the conference with a talk generally interesting for people who are into science, without delving deep into technical details
Essentially an introduction to an opinionated way to handle (project-local) module/package imports
Very introductory (for example, I would expect everyone @ Canonical would already know this and/or have their own opinions on it)
Argues against using relative imports (seems counter to my experience where absolute runs into collisions with paths, like collisions)
Core is an argument that everything should be “import core.module.submodule” where ‘core’ is the top-level code folder
Grant feels that the issue that that existing documentation on this is generally outdated, unclear, or delves deeply into internals instead of giving a “how to”
Good speaker
Unfair comparison with his talk in 2013: I don’t remember the 2013 one in great detail, and my notes on it are minimal, but I believe I liked this one more
Interesting note: prior to his Python work, worked in social sciences on interesting topics like alcohol and gambling issues. All the papers seem locked away (as academic papers often are, sadly).
Moving from unittest to pytest, Tim Penhey (Stacklet) 1021-1200
Had the same realisation as I did (in the shuttle ride to the accomodation) that some of the younger people may have been born after we started using Python!
Talked about initial dislike of pytest because of the implicit magic (conftest.py, and fixture naming matching) (agreed!)
Not entirely convincing arguments about why he changed his mind – basically this came down to “the good outweighed the bad”, which I suppose is also where I have landed, but it seems like you could have most of the good without having to have all the magic. Maybe there’s some other testing framework that does that, although it seems like everyone is standardising on pytest (for these use cases, rather than others like Hypothesis, Playwright or Robot)
Nice examples from real-world (slightly simplified) code unittest->pytest
Several examples of fixtures from real-world code that they find useful (lots of composition)
Medium level, expects understanding of non-trivial code, but would all be known to anyone that knows pytest moderately well (aimed more at people familir with unittest and not familiar with pytest)
Very good speaker
Interesting note: previously worked for Canonical (on Launchpad)
Automate business processes for all your companies with Odoo, Danny Adair & Graeme Gellatly (Roofing Industries) 1333-1417
Automating business process (from a roofing material company, not a software company)
Graeme is from the business side, Danny is the tech side (he was core to the early Kiwi PyCons, started NZPUG, etc)
Considerable amount of LoB automation (seems like a huge amount for a roofing supplies company, but perhaps that’s just ignorance on my side). For example, email comes from supplier with an invoice attached, automatically extract that, match to a purchase order, raise issues if there are differences, otherwise automatically approve an pay, with no human involved
A “this is a tool we use and really love and this is why” talk
General introduction to Odoo and how it’s used
Deep dive into the way that you customise Odoo, with a system that builds classes (and figured out a MRO) on the fly. Interesting, although complex (in implementation, but simple to actually use)
Interesting talk, although not sure that it was to the right audience?
Good speakers, handled the dual speaking well
Some mic issues 😦
Interesting note (Danny): Event Director for Kiwi Pycon 2013, when I previously attended
A practical guide to using OpenTelemetry in Python, Tom Eastman (Kraken) 1423-1455
Very good introduction to OpenTelemetry (probably too basic if you know OpenTelemetry but as someone who has some experience with observability but not much with OpenTelemetry it was good, particularly since OpenTelemetry has improved a lot in recent time and is a fairly young project)
A “this is something I use and really like and this is why” talk
Very good speaker
Inferior mic’ing
Unfair comparison with his talk in 2013: both good quality, but I liked the fun aspect of the 2013 one more than the practical aspect of the 2023 one
Replacing server-side HTML with React, but page-by-page rather than as a SPA. In particular, keeping the routing done with Flask. At the same time, wanting to have strong types that are shared between the Python and Typescript code. Created tooling to automate generation of Typescript that had type definitions based on the type definitions in Python.
Then expanded this to also generate Typescript that provides types (and generally code-competion in an IDE) for API use, but without using (e.g.) OpenAPI since everything is in one local space.
It seems like using something like Vue would have been a simpler way to solve the “TypeScript/JS Framework but page by page” problem, although the coupled typing in the API would still be an improvement over that.
Interesting, assumed an ability to keep up with examples without much context, which generally worked (started out with some overly basic explanations, like “this is how decorators work”, but jumped quickly past that)
DuckDB: Supercharging Your Data Crunching, Richard Wesley (DuckDB) 1550-1624
Significant mic issues 😦
General introduction to DuckDB and where it fits in the DB space, and what the advantages it offers are
Good level (would be known to people that use DuckDB, but e.g. if you use something like Clickhouse and don’t know DuckDB this is a good intro)
Interesting note: worked for Tableau for a long time
Sometimes this is a pipe, or close enough, David Hood 1628-1657
Non-technical talk
Aimed at where he (a data journalist) sees developers needing help when moving into working with data
Important to always consider and document the context and the bias, how valuable the data is depends on what you are wanting to do with it
Can do much with very simple analysis – complicated models are really needed more when figuring out ranges
Very interesting, even though it seems like it would maybe would have been better at a different conference
Talked about examples have seen previously on Mastodon (e.g. time of day/week driving injuries/fatalities, changes in COVID incidence after changes in legal requirements)
Important to understand what you are doing with the data and the context
MIMO scheduling (multiple ground stations, multiple spacecraft, need to maximise the communication, choosing which station to talk to which craft)
He mentioned that he put together the talk the day before, and it was a little apparent. He spoke well and knew his material, but it didn’t have a lot of structure – some of it was praising GNU Radio, some was about what spaceops does, some was (overly trivial) why Python is good/bad, some was about how they’re using Python – it was like 2 good and one less good lightning talks merged into one
Good speaker
Interesting note: interned in Whangārei – maybe from there?
Saturday Conference Opening 0906-0915
No notes
Keynote 2: You’re Doing Great! The underappreciated art of appreciation. Loren Crary, Director of Resource Development of the Python Software Foundation 0917-1007
Very good speaker
Brief intro to the PSF
Brief speaker bio
Why expressing gratitude (written, spoken) matters, tips on how to get better and more regular at doing this
Really good (non-technical) talk
This is something I am also super passionate about (particularly in work, where I think it’s forgotten or overlooked more than elsewhere, and where ‘forced’ appreciation is common and not useful). Hopefully this changes how people behave
Interesting note: was asked to speak at Kiwi PyCon 2023 in late 2012, just days after starting work at the PSF!
Panel: A conversation for inclusion in tech, Samantha Nickson, Loren Crary, Kelsey Vavasour, Daisy Brenecki, Tom Eastman, and Christopher Neugebauer (replacing Carlos Cordero) 1220-1302
(I’m cis, straight, white, middle-aged, male, and work in a well-paid industry (the privilege jackpot), so that and my lack of experience on the minority side may bias this)
Held during lunch, quite lightly attended
No intro of the panelists 😦
Weird having the moderator stand while everyone else sat
Moderator too quiet
Very low energy
Loren was great, although didn’t say a lot; Kelsey was the strongest panelist; Daisy had notes, which seemed odd for a panel
No opportunity for questions from audience, which seems odd for a panel
Speaker diversity at the conference was noticeably lacking PoC, was light on women (every single session on Friday was given by someone that presented as male and ~white (I realise that there are issues with assuming gender & ethnicity) – Saturday was better, but not hugely). It would have been interesting to have introspection on that
Delivering Customer Projects in a Rapidly Evolving Python Landscape, Romi Dexter, Benoit Chabord 1331-1412
Talk from Integration Glue and Hype & Dexter (sponsors), these are the founder/co-founders of the two businesses (which are connected in some way I didn’t fully get)
Practical suggestions particularly around improving devex
Quite a practical talk for a sponsor talk
Talked about the specific tools they use (Ruff, Pyright, Black, pytest, coverage.py, Github Actions, Sentry, GCP, Clickup, Google Docs, Cookiecutter)
An introductory level talk
Good speakers
A little on the long side
Interesting note (Romi): was previously CIO for GrabOne
Interesting note (Benoit): first AoNZ role was at Yellow (Pages)
Building Kubernetes Operators with Python and Kopf, Sam Bishop (Runaway) 1422-14:50
Much more interesting level (it felt intermediate, although if you know k8s then probably more novice) and nice speed and consistency working through it
Nice slides
Exactly what the topic says (not that much else to say: exactly what was on the label)
Good speaker
Easily the best talk
Recommended packages: pendulum for datetimes (I believe I’ve seen this recommended before), deltaman for parsing human-readable time intervals, dynaconf for configuration management
Building an OAuth2 Authorisation Server with Flask and Authlib, Sam Watson (Runaway Play) 1548-1611
Walkthrough as per topic (not much else to say: exactly what was on the label)
Intro level, technical, assumes can keep up with code
Interesting note: the OAuth2 auth server described went live a ~week before the conference (and is working well so far)
Automating Victory: Beating browser games with accessible Python, Jon Gaul (Heenge) 1620-1651
Very good speaker
Project management, useful I/O libraries
Reminded me of Tom’s talk from 2013. Fun but pratical
Technical issues with live demo (screenshoting/GUI automation with projector screen secondary) but had backup videos
Close second for best talk of the conference
Basically: scripting an app by taking screenshots, using (basic) computer-vision to recognise the board, some (simple) rules to decide on moves, and then GUI automation to make the move, aiming to beat the speed run times (the game is like Minesweeper, but with levels of the dangerous squares, so much more maths, Momono Sweeper)
Interesting note: wrote a kid’s book (my guess is that it’s this one)
Basically delved into “simple is better than complex”, pointing out that often “simple” is achieved by moving complexity elsewhere, and that it’s best when complexity is managed by those who are most familiar with the domain
I skipped this. I needed a break by this point, and I didn’t believe the extra COVID risk was worth it for taking part in a quiz. I also lacked the energy to find 7 other people looking for an extra team member (it seems like the conference could have facilitated something here, even if it was just a whiteboard where you could post teams looking for people, or a Slack channel – except that most of the attendees seemed missing from Slack)
(Interestingly, this was the only organised social activity – e.g. there was no conference dinner).
Sunday Opening and Awards 0906-0927
Typical conference thanks etc – done early to accomodate people needing to get a limited number of flights out of Waihōpai Invercargill
General AoNZ Python history & update
Dropping having the conference in the location of the organiser (rotating North & South island), having it in Wellington every year instead
Changing where the conference is located going forward is an interesting choice. I’m sure there must have been much debate about this (although I’m a NZPUG member and don’t recall seeing it). I can see both advantages and disadvantages:
Advantages:
I assume some logistics are easier, particularly if you tend to stick with a single venue and so forth
The ‘average travel’ probably decreases, given that Wellington is located in the (rough) centre of the country, although this sort of calculation is tricky, because in reality it really depends how the origin is distributed
Travel is likely much simpler for international travellers, since you can potentially arrive in AoNZ in Wellington, or at worst would have one connecting flight from Auckland (and there must be many flights Auckland/Wellington every day), rather than travelling to more off-the-path locations like Waitangi or Invercargill
Disadvantages:
A drawcard (I assume for others as well) is seeing other places. This was certainly the case this year for me. I’ve been to Wellington many times (likely most people have) so there’s no appeal there, and even if you haven’t been, then you will have after attending once.
Either the organiser needs to be located in Wellington, or have members of their team in Wellington, or you have to do a lot of organising remotely – this is probably not too difficult this year, and if you’re re-using pieces (e.g. a venue) then it matters less
There are no cheap travel/accomodation years for anyone outside of Wellington (although every year is a cheap travel year for those in Wellington). Not having to pay for accomodation or flights was definitely a drawcard the first time I attended, and I imagine that it still would be if I was early in my career – maybe a lot of this is handled by companies, but it still hits students for sure
Development/boosting the local Python communities (outside of Wellington) is lost
It’ll be interesting to see how this goes.
Lightning Talks, Christopher Neugebauer 0933-10:55
I enjoyed many of these, although a lot were good as lightning talks rather than something where I’d want to see a 30-45 minute version.
Jonas, Promo for PyCon APAC 2023 and other PyCons in the APAC region
Grant, Opinion that Python (and Python-like, e.g. Mojo) will become the norm for development and other languages all exceptions (by 2045)
Sarah Greeff, Issue of low uptake of programming by females in high school education
Sam, “Loss & Grief” (the Tamagochi Effect, need to be careful about downstream consequences of development)
Simon “DevOps for Highly Regulated Environments” – comes up against arguments that devops practices conflict with security regulations, but argues that it’s entirely possible
Kristina Photos of the conference – Kiwi PyCon is about people, and not only developers, basically thanking everyone through photos (started with te reo & a mihi :tada:)
Steve Baker Wavetable Synthesis, live demo playing an instrument (electric ukelele) (music and live demos always very popular)
Kelsey Vavasour How to bring more people into programming (started with a te reo greeting :tada:)
Kesara PyPI Supply Chain Attacks (brief history of improvements that PyPI has made recently, and where there is still work to be done)
Warwick ?Walter? Basic introduction into binary/logic gates for addition (half/full adders), live demo of a home-built 1-bit adder with transistors (again live demo with hardware always popular)
Chelsea Finnie Learn A Sea Shanty (audience participation, learning a sea shanty), mostly just an excuse to get the room to sing a song together (audience partipation and music popular with a subset)
Hugh Davenport Showing a toy OS he has written (in x86 assembly), how he debugs issues with it using Python, live demo (one-handed), includes extremely minimal Python in the OS
Vicki McKay What to do when you don’t have a plan (decide to do something, follow intructions, listen and learn, follow the most passionate person), plan things, unclear on the message of the talk (maybe it was that people should participate in groups?)
Joelle Maslak How Networks Surprise Developers – works for Netflix, examples of how physical networks aren’t always as expected, how distance matters to speed
Daisy Talked far too fast (not the point of lightning talks), history of supermarket development in Austrailia and AoNZ (!)
Unconference
During the first two days of the conference attendees could suggest topics for ‘unconference’ sessions, and vote on suggested topics. My ride for Queenstown was leaving just before this, and none of the topics were ones I was particularly wanting to take part in, so I skipped this.
I think the rise of social media over the last few years have significantly decreased my interest in unconferences. It (possibly unfairly) feels like this would just be 30 minutes of ‘arguing with someone on the internet’ but in person. If there was a practical point, that would be different, but if it’s just a discussion, then I don’t feel like this is going to give me value, and will just get me annoyed. Again, this could definitely be unfair, particularly since I didn’t try these.
The topics were:
Can the Python Community Support Python Education in NZ? (answer: yes – and for the details this really relies on having people from education here, and I don’t think there were enough)
How Do We Improve the Python Packaging Experience, Especially for Beginners? (this seems like a talk for a bigger PyCon or elsewhere)
What are the Most Fun Things You’ve Done with Python (seems like this should just be lightning talks)
What Should Change in the Python Language Over the Next 10 Years / What Are Python’s Biggest Regrets or Mistakes? (this seems like it would drive me crazy)
Southern Tech: Is There Interest in Setting Up A Tech Advocacy Group Across Invercargill/Dunedin/Lakes District (probably good, but entirely out of my scope)
Is ChatGPT/Copilot etc Ruining Programming (this would also drive me crazy)
What Does Best Practice Python Data Science Look Like in 2023? / Do Notebooks Rot the Brain? (just not interesting for me personally)
What Can Python Learn from Other Languages? (another drive me crazy one)
Linters: Who Should Use Them? Which one? (Everyone, whichever one suits you/your team)
GNU Radio Live Demo (probably better during lunchtime)
Conference Closing
I obviously skipped this as well.
Closing Thoughts
I had three reasons for attending Kiwi Pycon this year:
To re-evaluate my now 10-year-old conclusion that attending Kiwi Pycon was not high value for me
To continue exploring areas of AoNZ that I haven’t travelled to
Originally, I was potentially not going to have a full-time development job at this time, and thought it could possible have some job search value; instead this became the value from combining the trip with working in Christchurch for a few days
I did get to see more of Christchurch, and visited Invercargill for the first time, and did the Invercargill->Queenstown road trip that I was keen on, so from that perspective it was a win. The tacked on induction visit in advance was really great (and also very valuable) and I doubt I would have done that without having this additional reason (Christchurch isn’t that far from Auckland, but it’s far enough, as compared to Christchurch and Invercargill when already travelling), particularly since Ben & I would be meeting in Riga in a few more weeks anyway. It’s interesting that the most positives from my trip are in this area, which vanishes when the conference becomes anchored in Wellington.
I did get a chance to re-evaluate attending Kiwi PyCon, and that was valuable. My conclusion ends up the same: I don’t get enough value out of it to attend. This is even more the case than in 2013, since I could watch any of the talks when the videos are available (fairly soon, I expect), so it’s really the experience and the networking that’s providing value. There were plenty of interesting and smart people, and I had some interesting conversations, but nothing that was so amazing (or so unable to be replicated online) that I would pay >$1000 and consume 3 days for it.
If the conference had more of the really great talks, and especially more that were aimed at people that have been using Python for 10+ years, then that might change my opinion (this is something I thought would have changed since 2013), although there’s still the “videos are all online” counter. I would like a mix something like 10% beginner, 80% intermediate, 10% experts, and 20% ‘fun and interesting’ rather than entirely practical, and roughly 30% soft, 70% technical talks. Obviously, other people will have other tastes.
If you’re someone that really enjoys the social & networking aspects (I don’t) or looking specifically to be hired by one of the sponsors or are very early in your Python journey or want somewhere to practice a talk you’re going to give elsewhere, then it could be worth it for you. However I have to recommend everyone against attending Kiwi PyCon because of the Code of Conduct issue. That’s a complete blocker to attending, and should be for anyone in 2023 and beyond (unless it does get publicly addressed).
TonyAndrewMeyer 