Author Archives: rrees

Blogging, Python

PyCon UK 2022

This was the first in-person PyCon since the start of the pandemic. It had slightly changed format as well, now being mostly single-track (plus workshops) and not having a teacher/youth day. Overall I found the changes welcome. I’m generally a big fan of single track conferences because they simplify the choices and help concentrate the conversation amongst the attendees.

A lot of talks were by developer advocates but some of the most interesting talks came from the core language maintainers talking about the challenges in balancing the needs of different parts of the community while the least interesting were from the company sponsors who generally didn’t seem to have refined their content for a general audience.Typescript

A simple lightning talk about the need to sanitise the input of the builtin int function was illuminating about the challenges of reconciling web needs versus data science. However the general point about whether unlimited number functions are necessary or not was interesting. Similarly the challenge of when to adopt new syntax and keywords in the case of the addition of Exception Groups to the language.

There were a few talks about how the process of maintaining a language and community actually works. How conferences get listed on the Python website, how performance benchmarks are built and used and the desire to have a single place to centre conversation about the language.

There were talks about how to interface to various technologies with Python (Kafka, Telegram) and the inevitable talk about how to improve the performance of your data science code by using NumPy. There were also quite a few talks about Hypothesis; which probably still isn’t used as much as it should be in the community. The library now includes a test generator that can examine code and suggest a test suite for it which is quite a cool feature and certainly would be a boon for those who dislike test-first approaches (whether it has the same quality benefits is another question).

The other talk that had a big impact on my was the introduction to using PyScript in static websites. Python is going to start targeting WebAssembly as a platform which will help standardise the various projects trying to bring a fully functional interpreter to the browser and provide a place to pool efforts on improvements.

