As a software project manager, do you need to be very familiar with coding

@Sergio, learning, and practice are the keys to success. Most importantly also as you mentioned that the people around you must be trustworthy when providing data, feedback, and knowledge relating to the project's domain.

When the people "around" you are not trustworthy then there is absolutely nothing you can do about it if you don't have the proper domain knowledge.

But even if they are trustworthy the lack of domain knowledge may create a barrier in communication.

The bottom line: if you don't have good domain knowledge you can't be fully in charge of a project. Others would make decisions over your head and if those decision are not good there is nothing you can do about it.

In software development the developers my like too much doing some tasks and they can focus too much time on them even if it is not required. As a PM with no coding skills you are at their mercy and have to accept whatever they tell you. If they tell you that without those tasks the project can't be completed then you must accept that. You can't challenge them in any way but if you do try then you must come up with an alternative solution but you would not be able to do this because of lack of knowledge.

When you are PM with no domain knowledge you must ensure that you are not held accountable for everything and don't end up being just a scapegoat for others.

You do not need to be an expert to get trust from the people around you. Is the same that a coach in sports or an orchestra conductor for example. Before a project start a PM must do her/his job to take fully understanding about the domain. There are well defined process to do that (for example the CMU SEI process about elicitation). But returning to the point, while trust is the key thing in my personal opinion, it could be or not could be a must. There are lot of studies that you can see in the practice about PM that without trust or few amount of trust have been leading very important and successful projects.

I agree with Adrian, but as PM you will not be the only firefighter in the field, and also PM must be equipped with the proper tools.
PM can control the team's appraisal, approvals of leave/attendance exceptions, bonus distributions, and so on so forth. Owning these levers will help the project manager not being under the mercy of others.

"PM can control the team's appraisal, approvals of leave/attendance exceptions, bonus distributions, and so on so forth"

On the companies on which I have worked this was not the case. Appraisals, bonuses, promotions and other human resources aspects were decided by the functional managers and not by the PMs. In fact it is very common on some projects for the PMs to be more junior than some team members or for the PMs to be contractors or consultants while the team members permanent employees. In these cases appraisals by PMs are not possible.

But even when you appraise a team member you must be an expert in his/her line of work. For instance when you talk with a developer about the tasks he has worked on you need to understand from a technical point of view how complicated they were and how well he has dealt with them. Otherwise you may end up appraising your employees wrongly and they will leave you for better employers.

Very good point Sergio, thanks for sharing.

Apprisal will be done according to the agreed SMART targets and KPIs that both sides agreed upon.
Those targets and KPIs must be business-based, in other words, it must be reflected in terms of revenue achieved, acceptance completed, customer's satisfaction, the incidents recovery rate.
The PM then will have the benchmark, and he will be capable to appraise his/her team.

If the team members are some sort of contingent workers such as contractors or consultants what you are saying could be implemented.

However when the team members are permanent employees this would not be possible. For a permanent employee, working on a project is just a work assignment and nothing more. The employee's line manager is responsible for the work the team member is performing and not the PM. I personally saw a case where a project team member was actually a manager having around 5-6 team leads under him and in total over 70 direct and indirect reports. The PM was a consultant. It would be impossible for a contingent worker to appraise a permanent employee that is also a manager in his own right.

Since in software development it is not possible to provide accurate estimates it is very easy for software developers not to reach the so called business-based targets. A PM that does not know how to code would just say: I don't care you haven't reached your targets so poor performance. A software developing manager on the other hand could say that the developer has done an extraordinary work in those circumstances. That's why appraisals should be done by people from the same line of work as those being appraised.

Then the conclusion will be that the software PM must have strong knowledge in the software domain in order to lead his/her project successfully.

I think so, as a PM should be a generalist.
Thanks for sharing the book.