Naomi Ceder

Uma vista de fora - 10 anos de PyLadies São Paulo

Introdução

Olá, tudo bem? Primeiramente fico muito feliz e muito honrada de ser convidada a dar esta palestra hoje. O décimo aniversário é um marco importante para uma comunidade como a de vocês. Mostra que ela é importante para as pessoas, que muitas pessoas a amavam o suficiente para cuidar dela ao longo dos anos.

Também é uma oportunidade para refletir sobre o passado e como chegamos até aqui, bem como para pensar sobre o futuro. Todas nós PyLadies queremos que esta organização continue, cresça e floresça. Mas sabemos bem que a vida acontece. As pessoas vêm e vão, com mudanças em empregos e carreiras, evoluções da tecnologia e todas as coisas de família, saúde, e tudo. Então não é comum que uma comunidade como esta dure dez anos, e continue a partir daí. Em outras palavras, o seu décimo aniversário é uma coisa importante, como dizemos em inglês, "a big deal".

Esta ocasião é importante para mim porque conheço o grupo de PyLadies São Paulo por quase toda a vida dele. No Python Brasil [12] conheci as organizadoras deste novo grupo, PyLadies São Paulo, e me lembro do orgulho e entusiasmo que elas demonstraram. (a propósito, guardei aquela camiseta e a usei até que ela estivesse totalmente gasta.)

No ano seguinte, eu dei uma palestra no segundo aniversário, e depois permaneci conectada com as PyLadies de São Paulo, encontrando-me com elas em conferências em todo o mundo e online durante a pandemia.

Na verdade, fiz tantos amigos e amigas brasileiras que decidi estudar português há alguns anos, e desta vez posso falar com vocês em português. Quando visitei o Brasil em 2016 prometi que da próxima vez poderia falar português. Infelizmente, ainda não pude visitar outra vez e hoje, com o regime anti trans atual no meu país, não me sinto confortável viajando internacionalmente. Mas estou pronta se as coisas mudarem.

Então, tendo visto esta comunidade durante tantos anos, sinto-me quase como uma tia das PyLadies São Paulo, e por isso é muito especial para mim falar com vocês. E espero que a minha visão de fora desta comunidade mostre tanto as ameaças e os desafios que vocês podem enfrentar no futuro quanto as qualidades que fazem este grupo tão especial.

Livros

Antes de começar a palestra, deixe-me mencionar mais algumas coisas. Sou autora do Quick Python Book, agora na quarta edição, e com um prefácio de Luciano Ramalho. Sempre fui grata pelo apoio dos brasileiros, e pedi à minha editora, Manning Publications, alguns códigos para cópias (ebooks) gratuitas do meu livro e um desconto em homenagem ao evento. As organizadoras vão compartilhar/compartilharam os detalhes.

Conexão

Eu disse que fiz muitos amigos nesta comunidade, mas também devo dizer que sempre fico feliz em ter mais. Estou aposentada agora, então não estou tão conectada com o cenário atual de empregos na área de tecnologia, mas se alguém quiser se conectar para conversar sobre outros assuntos, estou aberta a isso, seja em inglês ou português. Além disso, estou mais interessada atualmente em música, arte e leitura. Acabei de terminar uma aula sobre música brasileira com um cara no Rio, e posso dizer que descobri o Veríssimo pelo menos alguns meses antes da sua morte recente. Então, se você quiser conversar sobre essas áreas, ficarei feliz em fazê-lo. Você pode me encontrar no LinkedIn, Facebook, Bluesky ou no meu site.

Sobre a palestra

A última coisa é falar um pouco sobre esta palestra. Primeiro não vou usar slides. Não gosto deles, porque na minha opinião elas destroem ativamente a inteligência. Sim, mostrarei algumas imagens no fundo, mas a coisa mais importante será minha voz. Se vocês quiserem ler as palavras, devido ao meu sotaque ou o que seja, o texto está em naomiceder.tech/blog.

Além disso, tenho que admitir que a primeira parte da palestra contém coisas sombrias. Aqui às vezes dizemos que existe uma antiga maldição chinesa que diz "Que você viva em tempos interessantes." Na verdade, não existe nenhuma evidência de que seja chinesa, nem antiga, mas sim, sem dúvida é uma maldição, e também uma descrição justa da nossa situação.

Então vou começar com todos os problemas que enfrentamos, mas prometo que o final será otimista.

Por fim, não vou falar muito de temas técnicos. Suponho que, estando aposentada, eu tenha o luxo de pensar mais na humanidade, a arte, a música, etc. e eu diria que no geral assuntos técnicos são detalhes de implementação que nos dizem pouco sobre as coisas mais importantes. Para usar o lema que aprendi aqui no Brasil há 9 anos, "Pessoas > tecnologia."

Desafios e ameaças

Então

Duas semanas atrás eu vi a palestra que dei no segundo aniversário. Não gosto muito de ver os meus vídeos antigos. Sim, gostei do meu cabelo (menos grisalho) e dos meus óculos. E gostaria de ter 8 anos menos, claro.

Na verdade, agora essa época parece um mundo diferente. O vídeo me lembrou de como as coisas eram quando PyLadies SP começou (e tantos outros grupos de PyLadies). Acreditávamos que iríamos mudar e melhorar o mundo com tecnologia, que a inclusão continuaria a crescer, e a única coisa que deveríamos fazer seria ensinar mais mulheres e pessoas marginalizadas as maravilhas do Python e da tecnologia.

Ser mulher, ou LGBTQI+, ou uma pessoa não branca parecia ter menos desvantagens, com a esperança que as coisas fossem ainda mais favoráveis no futuro.

Alunos dos bootcamps conseguiam bons empregos e carreiras boas, e as grandes empresas sempre precisavam de mais pessoas, e ofereciam benefícios generosos, como comida, transporte, serviços e até mesas de pebolim e pingue-pongue. (Eu nunca entendi isso) Os salários eram ótimos, e as oportunidades estavam por toda parte, e se não encontrasse um emprego no próprio país, seria fácil migrar para fora.

Havia problemas, sim. Havia homens sexistas e machistas, que muitas vezes não aceitavam mulheres e outras minorias. Mas a opinião geral era a nosso favor. A mudança climática era uma preocupação, a ultra-direita estava surgindo em vários países, mas tudo estava (ou parecia) sob controle. Ou assim acreditávamos.

Agora

Nos oito anos seguintes, como dizemos, a vida aconteceu. Os partidos da direita ganharam mais poder, e cuidar das pessoas tornou-se um pouco menos importante.

Com a chegada da pandemia, tudo mudou. Ficamos isolados, trabalhando remotamente, lutando para manter um sentido de conexão e comunidade por meio de ligações com amigos, eventos no zoom, etc. Algumas pessoas morreram, outras lutaram contra a Covid longa, todos sentíamos mais sozinhos. Conferências e meetups pararam ou até morreram.

Finalmente, superamos a pandemia. As coisas reabriram e recomeçaram, mas não era o mesmo de antes. Eu diria que a pandemia marcou a transição para uma nova era em que estamos agora. O mundo de hoje é mais sério e menos gentil. Esta é a era do "hard tech". As empresas não se importam mais nem com empregados, nem com consumidores, as startups não estão mais tentando mudar o mundo.

Menos consideração

Elas agora estão focadas em conquistar clientes maiores e mais poderosos, grandes corporações e governos. As forças armadas e as finanças agora são preferidas. Lucros e dados concretos são preferíveis a mudar o mundo, e considerações éticas são menos importantes. Lembramos quando o lema do Google era "Não seja mau"?

Agora há menos consideração pelos funcionários e vemos um movimento universal de "volta ao escritório" "Back to the office" e uma redução de benefícios do escritório. Também estamos vendo demissões. As empresas não estão dispostas a contratar pessoas formadas em bootcamps e preferem oferecer contratos temporários em vez de vagas permanentes.

E mesmo lucrando com open source software, essas empresas fornecem pouco suporte às comunidades que o produzem. A PSF teve que parar de subsidiar eventos e conferências devido à falta de recursos, apesar do fato que Python é atualmente a linguagem mais popular do mundo e vital para a IA e a ciência de dados, que estão gerando riqueza. Sem mais apoio financeiro, as conferências e meetups serão impossíveis, o que será prejudicial ao software do qual dependem, mas elas parecem não perceber nem se importar.