PyScript aims to allow Python to also script DOM elements and be an alternative scripting language in the browser. That’s fun but not massively compelling in my view (having done many compile to Javascript languages in the past I think it’s easier to just do Javascript (with an honourable exception for Typescript). Being able to run existing code and models in the browser without change maximises the value and potential of your existing Python codebases.

Cardiff remains a lovely venue for the conference and I think it is worth taking time out from the tracks to enjoy a bit of the city and the nearby Bute Park.

Links

  • Pyjamas, a 24 hour online conference
  • Pyrogram, a Python library for interacting with Telegram
  • HPy, an updated API for writing C extensions in Python
  • Discuss Python, the general Python community forum
  • Trustme, a testing library that allows local certificates as testing fixtures
  • PyScript, Python in the browser via Web Assembly
  • PyPerformance, benchmarks for testing Python implementations
Standard
Blogging, Work

Trivialising stress with “Wellness at Work”

Burnout is a complex topic but employer responses to it are even more complex. Some definitions of burnout make it a direct occupational health hazard and therefore something that all employers need to consider and manage.

But the way that many companies are responding is facile and, as many other people have already pointed out, patronising to employees and minimising the employer’s own responsibilities. Occupational stress is not something that is resolved by reminders of “mindfulness” and the offer or an meditation app and an employee helpline.

Stress at work is probably inevitable for most workers employed by organisations. The friction and pressures of work continually generate stress which needs to be managed through conventional tools like support and leave. An employee does need to be aware of the indicators and behaviours associated with their own stress but this is probably something that requires some individual coaching rather than an app and a video lesson.

By offering inadequate or lackluster support employers seem to put themselves in the worst possible position, acknowledging their responsibility for the occupational nature of the problem and yet not offering a meaningful solution to it. Ultimately some reckoning seems inevitable in this situation.

A deeper review of the origins of stress within the organisation is needed. Things like client interactions, challenging targets, arbitrary deadlines, interpersonal issues may all be deemed a necessary part of an organisation’s management but acknowledging the consequences of these sources of stress and figuring out how the consequences can be managed and ideally neutralised through more positive activities is vital management work.

Commercialised wellness is an almost meaningless marketing concept, mixing it with the realities of workplace stress seems a recipe for disaster rather than the cheap, effortless fix some employers seem to think it is.

Standard
Programming

Keeping the batteries included

Python is well-known for being a “batteries included” language which means it comes with a rich variety of modules that work right out of the box. However this recent post about the regular expression library shows the problems that can occur from shipping such a wide variety of code as part of the language core. Maintaining a wide-ranging codebase is challenging as is keeping it aligned to a language’s release cadence.

The problems suggest that really the language should focus just on the core tools and syntax of the language with everything else being on a different release cycle. However by itself that core isn’t too useful for pragmatic coding purposes. Curation of code and having a sensible selection of libraries is a challenge. Some languages like Clojure and Elm have a controlled ecosystem of libraries that are adjacent to a small language core. However here the difference between curation and gatekeeping is fine and it feels like only languages with a large community can do it effectively.

Perhaps the answer is to have a basic implementation of core functionality in the core but to use the language documentation to suggest alternative libraries. This moves the problem to the documentation team but hopefully this is a simpler arena to both maintain and curate.

Standard
Software

State of the Browser 2021

This is the first in-person conference I’ve been to since the pandemic and since it normally clashes with PyCon UK this is also the first State of the Browser that I’ve been too in a while.

As a high-level pitch for the conference it a chance to hear from standard makers and browser developers about their thoughts on the web, web standards and issues in web development.

The conference had an audience of probably a third of what I felt it had the last time I attended in person. There was not issue with distancing and you could add a stickers to your attendee batch to nix photography and to ask for people to keep their distance.

Usually the chance to socialise and network is a major part of the conference experience but once I was there I realised that I didn’t really want to spend the time required to get to know someone new while COVID is as prevalent as it is, not attend the generous post-conference drinks.

Which made me wonder why I was there at all. The answer, on reflection, is that being physically present meant that I was actually present for the talks as well. I’ve bought tickets for virtual events earlier in the year and I still haven’t watch the videos.

By physically turning up I did pay more attention and I did engage and learn more than I did virtually.

I found a few things about the conference frustrating though. Firstly a number of the speakers weren’t there and instead had recorded a talk so being at the conference ended up being a collective video watch without being able to control the video and skip the boring bits. Also there were no questions from the audience because that was being handled on Discord. Now most of my Discord is taken up with gaming because, y’know that’s what Discord pretty much is for the most part. So I wasn’t able to see that side of things because I didn’t have time to set up some kind of work account. But generally whether it was Slack or something else I kind of think having the questions on the conference chat meant that the talks were actually lectures and where the speakers weren’t that proficient with their delivery it made the talks more boring.

So at the end of the experience I have no idea as to whether my attendance was a good idea or not. I probably would have been distracted at home but at least I could have sorted out Discord and have watched the pre-recorded videos in a more comfortable environment (I certainly could of dodged the morning torrential rain).

But when there was a good in-person speaker it was great. Rachel Andrew was the standout for managing a review of the history of layout systems while also previewing the thinking of the standards groups. In particular drawing a fascinating line between the necessity of the contains CSS directive to the ability to be able to look forward to container queries. Stephanie Stimac shared similar insight into what the future may hold for the development of the Form elements and their backwards-compatible codification and customisation.

Alex Russell offered a rebuttal of the locked down mobile ecosystems from a capitalist perspective but failed to really offer remedies given that this overall is a capitalist failure.

In a totally different vibe Heydon Pickering did a talk about requiring people to switch off Javascript to read his blog. It was closer to standup and I did laugh out loud several times although trying to explain what made it funny and entertaining has proven highly difficult.

Rachel Andrew is one of the people behind Notist which a few people were using to share slide links. I hadn’t heard of it before and I can see it’s pretty handy compared to trawling Youtube trying to figure out if some talk you half remember has been posted there.

Overall I think it was worth the effort, I felt I got outside my bubble for a while and felt a bit more connected to the efforts that are still ongoing to safeguard and advance the web as a whole.

Standard
Web Applications

Email services in 2021

I read this article about switching away from GMail and it struck a bit of a chord in terms of my own attempts to find a satisfactory replacement.

At the moment I feel I’m using all the services and at some point I should actually pick one or two that actually meet my need.

I have ProtonMail and Tutanota accounts for security. In truth I’ve ended up using neither (unless I see someone else using a ProtonMail address).

Day to day I’m probably still using GMail for most things and Fastmail for things where I don’t want to embarrass myself with my GMail address which is based on a gaming handle. Therefore over time my Fastmail address has become my address for financial things, communication with tradespeople and professionals and the odd real-world email invoice and so on.

It may sound strange but the biggest reason I don’t use Tutanota more is that it is hard to communicate verbally to other people. Fastmail still needs to the first word to be spelled out but people expect the XMail.com format and seem to have a lot less trouble with it.

I was on the verge of unsubscribing from Hey when it had it’s massive wobble over handling political issues at work (or alternatively white privilege, whichever way you see it). Rightly or wrongly I’ve kept on using and paying for it.

The strange niche that I’ve found for it is communicating with my extended family and occasionally a bit of business communication. The mail handling features just seems to work really well in terms of not wanting to respond immediately but wanting something better than “star” or “pin”.

When I started with Hey I was very excited about the “Feed” feature for managing email newsletters but after a while I’ve found myself not using it very much and instead I’ve started using Feedbin for these instead.

The Hey Paper Trail function is also good but when it comes to things like online orders I find the delivery updates easier to handle in GMail.

However exactly like the author of the article Fastmail is the most complete replacement for GMail having a similar functionality set (including a calendar) and while Hey might be better for having a well-managed near-zero mailbox, Fastmail is better for the pragmatic keep it all and search it when you need it approach to email.

Standard
Programming

PR Reviews: not the messiah, not a naughty boy

On Tech Twitter there seems to be a lot of chat recently about how the Github Pull Request (PR) review process is “broken” or underserves internal teams (an example) that have strong collaboration practices such as pairing or mob coding.

Another objection raised is the idea of internal gatekeeping within development groups, I’m not sure I fully follow the argument but I think it runs along the lines that the PR review process allows powerful, influential members of the group to enforce their views over the others.

This is definitely a problem but frankly writing AST tools linked to the “merge to master” checks is probably a more controlling tool than spending your time policing PRs.

With open source projects often all the action happens at the pull request because the contributors often have no other interaction. Proponents are right to point out that if this works for open source projects do you really need to put effort into other practices upstream of the PR? Opponents are also right to point out that adopting the work practice of an entirely different context into your salaried, work context is crazy. They are both right, individual organisations need to make deliberate decisions using the challenges of both side to the way they are working.

I’m not sure how much of this is a fightback by pairing advocates (that’s how I interpret this thread). There is a general feeling that pairing as a practice has declined.

In my work the practice is optional. As a manager I’ve always known that in terms of output delivery (which before people object, may be important particularly if you’re dealing with runway to meet salary) pairing is best when you’re increasing the average rather than facilitating the experienced.

I think even with pairing you’d want to do a code review step. Pairs are maybe better at avoid getting into weird approaches to solutions than an individual but they aren’t magical and if you are worried about dominant views and personalities pairing definitely doesn’t help solve that.

So I’d like to stick up for a few virtues of the Pull Request Review without making the argument that Pull Requests are all you need in your delivery process.

As an administrator of policy who often gets asked about Software Development LifeCycles (SDLC) as a required part of good software governance. It is handy to have a well documented, automated review process before code goes into production. It ticks a box at minimum disruption and there isn’t an alternative world where you’re just streaming changes into production on the basis of automated testing and production observability anyway.

As a maintainer of a codebase I rely on PRs a lot as documentation. Typically in support you handle issues on much more software than you have personally created. Pairing or mob programming isn’t going to work in terms of allowing me to support a wide ranging codebase. Instead it’s going to create demand for Level 3 support.

Well-structured PRs often allow me to understand how errors or behaviour in production relate to changes in code and record the intent of the people making the change. It makes it easier to see situations that were unanticipated or people’s conception of the software in use and how that varies from actual use.

PR review is also a chance for people outside the core developers to see what is happening and learn and contribute outside of their day to day work. Many eyes is not perfect but it is a real thing and people who praise teaching or mentoring as a way to improve technique and knowledge should be able to see that answering review questions (in a suitable form of genuine inquiry) is part of the same idea.

PRs also form a handy trigger for automated review and processes. Simple things like spelling checks allow a wider range of people to contribute to codebases fearlessly. Sure you don’t need a PR to use these tools but in my experience they seem more effective with the use of a stopping point for consideration and review of the work done to date.

Like a lot of things in the fashion-orientated, pendulum swinging world of software development good things are abandoned when no longer novel and are exaggerated to the point that they become harmful. It’s not a world known for thoughtful reflection and consideration. But saying that pull request reviews undermine trust and cohesion in teams or a formulaic practice without underlying benefit seems unhelpfully controversial and doctrinal.

Standard
Software, Work

The problem with developer job titles

Job titles are hard. This exchange on Twitter prompted a few thoughts that I couldn’t quite fit into a few smart-arsed twits.

In Chris’s Tweet he mentions that engineer is a co-opted title and that engineering is a discipline in its own right which most software groups don’t subscribe to because they aren’t really trying to do engineering. Not that this is a criticism but there is a massive difference between building a bridge or a road and creating a new web service. For a start there is a lot more established practice, science and understanding in physical engineering and more established and understood formal qualifications.

When I briefly worked in government helping create the Digital Careers framework people who were associated with Defence rightly objected to the confusion between software “engineering” and other engineers within professional frameworks. No-one is going to ask a developer to fix the combat damage on an airfield. I’ve previously joked that if we were honest we’d talk about “software overengineers” given that most developers struggle to find the simplest thing that works.

For the framework we settled on “developer” for people who wrote code and inconsistently used “engineering” for operational roles. I think on the basis that they created “infrastructure” where maybe the analogy makes a sort of sense.

I would also have gotten rid of “architect” if I’d had a chance; for exactly the same confusion but that term was too deeply embedded and still is a badge of prestige within the industry. Even now in the commercial world I have experienced hires wanting to be involved in “architecture” (and sadly not wanting to help me remodel my ground floor).

In Chris’s tweet he asks about what happened to the title “Programmer”. When I started in the industry this was indeed the coveted title and ideally I still think of myself this way even though it’s blatantly not true in the same way now.

However the issue with being a programmer is that jobs that literally involve just programming are few and far between. When I started in the industry the experienced developers were people who were at the tail-end of mainframe programming and a bit of what they were doing was still persuading machines to perform the tasks that were needed. The end was already in sight for pure programming jobs though. Some of my first professional programming work involved networking, a slightly dirty topic for the mainframe types.

Nowadays the emphasis is on understanding the domain space you are working on as well as the technical aspects of programming. I prefer the term “developer” (as others do) with the implication of being someone who develops systems of value via the medium of technology.

However that term also has its problems. When I worked at the Guardian I had a personal SEO battle with the Pune-based property development group for the search term “Guardian developers”. That battle seems to have been won now via sub-domain. This seems to be true more generally and now it is property developers who are having to use the prefix “property” on their job titles.

For a new profession not even past it’s first century, creating our professional lexicon is always going to be hard but in borrowing titles so shamelessly we are always creating problems for ourselves.

Programmer is probably the closest, truest name for what most of us do at the core of our role. For web developers though, assembling the typical bricolage of libraries and tooling is often an exercise in minimal programming and maximum duct taping. Perhaps it fairest to say that we are “software assemblers”, expect that might get confused with, you know, assemblers. Painful.

So in the end most of us are expected to bring capability in programming within teams that are creating technological systems of value. As long as programmers realise that programming is not the activity of value in itself then maybe we don’t need to worry so much about titles.

Standard
Web Applications

Roam Research: initial thoughts

Roam Research not only justified subscribing pretty much up front but has also made it onto my pinned tabs in virtually no time flat. It’s basically a web-based knowledge management system. I’m already a fan of Workflowy so I’m already comfortable with putting information into trees and hierarchies, in fact there’s a lot of overlap between the two applications as you can just use Roam as a kind of org-mode bulleted list organiser.

The thing that makes it different is the ability to overlay a wiki-like ability to turn any piece of text into a link which creates another list page to store other notes.

The resulting page highlights the linked portions of the trees in other pages as well as containing it’s own content.

The links then form a graph that can be explored but I haven’t generate enough content for it to be generating any useful insight yet.

The pages are searchable so you can either take wiki-like journeys of discovery through your notes or just search and jump to anything relevant in your knowledge graph.

By default the system creates a daily “diary” page for you to record notes in an initially unstructured way organically as you roll through the day. I’m still primarily in my todo lists in a Getting Things Done mode during the day but I have found it a useful end of day technique for reflecting or summarising ideas to follow up on.

Roam is very much influenced by and part of the new wave of knowledge management tools based on Zettelkasten. If you’re unfamiliar it’s worth reading up on it (I don’t know it well enough to create a pithy summary).

To date though everything I’ve tried in this space was a bit formal and tricky to get going or fit into my existing ways of working. Roam on the other hand is web-based, relatively quick and usable and uses enough metaphors from existing systems to make it feel accessible.

Weirdly the first use that convinced me I needed this service was actually recipes. You can have a hierarchy of different types of recipes but use a link and you can have a vertical slice across ingredients or techniques.

The second was while genuinely doing some market research on Javascript enhancement frameworks where I wanted to have one page for my overall thoughts (“Is this something to pursue?”) and was able to break the list of all the frameworks I was looking at into their own pages with links to the frameworks and any thoughts I had as I was playing around with them.

The mobile experience isn’t quite as good, it’s a kind of fast noting system where I’m not sure how I can quickly attach a thought to an existing page. Here it’s still easier to use a note-taking app and consolidate thoughts later.

Overall though this is still the most exciting web app I’ve used this year.

Standard
Programming

Recommendation: use explicit type names

I attended an excellent talk recently at Lambdale about teaching children to code (not just Scratch but actual computer languages) and one of the points of feedback was that the children found the use of names in type declarations and their corresponding implementations in languages such as Haskell confusing because frequently names are reused despite the two things being completely different categories of things.

The suggestion was that instead of f[A] -> B it was simpler to say f[AType] -> BType.

Since I am in the process of introducing Python type checking at work this immediately sparked some interest in me and when I returned to work I ran a quick survey with the team that revealed that they too preferred the explicit type name with the suffix Type rather than package qualifier for types that I had been using.

Instead of kitchen_types.Kettle the preference was for KettleType.

The corresponding function type annotations would therefore read approximately:

def boil(water: WaterType, kettle: KettleType) -> WaterType

So that’s the format we’re going to be adopting.

Standard
Work

Is it worth speaking at conferences?

I have been reading Twitter more often recently due to Brexit and I came across this mini-controversy that resonated with me.

Should you talk at conferences?

No, it’s a lot of effort that could be better spent on achieving your goals.

Yes you should if you’re from an under-represented background you should because it gives you visibility that is useful for developing your career.

Yes because it’s helpful for consolidating your understanding of a topic.

I certainly recognise this one, until you have to explain something its hard to say to prove that you really understand rather than having a strong intuition as to how something works

Yes because otherwise conferences are all-white boozy brofests.

The interesting point here being the idea that inclusion inherently leads to a loss of prestige in an activity because exclusion and prestige are related.

My lived experience

I did do conference talks to help build my “personal brand”. When I worked at ThoughtWorks it did help my career to be able to point that I was involved in community activity. At Wazoku I did talks simply to make people aware of the company.

At the Guardian doing talks was also important for your career because talking about our work was important to the organisation. In my early years there people at recruitment events were surprised to discover the Guardian had a in-house development team. I’m not sure that is was necessarily expected of everyone but at a senior level it was certainly an important part of the job not just to do the technical work but to ensure people outside the building understood what as a group we were doing.

At GDS doing talks was a complete pain because you had to get clearance for everything you were going to say and also there were various rules about the type of events and the representation at the events you could speak at. The level of bureaucracy around something that was already by this point a bit of a chore meant that I did one prior commitment and then basically stopped doing technical talks.

Stepping out of the cycle of trying to create and pitch talks was great. I just bought my ticket to events like a normal person and it was interesting to look at what value conferences were providing to me.

Relapsing

Recently though I did try doing some talks again. One of them about pop psychology concepts that are wrong was a very personal hobby horse. I don’t want to attend another talk where someone talks about various brain types (neuro-diverse, left-right, female-male, emotional intelligence) so I thought I do a talk about what is currently known about the mind and psychology.

Preparing was easy as I just needed to record various interesting bits and pieces as I came across them. Giving the talk was intense though. After a while not doing this kind of thing, getting up in front of people and aiming to entertain and inform them was a crushing pressure. Proper hand-trembling, mouth-dry, stage terror stuff.

The feedback was generally positive and I thought that while it had been a baptism of fire I was going to get back in the swing of things.

The next talk was to help a friend get their conference going in the North of England. It related to work activity so again preparation was not too hard… until the venue organisers said they needed the talk in Powerpoint format, which is not a program I own. They also needed the talk slides a month in advance whereas normally I will only finalise my content a couple of days before I am due to give the talk.

But I went ahead and cut a version of the slide deck via Google Docs. Fortunately I prefer to try and talk around my presentations and not heavily use slides so I just needed to try and sort out my tentpole slides and submit those.

The talk was reasonably well-attended and I was able to get a few questions going rather than presenting slides (a third of the deck ended up not being used). I genuinely prefer the Q&A format to the normal talk format. I was gratified to hear my talk referenced by other speakers later in the conference. However later in a vote on the most popular talk, my talk came last. I’m not sure anyone voted for it. I knew I hadn’t really gone for an entertaining format but I hadn’t thought it was that bad.

Later in the year I gave another version of that same talk. This time cut down to a running time of 20 minutes which required two weeks of practice. I was able to reuse the slides from the abortive earlier version but they still needed heavy restructuring to fit the new shorter format.

The talk got very little feedback on its second outing, no-one walked out though, which is positive. After the event the conference feedback system provided a score of 3.5 out 4, which I feel might be good or at least some proof that some people found value in it or possibly only a handful of people provided feedback.

The talk came at a particularly busy business time of year workwise and I don’t think I’d volunteer to do such a thing again due to the pressure of having to manage both preparation and regular work things.

Is it worth giving talks?

Giving talks for “personal brand” is essentially about making yourself feel like a known quantity to other people in your industry who you want to influence or have good relationships with. That might be clients you want to sell to, people you may wish to hire or employers who might hire you.

The truth is you want to achieve this as simply as you can with as least effort expended on your part. Talks, unless you are good at extemporising off the cuff, are probably more effort than the value they return.

A lightning talk, well-executed, might well have the same effect as a longer, more involved talk.

Giving a talk about something you care about or what to change in your industry is almost certainly worth it. Although it is the same amount of work, putting together your thoughts and arguments has value to you even if no-one ever hears the talk.

Also to some extent I think passion talks are easier to deliver. You are not really trying to entertain the audience beyond establishing enough rapport to get your message heard.

In terms of career development though I don’t think talks and conferences ever really helped because I’m simply not a good enough networker.

Many people have said that they enjoy talking at conferences because the talk serves as an icebreaker for meeting and talking to new people (as long as it is early in the programme). That has definitely been true for me in the past, and I totally recognise how much easier people find it to talk to me when they can hook it onto something that I’ve presented about.

If you are that kind of extroverted introvert then doing talks makes attending the conference more enjoyable and it makes sense to put in the work they require. Although again you want to limit the amount of effort you put in because the outcome you want is facilitated by the talk but the talk is not the point. You are giving the talk to help you to meet new people and find it easier to build a relationship with them; that’s where the effort should be spent.

So should I still be giving talks? Well at this point I think they do consume more effort from me than say, writing this blog post.

In terms of community or career-opportunities getting into roundtable discussions and breakfast meetings with senior technical people has more impact than talking at conferences with a general developer audience.

But talking and engaging audiences is a skill and a hard one to acquire and maintaining it requires practice. Therefore I probably should keep my hand in, but I should try to choose topics that I feel excited about and I should think about the format and make sure the effort involved is proportionate.

I should also think about the nature of the conferences I am pitching to so that I have a decent chance of succeeding in the selection while having the greatest chance of actually enjoying attending the conference and learning something as a result.

It’s also important who else is attending due to the networking effect. Beginner-friendly conferences while valuable are not going to fulfil my needs.

Therefore I think talking at conferences is valuable but you need to understand what you’re trying to get out of it rather than pursuing it as an abstract good in itself.

Standard