This is an overview of the typical roles you might encounter in the development department of a software product company. Knowing this might help you to understand the responsibilities of the people you meet. Knowing this might also help you to find out what you want to be when you grow up.
The person in charge of how the product is developed code-wise - how the code should look and where certain code should live. They are allowed to tell you where and how you should code because they know their way around the application code better then you do. Read more on Wikipedia.
The person in charge of the technical department of the organization. This guy or gal is the boss of your boss, so be nice! They can tell you what to do because they are the boss, but if this person tells you to pick up an unscheduled time-consuming task (or makes you bring him coffee), make sure your manager knows. Read more on Wikipedia.
A person who likes to work on the user-facing side of the application. Has to deal with users, browsers and devices. Loves pixels. Peek at their screens to find out what hip new features will end up in the application anytime soon. Read more on Wikipedia
The person who is in charge of the other programmers, code-wise. The role varies per company, but they usually spend some amount of their time on reviewing code and mentoring other developers. That's why you'll usually find 1 lead developer per 2-10 developers. Additionally these persons can probably do architect or team lead work if none are available. Read more on Wikipedia.
The person responsible for what features end up in the application. They discuss with stakeholders on how the application should evolve. This is the person that knows where to find that obscure feature you're supposed to change the color palette of. They get to tell you what you should build because they've talked to stakeholders and really thought it through. Read more on Wikipedia.
The person who is responsible for the planning and deadline of a project. Will expect you to estimate how long something takes. Will be stressed out if you take a lot longer. Is allowed to tell you when to build something, because it's their head that gets chopped of if the project isn't finished on time. Read more on Wikipedia.
A person who is responsible for testing the application (or just the new features) before actual users get to touch it. Will irritate you with little details you know weren't perfect in the feature you delivered, but which you had hoped to sneak by them anyway. Read more on Wikipedia.
A person or a group that has an interest in the application. Examples include end users, management, sales, support, and business consultants. They are all people who are affected in some way by what you deliver. If they tell you what to do, redirect them to the Product owner. Read more on Wikipedia.
The person responsible for who is in the team. This includes team assemblation, planning (not project related), and coaching of team members. Also the first point of contact for other teams, persons or departments that want something from the team. Is allowed to tell you when to do what because they spoke to all project managers and product owners to make sure you don't get overworked. Read more on Wikipedia.
A person who's really good at making the application look beautiful. Is allowed to tell you how a component or page should look and function, because they've thought about it a lot. Really likes pixels being in exactly the right place. Read more on Wikipedia.
A person responsible for fitting all features of the application into a cohesive whole. Will talk about end users as if nobody else is thinking about them. Loves whiteboards, wireframes and personas. Is allowed to tell you where the feature is supposed to show up in the navigation or page. Read more on Wikipedia.