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

Entry tags:

bits and bobs

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

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

Threaded | Top-Level Comments Only

Okay, burnt-out programmer view of the industry, actually that's wrong, burnt-out programmer view of only ever working for a certain well known aerospace/defence company we'll refer to as Evil Aerospace for the sake of the out-of-court agreement that I won't name them and they'll compensate me for the discrimination that never happened.

Appalling diversity, definite locker room atmosphere, glass ceiling for female engineers, even with a female CTO. Claimed to be market leader with equality, reality was rather different.

Technically what we were doing would be described as hard real-time, safety-critical programming, that's very different to a lot of the industry. Sometimes fascinating work, sometimes boring, also frustrating with late or changing requirements meaning you're fire fighting against deadlines because all the work ramps up at the end of the project. Try not to be the person responsible for the final step, you'll get the blame for the delays.

It's likely that the project will be larger than anything you've worked with (my main project was 100 plus engineers and has been underway since mid 80s, it has at least another decade to run, it was only one of several major software projects on the aircraft, admittedly this size is exceptional). Even on more typically sized projects this is likely to mean spending more time on negotiating with other people on how your work fits with theirs than you are used to. Done properly it should mean strong processes for managing control of changes to requirements ('change management') and managing who is working on which file ('config management'). Our project had IIRC something like 1400 change requests a year on a code base of about 30,000 files, coordinating this was essential, but a lot of the non-safety critical side of the industry is fairly lax about this. Some managers will not consider this side of things worthwhile as it does not actually involve writing code (guess what muggins was doing/what his user-boss thought).

Pressure to deliver from managers who want you to be a faceless cog in the machine. The eventual breakdown in my relationship with Evil Aerospace was over a demand for meeting daily deadlines, even though we only made deliveries to the customer once a year. The problem was internal business management processes that artificially pressurized the work process to create internal targets management could demonstrate meeting, and the pressure, and other stuff, flowed downhill. Some of the managers I had pressuring me over the time to do particular jobs had no idea of the complexity of the work involved and IMO might have made a competent clerk, with appropriate supervision. If you get a manager who is competent at both the personnel and technical side, treasure them! My impression of the rest of the industry was that we were fairly typical here, and that you're going to run into management pressure to deliver more wherever you are.

Industry approaches to testing are very variable. We were fanatical about it, the opposite end of the industry sometimes appears to consider testing optional. It's probably wise to work out where your employer stands on this and adapt to their perceptions, at least at first.

Pay on the engineering side of computing is worse than on the financial etc side. OTOH, we had a lot of ppl come to work for Evil Aerospace for a couple of years to get a big name employer/project on their CV, then make the switch to contracting to get the wage they wanted.

It's difficult for me to be positive about the industry because my own experiences were so negative. Some of the negatives were specific to Evil Aerospace, but I think some of it is structural and industry-wide and I'd hesitate to recommend it as a career to anyone who isn't a 20-something male.

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.

I like Spamlex.

Appropriate email address to direct job-stuff to?

kabe@rett.org.uk is good, please indicate in the e-mail whether you'd like me to strip identifying information/headers/etc out when I pass the info on. Thanks heaps. xx

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.

<333

(big post on religion upcoming - I'm at the draft stage, having outlined the body of the post and written the intro/background, and I'm already at 1000 words... -- and also counselling log from last night <3 AND THEN FOR VARIETY quite plausibly something acerbic about percussive maintenance ;) )

Thank you for sharing - much appreciated!

on a code base of about 30,000 files

Utterly irrelevant to the actual question, but memory and compulsiveness is nagging me this should be 30,000 config management packages, 210,000 files.

Seems you can take the compulsive organiser out of config management, you can't take config management out of the compulsive organiser.

I do what some people would call "devops", and others might call "system administration". This splits into a number of types of task:

i) routine maintenance & management of running services; this is not very exciting, and lazy sysadmins try to automate as much of this as possible
ii) user support; most of this is handled by helpdesk and the like, but I get some of the more technical problems. Related to this is contributing to technical advice on important issues (e.g. "what does the new weak-DH problem mean for your ssh server?")
iii) dealing with technical debt / trying to improve our infrastructure; this is both tricky and satisfying - you have to balance "what would an ideal world look like?" with what is achievable with limited time, and what you can persuade other people to do
iv) finding, reporting, (and sometimes, patching) Free software. One of the virtues of free software is that we can inspect the code and work out why it's going wrong; I think that means that when we find bugs we have a duty to help the free software community fix them
v) developing new services - this involves research, design, and implementation, usually as a small team (or by myself for small/simple tasks) - I do the automation and sysadminny bits, and other colleagues to the web front-ends

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.

