Monday 12 February 2024

Lessons from (and for) colleagues - and, implicitly, how NOT to get on

I have had excellent colleagues both at my day job and, especially, in Debian over the last thirty-odd years. Several have attempted to give me good advice - others have been exemplars. People retire: sadly, people die. What impression do you want to leave behind when you leave here?

Belatedly, I've come to realise that obduracy, sheer bloody mindedness, force of will and obstinacy will only get you so far. The following began very much as a tongue in cheek private memo to myself a good few years ago. I showed it to a colleague who suggested at the time that I should share it to a wider audience.

SOME ADVICE YOU MAY BENEFIT FROM

Personal conduct

  • Never argue with someone you believe to be arguing idiotically - a dispassionate bystander may have difficulty telling who's who.
  • You can't make yourself seem reasonable by behaving unreasonably
  • It does not matter how correct your point of view is if you get people's backs up
  • They may all be #####, @@@@@, %%%% and ******* - saying so out loud doesn't help improve matters and may make you seem intemperate.

 Working with others

  • Be the change you want to be and behave the way you want others to behave in order to achieve the desired outcome.
  • You can demolish someone's argument constructively and add weight to good points rather than tearing down their ideas and hard work and being ultra-critical and negative - no-one likes to be told "You know - you've got a REALLY ugly baby there"
  • It's easier to work with someone than to work against them and have to apologise repeatedly.
  • Even when you're outstanding and superlative, even you had to learn it all once. Be generous to help others learn: you shouldn't have to teach too many times if you teach correctly once and take time in doing so.

Getting the message across

  • Stop: think: write: review: (peer review if necessary): publish.
  • Clarity is all: just because you understand it doesn't mean anyone else will.
  • It does not matter how correct your point of view is if you put it across badly.
  • If you're giving advice: make sure it is:
  • Considered
  • Constructive
  • Correct as far as you can (and)
  • Refers to other people who may be able to help
  • Say thank you promptly if someone helps you and be prepared to give full credit where credit's due.

Work is like that

  • You may not know all the answers or even have the whole picture - consult, take advice - LISTEN TO THE ADVICE
  • Sometimes the right answer is not the immediately correct answer
  • Corollary: Sometimes the right answer for the business is not your suggested/preferred outcome
  • Corollary: Just because you can do it like that in the real world doesn't mean that you can do it that way inside the business. [This realisation is INTENSELY frustrating but you have to learn to deal with it]
  • DON'T ALWAYS DO IT YOURSELF - Attempt to fix the system, sometimes allow the corporate monster to fail - then do it yourself and fix it. It is always easier and tempting to work round the system and Just Flaming Do It but it doesn't solve problems in the longer term and may create more problems and ill-feeling than it solves.

    [Worked out for Andy Cater for himself after many years of fighting the system as a misguided missile - though he will freely admit that he doesn't always follow them as often as he should :) ]

     

 

 

Saturday 10 February 2024

Debian point releases - updated media for Bullseye (11.9) and Bookworm (12.5) - 2024-02-10

 It's been a LONG day: two point releases in a day takes of the order of twelve or thirteen hours of fairly solid work on behalf of those doing the releases and testing.

Thanks firstly to the main Debian release team for all the initial work.

Thanks to Isy, RattusRattus, Sledge and egw in Cottenham, smcv and Helen closer to the centre of Cambridge, cacin and others who have dropped in and out of IRC and helped testing.

I've been at home but active on IRC - missing the team (and the food) and drinking far too much coffee/eating too many biscuits.

We've found relatively few bugs that we haven't previously noted: it's been a good day. Back again, at some point a couple of months from now to do this all over again.

With luck, I can embed a picture of the Cottenham folk below: it's fun to know _exactly_ where people are because you've been there yourself.



Sunday 26 November 2023

MiniDebConf Cambridge - 26th November 2023 - Afternoon sessions

That's all folks ...

Sadly, nothing too much to report.

I delivered a very quick three slides lightning talk on Accessibility, WCAG [Web Content Accessibility Guidelines] version 2.2 and a request for Debian to do better

WCAG 2.2:  WCAG 2.2 Abstract

Debian-accessibility mailing list link: debian-accessibility

I watched the other lightning talks but then left at 1500 - missing three good talks - to drive home at least partly in daylight.

A great four days - the chance to put some names to faces and to recharge in Debian spaces.

Thanks to all involved and especially ...

Thanks to Cambridge Debian folk for helping arrange evening meals, lifts and so on and especially to those who also happen be ARM employees who were badging us in and out through the four days

Thanks to those who staffed Front Desk on both days and, especially, also to the ARM security guards who let us into site at 0745 on all four days and to Mark who did the weekend shift inside the building for Saturday and Sunday.

Thanks to ARM for  excellent facilities, food, coffee, hosting us and coffee, to Codethink for sponsoring - and a lecture from Sudip and some interesting hardware - and Pexip for Pexip sponsorship (and employee attendance). 

Here's to the next opportunity, whenever that may be.


Back at ARM for MiniDebConf day 2 - Morning sessions 26th November 2023

 Quick recap of slides and safety information for the day from Steve McIntyre

Now into the Release Team questions following a release team overview.

A roomful of people all asking questions which are focused and provoke more questions - how unlike a Debian session :)

