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

[davidgillon]

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.

[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.

[vass]

I like Spamlex.

[(Anonymous)]

Appropriate email address to direct job-stuff to?

[emperor]

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

Software tester here...

[redsixwing]

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.

[stephdairy]

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)

[untonuggan]

Thanks for that first link! helpful.

[azurelunatic]

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.

[(Anonymous)]

(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.