Edited 2015-05-29 11:08 (UTC)

In a financial institution, which I will not name as I am not representing my company in this post.

Diversity problems exist, and some people are acting against them, and most people aren't. Assumptions about who could possibly using our product exist, and have to be argued against when they are demonstrably false.

Pressures both real and artificial exist. Differences of degree, more than kind, truthfully. A slice of brain gets devoted to making the process better, no matter where I am in it. If I can wring even 1 or 2% more out of a given iteration, that adds up fast. (Admittedly, some days I use that 2% to go read the news.)

Dysfunction exists between multiple roles on a single team (and, sometimes, within single roles on a single team). Multiply that by number of teams to get a good sense of it. Despite that, camaraderie between teammates is a real, and necessary, part of the business. I spend a fair chunk of time trying to maintain this, at least in my immediate orbit.

Tedium exists, in the form of "do X to programs A-T, then do X and Y to a subset of those revealed by X." Tremendous interest exists when getting into the roots of something, or sniffing out a bug that's been giving trouble. My favorite days are when something's gone badly wrong in test and I get to dig down into it. My least favorite days are when something's gone badly wrong in production and I get to dig down into it. My job title sounds fun and exciting, and it is, particularly when finding something new. My daily routine bores people to tears, unless they just like getting into the guts of the code to see what's in there.

The actual work is designing, recording, and running tests. Thinking your way around a structure, using all your knowledge of how code works to make it do things it shouldn't. Using, maintaining, automating, and updating scripts and tools. Writing a fair bit of code from scratch, in whatever language the tool of the day supports, or installing a general-purpose scripting platform, or taking the function of the quick-and-dirty scripts and turning them into a polished and user-friendly tool in a development environment.

Environments range from "I stood up a server and knocked it down five minutes later" to the decade-old, cranky, and utterly essential. We need to know them inside and out, and manage their configuration as well as the config of the software residing on them.

I like my job, most days. It's a balancing act, all days. Always, it's about managing risk.

Yay!

And thank you for posting this, because I don't have anything to contribute but enjoy reading about what sort of technology work other people do.

I work in a part of Cambridge University (Maths), as a system administrator, network administrator, general technical person. I'm part of a team of seven or eight people, and together we ~~fight crime~~ provide services to about 700 people.

Day-to-day there's a lot of freedom. In long term things I'm usually handed a project and some vague parameters and left to get on with it, possibly with a colleague to help with various parts of it, and the management is such that we're shielded from the pressure of hard deadlines so that to us it appears that "it's ready when it's ready". The thing I've had most fun with recently has been less technical: project managing our local wireless rollout. It's been fun getting huge boxes full of kit and then working with our local Facilities folk to get it wired up neatly.

Short term things include user support and helpdesk duty, which even in a building full of mathematicians can include "plug it in", but can on the other hand include helping a researcher debug their code, buying hardware for people, dealing with security incidents. I muck about with a lot of free software and technology to see what it's like, because it might turn out to be useful at some point in the future.

You can't always choose what jobs you get to do, but things tend to get directed to people who like and/or are good at that particular thing.

In theory I don't have hours but duties, so in extremis it's possible I'd have to work weekends or work late occasionally. In practice this happens very rarely and I tend to do a boring 9-5:30 with an hour's break for lunch, reading, and a nap on my office floor.

I doubt this will be typical of the IT industry, and it may or may not be typical of academia or even of Cambridge, but that's what it is anyway...

(S)

Thanks for that first link! helpful.

I am Erstwhile Tech Support working in an allegedly non-technical role. In practice, since I also notice patterns and it drives me spare if Things Are Wrong, a non-zero portion of my day goes like:

