Best production & operations books according to redditors
We found 100 Reddit comments discussing the best production & operations books. We ranked the 28 resulting products by number of redditors who mentioned them. Here are the top 20.
We found 100 Reddit comments discussing the best production & operations books. We ranked the 28 resulting products by number of redditors who mentioned them. Here are the top 20.
The "Practice of System and Network Administration"; probably a bit too early in your career but has some strong advice.
https://www.amazon.com/Practice-System-Network-Administration-Enterprise/dp/0321919165
There's also a volume 2 which is cloud/site reliability engineering related.
This book has been suggested a few times so I finally got around to reading it. I think it has some good information in it. I'm only about halfway through it, but I like it so far.
Time Management for System Administrators
Other books would be any of the social books like "How to influence people", "7 healthy habits..." Etc.
I haven't read this one yet, but It has been suggested to me if you plan to go more into management/leadership Start with Why
Other books that have I have ear marked due to being mentioned:
Also, do a search for "Books for IT Professionals" to find a lot of other suggestions.
Welcome! Product management is an equally exciting and confusing place to be in. Here are some resources to point you in the right direction.
A few articles/websites for you to read to get a good overview of the product manager role:
These are my two favorite books that really helped me understand what product managers should be doing.
​
Here are my nominations:
I haven't read them all through but have started on the Time Management book. So far so good.
This mentions The Practice of Network and System Administration, and how it could do with an update; that would be here, in The Practice of Cloud System Administration, which as I understand is effectively the 'replacement' book, at least for an approach more suited to modern infrastructure.
The senior part is more of a technical grade level and not necessarily management... granted I'm in the lead role here, it's my first time as one. All I can say is what help me spring forward at a lull at mid-level was picking up Thomas Limoncelli's books, [the sysadmin one] (https://www.amazon.com/Practice-System-Network-Administration-Enterprise/dp/0321919165/ref=sr_1_1?ie=UTF8&qid=1512041042&sr=8-1&keywords=thomas+limoncelli) and [the cloud one] (https://www.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X/ref=sr_1_3?ie=UTF8&qid=1512041042&sr=8-3&keywords=thomas+limoncelli) /r/sysadmin recommends them too. These are your best practice books, these tell you why to do things, not how. It will turn you from being the guy that mops the floor in a burning building into knowing when to yell, "FIRE!"
Cert wise, unless a specific company or contract requires it, I don't bother with the time and money on certs if you already have years of experience on the books. I'd probably go for a Security+ and then go for a Red Hat and/or CCNA certification as they are both prestigious. Red Hat is a big deal just by its practical application test.
If you want to go into cloud related stuff, you might want to brush up on your programming. This is what is limiting me, I have very minimal bash scripting experience coming from military in the Windows world then making a move to Linux.
Honestly, I would focus on being both as they both overlap very often unless you are in really large stovepipe enterprise environments, but you never know if you need to make a move to something smaller where you have the many hats role. I'd get your degree in something Computer science related (CS, CIS, EE, CE, etc) and then go RHCSA/CE and maybe Sec+/Net+ or instead of Net+ just go for something Cisco related. My networking is Net+ strength at best and I resent not doing better when I was younger.
EDIT: Also, if you can do the math, BS is Computer Science all the way... sysadmins are still really kind of not doing well in the degree program department, mainly because were so... trade-like I guess. Honestly, we're the new Millwrights like my dad was. We keep the factory going and fix it when production stops. It's kind of cool actually, it's nice to be able to have some kinship to my dad in that way.
Might as well get the follow up:
https://smile.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X
The book is good, but again a little too Google focused.
TPS predates Six Sigma and Lean Production. Lean actually came out of TPS. As they show in the video, Lean can be applied to pretty much any process. Toyota uses it for manufacturing, here they apply it in a food bank, and it is also widely used in software development.
Notice how they apply Value Stream Mapping. They start by looking at what is happening, and listing all the steps that add value, and those that do not. Putting food in a box adds value, running around to get the stuff does not add value and is waste. By eliminating waste they can reduce the takt time from 3 minutes to 11 seconds.
Another important aspect of TPS is respect for people. In its entire history, Toyota has never laid off any (salaried) workers during hard times. Instead it uses the free time to invest in kaizen.
In this case, respect for people means giving back to the American people, because the USA helped rebuild Japan after WW2.
If you want to learn more about TPS, go read Toyota Production System: Beyond Large Scale Production, written by Taiichi Ohno, the father of the Toyota Production System.
I can also recommend The Toyota Way and The Toyota Way To Lean Leadership. These are a bit more recent and an excellent insight in the Toyota way of working.
If the Practice of System and Network Administration is a bit dated, check out The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, Volume 2, September 15, 2014, by the same author.
I found the O'Reily Linux Networking book to be very informative.
https://www.amazon.com/Understanding-Linux-Network-Internals-Networking/dp/0596002556/ref=sr_1_3?s=books&ie=UTF8&qid=1543153401&sr=1-3&keywords=linux+networking
Also here
https://www.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X/ref=sr_1_1?s=books&ie=UTF8&qid=1543153468&sr=1-1&keywords=cloud+administration
Don't let minimalism get in the way of discoverability and usability. iOS 6 struck about the right balance. If you want to see if your app is truly usable, see if one and two year olds can figure it out. Kids like buttons. Kids like distinctive icons and colors.
iOS > Android > Windows Tablets
YouTube > YouTube Kids. However, they always get trapped in comments sections and popup menus, and whenever they end in live chats. The luckier ones figure out how to get into the app switcher and how to force kill apps.
A good minimal website will be navigable in lynx, a text only web-browser. This is also important for blind users, and other users with accessibility issues. This is also important for users of various screen sizes or who may also increase the font sizes for readabiity.
A good minimal website will look very similar if you run it through it through a "readability" filter that many modern web-browsers use. (It used to be called the readability extension, but the original creators open sourced it and now Safari, Brave browser, and various extension writers have picked up the slack).
If you're talking about things like minimizing workflows and supply chains. . .
https://www.amazon.com/Lean-Sigma-Dummies-John-Morgan/dp/1119953707
https://www.amazon.co.uk/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143
"The Practice of Cloud System Administration" is my bible. Every time I have a question like this, I find the answer in here.
https://www.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X
Time to immerse yourself in the world of Lean manufacturing and production. Good reading includes The Goal, and Taiichi Ohno on how Toyota learned to really manufacture efficiently, and anything written by Shingeo Shingo. Don't think "manufacturing" reduces quality, in fact if anything modern manufacturing concepts increase quality while reducing waste, and are optimal for small scale production such as roasting.
This is more of an operational problem and less of a programming problem. The troubleshooting aspect is about the only thing problem related, i.e. stack traces, perf, flame graphs, and logs on the programming side.
The operational side is how do you keep the program running adequately and the simple answer is to detect when it fails automatically, and have a new process start if its failed. So healthchecks, triggers, siem, and probably a cloud based 3-4 tier topology (load balancers, orchestration [docker], app, databases/fileshare [state]) if it needs high availability or the ability to scale.
The Practice of Cloud System Administration is a must have for a starting point in developing resilient services.
And [The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services] (https://www.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X)
This book is pretty good. Very direct, compact, written by the guy who implemented lean production at Toyota https://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143/ref=sr_1_13?ie=UTF8&qid=1542149684&sr=8-13&keywords=toyota+manufacturing
Sysadmin, I've been doing Lead SysEng/DevOps/SRE for the past 4 years and literally have multiple written offers I'm trying to choose from right now.
I only started looking 3 weeks ago.
Learn multiple clouds(I've done the big 3 in prod and other ones for utils/tools/hobby/legacy systems), Kubernets/docker, Linux, distributed systems and ansible/puppet/chef
Read this:
https://www.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X/
and this:
https://www.amazon.com/Site-Reliability-Engineering-Production-Systems/dp/149192912X/
See if you can buy time for the internship offer, having multiple offers is always better :)
Is the internship paid?
Keith Law. https://www.amazon.com/Smart-Baseball-Behind-Ruining-Running/dp/0062490222/
Herding chickens is the only one I read, but very good. http://www.amazon.com/Herding-Chickens-Innovative-Techniques-ebook/dp/B001D78FZ6/ref=sr_1_1?ie=UTF8&qid=1382962857&sr=8-1&keywords=herding+chickens
Keep in mind that project management is about communication. You can use whatever tool or approach you want, a good project manager is someone who can listen and talk. Consistently.
>Problems arising in development for which we have trouble finding or creating a good solution. This may take a few extra hours but in some cases it has taken days to figure some things out, and this is time that is 'unaccounted for' because these tasks have specific hours/points assigned to them.
This is an issue with planning. Things can and do happen, but if they are happening frequently you have an issue with planning.
One thing you can try to do is assign a 'champion' to each ticket during the first discussion. (backlog grooming usually) The champion is responsible for gathering all the needed information and essentially the go-to person for understanding what needs to be completed and all of the dependencies. This person should also work with product to break an epic or story into the appropriate scope and subtasks. If a problem does arise, this is the person responsible for working with relevant stake holders to come up with a potential solution to take to the group.
>Time spent going back and fixing previously-completed components when new components break them. Our app is comprised of many components that work off of each other and sometimes changes to one either break another one or require some further changes to other ones to prevent breakage.
This is another planning issue. if you have to frequently go back and fix stuff that was completed then you didn't accurately capture the dependencies. (or someone else released something without checking your dependencies. still an issue with planning, just maybe not yours)
This is harder to fix. a champion can alleviate this to a degree, but it depends on the nature of the dependency. either way, not enough communication is going on.
>From the UI side, going back and fixing/updating/improving components that were functionally in a completed state. This one doesn't take up much time, but it is still not 'tasked' time.
Then task it. you should be capturing as much of your work on paper as possible.
if UI is outside of your team, it should be accounted for as a dependency the team is responsible for.
Again, not enough communication is going on. UI people should be part of your planning and you should be accounting for this time.
>The biggest problem comes when we have to make changes to multiple components simultaneously because they share functionality or work together, and this appears to cause a delay because 'neither of them are being completed on schedule'.
guess what I'm going to say. :p
sounds like you need to work with your SM to re-establish communication chains. they aren't there.
>We are all talented developers and we know what we are doing, but the seemingly 'results-driven' approach of SCRUM is not making a lot of sense to us right now, and morale is low.
your SM doesn't know what he's doing, sadly. Sounds like a converted PM that hasn't crested the learning curve yet. It sucks that Morale is low. You can do things to help him out and keep morale high. unfortunately this also depends on his willingness to accept the fact he doesn't know what he's doing.
You should really sit down with your SM and talk to him about this. It's his job to remove impediments. low morale is an impediment. how do your retro's go?
One of my favorite stories to tell, is one of the first retro's I was observing. (normally only the team should be present, but we made an exception for training purposes. I was there to observe, not to add) The company I was at was in the middle of a transition to Agile. They weren't prepared to hire dedicated SMs, so we were training within and having volunteers be SMs on teams temporarily.
Anyway, during the course of the retro, the team talked about how the current SM was not meshing well with the team, and wasn't really embodying Agile/Scrum as everyone else understood it. They decided in the Retro that the SM wasn't right for the team, and they needed a new one. So that's what they did, switched SMs right in the middle of the retro.
>Sometimes unexpected and time-consuming shit happens, and tasks cannot be completed 100% in one sitting. It just doesn't make sense to me. Can someone please explain how to handle these scenarios?
This largely depends on the group and the environment. if things are changing as frequently as you say, and they always will, then you should explore other models than Scrum. Specifically lean/kanban is better suited to volatile environments.
Within Scrum, when an event occurs that drastically changes the scope of a sprint you're supposed to bust the sprint. This is, by design, a painful process. you should immediately go into retrospective. talk about what went wrong. go into planning and re-establish baseline. figure out what the team can get done with this new information and restart the iteration.
Again, this is painful by design because it is a last resort. if these events happen frequently, then there's something else going on that needs to be addressed and talked about. mostly because you lose two days every time you bust a sprint. it paints a giant target on you that screams 'we didn't have our crap together. so now we have to go back and get our crap together' and no-one likes that. This is the main mechanism used to 'force' a team to fix their problems. granted, most SMs and most companies don't bust sprints even when things are going very poorly. but this is what scrum has in place for what you described. (so start doing it.)
In reality, Scrum tries to prevent these scenarios by enforcing better habits around planning and commitments. if you're new to scrum, or don't understand it yet, this can be extremely chaotic as Scrum assumes you have certain things already worked out. Scrum training generally does a woefully inadequate job of explaining this. the point is to highlight your main problem areas so you can fix them.
It's doing that very well. you've identified your time sinks. have some problems. Scrum's job is done. now it's your turn. talk about the issues as a team and figure out a solution based on the context of your environment (team/project/company/organization).
-------------
Recommended reading:
Phoenix Project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509
Crucial Conversations: https://www.amazon.com/Crucial-Conversations-Talking-Stakes-Second/dp/0071771328/
Lean from the Trenches: https://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/
When you're ready for something more advanced:
Tribal Leadership: https://www.amazon.com/Tribal-Leadership-Leveraging-Thriving-Organization/dp/0061251321/
Toyota Production System: https://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143/
Lean Software Development: https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/
Note: This last book is 'advanced' mostly because of price. It's worth it.
Though you're asking in the context of AWS, there are many best practices for designing and operating a distributed system at scale whether it's under AWS or not. The Practice of Cloud System Administration is platform agnostic and a fantastic place to start. No referral link!
I think all of those things you've listed are valuable in their own right, however I think a bit of focus may help. First, determine what you are actually trying to accomplish because learning all those at once is not really feasible. Break that long term goal down into more meaningful steps.
For example, a good long term goal may be:
> Deploy an source controlled application on AWS using a configuration management tool, leveraging Infrastructure as Code to make it repeatable and Immutable Infrastructure to provide stability.
Breaking that down we have a series of things to learn:
These things can be done somewhat in parallel, but I would say focus your efforts will most likely provide the best value. The order in which I've listed these I find is the most useful to instruct people that are new to the area.
AWS:
Building A Scalable Web App on AWS
General Cloud Architecture
The Practice of Cloud Systems Administration
GIT
Git Book
You are really taking this personally aren't you? A simple comment meant to be a lighthearted jab at the USA for completely ignoring nuclear power and you take it as gospel? Incredible.
The USA has 98 operating nuclear plants. Those plants are 10% of the installed capacity and provide nearly 20% of the power we use. Somewhere in the range of 160 million tons of carbon is NOT emitted into the atmosphere as a result. If China continues on their nuclear power path, which seems very likely, then they will soon be emitting less CO2 than the USA. I don't have hard facts for that but it is pretty straight forward. The more low carbon, or in the case of nuclear no carbon, power generation sources operating then the cleaner your emissions. China has a long road ahead but they are moving there faster than the USA.
Try not to take things so personally. It makes you sound like a dick.
Also, please feel free to start educating yourself about nuclear power.
[Dr. Rogers wrote a decent book] (https://www.amazon.com/Nuclear-Energy-Leadership-Lessons-Operators/dp/1593702450)
Raymond Murray also wrote an okayish book. It is easy to understand but has some odd math problems.
What the hell has happened to reddit? Why is everyone fucking on edge all the time?
Edit: China is currently operating, constructing, or planning 21 nuclear power plants. Nuclear will take on a major role with their low regulatory environment.
Here are all the local Amazon links I could find:
amazon.co.uk
amazon.ca
amazon.com.au
amazon.in
amazon.com.mx
amazon.de
amazon.it
amazon.es
amazon.com.br
amazon.nl
amazon.co.jp
amazon.fr
Beep bloop. I'm a bot to convert Amazon ebook links to local Amazon sites.
I currently look here: amazon.com, amazon.co.uk, amazon.ca, amazon.com.au, amazon.in, amazon.com.mx, amazon.de, amazon.it, amazon.es, amazon.com.br, amazon.nl, amazon.co.jp, amazon.fr, if you would like your local version of Amazon adding please contact my creator.
Senior Level Software Engineer Reading List
Read This First
Fundamentals
Development Theory
Philosophy of Programming
Mentality
Software Engineering Skill Sets
Design
History
Specialist Skills
DevOps Reading List
> What knowledge do you carry over from the history of our field that you can't easily learn or discover now?
and
> Instead of one system to do everything for the business, I am starting to see a trend towards many specialized systems that are built to interface with other systems.
Go together nicely. This is how things were before the PC took over. What did the old-timers do? What approaches to system design need to be taken into consideration when dealing with multiple vendors that are not interoperable? What about support contract management? These things haven't changed much. And they are hard questions to answer through a book.
Books to read? Hmm. I generally suggest:
And yes these are written by old people.
you need to do some serious reading on recessions
https://www.amazon.com/How-Survive-Recession-Slim-Thug-ebook/dp/B008NWJUXA
Second those and add The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, Volume 2 1st Edition
The title is a little misleading, but the latest version of The Practice Of Cloud System Administration is excellent.
Stay on-prem.
Unfortunately, you're asking a very broad and vague set of questions. All of those topics you're asking about are an issue to be managed even if you're only using a single cloud provider, let alone multiple ones. Books have been written on these topics. Read those books and build the answers that apply to your job. That's the best way to handle those challenges. There's no silver bullet, not for any one of those topics.
Here's a good starting point, especially if you literally don't know where to start.
https://www.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X/ref=pd_lpo_sbs_14_t_2?_encoding=UTF8&psc=1&refRID=7D6GJ0MDAF0DA469WJK1
I know this is days later but I thought I'd throw in my two cents.
The Best Team Money Can Buy was great.
I also enjoyed The Arm.
The Big Chair by former Dodger GM Ned Colletti was a really interesting look from the perspective of the front office. It's more of a memoir so it starts about Ned's early life as a kid in Chicago. It gave me newfound respect for Colletti.
Currently reading The MVP Machine, which is a great look at player development.
Smart Baseball is a few years old but is a good book about newer stats and why things like RBI, pitcher wins, and stolen bases are pretty bad ways of evaluating players.
If you want more Dodger history from their Brooklyn days, Bums was a fascinating read.
Well I'll be the first one to give you generic information that you could have found with the search function.
You just do the needful.
https://www.amazon.com/dp/032194318X/ref=wl_it_dp_o_pC_nS_ttl?_encoding=UTF8&colid=3IXCECMPTZ0C5&coliid=IJFXHOHENJ2FH
https://www.amazon.com/dp/0321492668/ref=wl_it_dp_o_pC_nS_ttl?_encoding=UTF8&colid=3IXCECMPTZ0C5&coliid=I3J2AR8V86JZMD
https://www.amazon.com/dp/0596007833/ref=wl_it_dp_o_pC_nS_ttl?_encoding=UTF8&colid=3IXCECMPTZ0C5&coliid=I2OPTI4J0S4UG2
Good screwdriver set.
https://www.ifixit.com/Store/Tools/64-Bit-Driver-Kit/IF145-299
A network tone tester in case you need to map out your network and document everything. Also functions as a basic cable tester.
https://www.amazon.com/Fluke-Networks-MT-8200-60-KIT-IntelliTone-Toner/dp/B00N2S6RPY/ref=sr_1_5?ie=UTF8&qid=1473701817&sr=8-5&keywords=fluke+networks+tester
A punch down tool.
https://www.amazon.com/TRENDnet-Punch-Krone-Blade-TC-PDT/dp/B0000AZK4D/ref=sr_1_1?ie=UTF8&qid=1473702091&sr=8-1&keywords=punchdown
An ethernet crimper.
https://www.amazon.com/TRENDnet-RJ-45-RJ-12-RJ-11-TC-CT68/dp/B0000AZK4G/ref=sr_1_1?ie=UTF8&qid=1473702137&sr=8-1&keywords=ethernet+crimper
A quick cable stripper.
https://www.amazon.com/Monoprice-Stripper-Cutter-Cables-107051/dp/B0069LRBU6/ref=sr_1_3?ie=UTF8&qid=1473702190&sr=8-3&keywords=ethernet+stripper
A usb hard drive dock.
https://www.amazon.com/Sabrent-External-Duplicator-Function-EC-HDD2/dp/B00IKC14OG/ref=sr_1_2?ie=UTF8&qid=1473702021&sr=8-2&keywords=usb+hard+drive+dock
A notebook.
https://www.amazon.com/Rhodia-Meeting-Book-Made-France/dp/B001DCDSW6/ref=sr_1_1?ie=UTF8&qid=1473702220&sr=8-1&keywords=rhodia+meeting+book
Your necessities may vary, this applies to more of a one-man shop, and there's plenty of other things you'll want to get that I don't have listed here depending on your job.
I dunno how much you should get paid.
It's a book. Like others said. Here's an amazon link: https://www.amazon.com/Possible-Release-World-Warcraft-PlayStation/dp/3659762296
Time Management for System Administrators: Stop Working Late and Start Working Smart
The Practice of System and Network Administration, Second Edition
Windows Server 2008 R2 Unleashed
Windows Server 2016 Unleashed includes Content Update Program
The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2
The Practice of System and Network Administration: Volume 1: DevOps and other Best Practices for Enterprise IT
Network Warrior: Everything You Need to Know That Wasn't on the CCNA Exam
I wouldn't say im a fan per se...but you sound bitter as fuck...like your angry or some sort of authority when no one in this reddit forum knows sh1t about you.
I mean..any jealous person can anonymously talk shit about someone whose accomplished and has actually put themselves out there.
It doesnt matter what is presented to you, youre still hating on the guy....i mean..anyone that hates like that is a tad b1tchlike...dont you think?
He does alot of other things too...and like i told the other guy:
https://www.amazon.com/Agile-Pocket-Guide-Making-Business-ebook/dp/B008KPM7ZS
https://www.linkedin.com/in/petersaddington
https://www.cnbc.com/video/2018/02/07/peter-saddington-bought-a-lamborghini-with-bitcoin.html
https://www.youtube.com/watch?v=yY86vH7z9qA&t=
But of course...this means nothing to you cuz that hate feels so gooood lol!
Here you can find some recommendations: https://agilestash.com/books.html
Apart from the ones in the website above, I'd like to recommend to you as well:
https://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381/ref=sr_1_2?ie=UTF8&qid=1527189551&sr=8-2&keywords=lean+software+development
https://www.amazon.com/Lean-Dummies-Natalie-J-Sayer/dp/1118117565/ref=sr_1_1?ie=UTF8&qid=1527189536&sr=8-1&keywords=lean+for+dummies
Happy reading!
http://www.amazon.com/gp/product/032194318X/ref=oh_aui_detailpage_o08_s00?ie=UTF8&psc=1
u/sigbox here is a reply for now from my partner:
---
Win Probability Added (WPA)
We will be publishing a full article comparing the WPA statistic with the RunPlusMinus RPM statistic.
Wikipedia defines WPA as a sport statistic which attempts to measure a player's contribution to a win by figuring out the factor by which each specific play made by that player has altered the outcome of a game. Fangraphs gives a good description of the WPA statistic here and contains references to related articles. As well, Keith Law’s book “Smart Baseball” devotes a whole chapter to WPA.
The RPM statistic measures the contribution of every player’s involvement in every play relative to the historical average contribution of a player in the same role in that game situation. The most succinct way of comparing WPA and RPM is to show the differences when considering their respective adherence to the 5 “CRAZI” principles described in the post “The Best Baseball Statistic”. These are summarized in the table below. The forthcoming article will provide much more detail on each principle.
|Principle|RPM|WPA|
|:-|:-|:-|
|Comprehensive|Yes (all players & events)|No|
|Run-Based|Yes|No (win based)|
|Additive|Yes (player & team)|Yes* (player only)|
|Zero-Sum|Yes|No (average is zero)|
|Independent|Yes|Yes|
The applications of RPM are more extensive than those of WPA. Specifically, RPM results can be used to: assist in-game decision making, predict game winners with more than 50% accuracy, forecast team standings, suggest fair salaries, rank all players and teams on both total and component (batting, running, pitching, fielding) performance.
---
I hope that helps!
- Ivan
Good for you, you're seeking out your knowledge and it sounds like you're dedicated to learning as well.
You won't get a good sense of what we do alone, especially because it is a very diverse field and can include specializations in storage, virtualization, databases, helpdesk, desktop support, mobile device management, security (which in itself has a number of specializations), operations, project management, monitoring and reporting, copper and fiber networking, firewall management, programming or developing... See my point? You can read a little more on the fields here
Anyway, if your computer is capable I would suggest you at least familiarize yourself with SOME of what we do, try and get Hyper-V running and learn some of the Powershell commands for interacting with the VMs, then use those VMs to run some *nix stuff and learn how to use those.
There is honestly a ton of free stuff, books, documentation and such available for you, you just have to know where to look and what you might want to see. The search bar here sucks but use the google advanced search for this subreddit and there is a ton of stuff to find, here's a few examples you may find useful:
... I've got literally dozens and dozens of relevant links that you might find useful. My suggestion is to start wide and shallow and figure out what you might interesting, then explore that further. If you want career advice I would suggest you focus on programming and *nix administration (there's a great comment on here in the last year with a path of things to accomplish) as these would give you the greatest variety of skills to create programs, apps, shell scripts, admin servers, etc... Also, don't neglect your soft skills or negotiation abilities as they are very valuable in helping you complete work when not working alone. Good negotiating skills will help ensure you don't get a $14/hr job when you're doing the work of a $70k
It sounds like you're trying to use technology to solve a problem that correct and useful documentation and processes would solve.
You don't want your team to have to re-invent the wheel every-time a patch is required.
Here is a useful book I would recommend.
Book
Do you know anyone in business? Ask them. If not, write to people in your market or industry - people will help you for sure if you ask the right questions and are polite.
> Are there any recommendations on books to get me started.
One I've read that was really insightful from a hardware perspective i.e getting a physical product to market - From Concept to Consumer
Highly recommend it.
Black Belt Librarian and First Time Manager were helpful for me.
Not quite Wu Tang, but still financial advice from a rapper
There is a really great solution that works great when it is politically practical: fold the dev and QA team together and tell them that they own releasing a quality product. That is the only real fix I've seen.
If you are stuck with separate teams, then I have two pieces of advice...
First, stop tracking anything that is per-discipline; only track "feature is ready for release/not ready". The reality is that "dev complete" is not a useful state from the business perspective, so just stop tracking it. Your devs will likely resist this because they have been getting rewarded for "dev complete" even when it's crappy quality. You want them thinking about optimizing the "dev + QA" time, not purely the dev time.
Second, start doing bug categorization. I wrote up how I did it here. I had *amazing* luck with the first team I did this with and it was a team with separate dev/qa roles; my devs felt that having "foreseeable" bugs come up in the feature they worked on was a pride thing. I don't remember the numbers, but merely by reporting the stats monthly at the end of an iteration, they went from 45 foreseeable bugs in the first month to 4 foreseeable bugs 4 months later, and that was with me expanding the definition of foreseeable along the way. It drove dev/qa discussions in a way I have never seen elsewhere and pulled in our product owners in a very agile way as well.
I also recommend that you go read "The Goal" by Goldratt as it provides some insight into optimization across groups (others recommend "The Phoenix Project" as that's IT-based, but I think "The Goal" is a better choice).
I also wrote a blog series on applying the theory of constraints to software; you can find it here. Read from the bottom up.
If you think it is in any way useful to blame someone for making a mistake and then admitting it without pressure, I have the book for you.
Supply Chain Logistics Management
https://www.amazon.com/dp/B07N1478YG/ref=cm_sw_r_cp_apa_i_1ewDDbC7QAJSY
Need PDF asap, will Venmo or PayPal $15.
My top 3:
Just came across this one, but haven't read it yet: