I want to talk about work for a bit, though I'll probably post something about the coronavirus soon after. I'll try to keep this from getting too technical, so bear with me. :)
My job title is "Technology Integration Engineer". I don't recall if I wrote about that before, so here's a very simplified version of what I do -
Every time you have an app that updates (Windows updates, smartphone apps that update, whatever) it generally involves many, many hours of work behind the scenes. You have programmers that code up some changes, testers to test them, etc.
Because some things change on a regular basis, there are also configuration files for just about everything. That way if you are using a specific url (as one example), when it changes you don't have to change the code, you can just update the configuration files as needed.
Since applications run on multiple machines (generally a machine for the database, which stores all your data. A machine for serving up the webpage, and various machines for other tasks - like verifying you when you log in, or validating your credit card when you pay a bill, and so on and so forth) there's also connectivity settings, messaging, and a lot of other things. It's complicated and messy -
And I actually kind of like it. I do still intend to get into computer security (infosec, cyber security, whatever you want to call it), but it's kind of fun to troubleshoot why the heck something isn't working. I'm getting reasonably good at reading logs and trying to figure out what they mean.
Now, tech is a fast-paced industry, and it seems to me that tech companies that have been around for a while are always in the midst of some sort of transition. There's older, legacy systems - and since they work, and most of the bugs have been sorted out, they don't generally want to replace them unless they have to - and then there's newer technology, and it all makes a rather confusing mess. One of the big changes going on is less about the tech (though that plays a role), and more about how the company is organized.
See, in the older style of software development, you might put out new code one a month, or once a quarter. The developers develop, the testers test, and my job is to help integrate the code with all those various configuration settings so that the environment works. Sometimes that means fixing issues when a new build (i.e. the code changes for whatever version they're working on), and sometimes it means trying to help troubleshoot some defect that the testers have identified.
But once a month is... slow. Faster, more agile companies can push out changes daily... or even faster. Which is what one of the current industry buzzwords is - agile.
As someone who graduated a little over a year ago, I had heard the term but didn't initially have a clue what it really meant - but last Feb I was in Dallas for some corporate training, and we discussed it in more detail.
The biggest takeway, for me at least, is that in order to be more agile they essentially want to restructure how we do things. Instead of having a dev team, and an integration team (mine), with database administrators and the like, and testers... they essentially put those skills all on a small team dedicated to one particular application. That way they can code it up, run it, test it, and push it out in a timely fashion.
Which made me wonder what was going to happen in my own company, because it means my current job would go away. (Maybe. Supposedly the transition can take five years or so).
Now, I want to circle back to something that happened early in my career here. Before I learned enough to actually be busy fixing things, I got sent to some training that discussed the concepts layed out by Google for SRE. I then got tagged to be on a scrum team (which is what they call those small teams in the agile framework, iirc), but tbh I hadn't really been able to do much with it. Most of it was very different from what I do in integration, and the project I found most relevant to my day job was when we tried looking at file system cleanup.
But now that I've learned enough to be more useful, and don't have to spend most of my time dealing with the day-to-day integration issues (we each take turns being 'on call' as the primary point of contact for the days issues, and as a trainee I'd been handling more and more of the non-production issues. Now, though, I should be rotating when I'm on call... so about one week a month I should be busy with that, and the other three weeks I can start working on other things.)
Last week was the first time I had the chance to really dig into some of that, and it sort of amuses me. Because even though I was hired as an integration engineer, and even though I learned java for school, it turns out that I'm apparently also a bit of a python developer now.
Sort of. Still spend most of my time in integration, ofc. It kind of amuses me, as someone who learned an entirely different language. Like, yes... you too can wind up programming in an entirely different language, even if you weren't hired as a programmer in the first place.
The last few months have been interesting. I like learning new things, but I have had to learn soooooo much! It's right at the edge of my comfort zone, tbh. And there's all sorts of things that I feel I only barely understand. (The number of times I've been asked to help fix something, and have no clue what the acronym they're using means, or what it really does for our application... well. I can see why imposter syndrome is such a thing in our industry. I now have a little bit of an understanding of containers, and microservices, and mq, and a bunch of other enterprise level technology... and a bit of sql and Oracle, plus some Couchbase and nosql. Only superficial knowledge, I'd say... barely scratched the surface on a lot of it, but def something that keeps me on my toes.)
There's other parts to the job, non-tech related. Some days we're slammed with issues, all of which they claim are 'Severe 1, high priority, must be fixed right away.' Which, I mean, yeah... we'll all do the best we can. But the true top priority is production, since there are real live people who would get pretty darn mad if things break. If they couldn't pay their cell phone bill, or get a new phone, or whatever.
And the training environments are also pretty important, since our customers have people who are trying to learn the system... and they can't if that system isn't working.
Which is why, as someone still relatively new, my focus has been on non-production. If I screw something up there, it won't have as big of an impact.
But the customers often act as though these testing environments are as important as production (Severe 1, high priority. Fix it now!), and there's only so many of us to do the fixing. Which means I also have to learn how to multi-task, and prioritize, and try to keep the customers happy while also keeping some semblance of work-life balance.
Supposedly, I think as part of that work-life balance our bosses and clients got together and agreed that we wouldn't support outside of working hours, but the clients don't often act like that... and want us to work all hours of the day. (I had been a bit miffed when one of them called on Christmas Eve - Christmas Eve!!! - for one of those issues. It wasn't production, it wasn't the training environment, and what the heck are they doing testing on Christmas Eve!)
I feel a bit guilty saying that. Like, there is so much pressure, maybe mostly self-imposed?, to try and get it done, fix things, and keep the customers happy. But... nobody is getting shot at. It's not production. Especially now, with the coronavirus and everything else going on, I wish I could tell them that they're are more important things they ought to be doing right now.
Like spending time with family.
Whatever. I don't really think I'm wrong, I think I feel guilty for two reasons. One, because I can do it, and it prob wouldn't take all that much time, but I'm putting my foot down because you have to draw the line *somewhere*. It becomes too easy to say, sure... let me knock that out. And then you wind up staying an hour or so after work, and dealing with non-production issues on Saturday and Sunday, and skipping lunch, and no. Not unless it's a true priority.
Secondly, because it feels like most businesses (no matter what they say) don't like people acting as though there's more to life than work, so I wonder whether or not my company has my back on this.
Except they mostly do? Sort of? I'm on call again this week, and just got a call about an hour or so ago for another one of these things, and basically said "we're not supporting you right now, feel free to escalate to my boss"... and I haven't got a call yet, or been told I'm in the wrong.
It's Saturday. What are the consequences of not testing, right now? A slight delay in releasing to production? Is that really that big of a problem?
Smh. (This touches on something I may or may not get into as I talk about coronavirus, since there's been this whole question about the impact of social distancing on the economy, but I'll get to that if or when I get to it.)
My job title is "Technology Integration Engineer". I don't recall if I wrote about that before, so here's a very simplified version of what I do -
Every time you have an app that updates (Windows updates, smartphone apps that update, whatever) it generally involves many, many hours of work behind the scenes. You have programmers that code up some changes, testers to test them, etc.
Because some things change on a regular basis, there are also configuration files for just about everything. That way if you are using a specific url (as one example), when it changes you don't have to change the code, you can just update the configuration files as needed.
Since applications run on multiple machines (generally a machine for the database, which stores all your data. A machine for serving up the webpage, and various machines for other tasks - like verifying you when you log in, or validating your credit card when you pay a bill, and so on and so forth) there's also connectivity settings, messaging, and a lot of other things. It's complicated and messy -
And I actually kind of like it. I do still intend to get into computer security (infosec, cyber security, whatever you want to call it), but it's kind of fun to troubleshoot why the heck something isn't working. I'm getting reasonably good at reading logs and trying to figure out what they mean.
Now, tech is a fast-paced industry, and it seems to me that tech companies that have been around for a while are always in the midst of some sort of transition. There's older, legacy systems - and since they work, and most of the bugs have been sorted out, they don't generally want to replace them unless they have to - and then there's newer technology, and it all makes a rather confusing mess. One of the big changes going on is less about the tech (though that plays a role), and more about how the company is organized.
See, in the older style of software development, you might put out new code one a month, or once a quarter. The developers develop, the testers test, and my job is to help integrate the code with all those various configuration settings so that the environment works. Sometimes that means fixing issues when a new build (i.e. the code changes for whatever version they're working on), and sometimes it means trying to help troubleshoot some defect that the testers have identified.
But once a month is... slow. Faster, more agile companies can push out changes daily... or even faster. Which is what one of the current industry buzzwords is - agile.
As someone who graduated a little over a year ago, I had heard the term but didn't initially have a clue what it really meant - but last Feb I was in Dallas for some corporate training, and we discussed it in more detail.
The biggest takeway, for me at least, is that in order to be more agile they essentially want to restructure how we do things. Instead of having a dev team, and an integration team (mine), with database administrators and the like, and testers... they essentially put those skills all on a small team dedicated to one particular application. That way they can code it up, run it, test it, and push it out in a timely fashion.
Which made me wonder what was going to happen in my own company, because it means my current job would go away. (Maybe. Supposedly the transition can take five years or so).
Now, I want to circle back to something that happened early in my career here. Before I learned enough to actually be busy fixing things, I got sent to some training that discussed the concepts layed out by Google for SRE. I then got tagged to be on a scrum team (which is what they call those small teams in the agile framework, iirc), but tbh I hadn't really been able to do much with it. Most of it was very different from what I do in integration, and the project I found most relevant to my day job was when we tried looking at file system cleanup.
But now that I've learned enough to be more useful, and don't have to spend most of my time dealing with the day-to-day integration issues (we each take turns being 'on call' as the primary point of contact for the days issues, and as a trainee I'd been handling more and more of the non-production issues. Now, though, I should be rotating when I'm on call... so about one week a month I should be busy with that, and the other three weeks I can start working on other things.)
Last week was the first time I had the chance to really dig into some of that, and it sort of amuses me. Because even though I was hired as an integration engineer, and even though I learned java for school, it turns out that I'm apparently also a bit of a python developer now.
Sort of. Still spend most of my time in integration, ofc. It kind of amuses me, as someone who learned an entirely different language. Like, yes... you too can wind up programming in an entirely different language, even if you weren't hired as a programmer in the first place.
The last few months have been interesting. I like learning new things, but I have had to learn soooooo much! It's right at the edge of my comfort zone, tbh. And there's all sorts of things that I feel I only barely understand. (The number of times I've been asked to help fix something, and have no clue what the acronym they're using means, or what it really does for our application... well. I can see why imposter syndrome is such a thing in our industry. I now have a little bit of an understanding of containers, and microservices, and mq, and a bunch of other enterprise level technology... and a bit of sql and Oracle, plus some Couchbase and nosql. Only superficial knowledge, I'd say... barely scratched the surface on a lot of it, but def something that keeps me on my toes.)
There's other parts to the job, non-tech related. Some days we're slammed with issues, all of which they claim are 'Severe 1, high priority, must be fixed right away.' Which, I mean, yeah... we'll all do the best we can. But the true top priority is production, since there are real live people who would get pretty darn mad if things break. If they couldn't pay their cell phone bill, or get a new phone, or whatever.
And the training environments are also pretty important, since our customers have people who are trying to learn the system... and they can't if that system isn't working.
Which is why, as someone still relatively new, my focus has been on non-production. If I screw something up there, it won't have as big of an impact.
But the customers often act as though these testing environments are as important as production (Severe 1, high priority. Fix it now!), and there's only so many of us to do the fixing. Which means I also have to learn how to multi-task, and prioritize, and try to keep the customers happy while also keeping some semblance of work-life balance.
Supposedly, I think as part of that work-life balance our bosses and clients got together and agreed that we wouldn't support outside of working hours, but the clients don't often act like that... and want us to work all hours of the day. (I had been a bit miffed when one of them called on Christmas Eve - Christmas Eve!!! - for one of those issues. It wasn't production, it wasn't the training environment, and what the heck are they doing testing on Christmas Eve!)
I feel a bit guilty saying that. Like, there is so much pressure, maybe mostly self-imposed?, to try and get it done, fix things, and keep the customers happy. But... nobody is getting shot at. It's not production. Especially now, with the coronavirus and everything else going on, I wish I could tell them that they're are more important things they ought to be doing right now.
Like spending time with family.
Whatever. I don't really think I'm wrong, I think I feel guilty for two reasons. One, because I can do it, and it prob wouldn't take all that much time, but I'm putting my foot down because you have to draw the line *somewhere*. It becomes too easy to say, sure... let me knock that out. And then you wind up staying an hour or so after work, and dealing with non-production issues on Saturday and Sunday, and skipping lunch, and no. Not unless it's a true priority.
Secondly, because it feels like most businesses (no matter what they say) don't like people acting as though there's more to life than work, so I wonder whether or not my company has my back on this.
Except they mostly do? Sort of? I'm on call again this week, and just got a call about an hour or so ago for another one of these things, and basically said "we're not supporting you right now, feel free to escalate to my boss"... and I haven't got a call yet, or been told I'm in the wrong.
It's Saturday. What are the consequences of not testing, right now? A slight delay in releasing to production? Is that really that big of a problem?
Smh. (This touches on something I may or may not get into as I talk about coronavirus, since there's been this whole question about the impact of social distancing on the economy, but I'll get to that if or when I get to it.)
No comments:
Post a Comment