Seems to me that “good job” is a 2-place word—which working environments makes which people productive? I have experiences very similar to what you described (dozen new components, zero time to learn, expected high productivity immediately, other people seem to cope well and receive performance bonuses). But I also have experiences of high productivity in business situations, where I received performance bonuses. Sometimes both experiences in the same company, just in a different project or with a different boss.
My “natural” approach is to do some learning first: I try to make sure that I understand the specification, that it is complete and unambiguous. For example I will first sketch the dialogs on paper and ask my boss or customer whether this is what they meant (because redrawing a sketch is much easier, faster, cheaper, and less frustrating than changing the code of an already developed and tested program). I think about all the additional work which was not mentioned but may be logically necessary, and I ask about it in advance, offering the least complicated solution. (“You want to have a list of users with passwords. What happens if someone forgets their password? Perhaps there could be an administrator who can change passwords, and as an almost free bonus, they could also block and unblock users. Or maybe users could provide their e-mails, and then change their passwords using e-mail verification, but that would be more complicated, and some users will call your support anyway, so unless you have thousands of users I believe this is not necessary, and can still be included later.”) I also research the framework I am supposed to use, and make a few simple prototypes with the functionality I expect to need in the project. (Thus, if the framework has some serious problems, I am likely to find out in advance, when there is still a chance to use a different technology, or at least to avoid the problematic parts of the framework. The fact that I am not under pressure yet helps me notice more details and context.) Then, when I am ready (which is never perfect, but that’s not the point), I implement the solution, step by step. At each moment I know where I am in the project and how much needs to be done yet. (This knowledge usually also makes my boss happy, assuming they believe my analysis.) I do a part, and I test it. When I am ready, there are usually very few bugs. So the time “wasted” analysing the problem and doing the prototypes is later offset by less bug fixing and less remakes. And there is generally less stress.
As an example of my work (probably the only example available freely online), I did a cycle route map for Trnava region in one month; and that included learning the Google Maps framework which I have never used before. A short tour: Choosing “Zoznam cyklotrás” displays a list of cycle routes; clicking on one of them displays it on the map. The “Zobrazenie cesty k bodom mimo trasy” checkbox allows you to click anywhere on the map to display the shortest path from that place to the route. There is also a possibility to find a cycle route according to your criteria, display “places of interest” within given distance from the route; your results can be printed or exported to PDF. This is the part visible to the user. The administrator part allows importing the cycle routes from GPS log files, editing and annotating the route points (e.g. “crossing a road”, “crossing a railway”); and importing the “places of interest” from an Excel file. -- I believe I was rather productive here, but of course I am open to feedback. (I am not working for that company anymore, so I can’t use the feedback to improve the product.)
However, most managers insist on a completely different approach to work, which other programmers seem to handle somehow (some enjoy it, others complain but cope anyway), but it makes me suffer and less productive. I would describe it as chaotic, short-sighted, penny-wise and pound-foolish, treating experts as replaceable, and accumulating the technical debt until the whole thing collapses under its own weight. Learning the new technology or debating the details of the project is considered an unproductive waste of time; the important thing is keeping the programmers busy (even if it means doing something merely to tear it down later). Maybe it’s because the managers cannot recognize productivity, but can recognize silence and typing. And I really hate the idea that people are completely replaceable and should be randomly switched between different parts of the project or even random projects; in real life it often means the code is sloppy and undocumented, and there is no time or incentive to fix it, because if you spend your time refactoring the code, it makes you seem less productive, and the benefits will be enjoyed by someone else when you are moved to the next piece of spaghetti code. (Somehow collective code ownership is the part of agile programming most accepted by self-labeled enlightened managers. The other parts like unit testing or pair programming are obviously just a waste of time. I have to ask Robin Hanson whether it is a coincidence that the managers embrace exactly the one part which allows them to reduce the perceived status of expert programmers.) Well, to be fair, sometimes there are also external constraints, such as the customer insisting on doing things the stupid way; but I believe most of this comes from inside of the companies.
Most of my productive work was done when I worked on a project alone; and once when I was a leader of a small project. My approach as the leader was asking people what are their individual strengths and what part of the project would they prefer to do, and dividing the work accordingly. Then I paid attention to have clean APIs between the team members, good documentation of the data, and sketches of the dialogs. And then we just coded, and sometimes debated. Three programmers, myself included, the other two were part-time working students, for me it was the first Java EE project done from the scratch and I didn’t have experience with many parts. Yet we completed it in three months, and received bonuses.
Seems to me that “good job” is a 2-place word—which working environments makes which people productive? I have experiences very similar to what you described (dozen new components, zero time to learn, expected high productivity immediately, other people seem to cope well and receive performance bonuses). But I also have experiences of high productivity in business situations, where I received performance bonuses. Sometimes both experiences in the same company, just in a different project or with a different boss.
My “natural” approach is to do some learning first: I try to make sure that I understand the specification, that it is complete and unambiguous. For example I will first sketch the dialogs on paper and ask my boss or customer whether this is what they meant (because redrawing a sketch is much easier, faster, cheaper, and less frustrating than changing the code of an already developed and tested program). I think about all the additional work which was not mentioned but may be logically necessary, and I ask about it in advance, offering the least complicated solution. (“You want to have a list of users with passwords. What happens if someone forgets their password? Perhaps there could be an administrator who can change passwords, and as an almost free bonus, they could also block and unblock users. Or maybe users could provide their e-mails, and then change their passwords using e-mail verification, but that would be more complicated, and some users will call your support anyway, so unless you have thousands of users I believe this is not necessary, and can still be included later.”) I also research the framework I am supposed to use, and make a few simple prototypes with the functionality I expect to need in the project. (Thus, if the framework has some serious problems, I am likely to find out in advance, when there is still a chance to use a different technology, or at least to avoid the problematic parts of the framework. The fact that I am not under pressure yet helps me notice more details and context.) Then, when I am ready (which is never perfect, but that’s not the point), I implement the solution, step by step. At each moment I know where I am in the project and how much needs to be done yet. (This knowledge usually also makes my boss happy, assuming they believe my analysis.) I do a part, and I test it. When I am ready, there are usually very few bugs. So the time “wasted” analysing the problem and doing the prototypes is later offset by less bug fixing and less remakes. And there is generally less stress.
As an example of my work (probably the only example available freely online), I did a cycle route map for Trnava region in one month; and that included learning the Google Maps framework which I have never used before. A short tour: Choosing “Zoznam cyklotrás” displays a list of cycle routes; clicking on one of them displays it on the map. The “Zobrazenie cesty k bodom mimo trasy” checkbox allows you to click anywhere on the map to display the shortest path from that place to the route. There is also a possibility to find a cycle route according to your criteria, display “places of interest” within given distance from the route; your results can be printed or exported to PDF. This is the part visible to the user. The administrator part allows importing the cycle routes from GPS log files, editing and annotating the route points (e.g. “crossing a road”, “crossing a railway”); and importing the “places of interest” from an Excel file. -- I believe I was rather productive here, but of course I am open to feedback. (I am not working for that company anymore, so I can’t use the feedback to improve the product.)
However, most managers insist on a completely different approach to work, which other programmers seem to handle somehow (some enjoy it, others complain but cope anyway), but it makes me suffer and less productive. I would describe it as chaotic, short-sighted, penny-wise and pound-foolish, treating experts as replaceable, and accumulating the technical debt until the whole thing collapses under its own weight. Learning the new technology or debating the details of the project is considered an unproductive waste of time; the important thing is keeping the programmers busy (even if it means doing something merely to tear it down later). Maybe it’s because the managers cannot recognize productivity, but can recognize silence and typing. And I really hate the idea that people are completely replaceable and should be randomly switched between different parts of the project or even random projects; in real life it often means the code is sloppy and undocumented, and there is no time or incentive to fix it, because if you spend your time refactoring the code, it makes you seem less productive, and the benefits will be enjoyed by someone else when you are moved to the next piece of spaghetti code. (Somehow collective code ownership is the part of agile programming most accepted by self-labeled enlightened managers. The other parts like unit testing or pair programming are obviously just a waste of time. I have to ask Robin Hanson whether it is a coincidence that the managers embrace exactly the one part which allows them to reduce the perceived status of expert programmers.) Well, to be fair, sometimes there are also external constraints, such as the customer insisting on doing things the stupid way; but I believe most of this comes from inside of the companies.
Most of my productive work was done when I worked on a project alone; and once when I was a leader of a small project. My approach as the leader was asking people what are their individual strengths and what part of the project would they prefer to do, and dividing the work accordingly. Then I paid attention to have clean APIs between the team members, good documentation of the data, and sketches of the dialogs. And then we just coded, and sometimes debated. Three programmers, myself included, the other two were part-time working students, for me it was the first Java EE project done from the scratch and I didn’t have experience with many parts. Yet we completed it in three months, and received bonuses.