Movimentos da direita

Ao mesmo tempo, movimentos de direita estão crescendo e governos antidemocráticos estão se tornando mais comuns. O resultado é que as empresas estão abandonando a diversidade e a inclusão e elas se tornaram um alvo político da direita. Sim, isso é mais óbvio com o governo de Trump, mas a influência dos EUA é amplamente sentida em muitos países. E a atitude anti diversidade permite que homens insultem mulheres e minorias, e torna mais difícil para pessoas não homens brancos conseguirem empregos e mantê-los.

Esse movimento já está reduzindo oportunidades, com mais restrições à imigração e até mesmo (no caso dos EUA) tarifas, que são prejudiciais a todos.

As guerras

E claro, agora temos guerras, na Ucrânia, em Gaza, na África, e ameaças de ainda mais guerras ao redor do mundo. Membros da comunidade Python de todos os lugares foram afetados, e para ser sincera, parece que a situação está piorando.

Todos esses fatores estão nos separando e nos enfraquecendo no exato momento em que precisamos trabalhar juntos.

A IA

Além disso, agora vemos que a IA parece estar dominando o mundo, uma força imparável. Sim, às vezes a IA faz coisas impressionantes, mas muitas vezes também cria problemas igualmente impressionantes. A IA tomou e usou a propriedade intelectual de muitos milhares de autores (inclusive eu) sem permissão e sem recompensa.

A IA também consome recursos a uma taxa incrível. Aqui na região de Chicago, as contas de energia estão disparando porque não temos energia suficiente para abastecer os parques de servidores do LLM e atender às necessidades das pessoas.

A IA também consome água potável e produz CO₂. O Google afirma que um prompt de texto "normal" consome uma pequena quantidade de energia e água e produz pouco CO₂. Parece, no entanto, que eles não estão incluindo os custos de todo o processo e infraestrutura. E, claro, nem todos os prompts são simples prompts de texto. Só podemos imaginar quantos recursos a mais são consumidos para produzir vídeos bizarros, imagens no estilo do Studio Ghibli e imagens de pessoas com 14 dedos. E agora, cada consulta de pesquisa do Google envolve IA, então mesmo pequenas quantidades de consumo precisam ser multiplicadas por bilhões todos os dias.

Outra consequência da IA será que os líderes empresariais acreditam que não precisam de desenvolvedores, especialmente os juniores. Já que a vibe coding supostamente pode fazer o mesmo trabalho, por que gastariam dinheiro (e tempo) contratando juniores? Agora, até mesmo graduados de universidades de prestígio estão com dificuldades para encontrar emprego, e os formados em bootcamps não têm chance.

É claro que isso não funcionará a médio ou longo prazo, nem para empresas nem para indivíduos. Mesmo que a IA pudesse substituir alguns programadores (e isso é verdade em pouquíssimos casos, na minha opinião), o que as empresas farão no futuro, quando não houver desenvolvedores de nível médio ou sênior, já que eles não foram contratados como juniores?

Há também preocupações com os efeitos da IA nos mercados. No momento, as avaliações estão altíssimas, em parte devido ao entusiasmo pela IA e à expectativa de que ela trará um crescimento incrível. Mas o que acontece se o crescimento não for tão incrível? Li recentemente um estudo que constatou que os ganhos de produtividade com a IA são, na verdade, bem pequenos, cerca de 3%. Se o milagre não acontecer, se (como acredito ser o cenário provável) os resultados da IA forem apenas positivos, mas não milagrosos, é provável que assistamos a uma quebra do mercado global, com consequências graves para todos.

O entorno

O maior horror que enfrentamos são as mudanças climáticas. Sem dúvida, as temperaturas globais estão subindo, de forma mais rápida e drástica a cada dia. Em todos os lugares, vemos ondas de calor, inundações, tempestades, incêndios florestais, chuvas torrenciais e muito mais. Ao mesmo tempo, o nível do mar está subindo e os sistemas climáticos estão mudando.

A maioria das pessoas e governos vê isso como uma emergência (o atual regime americano, infelizmente, não), mas ainda não estamos fazendo o suficiente para lidar com isso.

O que fazer?

Stockton

Por que estou contando isso? Não quero que todos fiquem tristes e deprimidas, mesmo que pareçam assim. Um fator na capacidade de sobreviver e superar momentos difíceis é reconhecer as dificuldades sem ceder. Isso se chama "efeito Stockton", em homenagem ao General Stockton, que foi capturado no Vietnã e sofreu torturas brutais. Apesar da tortura, ele se manteve firme e nunca desistiu, e finalmente conseguiu voltar para casa.

Mais tarde, Stockton disse ter notado (e vários estudos confirmaram isso) que homens otimistas irrealisticamente (que sempre diziam: "As coisas vão melhorar em breve, estaremos em casa antes do Natal", coisas do tipo) eram os primeiros a morrer. Como as coisas não melhoraram em breve, eles não voltavam para casa antes do Natal, e a decepção os enfraquecia e, por fim, os destruía.

No entanto, aqueles que reconheceram o quão ruins as coisas estavam e continuavam determinados a perseverar e tentar na esperança de superá-las algum dia foram os que tiveram mais probabilidade de sobreviver.

É por isso que estou lembrando vocês de todos os desafios e ameaças que enfrentamos. Mas a segunda parte também é importante: precisamos ter esse tipo de otimismo teimoso, informadas sobre os desafios, mas ainda determinadas a fazer o que pudermos para um dia superá-los.

Este tipo de otimismo é um ato revolucionário. Ou seja, como disse Noam Chomsky, "otimismo é uma estratégia para criar um futuro melhor. Porque, a menos que você acredite que o futuro pode ser melhor, é improvável que você assuma a responsabilidade de criá-lo."

Por que otimismo?

Por mais importante que seja enxergar os desafios com clareza, é igualmente vital considerar honestamente nossas razões para otimismo. Um fator vital para enfrentar todos os desafios que mencionei está ao nosso alcance. É a força unida de todos nós, a força da comunidade. E aqui, nesta comunidade, vejo três fortes fontes desse espírito de comunidade.

Python

Primeiro, a comunidade está no DNA de Python. A comunidade sempre foi uma parte importante de Python, o que uniu tantas pessoas com tantos interesses diferentes. Se você ainda não viu o documentário recente sobre Python, recomendo fortemente. Como disse Bret Cannon (um ditado que já peguei emprestado muitas vezes): "Vim pela linguagem, fiquei pela comunidade". E todos nós fazemos parte dessa tradição.

É o que manteve o progresso da linguagem durante várias crises. Em 2008-2009 a crise financeira levou a grandes perdas da PyCon US. Tivemos contratados hotéis, espaços de eventos e, como aconteceu, as empresas não tinham condições de enviar pessoas para a conferência. Pareceu possível que a PSF não poderia continuar. Mas como comunidade perseveramos e superamos.

Eu sei isso por experiência própria. Quando estava fazendo minha transição, tinha medo de perder minha conexão com a comunidade Python. Pensei que ninguém (ou poucos) me aceitaria, que eu ficaria sozinha. Na verdade, todos se esforçaram para garantir que eu me sentisse aceita. Sim, as coisas não eram perfeitas, mas no geral recebi abraços e apoio.

PyLadies

O segundo fator positivo é a tradição de PyLadies. PyLadies sempre fomentou um sentido de comunidade e apoio mútuo. Desde o início o objetivo foi que nós, mulheres, nos apoiássemos e nos ajudássemos a enfrentar os desafios de ser mulheres entrando em um mundo dominado por homens.

As primeiras organizadoras de PyLadies, Lynn, Esther, e Sophia me fizeram sentir bem-vinda, e, quando estava organizando os primeiros eventos de Trans*Code, elas foram minhas maiores apoiadoras e conselheiras.

Desde o início é uma tradição no almoço de PyLadies em PyCon e EuroPython incentivar as pessoas a compartilhar suas conquistas e serem celebradas. E espero não precisar lembrar vocês que o Brasil tem um dos movimentos de PyLadies mais fortes do mundo inteiro.

