Many people have asked me over the years about Software Engineering; what's it like to be a computer programmer? They see the glamour of the job (believe it or not), or hear about the paychecks, without seeing the downsides. There are many positives to the job; because it takes a lot of knowledge to do well, so there are few that will do it. And because it requires thought and continual learning and change, there are fewer that can do it well. So getting a job that's in demand and hard to fill, generally means reasonable salaries and relative security (compared to other jobs); and there are many companies looking for people.
What's the difference between a programmer or a software engineer? Trick question. Since "Software Engineer" (or not "Computer Scientist") has more prestige, virtually all programmers (software developers) call themselves by fancier titles. But in truth, there used to be a difference... since the age of agile programming (rapid application development), there are scant few software engineers. Unless you're doing genetic algorithms (or Artificial Intelligence/Machine Learning) and running experiments on your code to see what it does, you're not really a Computer Scientist. But I'll cover what it used to mean.
People Manager - I've managed a LOT of people over the years (not to mention taught martial arts for a couple of decades). To me, being a good people manager/motivator just isn't that hard:
Help people prioritize their work and keep on task (with nudges as needed)
Do a little blocking and bureaucratic bullshit so that they can focus on work. (Know what/how to delegate, and what not to).
Keep a diverse/balanced team (intellectually), where folks compliment each-others weaknesses, and an environment where they're open to contributing differing views
Play to people's strengths/interests, give them praise/recognition for what they do well (keep them happy, appreciated and motivated), and help them stretch (challenge them) at a rate that they can tolerate. (Give Credit, share the blame).
Occasionally, play therapist and listen to their complaints. Sometimes doing nothing (just being a friendly ear for their frustrations), sometimes helping them back on track and focusing on what they can control or can do to make things better.
There's a lot of nuances of general management, like good communication, manage expectations, planning and other things as well. But for the wetware (people) side of it, it's mostly about the above to me.
Sometimes I'm amazed at how few "people managers" understand those requirements, or can do some or any of that well.
There are good managers, and there are micromanagers, but there are no good micromanagers. You can lead, trust and inspire, or you can question, dictate and undermine -- but not both. That's not to say that there's never a time to micromanage some people or some aspects of a project, but in general, if you micromanage, you aren't delegating and giving people the freedom and protection they need to succeed.
Management - Everything I know about management can be summed up in this one article. OK, maybe not. I've managed many teams of people over the years, and read quite a bit on the subject before getting my MBA. There are many views on the subject, and many that I disagree with; but rather than heckling others, I'll just spew forth some of my own. None of them are horribly original, but sometimes there's value in sorting the wheat from the chaff.
Is there a shortage of qualified technical people? Yes and no. Unemployment is low, so there's certainly a demand. But there's also a lot of qualified people looking that can't get hired or want to break into the field, and the number of Résumé's to job openings is still absurdly high, so let's not pretend that you can't find people -- companies just can't find people that meet their requirements (which are often stupid).
Human Resources people, Managers, and general users, have no idea how simple or complex computer programming is. They think that they can just throw programmers around from one task to another, then some HR people select computer programmers based on language (Syntax), and not what really matters (skills and abilities). This would be like hiring an employee based on what school they attended and not what subjects they studied! This article will give some non-programmers a better idea of what Programming is about, and what they should be looking for when hiring programmers.
How to get a raise? It's not that hard, assuming you're actually worth more than you're getting paid, and if you're not, then you can learn to be worth more. (1) Reduce the risk to your company (2) be easy to work with (3) Manage expectations (4) Show your worth (5) Demand what you're worth (6) be prepared to leave (7) leave if you are worth more, and can find it somewhere else.