Good Coder - Good Architect
In my opinion only good coders tend to be good architects. Why?
First of all before delving into my statement, Let me try to be clear with the following fact. You may be a fantastic resource/architect in your organization, or you may have awesome designation achieved during short time bla bla.... Whatever it may be, in reality it has nothing to do with genuine architecture skills.
Architecture itself is something not indigenous or induced in our DNA by birth. Furthermore remember that don't get deceived by title or designation. They are measured from company's perspective, not from your own genuine self-assessment. You could be a superb architect in your current company, probably when you try for jobs and switch, it's then you realize that you are not even valued as developer/senior developer with regards to your target employer, or it could be other way around too. Nothing can beat self-assessment/realization.
If someone overstates that he/she is a good architect, but never ever have coded or involved very less in coding activities at their early career stages (yet entitle themselves as an architect), is simply crap to me.
Next gonna talk about managers, not leaders. There are massive differences between them. For simplicity i am not going to stretch on those differentiators. Growing and achieving to be a good manager is quite natural and not so surprising. Why? From the day of our birth we have been directly or indirectly influenced with management tricks, tactics and skills. We talk and behave differently with friends, relatives, parents, loved ones etc...? They are to self-adjust ourselves, basically to bend and set positive and favorable conditions for our peace, self-satisfaction and growth. That's what exactly people managers are supposed to do, the only difference is that you do it for the sake of your company/employer.
Architectural skills are quite different as opposed to managerial skills, and have no relation too. You need rational thinking, logical and space thinking, optimization and other techniques cum skills. These cannot be acquired or pursued so easily. Imagine it takes 20 + years from your birth to learn little bit of management. How on earth one can assume that architectural skills can be grabbed just like that. It's not a piece of cake.
A year ago one of my friend questioned me, what is it that makes or shapes oneself to become a good architect. My answer: (1) 50% professional coding experience, (2) 20% reading topics and articles, (3) 30% committing mistakes. Yes you read that right "Committing mistakes". People might think I am talking crazy. Let it be, in the eye of an idiot I might look crazy. In reality I know what i am talking about, and who I am.
Hope I don't need to throw much lights on point 2, since in this technology era we have access to umpteen number of sites, blogs, e-books etc... to accomplish it? All that is important is that we need little bit of desperation to consistently achieve point 2.
Point 1 and 3 are very crucial and important, cannot be neglected any cost. In my experience i have witnessed many Indians (especially), those involved in coding for 2 or 3 years (be it .NET, Java, etc...) tired and bored of coding, subsequently target to either be a manager or an architect. Whatever be it, sounds funny and baseless to me. This is equivalent to the statement, if someone says that they have managed and ruled a district, tired of it, now it's the time for them to rule America. Doesn't it sound funny :)
Coding is just not just syntactically composing lines of code. It teaches how to structure code for reuse, manageability, loose coupling, memory and performance optimization, right use of natural language power, and its simplicity. Lots of people overstate that coding in C or C++ is great, compared to .NET and Java, since in such languages there are no degree of control or are abstracted too much. Remember this, if a language has too complicated syntax and semantics it does not mean anything. It could be complex to learn, but then at the end of the day it should be easy to use in terms of maintainability, modularity, understand ability, and mainly simplicity.
Assuming that we have written beautifully structured code, works fine on our PC. Does this mean we have done a good job? Nope. Here comes point 3, trial and error, learn through your mistakes. For example: your code might run perfect in your PC. What if it has to run on distributed environment? What if tomorrow your data volume, and transactional volume increases dramatically? What if you have integrate with some existing systems? What if you can accommodate various alternative course of actions? In simple words, the system we design and code should be manageable in such a way that it can cater to any scale, and accommodate changes, yet be easy to maintain. This not only solves problem of maintainability and flexibility, it also saves huge cost and time.
You might argue that there are lots of books related to best practices and architectural patterns, yes there are, I agree. But understanding and choosing patterns that best suites ones business requirement in current and future is more important (This is wisdom). For this wisdom there is no book in the world as far as I know which can teach you directly. It only comes through work experience and mistakes. Committing mistakes at early career stages are important, since that's the only way you learn and understand what is correct and not correct for several business situations. It is this skill very important and hard to acquire.
For example: Let's say you try to use cache objects in .NET to solve your application data performance in web applications. What about cache coherence, how are you going to solve it? Have you thought about distribute cache mechanisms etc...? Same goes with dependency injection too...
Even if we are good at designing our components, their actual implementations could still screw up. To avoid such situations we need to be very good coders. We have to know which language constructs to use at the right place wisely. It's like an arrow with Arjuna versus an arrow with Dhuriyodhana. Although both have the same arrow it dramatically varies on the person's skills on how they use it. Without extensive coding my mentioned point number 1 cannot be achieved, nor can we be Arjuna.
The broader types of applications you work, more coding, and more mistakes committed initially, learning through trial and error and evolution, will make you better in terms of right thinking and shape our wisdom.
Just by drawing UML and architectural diagrams and by reading design patterns and architecture books, one cannot turn out to be a good genuine architect.
Happy coding. Happy architecting.
Great article , as an experience more than 10 yrs , still in coding, i am with you
I was convinced.
A good architect is someone who started as a good developer, and then learned to think like a normal, sane, non-obsessive person. I hope no one finds that comment offensive. But examine the good architects in your midst and tell me it isn't true.
Interesting perspective but short in some areas I'd say. Architecture isn't necessarily technical (business architects are also architects, right?)... and the activities, products and practices may not translate to code (think strategy, standards, frameworks, etc.). What you seem to be referring to here is a domain of architecture and so clarifying would help your argument. To conclude: an architect, regardless of domain, will become successful when they learn the acts and arts of persuasion, politics, communication, achieving consensus, presentation... these non-technical but seriously important points coupled with the technical and business-context "appreciation" of them good architect in my view. What makes them excellent is answering this question: do the outputs of your work help address and concerns of business?
I agree with you that good coding skills are a prerequisite for being a good architect. However, they are not sufficient. You're making the classic mistake that being an architect requires only technical skills. Architects "communicate". To developers who will help implement their ideas. To product owners and managers who find the implementation of those ideas. To other architects do that designs across the enterprise are congruent. Where there are differences in proposed solutions, inter-personal skills and negotiation skills are an important part of the architect's role. These "soft skills" are critical to being a good architect. I hope this helps.