Mais importante ainda, PyLadies é uma organização de mulheres, mulheres dispostas a se unir e fazer o que precisa ser feito. E, na minha opinião, essa é uma das forças mais poderosas do mundo.

Cultura brasileira

A terceira fonte da unidade e comunidade que eu vejo talvez possa parecer estranha para vocês. Mas, como estrangeira, é bem claro para mim. É a cultura brasileira.

Sim, eu sei que toda cultura tem suas desvantagens, que nem todas as pessoas de um país, especialmente um país grande como o Brasil, compartilham os mesmos valores e normas. No entanto, acho que há algo especialmente propício à comunidade em vocês.

Viajei literalmente o mundo e conheci milhares de pessoas de diversas culturas. É claro que existem boas pessoas em todos os lugares. Mesmo assim, desde o primeiro dia em que cheguei ao Brasil, nove anos atrás, continuei a me sentir bem-vinda, formar conexões e encontrar amizades duradouras com brasileiros. Nenhuma outra nação me recebeu tão calorosamente. Vocês criaram meu lema favorito - Pessoas > tecnologia. (Outra camiseta que adorei e guardei até ficar gasta).

Não estou exagerando quando digo que agora tenho mais (ou quase) amigos brasileiros do que norte-americanos. São muitos para mencionar, mas quero contar um exemplo só. Quando a PSF me entregou o Prêmio por Serviço Distinto em PyCon em Salt Lake City, em 2023, a pessoa mais orgulhosa da plateia, a que me abraçou mais forte, não foi de Chicago, não foi dos EUA, nem da Europa. Foi um brasileiro, meu amigo Felipe de Morais. Nunca vou me esquecer disso.

Não sei por que vocês se importam tanto com os sentimentos dos outros... Não sei, mas acho importante que você ouça de uma estrangeira que eu nunca encontrei um senso de comunidade tão forte quanto entre vocês. Não é uma fraqueza, é um superpoder, e tenho certeza de que ajudará esta comunidade, não importa os desafios que o futuro traga.

Conclusão

Então, como eu disse no início, vivemos em tempos interessantes... Isso me lembra de uma citação de O Senhor dos Anéis:

"Gostaria que isso não tivesse acontecido na minha época", disse Frodo.

"Eu também", disse Gandalf, "e todos os que vivem para ver tempos assim. Mas isso não cabe a eles decidir. Tudo o que temos que decidir é o que fazer com o tempo que nos é dado."

Eu sei que todas vocês nesta comunidade, assim como todos nós nas comunidades globais PyLadies e Python, temos a tradição de nos unirmos não apenas para sobreviver, mas para superar estes tempos interessantes.

DIY Ear training with Python and Music21, part 2

