Architect sounds like such a mysterious title. Especially in the eyes of novice programmers who are just starting out in the development field, architects are all good, they are all great, they are all so high up in the world.
But after four or five years of programming, programmers often lose the mystique of these “senior” positions and complain that the architects on their projects are water Kings. Therefore, Jiangnan Bai Yi once wrote: “Most domestic architects start to run in theory after they reach 30 years old, while foreign architects keep their programming experience while developing upwards. Therefore, there are many water Kings in China and many masters in foreign countries.”
This is the topic of today’s article: a good software architect must first be a good programmer.
In my own words, “The career of an architect who doesn’t program is short.” He said that the background of this sentence is mainly aimed at some architects’ design and implementation of the fault problem, because if the architect does not practice, just take it for granted that “no problem, this idea can be implemented”, then it is a great hidden danger for the implementation of the project. The architect of Alipay also said that the architect is a relatively “virtual” position, and the main problems are in the process of “landing”.
The most direct way for an architect to know if an idea will ever get off the ground is to write code and try to “implement the hardest part of a system” (Fred George). Look at Fred, who is himself a prime example of an old man still coding every day. In fact, we could go through a long list of top architects and you wouldn’t find a single one who wasn’t a top programmer.
We can go through a long list of top architects, and you’ll find no one who isn’t a top programmer
This may not be very convincing logically, though, because it doesn’t seem to prove that an experienced architect can’t know from experience whether an idea will work or not. If you think all of this is just some geeky western obsession with programming, take a look at how the architect at eBay summed up the architect’s role on a project:
1. The product team is working on a new product, and the architect starts. The architect helps the product team break down feasibility, technical requirements, and trade-offs.
2. With the technical requirements in place, the architect’s main job begins: designing the overall technical implementation steps. Randy goes on to add that “most successful architects like to work on architecture and design with other team members,” and that it’s a common mistake for novice architects to think they should do this alone.
3. Work with the development team to complete the design and implementation details
4. Work with the development team and operations team to complete the deployment process
5. Perform post-deployment maintenance and troubleshooting together with the O&M team
In this process, at least half of an architect’s work needs to be done with the development team. According to Randy, this is a sign that “an architect can’t leave implementation details behind.” Working with a development team, commanding leadership is not appreciated, and an architect must direct the development team through his or her personal influence. And what is influence? To put it bluntly, the idea is to guide team members in implementing each architectural detail by writing code themselves and with other members.
It only takes a moment to understand the importance of this move. If an architect manages a development team by command, telling them “implement this module,” “implement that feature,” and the team tries to do that. But maybe the architect’s requirement is too high, or the team’s development strength is not enough, the team members will turn to the architect for help: look, we don’t know how to implement this, can you give us some guidance? The architect may or may not know how to deal with this problem, but he or she feels that he or she doesn’t care about small things, so he or she frowns and says, “This is your problem, you solve it!”
And then the conflict begins. The architect felt that the team was not skilled enough, and the team became increasingly dissatisfied with the architect. When the project fails, there will be a lot of talk from the development team, such as “This guy is a liar who can’t write a line of code!”
Architects need to know that effective communication is a critical skill for building trust and influencing people outside the team. They know that different groups use different words, and it can be difficult to communicate with business people using technical terms and descriptions. Instead of talking about patterns, tools, and programming concepts, the architect needs to communicate with the audience using familiar vocabulary, such as risk-reward, cost, and benefit. This is better than simply using technical terms to communicate.
Taken together, this proves Fred’s assertion that “the career of an architect who does not program is short.” Not only must an architect be able to write code, he must also be able to write the most difficult code to implement in the system he designs. This way he can safely leave the burden of landing to the development team.
If you are a good programmer, but want to develop toward the direction of the architect, you can join my group of 650385180, I will share in the group of industry work experience over the years, I help you to become the architect of the road more walk more far above, also hope that we can speak freely, after joining to share their experience, Help your friends in the group avoid detours.
Being a technically well-rounded architect is not easy because there are so many areas to focus on, and each area has many skills that developers often don’t focus on and practice. The most important thing is not necessarily the ability of an architect, but that they have enough expertise in each different area.
Let me conclude this post with a quote from Fred: “The value of an architect is that he can not only see the beauty of a system, but also create that beauty as he builds it.”
Yes, every good architect must be a good programmer.
distributed
Micro service