Yeah, they are both bullet points on my resume, actually. But there are several jobs where I can't quite say this.
Like I worked on several games that didn't do well in the market (for various non-technical reasons), so I know I can't brag about saving money or time or usage for the company, but I learned a lot of skills by being on those projects, so I benefitted personally in ways that could help the prospective company out.
In fact I might have gotten more skills from those projects than that speech application, for example, despite that one being used a ton.
So I don't really have anything better I can say there than "did this this and this on the project, lead X number of people, etc", which are basically the 'responsible for...' bullets that everyone advises against including on a resume.
Also in case you're curious, I set up the process by using Octopus Deploy and several custom Powershell scripts after an audit of their existing processes and all the various information for all the servers, firewall settings, windows services, database snapshots and schema migrations, etc (there was a lot, each major system had like 40+ steps to it by the time they were done) etc.
Before the engineering director of the department would lock himself in his office and execute .BAT scripts one by one from a terminal and copy files and other things manually, while everyone else chilled in the main office, waiting (usually around 4-5 people). If anything ever went wrong, and usually it did, it would take several engineers to investigate and help revert things if necessary.
It was a mess. They knew it was a bad process, and had previously had another developer start investigating how to make things better using Octopus Deploy, and he gave up and quit the company and KT'd to me that it was impossible, no one was cooperating with him, he couldn't get the information needed, and well... I didn't have his experience and think he just didn't want to do it.
I had everything working for several processes (and we set up more and more over time after we had things working) in about the same time as he spent accomplishing very little (I started with his setup), and I didn't know anything about Octopus Deploy and barely anything about DevOps beforehand.
Great anecdote that, a real classic - previous experienced engineer couldn't get the cooperation and information he knew he needed to do it properly so barely started. Newer inexperienced engineer wasn't quite sure what was needed but built something to get several processes working and used that to convince everyone to provide the support to complete it.
I've closed $100k worth of consulting by opening with "My name is Zwayhowder and I've spent years making every cloud transformation mistake possible so you don't have to".
Like I worked on several games that didn't do well in the market (for various non-technical reasons), so I know I can't brag about saving money or time or usage for the company, but I learned a lot of skills by being on those projects, so I benefitted personally in ways that could help the prospective company out.
In fact I might have gotten more skills from those projects than that speech application, for example, despite that one being used a ton.
So I don't really have anything better I can say there than "did this this and this on the project, lead X number of people, etc", which are basically the 'responsible for...' bullets that everyone advises against including on a resume.
Also in case you're curious, I set up the process by using Octopus Deploy and several custom Powershell scripts after an audit of their existing processes and all the various information for all the servers, firewall settings, windows services, database snapshots and schema migrations, etc (there was a lot, each major system had like 40+ steps to it by the time they were done) etc.
Before the engineering director of the department would lock himself in his office and execute .BAT scripts one by one from a terminal and copy files and other things manually, while everyone else chilled in the main office, waiting (usually around 4-5 people). If anything ever went wrong, and usually it did, it would take several engineers to investigate and help revert things if necessary.
It was a mess. They knew it was a bad process, and had previously had another developer start investigating how to make things better using Octopus Deploy, and he gave up and quit the company and KT'd to me that it was impossible, no one was cooperating with him, he couldn't get the information needed, and well... I didn't have his experience and think he just didn't want to do it.
I had everything working for several processes (and we set up more and more over time after we had things working) in about the same time as he spent accomplishing very little (I started with his setup), and I didn't know anything about Octopus Deploy and barely anything about DevOps beforehand.