Having a basic ear training app (as described in part 1 working, I started to use it. As I mentioned in my last post I quickly discovered I was surprisingly bad at it, and my bare bones app was not helping me as much as I thought it could.

Correcting and learning from mistakes

Not having had much experience with recognizing intervals, I decided to keep things simple and start with just 3 intervals, the major third, the perfect fifth, and a perfect octave. Since I was making plenty of mistakes, I started thinking about how to correct those mistakes. For a while I tried repeating an interval until I got it right, but considering the limited choices (major third, perfect fifth, and octave) and the fact that I was showing the right answer after the fact, that wasn't much help.

I was also finding that I was struggling most with telling a perfect fifth and an octave apart. I have no idea if this is a common issue, but it seemed to me that they are both similarly consonant, and unless I was careful (and all too often even if I was careful) they sounded similar to me.

My approach was first, reduce the possible choices to just those two. I could always add thirds back in later, but first I wanted to get past the fifth/octave confusion. Next I tried creating a cell that picked notes at random and then played the possible intervals. Warming up with this approach seemed to improve performance at least for a session immediately after that.

That said, I do wonder if that approach might be worth trying. but only playing the samples randomly, only part of the time, and progressively less often. Another option might be to play only one reference tone, say the octave or fifth, to help set the stage.

That said, I do wonder if that approach might be worth trying but only playing the samples randomly only part of the time, and progressively less often, might be worth investigating. Another option might be to play only one reference tone, say the octave of fifth, to help set the stage.

Finally, I decided to add code to review the mistakes. Since I was already collecting the incorrect answers, along with the notes and correct interval, it was easy enough to instead add a review of wrong answers after the main run was finished. This randomly selected items from the list of incorrect answers, only removing them when they were answered correctly. After trying it a time or two, I decided to double the list of incorrect choices (incorrect = incorrect * 2), just to give me extra practice with the trouble spots.

Improving feedback

In addition to handling the errors, I had found the feedback was not clear enough. If I made and error, I wanted it to be a little bit obnoxious about it. (As you might guess I'm not totally against negative feedback).

I decided that playing an irritating noise might be a good way to handle indicate an incorrect guess. I wasn't able to get the Jupyter Audio component to play a sound automatically during a loop (although it would as the main code in a cell), so instead I went with the playback3 library and a gong .wav file I found in a quick search. This, along with some clearer messages and a count of the total attempts in a session, gave me much better feedback.

The current code

The actual code was this:

choice = ""
correct = []
incorrect = []
total_tries = 0
while choice.lower() != 'q':
    total_tries += 1
    test_interval = random.choice(intervals)
    base_note_name = random.choice(chromatic_guitar[:-12])
    base_note = note.Note(base_note_name)

    test_stream = stream.Stream([base_note, 
                     base_note.transpose(test_interval)])

    test_stream.show("midi")
    choice = input("interval: ")
    clear_output()
    if choice == test_interval:
        correct.append(choice)
        print(f"{choice} is correct\n")

    elif choice.lower() == 'q':
        total_tries -= 1
        break
    else:
        playsound("gong.wav")
        incorrect.append((test_interval, base_note, choice, base_note.transpose(test_interval)))
        print(f"{choice} is incorrect\n")

    print(f"{len(correct)}/{len(correct)+len(incorrect)}")
    print(f"{base_note.name},  {base_note.transpose(test_interval).name} --> {test_interval}, {choice}")

incorrect = incorrect *2
while incorrect:
    total_tries += 1
    print(f"Reviewing {len(incorrect)} missed items")
    test_item = random.choice(incorrect)
    test_stream = stream.Stream([
                                      test_item[1], 
                                      test_item[3],
                                ]
                               )
    test_stream.show("midi")
    choice = input("interval: ")
    clear_output()
    if choice == test_item[0]:
        correct.append(choice)
        incorrect.remove(test_item)
        print(f"{choice} is correct\n")
    elif choice.lower() == 'q':
        total_tries -= 1
        break
    else:
        playsound("gong.wav")
        print(f"{choice} is incorrect\n")
    print(f"{len(correct)}/{len(correct)+len(incorrect)}")
    print(f"{test_item[1].name},  {test_item[3].name} --> {test_item[0]}, {choice}")

percentage = float(len(correct)/total_tries * 100.0 if total_tries else 0)
print(f"{total_tries} tries for {len(correct) } intervals correct = {percentage:02.1f}%\n")

if not incorrect:
    print("All errors fixed")
else:
    print(f"{len(incorrect)} errors not fixed")

Future options

This is still pretty simple minded. There is no attempt to track results or progress over time and no analysis of the types of errors which could shape remedial exercises. Both of those would require adding a SQLite database, which would be easy enough to do.

Beyond that, with a database, I could also add spaced repetition to the sessions, refreshing old work why moving on to new items. I had included that in my first notes on the project, but I'm not sure if I'll feel the need to implement it. If I do, I guess that would lead to a part 3 of the series.

Results

But even with it still being simple, I now had\ something that was starting to work as I'd hoped. I can fire up this notebook every day, work through 3 or 4 runs of 30 choices and get extra practice with my mistakes.

I've been pretty consistent in practicing every day, which I think is at least partly due to the fact that it's my code and I had to understand the problem in order to create it.

So far I've been happy with the results. After a few days of practice, I can now more reliably tell my fifths from my octaves, I've even added both major and minor thirds back in, and am surprised at how much easier those are for me.

If you want to leave a comment, or just prefer a more interactive experience, this post can also be found on Sustack at https://naomiceder.substack.com/p/diy-ear-training-with-python-and-2d5

DIY Ear training with Python and Music21, part 1

For the past 3 years I've been studying classical (and now also jazz) guitar, music theory, and doing a little composing. I tend to dive into things, and in that time I would say that I've made it to intermediate level as a classical guitarist, I've learned a fair bit of music theory, and I've written a few pieces for guitar.

One piece has been missing, however. That is ear training. I hear and learn melodies and rhythms just fine, but I've been missing the ability to recognize intervals by ear. Is that a perfect 5th? Or is it a minor 3rd? Maybe an octave? My guesses were not nearly as reliable as I thought they should be.

The answer, of course, is ear training, basically practicing identifying intervals until one's recognition improves. There are, of course, tons of apps and web sites that will help you do that for free.

That would be the easy way, or at least the obvious way. But I've tried them (very briefly) before and they never engaged me. In fact, they just seemed frustrating. After decades of teaching, I know that frustrating = un-motivating = doomed to fail.

So my solution was to create my own ear training program. The process is inherently more interesting (at least for me). You have to think a bit about how to go about the training, you have to think about the structure of a program to do that, and you have to write the code. And you have to TEST the code, which in itself assures more time using it.

I should also note that so far, this entire project has been free from AI. Yes, I know I could get a chatbot to generate the code, the approach, the design, or even a whole ear training website. If I were mainly interested in using AI to generate code, then maybe that would make sense. But again, that would diminish, or even eliminate, my involvement and motivation in the whole process. In the end, it would be no better, if not worse, than just using one of the many pre-existing apps.

So here begins my ear training journey, coded the old fashioned way.

Basic app idea

The basic idea is just play intervals, try to guess them, and evaluate whether the guess is right or wrong. So that means that the pseudocode at a high level might be something like:

loop:
    Get a note name at random from list of notes
    Get an interval name at random from list of intervals
    Create first note from note name
    Create second note of interval by transposing the  first note by the interval
    Play the notes 
    Get the user's response
    Check response against actual interval name

The implementation of that basic idea was the next step.

Platform

I was pretty clear from the beginning that I would use a Jupyter notebook for this experiment, since I had no need for a standalone app, and the convenience of a notebook is hard to beat. For generating the sounds, Music21 seemed right for me, since it can generate midi sounds and can manipulate and transpose notes, making it easy to create pairs of sounds separated by arbitrary intervals.

I knew I needed to install music21 so once I had a notebook ready (I used pyenv to create a Python 3.13 environment for the project), I installed music21 from within my notebook:

%pip install music21

The code, first iteration

The first thing I needed to do was load dependencies:

from music21 import * # import everything from music21

import random

from IPython.display import Audio # load the Jupyter audio widget
from IPython.display import clear_output # used to clear the cell after an attempt

I needed music21 of course, the random library for selecitng notes and intervals, and from the IPython.display library I would need both the audio player and the clear_output function to clear the output after each guess.

Since I'm primarily a guitarist, I wanted to use the range of sounds available on the guitar. I had already experimented with music21 a couple of years ago, so I had the code to define the notes of the fretboard ready to go:

chromatic_guitar = ["E3", "F3", "F#3", "G3", "G#3", "A3", "A#3", "B3", 
           "C4", "C#4", "D4", "D#4", "E4", "F4", "F#4", "G4", "G#4", "A4", "A#4", "B4",
           "C5", "C#5", "D5", "D#5", "E5", "F5", "F#5", "G5", "G#5", "A5", "A#5", "B5",
           "C6", "C#6", "D6", "D#6", "E6", "F6", "F#6", "G6", "G#6", "A6", "A#6", "B6"
                  ]

Transposing is pretty easy to do with music21, you can either use a number of steps or a string with an interval name (in either case, the default is to transpose up, and prepending a "-" will transpose down.) For example:

from music21.note import Note

Note("E").transpose(1)    # E to F
Note("E").transpose(-1)    # E to Eb
Note("E").transpose("m3")    # E to G

Using a list of interval names is more useful for the current purpose than using integers so I created a list of intervals, but commented out all but the perfect 5th and perfect octave to make it a bit easier on my untrained ears:

intervals = [
    # "m2",    #minor 2nd
    # "M2",    #major 2nd
    # "m3",    #minor 3rd
    # "M3",    #major 3rd
    # "P4",    #perfect 4th
    # "D5",    #aug 4th/dim 5th
    "P5",    #perfect 5th 
    # "m6",    #minor 6th 
    # "M6",    #major 6th
    # "m7",    #minor 7th 
    # "M7",    #major 7th 
    "P8",    #perfect octave

After those three cells of preliminaries, the basic app looked like this:

Disclaimer: of course my actual first iteration was messier than this, I've cleaned up the false starts, errors, and extraneous bits.

# initialize
choice = ""
correct = []
incorrect = []

# loop
while choice.lower() != "q":
    test_interval = random.choice(intervals)
    base_note_name = random.choice(chromatic_guitar[:-12])
    base_note = note.Note(base_note_name)
    test_stream = stream.Stream([base_note, base_note.transpose(test_interval)])

    test_stream.show("midi", autoplay=True)
    choice = input("interval: ")
    clear_output()
    if choice == test_interval:
        correct.append(choice)

    elif choice.lower() == "q":
        break
    else:
        incorrect.append(
            (test_interval, base_note, choice, base_note.transpose(test_interval))
        )

    print(f"{len(correct)}/{len(correct)+len(incorrect)}")
    print(
        f"{base_note.name},  {base_note.transpose(test_interval).name} --> {test_interval}, {choice}"
    )

Reflection

This was enough to get me started, and I soon discovered that I was every bit as bad at telling perfect fifths and octaves apart as I'd feared, and I struggled to call 2/3 of the pairs correctly.

That pushed me back into teacher mode, and I started thinking about how I could modify the code to help me learn. As I thought about it, there were several things that were not optimal.

First of all, the feed back on whether a guess was right or wrong, was only indicated by the change in the counter of correct over total attempts. More obvious and forceful feedback would be helpful,

Secondly, there was no way to learn from the mistakes, other than displaying the incorrect list. In fact, I'd decided to use lists for correct and incorrect, rather than just counters, because I was pretty sure I'd want to do something to help learn from the mistakes.

I'll talk about what I did to address these issues (and why) in the next post, coming soon.

If you want to leave a comment, or just prefer a more interactive experience, this post can also be found on Sustack at https://naomiceder.substack.com/p/diy-ear-training-with-python-and

A surreal nightmare - Chelsea Manning's README.txt

Here are my thoughts on Chelsea Manning's memoir README.txt

Reading Chelsea Manning's README.txt was an odd experience for me. On the one hand, there were lots of things that made me feel connected to her and interested in her story. The most obvious was that we are both trans women, and we began our transitions at roughly the same time. And of course, her struggles for trans care were widely publicized, so I was aware of them, and to a certain extent my transition was also fairly public, if within a much smaller social network and the Python community. We had grown up in very conservative parts of the country - in her case, Oklahoma (at least in part) and in mine, Nebraska. In addition, her use of technology and the internet was similar to mine in the 90's and 2000's.

With that said, there were some real differences. For one thing I'm more than 30 years older, so I had served a self-imposed term of decades of suppressing my gender identity, waiting until circumstances made it safer and easier to transition. Chelsea's childhood was abusive in many ways, while I would not claim that of mine. And in spite of some temptation, I had resisted and avoided entering the military.

In spite of the points of connection, I was not immediately grabbed by her story. She starts with the striking scene of her desperately trying to upload all of the files via a shaky network connection in suburban mall land, during a snowstorm no less, with less than 24 hours before she has to get on a plane back to Iraq. But the telling of it is a bit pedestrian, and it takes a while for the story to emerge. Dramatic as it might be, the how and the why of the uploading of information about the war is not the story. Rather it's what happened after she was caught that I found more compelling.

The story of how she came to have that information and how she uploaded it is all too simple, and the why is not so well articulated, emerging as it does from a tough childhood and rootless adolescence that ended in the army almost out of desperation.

But once she is discovered and taken into custody things get much more gripping. The style is still matter of fact, flat, and mostly emotionless, as if it could only be told by keeping it safely at arm's length. It's a story that is almost Kafka-esque in its absurd cruelty. Earlier, when describing basic training, Chelsea acknowledges that its function is to break people, tear down part of who they are in order to reconstruct them as different people. It's interesting to me that of all the veterans I've known, the only other person who described military training that way was another trans woman, who washed out of ROTC because she wouldn't endure that.

Chelsea on the other hand gives a sense that the process of breaking and rebuilding that happens basic training was not all bad for her. So it's interesting that once in the clutches of the US government she is the target of a similar process, except there is no goal of rebuilding a new personality this time. This time the only goal is to destroy her totally. The unemotional descriptions of the inhuman torture they put her through leaves no doubt that the primary concern of her jailers and the government was pure revenge, nothing more.

That she survived her initial captivity and what was a bizarre show trial (bizarre in that many parts of it were blacked out in the name of "security") and her early captivity is amazing. The treatment she received from her own government, our government, as a citizen on US soil, under an administration that was supposedly humane and progressive, should be a curative for any idealism in regards to the justice of our ways.

If there is anything positive in the story it would be that once she given even the slightest breathing space, she was able to find people to help her as she found ways to deal with the government and even gain concessions from it, both in terms of dealing with prison and in forcing the grudging accommodation of her gender transition.

In the end her eventual movement to Leavenworth to serve her 35 year sentence (which seems almost like summer camp in comparison to what went before) and even the eventual commutation of her sentence and her release all seem not so much the restoration of justice as a calculated attempt to evade the judgment of history.

Chelsea emerges as someone of intelligence, of stunning courage, but not unscathed. After a difficult youth and her nightmarish captivity, she is not broken, but the scars (and even the still open wounds) are extensive, and one wonders if Chelsea Manning will ever be at peace in this world. And to be honest, one wonders if her ordeal was worth it.

PyCon Bolivia 2022 Keynote

Esta charla se presentó como keynote de PyCon Bolivia 2022, 2022-12-09

El texto y las diapositivas de esta charla están aquí.

Una época de regalos

Esta charla se presentó como keynote de PyCon Latam 2022, 2022-08-27

Buenos días. Estoy encantada de hablar con ustedes hoy. Es un honor y un reto dar esta charla tanto en español como en portugués, hablando a (casi) toda América Latina.

Antes de empezar, quiero compartir mi proyecto actual. Me jubilé hace dos meses y ahora tengo tiempo para apoyar a las comunidades de Python. Quiero ofrecer mis 20 años de experiencia como regalo a cualquier comunidad de Python en todo el mundo que lo desee. Si desean consejos sobre cómo construir y administrar comunidades, mejores prácticas, códigos de conducta, inclusión, lo que sea, me encantaría ofrecerles mi consejo y ayudarlos a pensar en esos temas. Para obtener más información, visiten naomiceder.tech/community o ponganse en contacto conmigo en info@naomiceder.tech.

El título de esta charla es "Una época de regalos", inspirado por una joyita de memorias de viaje escrita por Patrick Leigh Fermor. En los años 30 Fermor, después de ser expulsado de su último año de "public school" por no haberlo tomado en serio lo suficientemente, decidió caminar desde Los Países Bajos por el Rin, a través de Europa, por el Danubio y finalmente a Estambul. El tardó más de un año en hacerlo, y el enfoque del libro no es los lugares que visitó, ni los eventos históricos que se desarrollaron a su alrededor (cruzó Alemania y Austria cuando los Nazis llegaron al poder, pero parece que apenas se dio cuenta). Más bien, Fermor está siempre más interesado en las personas que conoció en el camino: barqueros y camioneros, granjeros y comerciantes, incluso un aristócrata ocasional, cuyos regalos de comida, refugio y compañía lo ayudaron a mantenerse en el camino.

Para mi, tal vez para muchos de ustedes, mi tiempo en esta comunidad ha sido un época de regalos, regalos que me han sostenido de muchas maneras en mi viaje durante los últimos 20 años a través de vários continentes, a través de dos géneros y a través de mi vida. Eso me hizo pensar sobre cómo valoramos y compartimos los regalos de nuestra comunidad y cómo muchas personas han comparado las comunidades Open Source como la de Python a una economía de regalos.

En PyCon US escuché a alguien decir, "En Python la gente entiende cómo funciona Open Source." Quizás. Pero tengo dudas de que ese entendimiento sea el mismo para todos. Existen muchas formas de ver las comunidades y yo creo que tienen sus diferencias entre ellas. Pero creo que sí es importante que las comunidades piensen y articulen sus principios, y quiero presentar una forma de pensar en nuestra comunidad que tenga sentido para mí. Ojalá que inicie unas discusiones.

Yo creo (espero al menos) que lo que voy a decir tenga resonancia para la gente de América Latina, ya que muchos de ustedes han experimentado culturas de regalo similares en sus redes familiares y también han visto el daño que puede causar la explotación de recursos y comunidades por dinero.

Por supuesto, lo que voy a decir es solamente mi opinión - me jubilé de la junta directiva de la PSF hace dos años, por favor no les echen la culpa a ellos.

Yo diría que, como una comunidad centrada en un lenguaje y un ecosistema open source, tenemos una orientación de regalos. La definición breve de esta orientación es que la gente contribuye cuando y cuanto puede, y a su vez confía en recibir recursos y ayuda de otros en la comunidad cuando los necesitan.

Estamos tan acostumbrados a los valores de una economía de mercado que nos resulta difícil entender cómo funcionan estos regalos. La entrega de regalos no es como el trueque: los regalos generalmente no se intercambian al mismo tiempo, ni el objetivo es dar regalos de valor equivalente, de modo que todos salgan "iguales".

Más bien, una persona contribuye con algo y en algún momento recibirá algo que necesita de otra persona. Nadie tiene derecho a exigir un regalo, pero aún así, se acepta que todos contribuirán como puedan. Por ejemplo, en las sociedades de cazadores-recolectores, si alguien mata o encuentra algo de comida, lo comparte con todo el grupo, sabiendo que todos los demás harǻn lo mismo.

Este estilo de dar regalos o contribuciones mutuas es lo que vemos en nuestras comunidades de Python - algunas personas están contribuyendo con código, otras con documentación, y trabajan para realizar eventos para su comunidad. Todos estos regalos se otorgan sin obligación y todos disfrutan de los beneficios, ¿no? Algo así como una comuna anarcosindicalista, o como lo que tenían los animales en Animal Farm hasta que los cerdos se convirtieron en dictadores totalitarios.

Y creo que para muchos de nosotros que amamos a esta comunidad, esta es la narrativa a la que recurrimos, particularmente en esos momentos nostálgicos que al menos los ancianos como yo experimentamos en cada PyCon.

Sin embargo en esos momentos nos olvidamos de que las cosas nunca son tan perfectas, tan sencillas o tan idílicas. Como Python, nuestra comunidad, nuestros proyectos y nuestras reuniones han crecido, la situación no es tan clara. De hecho, mucha gente tiene dudas sobre si este modelo de open source alimentado por regalos todavía sigue siendo sostenible.

Supongo que una parte del problema es que el mundo de open source en general y de Python en particular han tenido casi demasiado éxito. Si bien hemos crecido en casi todos los aspectos, el número de usuarios y sus demandas han crecido exponencialmente más rápido. ¿Cómo pueden grupos tan pequeños de voluntarios sostener una comunidad y un lenguaje utilizado por millones?

Es fácil de encontrar varios ejemplos de cosas que salen mal. Un problema es el agotamiento por parte de los voluntarios que hacen que todo funcione. Muchas veces he visto lo que llamo 'estrellas fugaces', personas que irrumpen en escena y comienzan a contribuir a la comunidad, a menudo de múltiples maneras, mostrando cantidades sobrehumanas de energía y entusiasmo. Parece que solo unos meses después de sus primeros eventos, están organizando otros eventos, impartiendo cursos, contribuyendo con código y más. Estos recién llegados son tal exitosos, tan ansiosos de ayudar, que nosotros felizmente les damos más y más que hacer, hasta el punto de que los veteranos como yo comenzamos a preguntarnos, "¿cómo es posible que alguien pueda hacer todo eso?"

La respuesta suele ser que no pueden, al menos no por mucho tiempo. En estos casos, comenzamos a notar que se ven cansados, que el entusiasmo se desvanece mientras la carga de trabajo continúa aumentando. Algunos me han llevado a un lado para preguntarme cómo lidiar con el estrés, cómo mantener todas las pelotas en el aire… y cuando les digo que la respuesta es hacer menos, nunca lo aceptan. Oh, se nota que les encantaría creerlo, pero ahora no tienen tiempo. Tienen un evento para organizar, una revisión o blog post para editar, código para escribir, o llamadas para unirse.

Y después de pocos meses, o un par de años, ellos desaparecen. Los correos quedan sin respuesta, los plazos se retrasan, las pull requests se ignoran, las llamadas se pierden, y tal. Las demandas de todo lo que estaban haciendo como voluntarios combinadas con las demandas del trabajo, las necesidades de la familia, etc, literalmente les han quitado toda la energía. El tanque está vacío y no tienen más para dar, y la relación entre ellos y la comunidad se daña, a menudo de manera irreparable.

También he visto personas que comenzaron más moderadamente, y construyeron su trabajo a lo largo de los años hasta que se convirtieron en key developers, o maintainers, o organizadores clave de la comunidad. Han estado haciendo lo que hacen durante mucho años, por lo general reciben más quejas que elogios, y sienten que su trabajo se da por sentado. En muchos casos, creo que han invertido demasiado para alejarse, pero están cansados, y se preguntan cuánto tiempo más podrían aguantar.

A veces estos líderes han dado más que nadie, y resulta que ellos manejan su proyecto solos. Poseen todas las credenciales, y cada vez que se necesita hacer algo, todo tiene que pasar por ellos. Cuando se les anima compartir la carga, tienden a explicar que pueden manejarla bien y, además, es más trabajo capacitar a nuevas personas que hagan el trabajo. O tal vez sienten que no tienen el conocimiento ni el tiempo para incorporar a nuevas personas.

Cualquiera que sea la causa, todo el tiempo también vemos personas que están ansiosas por unirse a un proyecto de código o un esfuerzo comunitario y ayudar, que terminan siendo rechazadas. Al menos una vez a la semana veo alguien cuyas ofertas de ayuda sinceras, incluso ansiosas, terminan siendo ignoradas por una variedad de razones: nadie tiene el tiempo para incorporarlos, lo que les interesa tiene suficiente gente involucrada, están preguntando en el lugar equivocado, están tratando de entrar en un nivel demasiado avanzado, o lo que sea.

Muchas veces me parece que muchos otros simplemente pasan desapercibidos. Y en estos casos, cada vez que intentan involucrarse y de alguna manera son rechazados, es menos probable que lo intenten otra vez, y terminamos perdiéndolos

El resultado es que nuestros proyectos y nuestras iniciativas comunitarias corren el riesgo de ser abandonados, cuando las personas se agotan sin ser reemplazadas. Así resulta que muchas veces nos encontramos proyectos de open source abandonados, con asuntos sin respuestas, PR's ignoradas, y dependencias desactualizadas. O iniciativas con listas de correo silenciosas, slacks vacíos,et cetera.

Algunos aún dicen que los proyectos open source simplemente funcionan así. Hace un par de meses yo estaba leyendo un artículo sobre la sostenibilidad de open source y un maintainer de varios proyectos de Javascript describió open source como "un modelo que se basa en que las personas dan más de lo que pueden por muy poco o nada a cambio, y con la esperanza de que haya alguien que se haga cargo del manto cuando la persona anterior se queme".

Esa descripción de cómo funciona open source me dice que si de hecho somos una cultura de regalo (y yo creo que lo somos) las cosas van mal. Tenemos personas que dan más de lo que pueden sostener y otros que son capaces (apenas) de sostener lo que dan, pero sienten que no están recibiendo nada a cambio. Ese sentimiento puede empeorar al ver incluso a empresas de Fortune 100 que utilizan su trabajo en lugar de sistemas que solían costar cientos de miles de dólares en derechos de licencia, sin reconocimiento y sin devolver una pequeña fracción del dinero que están ahorrando. Y hay otros que sienten que sus regalos son rechazados. Esto último también es grave: en una cultura de regalo rechazar el regalo de alguien es un insulto, es una forma de decir que no los quieres en la comunidad.

Entonces claramente como una comunidad de open source nos enfrentamos a desafíos. La pregunta es ¿qué hacemos? ¿Qué podemos hacer? Para mí el primer paso es entender lo que está pasando y las motivaciones y valores que están impulsando el comportamiento de la gente.

La manera en la que piensas en algo, la narrativa que te dices, tiene un impacto en cómo lidias con ello, y algunas maneras de pensar en un problema pueden de hecho impedir que lo soluciones. Sé por mi experiencia personal que, a veces, cambiar o aclarar la narrativa puede ser un primer paso importante para manejar mejor una situación.

Entonces, ¿qué impulsa a comunidades como la nuestra? ¿Por qué estamos en una conferencia en que hay tanta discusión sobre la comunidad? Hace veinte años, la interpretación más popular, popularizada en cosas como La Catedral y el Bazar, era que open source estaba impulsado por el interés propio. Interés propio ilustrado hasta cierto punto, ya que en términos prácticos era más probable que obtuvieras lo que querías si eras agradable, pero era sólo interés propio. Las personas trabajaban sólo en lo que les interesaba o beneficiaba, y más allá de eso la única otra motivación era el impulso del ego que podía obtenerse al reflejar que eras tú quien había resuelto el problema, y todos los interesados en el proyecto lo sabrían. De hecho incluso si fueras a hacer algo altruista, sin el estímulo del ego, eso era sólo porque entonces podrías obtener el impulso para tu ego de pensar en lo noble que eras. En otras palabras, era el interés propio todo el camino, hicieras lo que hicieras.

Junto con esto estaba la creencia de que suficientes personas genialmente egoístas que trabajaban por solo sus intereses particulares y para impulsar sus propios egos se combinarían de alguna manera para producir el mejor de los mundos posibles para todos. Como se puede notar, esta visión no incluye ninguna noción de comunidad, servicio o altruismo.

Si tienes esta visión de cómo funciona open source, no hay problema con ninguno de los ejemplos que he mencionado antes. ¿Agotamiento rápido y salida? Pues, el nivel del interés ya no era lo suficiente para que continuaran. O tal vez simplemente no consiguieron impulsos suficientes para sus egos. ¿Voluntarios cansados? Si están haciendo lo que quieren, continuarán, y cuando las recompensas no sean suficientes, van a salir, así funciona el mundo. ¿Proyectos y comunidades abandonados? Eso ocurre por falta de interés y debes aprender a lidiar con eso. Y ¿esos voluntarios ansiosos? Por supuesto no lo quieren lo suficiente, o quizás no son lo suficientemente inteligentes o agresivos para abrirse paso a codazos.

En retrospectiva, muchas cosas escritas hace 20 años sobre esto parecen una mezcla adolescente de Ayn Rand y el capitalismo liberal, y afortunadamente han caído en desgracia. Tampoco estoy reclamando la superioridad moral - en esa época la mayoría de nosotros no cuestionamos nociones como estas, aunque en la práctica en las comunidades en las que estábamos, la gente en general no se comportaba así: en realidad no ponía los impulsos del ego y el interés propio por encima de los demás.

Supongo que todos disfrutamos de varios beneficios de nuestra participación, pero había demasiada gente haciendo demasiadas cosas generosas y altruistas para que el interés propio fuera lo único o lo principal que nos impulsara. Pero si nos hubieras preguntado, te habríamos explicado que así es como funciona open source. Para mí, esa narrativa de interés propio perjudicó a todas las comunidades de open source: alentó la cowboy coding, las flame wars y la fragmentación mientras devaluaba la colaboración, la inclusión y la construcción de comunidades. Es algo que todavía estamos luchando por superar 20 años después.

De hecho la frase famosa de Brett Cannon, (que he usado tantas veces), "Vine por el lenguaje, pero me quedé por la comunidad" resume muy bien como muchos de nosotros hemos cambiado nuestra visión de esta comunidad.

Eso me lleva de vuelta a la noción de dar regalos como algo esencial para nuestra comunidad. Otra vez, si pensamos en los cazadores-recolectores, uno de los ejemplos clásicos de una cultura del regalo, si un cazador tiene éxito, comparte la carne con todos. Claro, el cazador quiere comer, por lo que hay un elemento de interés propio en lo que hace, pero también lo comparte con la comunidad. No es nada especial, es solo lo que se hace.

Por supuesto, no somos cazadores-recolectores, pero yo diría que este patrón nos gusta a la mayoría de nosotros, a la mayoría de humanos, de hecho. Si consideras como se comporta la gente en nuestra comunidad, no es difícil ver el mismo espíritu. Las personas que contribuyen con su código lo hacen porque pueden y porque mejoran las cosas para todos. Claro, a veces el código que ellos contribuyen responde a una necesidad personal, pero muchas veces no es así. Del mismo modo los organizadores de los eventos y las personas en la junta dan mucho trabajo que no los beneficia personalmente.

Sin embargo, podemos (o deberíamos poder) contar con compartir los beneficios de la comunidad. Puede ser apoyo y amistad, o tal vez educación y habilidades, o contactos y una mayor red profesional. Yo sé que he experimentado todo eso, desde que me ofrecieron un contrato para un libro, hasta hacer tantos amigos en diferentes países, algo que me ha animado a aprender dos idiomas en los últimos años. Recuerdo también la PyCon hace 9 años cuando mi padre murió la madrugada del domingo, y esa noche varias personas se sentaron conmigo para asegurarse de que yo no estuviera sola. Lo interesante para mí sobre las culturas de regalos es que el proceso es muy vago y desordenado. Realmente no hay forma de determinar, por ejemplo, que compartir un venado es exactamente equivalente a 15 peces, digamos, a 50 manzanas, o lo que sea. Del mismo modo, tampoco hay forma de determinar que 10 parches de código equivalen a una charla, o 3 reuniones de la junta directiva, o lo que sea. Simplemente no existe una forma de mantener las cuentas exactas: con lo que todos podemos contar es que cuando alguien puede, hace una contribución que todos podemos disfrutar. Y a su vez aportamos lo que podamos y cuando podamos

Este desorden no es un bug sino un feature - no saber ni la hora ni el valor exacto de las contribuciones en realidad funciona para unir a las personas, ya que nadie puede decir con certeza que está exactamente a la par con los demás. En cambio, se da cuenta de que las fortunas de todos están enredadas, que estamos todos juntos en esto. En otras palabras, las contribuciones mutuas, este dar regalos, es lo que ayuda a unir a la gente y crear comunidad. Para mí, articular dar regalos como lo que impulsa a nuestra cultura, lo que crea nuestra comunidad, me lleva a lo que podemos hacer mejor, y que debemos tener en cuenta si queremos preservar nuestra comunidad de Python y si queremos que siga creciendo y floreciendo.

Como individuos, creo que si consideramos que todos en la comunidad están contribuyendo lo mejor que pueden, dando sus regalos a la comunidad, los trataremos a ellos (y nosotros mismos) de manera diferente (y mejor) que si creemos que todos somos impulsados por interés propio y no le debemos nada a nadie. Yo diría que entender que todos nos beneficiamos de las contribuciones de los demás hace más fácil apreciar ese trabajo, los regalos que ellos dan. Espero que también nos impulsará mostrar nuestro aprecio, algo de lo que muchos voluntarios reciben muy poco. Y también debería hacernos un poco menos críticos con los demás, si entendemos que su contribución es un regalo, no una obligación ni una transacción.

En cuanto a esas estrellas fugaces que se agotan rápidamente, tal vez reflexionar sobre dar regalos les ayude recordar que nadie debe dar más de lo que puede, y que lo que podemos ofrecer en cualquier momento es suficiente, y a su vez, nosotros también necesitaremos recibir regalos de los demás. Y espero que nosotros veteranos seremos más inclinados a darles a las personas que se están dando demasiado el regalo de este consejo.

La mentalidad de que somos una comunidad de regalos también puede ayudarnos a compartir más la carga y a dar el regalo de permitir que otros asuman algunas de las tareas que hemos hecho. Como he dicho, rechazar la contribución de alguien muestra una falta de respeto - rechazar su regalo es decir que no queremos que sea parte de nuestra comunidad. Teniendo eso en cuenta, debemos asegurarnos de que haya formas en que las personas nuevas y diferentes puedan contribuir, y debemos dar el regalo de ser mentores y guías para esas personas.

Una parte de esto es que también debemos entregar el liderazgo con generosidad, y dar el regalo de compartir posiciones de liderazgo. Este regalo beneficia tanto al que da como al que recibe. Estoy bien segura de que una de las razones por las que he podido seguir siendo una parte activa e involucrada de nuestra comunidad durante 20 años es que he tenido una política deliberada de traspasar el liderazgo de cualquier proyecto que yo haya creado después de 3-5 años. No es fácil al principio, se siente como una pérdida, pero ayuda a crecer a la gente nueva y mantiene frescos a los veteranos. Lo recomiendo absolutamente.

Otro aspecto relacionado con lo que hace que nuestra comunidad funcione y donde creo que una gran claridad es vital, es cuando se trata de dinero. Hasta ahora deliberadamente no he mencionado la forma dominante que tenemos de compartir recursos: una economía de mercado con intercambios basados en dinero.

Lo que pasa con dinero, con su tendencia a las transacciones exactas, totalmente lo contrario del desorden de los regalos, es que va en contra de la conexión y la comunidad. Se me das algo que vale $5, y yo te doy $5, ambos sabemos que estamos exactamente a la par y la transacción está hecha. No hay necesidad de continuar la relación. Las transacciones no construyen comunidad.

Por eso, nosotros, particularmente como comunidad, debemos tener mucho cuidado acerca de cómo manejamos el dinero. No soy ingenua, en este mundo casi todos necesitamos dinero y yo puedo testificar que es mejor tener un poco más que menos.Eso es cierto tanto para individuos como para organizaciones como la PSF y en general.

Cuando les pedimos a algunas personas que hagan un trabajo de tiempo completo de ayudar a nuestra comunidad, ya sea administrando nuestra comunidad y eventos, o nuestra infraestructura, o nuestro proceso de codificación, esas personas merecen que se les pague de manera justa, incluso generosa. También queremos que nuestras comunidades y eventos sean más inclusivos, y muchas personas necesitarán ayuda financiera para participar. Del mismo modo, fomentar comunidades en todo el mundo requiere dinero, y en el futuro previsible, por diversas razones, las cosas costarán aún más.

Por supuesto necesitamos los recursos financieros para ayudar a la comunidad a seguir creciendo y prosperando. Pero me preocupa la idea de que debemos hacer que las transacciones sean lo más importante en cómo obtenemos los recursos financieros o cómo los compartimos. Lo que quiero decir es que cuando enfrentamos los desafíos de recaudar dinero y luego usarlo en nombre de la comunidad, creo que debemos pensar con mucho cuidado para no convertirnos en "un negocio".

No tengo nada en absoluto en contra de los negocios per se. Me he ganado la vida trabajando para empresas y ayudándolas a tener éxito. Pero yo estoy totalmente en contra de que nuestras comunidades de Python, siendo la PSF el ejemplo principal, actúen como un negocio. He trabajado en varias empresas durante 35 años, y no importa lo que RRHH o Marketing quieren que creas, ser un empleado no es como estar en una comunidad de dar regalos con tu empleador, ni tampoco lo es ser un cliente. Si nuestros contribuyentes se convierten en empleados y nuestros patrocinadores se convierten en clientes, nuestra comunidad se verá disminuida, si no destruida.

Probablemente estoy sesgada, pero creo que hasta ahora la PSF y la comunidad de Python han manejado esto bien. La PSF ha contratado personas para apoyar el desarrollo de la comunidad y para ayudar que la gente contribuya con más éxito en todas las áreas. El dinero se gasta apoyando grupos regionales y locales, y la ayuda financiera para PyCon y otras conferencias también ayuda a las personas con menos recursos a hacer contribuciones a nivel mundial.

Algunos patrocinios se han desarrollado de forma que respaldan a la PSF y la comunidad en general, con pocas condiciones corporativas. Creo que esta es la estrategia correcta: a medida que interactuamos con el mundo empresarial, no debemos tratar de convertirnos en un negocio, sino invitar a esas empresas a unirse a nuestro mundo de contribuciones y regalos. Para hacerlo hay que convencer a esas organizaciones de beneficios intangibles y difíciles de cuantificar. Es algo difícil, pero no imposible, y vale la pena.

Sin embargo, estos son solo los primeros días. Mientras el capitalismo se vuelve más duro, y tanto la importancia de Python como el poder de las grandes empresas de tech continúan creciendo, la tensión entre una economía de mercado y una comunidad de regalos seguirǻ creciendo. En otras palabras, creo que es inevitable que haya más presiones para que abandonemos nuestra cultura de regalos y contribuciones a favor de transacciones monetarias. Podrían ser empresas que intentan comprar el control sobre el idioma y/o la comunidad, o podría ser presión para tratar a los colaboradores y voluntarios más como empleados, o podría ser cualquier otra cosa, pero en los próximos años habrá oportunidades para vender nuestra comunidad por una o otra oferta tentadora.

Cuando eso pase, dependerá de nosotros decidir si todavía queremos ser una comunidad de regalos y contribuciones. Por mi parte, estoy segura de mi respuesta.

Muchas gracias por la atención y muchos abrazos a todos en nuestras comunidades.

The time has come...

As we head into the PSF election cycle, I'd like to let everyone know that I will not be running for re-election to the PSF Board of Directors and consequently from mid June I will no longer be serving as chair of the PSF.

Announcements like this always strike me as awkward, since they make two rather unlikely assumptions: that people will even notice, and that they will care if they do. But in the interests of transparency I'm going to go ahead as if both were true and share my reasons for this decision.

FIrst of all, I truly do believe that limited terms are good for the sustainability of an organization like ours. If someone is in a key role for too long, their inevitable departure and replacement can be unnecessarily disruptive and difficult, even with the best intentions. Of course "too long" can be hard to define, but I think it's safer to err on the side of leaving sooner rather than later. I also think it will be good for the PSF to practice handing off board leadership.

My other reason is that it's just time to move on. After five years on the board and 3 as chair, it seems like it's time to step out of that role and find something different to do, some other way to work for the Python community.

This isn't a dramatic change - I will be available to the next board as an advisor, and of course I will remain a passionate supporter of the PSF and Python communities around the world. So no, you're not getting rid of me that easily. :-D

I do hope that the PSF will continue to work on electing a diverse board, in all of the endless possible dimensions. For one target, I would love to see more representation on the board from Latin America, southern Europe, Africa, and Asia, as well as LGBTQ folks, racial and religious diversity, neurodiversity, and the rest.

If you're one of those people would help make the board more diverse but you're thinking, "yes, but there's no way that someone like me could be elected," well... I was thinking exactly the same thing when I ran for the board 5 years ago. There are no guarantees, but I believe it's worth a try, both for what you might bring and for the experience you will gain. So if that's you, get in touch - I'd be happy to talk about the board and what it involves, and offer any support I can.

It's been a privilege to work with so many amazing people on the board - we may not always have agreed on every point, but you would be hard pressed to find a group of people more dedicated to the success of the PSF and the Python community.

I'm also honored to have worked with the PSF staff as it's grown. They are truly amazing - smart, hardworking, and dedicated. I've seen their work up close, and believe me when I say that we're lucky to have them and they deserve all of the support we can give them.

As we move forward into the changes that the current crisis will bring, I have no doubt that the PSF and its board and staff will be more than up to the challenges ahead.

My time as chair of the PSF has been a lot of things for me - sometimes a challenge, often a learning experience, always an honor and a wonderful opportunity to get to know so many Python communities and their members. But above all it has been a rare and ridiculously improbable gift, something to be treasured, but also to be held lightly, and then passed on.

So long, and thanks for all the fish...

Notes on Teaching Python – Mental Models

I admit it – I’m just an old, cranky teacher. As much I love seeing so many people all around me teaching Python, as much as I love the notion of spreading the joy of Python to various masses, there are things… things that give me pause. No, worse than pause, they give me a serious case of teacher twitch.

I start feeling the overwhelming urge to offer constructive criticism and helpful advice where none is wanted. I usually fight these urges, not wanting to be shunned by everyone as “that woman” (or something worse).

However, I also don’t want to end up in the corner muttering something like “get offa my lawn”. So I’m going to rant gently about some of these twinge inducers here.

What are we teaching, really?

I think one issue arises from a failure to ask ourselves what we really are trying to teach when we are teaching “Python”. It seems like a silly question, or a redundant one, but humor me. What are we trying to teach? Syntax? Best practices? Problem solving? TDD? OOP? What is Pythonic? Coding? Critical thinking? Computer science concepts? All of the above?

I’m pretty sure I’ve heard all of those answers at one point or another, and even given some of them. Yet I’m equally sure that something vital is missing when we talk about what we need to teach when teaching Python. And this something really holds everything else together.

The importance of a mental models

The missing “somethings” I’m thinking of (since in fact there are many of them) are mental models. We may not know every detail of how a thing works, but if we have an accurate mental model how it works, we can form some reasonable expectations about how it might work in different situations.

If I have a sound mental model of how AC current works and see that the lamp has a frayed cord, I can pretty confidently unplug it and deal with the problem. On the other hand, if I have an inaccurate mental model of how AC current works, I might either run from the room expecting the lamp to explode, or reach down and grab the bare wire. Neither is a desirable result, but yes, I’ve actually known people who fall into both categories.

The same is true in Python and coding. If we have an accurate way of thinking about a feature of the language, we stand a much better chance of getting code that works as desired. If we have faulty mental models, then the coding equivalent of electrocution or irrational avoidance awaits.

Take “variables,” please

For example what about “variables”? Yes, I agree that the term “variable” is questionable in Python. Yes, I prefer either “name” or “label”. However, it seems pretty much everyone calls them variables at some time or another, which may well be part of the problem. Several times now I’ve seen newcomers to coding being taught that about “variables” in Python. And many of those times I’ve seen the explanation that a variable is a “container that holds a value.” Or, as I used to say when I taught C, they’re told that a variable is like a bucket.

For C this makes some sense. And while no one should argue too much with the notion that the contents of a variable must go somewhere, in fact thinking of Python variables as containers is an inaccurate model – names in Python are more like post-its than buckets. But what makes the notion of variables as buckets even more insidious is that it seems to work well enough at first that people get used to thinking this way, and then pass it along.

Consider the following mindless code:

    a = 1
    b = a
    c = b
    print(a, b, c)

So far, so mindless. If you ask people what you get, they will not have a problem saying 1 1 1.

But suppose you then add the line

   b = 2

and ask about print(a, b, c)?

The followers of the bucket camp will usually (and correctly) say that the result is 1 2 1. In fact, there may be some confusion about what the “contents” of c are, but if you are thinking buckets, the answer makes sense.

But what about a mutable object? Suppose we have this:

    a = [1, 2, 3]
    b = a
    c = b
    b[1] = 5
    print(a, b, c)

Here the members of the bucket brigade are often stumped. In my experience I have been stunned at how many beginning (even intermediate) Python coders are surprised by the actual output of [1, 5, 3] [1, 5, 3] [1, 5, 3]. If variables are containers, how on earth can changing the contents of one change the others?

But if instead they are names that point to objects, the right answer makes sense. Once they have a better mental model of how names work in Python, such surprises (and the attendant bugs) become much rarer.

Let me be clear, this example isn’t the only case of poor mental models in teaching Python. I’ve picked on this example because it’s so fundamental and, in my experience at least, so common.

The question is not if our students will create mental models or not – we all form mental models as we learn. It’s our job as teachers to be thoughtful and help our students form useful and accurate ones.