By Carl Newton (pictured above, blue T-shirt), Socitm Web and Digital Development Manager
Here at Socitm HQ, we have two developers who are masters in the art of making web thingys. I am one of those developers, and I build and maintain web thingys all over the shop in order to support our services. For instance, socitm.net is our long-standing flagship website. The Women in IT site is another example of a website we built. We have some internal web apps too, such as our purchase order management system, which we called ‘Spom’, much to the disapproval of everyone, ever. But we strongly believe in the ‘We made it; we name it’ rule, which any parent of a child named ‘Harley Quinn’ will tell you, is a just and fair rule indeed.
Here’s the thing about web thingys (I’ll stop saying that in a while, let me just get it out of my system): they aren’t the ‘drag-and-drop’, ‘five minutes and you’re done’, ‘one size fits all’, easy-as-pie process that the banner ads tell you they are. Okay, maybe they are for a personal blog or something equally straightforward. But for an infrastructure like ours it takes a lifetime of obsession and poor posture to achieve what we do. Glamorous working conditions aside, it also takes a programming language. Several, actually, but the main programming language we’ve been using in recent years is called Python. Most people won’t ever need to know or care about the kind of snakes we use to keep Socitm’s systems working, but just know, us developers love Python.
Socitm’s web team (Richard and I) love Python so much that we went to a conference dedicated to the language. It’s called PyCon and the name is even more fun when spoken aloud due to sounding like a conference for eating pies. But Socitm did not pay for us to attend a pie eating conference. And if you believe this to be an injustice, please contact firstname.lastname@example.org with any expletives you deem necessary…
Okay, so now you’re up to speed, you know what Python is and you know what PyCon is, let’s get to the good stuff…
1: Prepare for growth
All kinds of zany things happen to our systems every now and again. For instance, about a year ago we encountered an unfriendly computer that posted a forum thread on socitm.net every second or so overnight, linking to some pirated movies. By the time I found out what happened, we had 70,000 users on our doorstep looking for Jurassic World and a stern warning from Google about piracy on the internet! We were very surprised, because Jurassic World isn’t even a good film.
Our technical issues are often reasonably small and can be resolved by sniffing out the cause in an afternoon or so. This is because we have a small infrastructure: two developers and probably fewer than 20 web apps talking to each other. I wouldn’t use the word ‘simple’, but things are manageable at this size.
On the first day of PyCon I was speaking to a fellow Python enthusiast about how the company he works for manages its infrastructure. He told me that the several hundred developers there are all great at their jobs, and do some fantastic and creative things in order to keep things running smoothly. The problem they have, he went on to explain, was that it’s very difficult to keep an eye on the bigger picture when all the cogs are turning in an ever-expanding system like that. “Is this piece of code running anywhere?”, “Is this repository maintained by anyone?” and “What’s this code actually doing?” he says he often asks — questions I have never had the misfortune to have to raise.
“That’s what the documentation is for though, right?” I queried. He was amused “Ha! Documentation!” he responded.
Quite often, when starting a small project, and when I’ve been asked to get it running in no time at all, I’ll skip the documentation. Clearly this doesn’t pay off in the long run, and it’s best to document right from the start if you are to grow as an organisation.
2: Playing is important for development
I don’t personally get the time to play with programming. At least, not in the same way some of the people I met do. For instance, after meeting some fellow Python fans for a burger, we got chatting about emojis. If you haven’t heard of emojis before, you might recognise them under the ☺️ icon on your phone’s keyboard. For reasons beyond my concern, these little icons are supported as actual text in a lot of places now.
“I have an idea!” shouts one developer, who is admittedly a little tipsy. “We should write an emoji programming language!”. Everyone else is excited and before I know it, there are five open laptops on the table and the waiters are looking perplexed, as though their own menus using the bog-standard alphabet might not cut the mustard any more.
Now, I promised myself that I wouldn’t be pasting any code into this post, but when making promises to myself, I sometimes lie. This is just to demonstrate what some code in a programming language would look like:
def favy(language): favy_lang = 'My favourite language is ' + language return favy_lang for language in ['English','French','Python']: print(favy(language))
The idea cooked up by my new loony friends was that you’d have to write something more like the following in their language:
✍️ 🌟🌜🌐🌛: 🌟🌐 = ‘My favourite language is ‘ ➕ 🌐 ↩️ 🌟🌐 🍀 🌐 👇 [‘English’, ‘French’, ‘Python’]: 🖨🌜🌟🌜🌐🌛🌛
Have you ever tried typing the letter ‘🍀’? Try typing it right now…
Difficult, isn’t it? Of course, this is of no use to anybody! But that hasn’t stopped them. At the time of writing this there are five people now working on this new language. Who knows where this will lead?
Also among the more playful of the delegates, there were:
- A woman who wrote a program which writes programs
- A young boy who built a device for cheating in exams
- A man who built a cat-flap which unlocked when it recognised his fictitious cat
- A man who wrote a website which finds proof of aliens* on Google maps (*spaceships which look suspiciously like centre pivot irrigation systems)
This kind of silliness, with no worries about deadlines or end-users, is perfect for honing your skills and learning things you would have never otherwise known. I’m looking forward to starting some of my own silly projects soon.
3: This is just the tip of the iceberg
Meeting so many people with different backgrounds who use Python in their everyday lives has made me realise the extent of the language. There are massive communities built from subsections of the language, and communities built from those communities! DjangoCon for instance, is a conference for those who build using the Python Django framework. Django Girls is an organisation supporting women in programming with workshops and resources. This is a fraction of what is out there, and we aren’t even talking about the syntax of the language itself! This is the same for anything in technology. It is developing at such a rate that if you take 20 minutes to learn something new, it’s probably out of date!
The truth is, the majority of what I’ve learned for my everyday job consists of aspects of the syntax itself:
- You can list almost everything within any object with Object.__dict__
- ‘is’ compares the allocation in memory, not the values
- Super() is a thing, and it’s really quite super!
But without being a programmer yourself, it’s difficult to understand these things and why they are helpful for what I do. Not a problem. Here’s where point four comes in…
4: ‘That it’s done’ is more important than ‘How it’s done’
Getting the right tool for the job is important, obviously! But there is often a great deal of time and energy spent on deciding the right tool. One thing I asked for at Pycon was advice on automated testing. Someone said “Oh, use Mock. It’s lightweight, fast and does the job!”, before another chipped in with “Yeah, you could use Mock, but it’s quite brittle. PYVCR is slightly better, but still fairly brittle and couples you to requests.” A third person added “Oh you should probably use Betamax.” After all this chatter, everyone finally agreed on something “All of these options have benefits and drawbacks. You could spend a lifetime deciding between them. Pick any of them now, start writing tests now. If you find another package might be more suitable, change it later.”
A similar thing was said in a talk about software development methodologies. There was the waterfall method, then Spiral, then SCRUM, Agile, RUP, RAD, JAD and every other fad! Each promising to solve all of your problems. The one thing all of them have in common is that they are there for developers. Problem solvers. The problem tends to get solved regardless of, and sometimes in spite of the method.
“No method can replace thinking.”
5: We work best when working together
It must be said, PyCon has introduced me to a community that is incredibly friendly, helpful and uncritical. This is the nature of people interested in open source — they want to contribute.
I saw plenty of examples of people who said they had a problem or a gap in their knowledge and got help from a fellow delegate. “Here’s what you can do” instead of “You should have done this” is an example of the careful language used to make everyone feel comfortable.
We had an announcement about a planned PyCon in Zimbabwe, which needed 3,600 EUR to go ahead. Within a couple of hours we donated enough to surpass that goal.
I also saw delegates operating cameras, carrying equipment and taking the role of teachers.
I really hope to spread this sense of community, passion and collaboration.
These are just five of the thousand valuable lessons learned during my time at PyCon, but not unlike The Matrix, you can’t be told what PyCon is, you have to experience it for yourself.
If I don’t see you there next year, just rest assured that the pies are delicious.