Bits & bobs, more to follow (sorryyyyyy appparently I am Spamlex at the moment)

[kaberett]

1. wyrdatlast has started writing a series about about coming to terms with diagnosis of chronic illnesses, viewed in a framing of grief, which I suspect a bunch of you will be interested in, and for which I personally am v grateful because it means I don't gotta get around to writing the wretched things. ;)

2. BECAUSE OF REASONS (do my housemate a favour by doing me a favour, folk?) if those of you in the tech/computer science industry felt like writing a couplefew paragraphs about what your job is actually like for someone with a very strong CS background but no industry experience, I'd be super grateful. Comments here or e-mail are great. Cheerssss xx

Comments

[macey]

I mean. For 2, I tend to do better as conversation / answering questions? 'Cause that's really general. You have my email I think ^.^ but tell me if you'd rather I just write it up.

[kaberett]

I will see about putting friendperson in touch with you (if it's okay to pass on your details) or get a list of questions out of 'em to ask you myself!

Some of what we're going for here is getting a sense of the range of problem-solving/intellectual activity - the extent to which you deal with "solved problems" versus the amount of time you spend on New And Interesting ones. Another point of particular interest is the degree of social stuff you get out of work, in terms of talking to colleagues (professionally and socially), feeling like Part Of A Team, and so on.

[davidgillon]

Picking up these points as I didn't really cover them.

The degree of problem solving was very variable. With some projects we were handed very specific module level requirements (we were implementing flight control laws, which essentially are fixed, if complex, mathematical formulae). At other times I was given instructions as broad as 'Design a new programming support environment' and 'write and roll-out new quality procedures for the entire multinational group of companies'. In one case I was able to go to management and say 'you want us to get CMM certification, we aren't doing X, CMM says we need to do X, I can see a way to do it,' and get the okay to design and implement the entire process. In general, if the company implements a split between coders and system analysts, the analysts will be the ones doing the design/problem solving, the coders will mostly be implementing fixed requirements (in general, I was always technically a coder, but an odd one with a specialisation in support tools). ETA: and the third sub-specialisation was tester, with very little problem solving at all.

The social side of things was equally variable. Because we ran project based teams we would get thrown into new projects with new people on a semi-regular basis, some were more social than others. I think I was in six very different teams over 22 years. Two or three of those had really strong teams, but in every case I was working in a small sub-team of about 6 (I'm going on holiday with some of those people, even though its years since we worked together). Sometimes the larger projects had socialisation I was on the outside of - problem of being neurodiverse with mobility impairments when the socialisation is heavily based around five-a-side, or MMO gaming. We did tend to have strong project identity, but that's a natural side of being in a pressurized environment, especially with something as tangible as an aircraft to hang it around and milestones as distinct as 'first flight' to aim for.

[macey]

Whoops, well, still available. Left this open and forgot about it, so -

As to those specific things - I'm a software engineer but I don't work on product ('Implement this feature for customers!'), I work on reliability and 'system' engineering, where 'system' is 'the backend stack, databases, appservers, etc' rather than 'write the kernel! fix the network card!'.

So, in my role, there's a /ton/ of New And Interesting stuff. Things I deal with include - okay, for example, we're integrating this new product that wants to use all of our backends, but the existing queries have a deadline of 600ms and the new ones have a deadline of 70ms. How do we separate and track these traffic flows so the new traffic always gets priority? Which database callouts can we still afford to do? How do we guarantee these queries get served close enough to the user that the round-trip-time is short enough to the user, when we don't really know what that is?

In response to this, I'm probably going to spend the next month writing a module that determines how much time a query has left, calculates how much network time this means we can afford, detects a list of clusters within that time range, and restricts the load balancer to only talk to them. We had a long chat with the team who designs and runs the load balancers, about making this a core feature, and they went 'Um. That's super specialised, guys, what are you even doing? Sorry, we can't help, but tell us how it goes?'

Which, to answer the other point - over the course of figuring this out, I and other SREs ('site reliability engineer') have had long discussions with a) traffic team b) load-balancer team c) product for the new queries d) development team for the frontend binary e) development team for the auction binary f) development team for each of the databases, etc. So SRE is very communications-y and you end up, as a junior SRE, talking to sometimes /very/ senior developers in other orgs and being respected - we're rare, and we're very specialised in these issues, so if you asked for a consult you better listen XD

Within my team, it's very social and loyal and supportive. We go on call, 12hrs a day for a week every ~7 weeks or so, dealing with things breaking, sometimes in pretty serious ways. It's stressful. But you can absolutely always call on a teammate if it's 9pm on a saturday and you don't understand why the database is gone, and they'll be there, no questions, won't make you feel guilty for asking or feel dumb for not knowing. We have a 'postmortem culture', where failures are dissected in the context of the circumstances that created them, not the people.

So. On both of those points - I love my job.