111–120 of 178 posts
A programmer who updates his skills frequently have a good chance of staying on top.
Earlier quoted context omitted.
Just a tip, if you want to keep with your sports metaphors, and meant to say "a good PM is on the offensive", you probably meant "a good PM is proactive (acts to solve a problem before it shows up)". Describing someone as 'offensive' is saying there is something about them that offends you.
"To be on the offensive" means "attacking something" or "being aggressive towards something", not that the person who is "on the offensive" offends somebody in the sense that that somebody's feelings are hurt - http://www.thefreedictionary.com/go+on+the+offensive . It's arguable whether or not a PM should be that aggressive, but I'd say his expression made sense.
Earlier quoted context omitted.
I realize this is an extreme case, but you should check out Valve's corporate structure. No one has a "title", everyone can move to whatever project that want to work on, and they still turn out excellent software.
...but not on schedule.
PMs and BAs are supposed to be able to both understand and bring these two elements together. Of course, whether it works that way in reality is another story.
The top rated comment on this question asserts that the reason why programmers have lower salaries is because they are logical, intelligent individuals who refuse to play the politics game and thus are hated by executives. Not only it this incorrect (have you seen the politics in certain open source software projects ?) but it plays into a narrative that programmers want to believe: business people are corrupt and pr…
Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, w…
We need not rely upon opinions here, we can be objective instead.
Let's ask how many business analysts without programming skills have made working software. Similarly, let's ask the same of the managers. And finally, let's ask programmers without any managerial or business skills how many pieces of software they've made.
My guess is that the numbers are 0, 0, and a lot. That's because programming is necessary to write software, whereas management and business analysis is only "nice to have". There is lots of great software that was not crafted by managers or analysts; Linux, Emacs, Google search, Facebook, and so on. Most of the stuff designed by product managers is one-off software that will have made no impact other than paying the team's salary for a while.
The top rated comment on this question asserts that the reason why programmers have lower salaries is because they are logical, intelligent individuals who refuse to play the politics game and thus are hated by executives. Not only it this incorrect (have you seen the politics in certain open source software projects ?) but it plays into a narrative that programmers want to believe: business people are corrupt and pr…
Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, w…
This right here should have been the top rated comment on StackExchange. And, everything else the parent said is dead on.
Earlier quoted context omitted.
Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, w…
Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. We need not rely upon opinions here, we can be objective instead. Let's ask how many business analysts without programming skills have made working software. Similarly, let's ask the same of the managers. And finally, let's ask programmers without any managerial or business skills how many pieces o…
Earlier quoted context omitted.
Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, w…
"Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say,…
The examples of "tech stuff" you mentioned are very junior programming tasks. The "programming" the article talks about is all the non-PM/BA stuff: the overall technical design of the system, not just the file writing and database queries; the testing process from individual components to integration to customer involvement; the build and deployment processes, including impacts on existing systems and addressing security/privacy concerns, etc.
> I can get the tech stuff done. Of course, I'd like to do it myself, but I can get others smarter than me [...] to do the tech stuff.
Project managers and business analysts usually try to add technical skills to their resume by dabbling in some of the "tech stuff" of the projects they're managing. Usually this is the highest level stuff like architecture design or programming language selection or programmer analysis/selection: generally the stuff with the greatest impact on the success or failure of a project. You write "Of course, I'd like to do it myself" so I guess you're one of them. But those with PM/BA experience are the least able to do this project-critical tech stuff.
Project Managers get to dabble in this work because of their power in an organisation. They also try to keep their jobs by "creating" work and problems, just like middlemen everywhere. They stop technical people gaining too much power by splitting the systems into arbitrary projects. They give programming jobs to their mates in return for loyalty.
Despite their talk about being accountable for their results, in reality they cover their behinds in case they fail. When the tech stuff goes wrong, they leave behind a huge mess for programmers to clean up, usually with extra hours and overnight standbies. The business users get to do unit testing as part of their change acceptance process. The PM's go into recruitment and back into management somewhere else. A recruiter once told me "if I had a job like that on my books, I'd apply for it myself".