So what does a master builder of software do? It is a person who understands the business, how to use software to solve business problems, and how to persuade people to use software to solve business problems.
I was re-reading What is a master builder? and when I came to the quote above I did not like it. Especially the last part, "how to persuade people to use software to solve business problems". Persuasion is the wrong word. I think about the "art of the possible", which I think is one definition of politics. I think it's about understanding what's possible in this situation. That means understanding the context you are in and collaborating to come with the best that's possible given the context. This will probably be the most difficult part of being a master builder to master.
...how to use software to solve business problems.
This part is also problematic. It is not about using software but building software. The building part is what must be mastered and most of the time that will require a team. So a master builder of software is a master technical lead.
...a person who understands the business
What is "the business"? It's one of those terms that gets thrown around, especially amongst software developers, as this mysterious abstract thing that pays their salaries. I think it's about having an answer to the questions, "Who are we trying to serve? What are we doing to serve them?". The answers should be specific. If there are no specific answers to those questions I don't think there's a point in doing anything. The answer to the "who" question will often include more than the end user of the software. The answer to the "what" question is dependent on the answer to the "who" question.
I would rewrite the above quote to be:
So what does a master builder of software do? It is a person that understands who and what the software is for, how to build the software to meet the requirements of who and what it's for, and how to do the best thing possible in each situation.
A better understanding of what the master builder of software does, makes the path forward a little clearer. I think the easiest part will be to master will be building the software. I've already started practicing that part, reading "TDD by Example" by Kent Beck and "Growing Object-Oriented Software Guided by Tests" by Steve Freeman and Nat Pryce. And most of the study I plan on doing in the following year is to be able to understanding more and more of the aspects of building software on a team. I'll go into more detail on that in a later post.
I think the next easiest focus will be on understanding who and what the software is for. Each project will have different answers to those questions and they may not be so easy to figure out. It will require an understanding of who in an organization is interested in a project and what they are interested in happening. It may not be the successful completion of the project. It will require some competence in business analyst. I don't quite have a plan for that as well thought out as I have for mastering the building of software.
I think the last part, understanding the "art of the possible", may not be something that can be learned in any book. I might just have to get into a bunch of situations, reflect on what was possible and see if I can take the learning into the next situation. I don't much of an idea now how I can do this but I have a decent idea of where to aim.