Teammate tells me what sort of laptop he would like to replace his current laptop which is dying. Attempt to use the helpdesk system to file this request with the hardware folks. Realize that X portion of the helpdesk system is Wrong. Make a note of it, and continue filing ticket for hardware.
Finish filing ticket for hardware. Log a note in daily journal file that ticket for hardware has been filed, in order to account for time. Send email with ticket number to teammate to confirm that ticket has been filed.
Open helpdesk system to file a ticket against said helpdesk system, because it is *Wrong*. Log the time accordingly.
Attempt to IM colleague on another team to complain about the helpdesk system.
Realize IM is down.
Use another IM system, which is still up. Complain about the helpdesk system and the busted IM system. Realize that the IM thing is not just you.
Call to file a help ticket for the busted IM system. (Call, because outages are supposed to be reported via phone, because the help ticketing system will take days, even though it's not supposed to.) Argue with the tech support guy about whether he should include your phone number when passing along the message to the team responsible for fixing. He includes your number. Comment to say that email is preferred, and phone is the worst way. Head to not!Facebook (the internal social network) to complain about the poor service.
Call helpdesk to check back on ticket for busted IM system, because it's a day later and IM still isn't working for everyone. Some people have it, some don't. You disconnect at your peril. Complain to same co-worker, who has found a document enumerating some helpful troubleshooting steps, including the host names of the expected two IM servers. Try pinging the two IM servers. Discover that one is up and one is down. Include this information in the ticket.
Teammate says that the model laptop that Procurement has sent to him for approval is not the correct model laptop. Nod grimly, as this is the thing that happened last time that you did not catch, and the guy that left last Friday got the wrong model laptop. (Someone else has already called dibs on it, or you could give the teammate that one and tell him tough luck about the model.) Happily he has got a quote for the correct model. Test and see whether you can upload the .pdf to the ticket. You can't, but that's okay -- because you have read the wiki for the system that the helpdesk software is based on, you know how to create an email which will attach itself to the ticket as a comment, and adding the .pdf as an attachment to the email will attach the .pdf as an upload even though you shouldn't have the ability to attach things as it's currently configured. You are a fucking superhero.
Come in to discover that your IM client has reconnected to the working server. Rejoice! Discover that your colleague is still not connected. Stop rejoicing.
Return to desk to find an email from the folks who may or may not be responsible for the IM system which is busted. They claim your personal account is working fine, and that you should email them a screenshot of the error you are experiencing. Swear (to yourself). Compose a message with perhaps unnecessarily detailed steps of what you have done so far, omitting any cursing. Request that they confirm that server #2 still exists and is powered on, just to rule out any data center events, like the migration you got a notification for, which said that any virtual machines without owner info listed would be powered off post-move.
Make a bet with your colleague: you say it was the data center migration, and you bet that there was no owner listed. He says that some other VM cloned its IP and MAC address by accident, and this is why some people get through and some don't. Both of you discount the conspiracy theory that this is being done on purpose to test who still uses the old IM server instead of the new one which only works reliably on Windows. The terms of the bet are two (2) chocolate-covered espresso beans. You are pretty sure you will win; you are pretty sure that when this happens, your colleague will snaffle two of them from your candy dish and present them to you as his payment.

Edited 2015-05-30 08:27 (UTC)

(This helpdesk system is the dystopia of helpdesk systems. I have been at war with it for going on 10 months. The new executive in charge of internal IT claims that the non-Windows users' problems with the new IM system are because they are whiners who will never be satisfied. I say that this new executive needs to get gone.)

(anon in public, but Alex can privately give my name & email address to anyone who has questions)

I'm a developer at a ~100-person company. Their primary focus is software; everyone in the building has done some coding; my immediate manager is two desks away working from the same task list as me. My immediate team is small and uses pair programming on about 50% of tasks. The place is small and cohesive enough that we all have some idea what each other are doing, and I cannot overstate the awesomeness of having managers and colleagues in other departments who really understand what my job entails. They're also great on work-life balance. You do your hours and go home.

As a social group outside of the office... basically the developers are all great to hang out with, but there are a couple of unapologetic Tories further up whom I will very deliberately only ever talk to in work about work.

There's plenty that I find new and interesting, but I never end up doing anything that's novel in a CS theory sense. It's engineering with a gradually evolving set of tools, rather than research. Typical concerns include "how can we tweak our architecture to make the output efficiently include XYZ data? How can we properly test this at all relevant levels to prevent future regressions?" (This team is really into testing. It's great.) We also push our patches to open source software that we use, and try to engage with those projects rather than just throwing stuff over the wall.

Probably the least interesting part is the occasional ticket of the form "test with this new range of inputs, and see if the profiler shows any opportunities for optimisation". Lots of staring at progress bars. But even then, as soon as we find a problem, it rapidly gets interesting again.

I'm immensely lucky here; I basically made this career choice when I was 8, had an entirely straightforward path to get here, and have never once regretted it. But then, I'm not in any group that's ever been made to feel unwelcome in this field. Obviously it's not so easy for everyone.

everyone in the building has done some coding

Really? In a 100-person company you have no office administrator / accounts / HR - or you do and they all have coding experience as well? That would be exceptionally unusual.

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.

Threaded | Top-Level Comments Only

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

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Software tester here...

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject