Most likely I'll be in a project or program management role.
Meant to give this more of a response, so here we go.
@Hair Warrior hit it on the head in that "project management" and "program management" can mean many things depending on where you work. I am by title a "Project Manager," mainly because my company is in transition and title/role changes require CIO approval for whatever reason. If you ask me what I "do," I am a Scrum Master/Agile Coach by trade. The dichotomy here is between old-style "waterfall" and modern "Agile" ways of delivering software.
The old style is defined by the Project Management Institute's PMBOK or Project Management Body of Knowledge. It assumes that you can and should make software the same way engineers build a bridge or a power plant. First, collect requirements. Then, design it. Then, build it. Then, test what you built. Then, turn it over. These things come in phases, hence the "waterfall." This is the realm where detailed requirements document R leads to detailed instructions to the devs to build X, which lead to detailed instructions to the testers to ensure that when the devs built X, it complies with R. This worked fine when the end goal was to put a software application on a CD, shrink wrap it in a box, put it in a store, and have someone buy it. Then you move on to the next application that took three years to develop. Think Windows 3.11, 95, 98, XP, Vista, and so on. No one worth their credibility, except maybe the government, can afford to work this inefficiently now. Even very highly regulated industries like medical software are trying to move to Agile, or at least incorporate what makes sense.
Agile realizes a few things, and I'm going to assume you read what I linked above. First, the customer doesn't really know what they want until they see it demoed to them. Second, long-range plans will change once you show stuff to a customer for the first time. And the second time. And the third, fourth, and so on until it's done. It's a dialog. Customers learn, you learn, the market changes, and the world changes. Third, if you go back to the Toyota Production System, apply empirical process control theory from Lean, and trust your devs to estimate honestly, you can get a good handle on how much stuff your devs can deliver in a given amount of time. And by "deliver," I mean take a small subset of the business requirements that's most important at the time, understand what it means, code it, test it, and demo it to a rep of the customer who can tell you if you are or aren't on the right track. Then you just iterate over and over, demoing to the customer or their rep, until they say "enough, that's good enough for what we need."
So the old style is to have a project manager who gets given requirements and a team, writes a project charter and has it approved, and then creates a waterfall-style work breakdown structure to deliver a given scope to meet that three year deadline within the given budget (Google the Iron Triangle of project management: Scope, Schedule, Cost). Even though the world could change between now and then. When the world changes, the PM works with a change control bureaucracy to update the maze of documents to account for the new plan. It's considered a success by PMI if the project meets its LAST known constraints of scope/schedule/cost, even if those have ballooned to shit since kickoff, as long as the proper bureaucrats approved the changes to the Project Plan.
Scrum plans in one- to four-week iterations, and is the most common way of doing Agile in software (there are others, and the minutiae and pros/cons of each are prone to set off Internet religious wars among Agilists). The development team alone has final say on how much work they can get done in an iteration. The Product Owner (who represents the customer) has final say on what the most important work to be done next is. The Scrum Master is the referee and process guru, as well as the person who goes outside the team to resolve blocking issues that are keeping the dev team from being able to get done what they said they would in a given iteration. The Scrum Master keeps the dev team from sandbagging, the PO from crushing the dev team, and everyone involved in continuous improvement; we're kind of like the NATOPS model manager of the team.
So as a "project manager" you could be anywhere on a continuum between traditional PM or Scrum Master. God knows there's enough hosed-up Agile implementations out there that try to half-ass it. Program managers in their traditional role are managing groups of related projects, so they're basically the PM of some PMs. In more Agile environments, they could be a Scrum Master equivalent for multiple Scrum teams, which goes by various titles, but is again a process coach, mentor, sounding board, servant leader and remover of blockers, not someone with decision-making authority.
Old-style project managers will have authority to sign off on changes for scope, schedule, and cost, maybe with approval of a project sponsor who is a senior manager. Agile folks deliberately do not. Because their goal is to be a coach and process improver, not a decision maker. Neither of these people ever tend to be line managers who write peoples' performance evaluations, have hiring/firing authority, or salary authority.
More to follow on working with devs when I get to it. Spoiler alert: they're definitely not all socially-inept neckbeards who stink.