May just have talked myself into giving a lightning talk this afternoon :)

Now about to have a talk about from Sudip about OpenQA, kernel testing and automation

Saturday 25 November 2023

Afternoon talks - MiniDebConf ARM Cambridge - Day 1

A great talk on SteamOS progress to effective boot loaders for atomic OS updates.

How to produce something that will allow instant updates and instant fallbacks when updating a whole OS image - lots of explanation - and it's good when three or four people who are directly interested in problems and solutions round, for example, Secure Boot are in the room.

Jessica Clarke on CHERI, Morello and security protections in hardware, software and programming hardware which has verifiable pointers and routines. A couple of flourishes which had the room breaking out in applause.

Roberto Sanchez and Santiago Rincon on suggestions for LTS and ways forward. The presentation very clearly set out what LTS is, is not, and maybe should be.

Last presentation of the day was from Ian Jackson on a potential change to git based working and tagging. 

Then lots of chasing around to get people out of the building. Thanks very much to the Arm personnel, especially the security staff who have been helpful throughout the day with getting us all in and out

Thanks to all involved with Arm, Codethink and Pexip for hosting and sponsorship without which this would not have been possible.

 

Lightning talks - MiniDebConf ARM Cambridge - Day 1

 A quick one slide presentation from Helmut on how to use Debian without sudo - Sudo Apt Purge Sudo

A presentation on upcoming Ph.D research on Digital Obsolescence - from Eda

Antarctic and Arctic research from Carlos Pina i Estany 

* Amazing * what you can get into three well chosen slides.

Ten minutes until the afternoon's talks

Laptop with ARM, mobile phone BoF - MiniDebConf Cambridge day 1

 So following Emanuele's talk on a Lenovo X13s, we're now at the Debian on Mobile BoF (Birds of a feather) discussion session from Arnaud Ferraris

Discussion and questions on how best to support many variants of mobile phones: the short answer seems to be "it's still *hard* - too many devices around to add individual tweaks for every phone and manufacturer.

One thing that may not have been audible in the video soundtrack - lots of laughter in the room prompted as someone's device said, audibly "You are not allowed to do that without unlocking your device"

Upstream and downstream packages for hardware enablement are also hard: basic support is sometimes easy but that might even include non-support for charging, for example.

Much discussion around the numbers of kernels and kernel image proliferation there could be. Debian tends to prefer *one* way of doing things with kernels.

Abstracting hardware is the hardest thing but leads to huge kernels - there's no easy trade-off. Simple/feasible in multiple end user devices/supportable  - pick one ☺