Technical Architect
-
I am thinking of moving from my current position of developer to a position of software architect. This is mainly out of the frustration of not having an input early enough in the project. I am not in a big rush, I am thinking of starting by reading a couple of books about software architecture and perhaps a book about how to speak to your boss. I'd be happy to get some advice here
-
I am thinking of moving from my current position of developer to a position of software architect. This is mainly out of the frustration of not having an input early enough in the project. I am not in a big rush, I am thinking of starting by reading a couple of books about software architecture and perhaps a book about how to speak to your boss. I'd be happy to get some advice here
How long have you been a programmer? How long have you been with the company? How much street cred do you have? If you do't fully understand the process of writing the code, how can you expect to become an "architect"?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
How long have you been a programmer? How long have you been with the company? How much street cred do you have? If you do't fully understand the process of writing the code, how can you expect to become an "architect"?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997His ambitions are legitimate. Do you really think a software architect understands the process of writing code? :rolleyes:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I am thinking of moving from my current position of developer to a position of software architect. This is mainly out of the frustration of not having an input early enough in the project. I am not in a big rush, I am thinking of starting by reading a couple of books about software architecture and perhaps a book about how to speak to your boss. I'd be happy to get some advice here
IMHO, a software architect is someone who has at least these properties:
- an extremely wide depth and breadth of technical knowledge
- several years of experience bringing products to market
- a high degree of expertise dealing with the challenges of scalability, security, reliability and maintenance
With all due respect, and to take nothing from your experience and background, I doubt this is the kind of stuff that one picks up simply by reading. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
IMHO, a software architect is someone who has at least these properties:
- an extremely wide depth and breadth of technical knowledge
- several years of experience bringing products to market
- a high degree of expertise dealing with the challenges of scalability, security, reliability and maintenance
With all due respect, and to take nothing from your experience and background, I doubt this is the kind of stuff that one picks up simply by reading. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
With all due respect, and to take nothing from your experience and background, I doubt this is the kind of stuff that one picks up simply by reading.
one would always hope this to be true but I think we all have worked in companies at some time or another where there was that one architect that made you wonder?? :confused:
as if the facebook, twitter and message boards weren't enough - blogged
-
I am thinking of moving from my current position of developer to a position of software architect. This is mainly out of the frustration of not having an input early enough in the project. I am not in a big rush, I am thinking of starting by reading a couple of books about software architecture and perhaps a book about how to speak to your boss. I'd be happy to get some advice here
If you do get into an "Architect" role, please remember to bring some humility and pragmatism to your work. If you were writing client / server VB.NET WinForms applications as a "developer", but as an "architect" you can no longer get anything done without (for example) seven tiers, UML, a web sever, the entire Rational tool suite, and a well-worn copy of the "Gang of Four" book, then I think that's a problem. Though my description may sound like an exaggeration, the sudden transition that I described is something I have observed multiple times in newly created "architects". I am not immune to this sort of flawed behavioral pattern myself, although I do feel I have grown out of it somewhat. At present, my conception of a good architect is that of an enabler. He or she should be someone who can help with difficult or pitfall-laden tasks, and whose help thus ends up being (mostly) welcomed by his colleagues. As much as possible, he or she should not be someone who snoops around uninvited looking for trivial "gotchas".
-
I am thinking of moving from my current position of developer to a position of software architect. This is mainly out of the frustration of not having an input early enough in the project. I am not in a big rush, I am thinking of starting by reading a couple of books about software architecture and perhaps a book about how to speak to your boss. I'd be happy to get some advice here
Pascal Ganaye wrote:
This is mainly out of the frustration of not having an input early enough in the project.
Many years ago I climbed the corporate ladder for this exact reason. I wanted more input on projects and/or products to try and make them better. I learned that no matter how high climbed I was never satisfied enough. During that time I sacrificed my love of developing code for climbing that ladder. So after a few years I settled back down into software development where I am happiest. I have been asked several times to take on management roles and each time I gave this story followed with a simple "no thank you".
as if the facebook, twitter and message boards weren't enough - blogged
-
Ravi Bhavnani wrote:
With all due respect, and to take nothing from your experience and background, I doubt this is the kind of stuff that one picks up simply by reading.
one would always hope this to be true but I think we all have worked in companies at some time or another where there was that one architect that made you wonder?? :confused:
as if the facebook, twitter and message boards weren't enough - blogged
-
Ravi Bhavnani wrote:
With all due respect, and to take nothing from your experience and background, I doubt this is the kind of stuff that one picks up simply by reading.
one would always hope this to be true but I think we all have worked in companies at some time or another where there was that one architect that made you wonder?? :confused:
as if the facebook, twitter and message boards weren't enough - blogged
Yes, the problem with architards and those in their ivory towers certainly exists. I've had the good fortune of working with architects who also write code every single day and are frequently called upon to solve hard problems. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I am thinking of moving from my current position of developer to a position of software architect. This is mainly out of the frustration of not having an input early enough in the project. I am not in a big rush, I am thinking of starting by reading a couple of books about software architecture and perhaps a book about how to speak to your boss. I'd be happy to get some advice here
Far as I know books about architecture don't teach the skill but instead teach techniques. Same way, for example, that the "C++ Programming Language" book teaches one about programming in C++ but doesn't teach one how to program. Also architecture more of a soft skill than programming and consequently writing it down is harder. You must have the following. - Basic understanding of project management and task management (and understand the difference) - How to gather requirements and analysis them - How to do high level estimating - How to do change management. - Be able to talk to people, - Have a basic understanding of managing expectations. - Have a basic understanding of risk analysis. - Have a basic understanding of project cycles including inception, design, implementation, support and maintenance work. - Have a basic understand of how formal QA works. - Probably also need some basic skills in effectively managing people. - Probably have more than a basic understanding of how to put together enterprise systems (multiple systems) and understand alternatives for that. You also need a deep knowledge in one or more business domains. Some examples (and not even close to complete list) - How hospitals work - How inventory/sales work - How large volume systems work - How large image systems work - How complex work flow systems work - How a game console works - How telephony works - etc, etc, etc.
-
I am thinking of moving from my current position of developer to a position of software architect. This is mainly out of the frustration of not having an input early enough in the project. I am not in a big rush, I am thinking of starting by reading a couple of books about software architecture and perhaps a book about how to speak to your boss. I'd be happy to get some advice here
Pascal, I've had the misfortune of working for two so-called architects. One was relatively competent but hardly a good communicator. The other was completely inept and generally kept his halitosis-damaged breath to himself, which suited us fine who had to deal with him. Don't make being an architect the be-all of where you want to go. True, a good architect is worth having onboard but a good developer who knows the best practices can often make a significant contribution to any project. I don't think you'll get everything you want from a couple of books. Architects are often as much political animals as they are good developers. Best of luck, all the same.
-
How long have you been a programmer? How long have you been with the company? How much street cred do you have? If you do't fully understand the process of writing the code, how can you expect to become an "architect"?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997The Microsoft definition of the require qualities is "over forty and over confident" (heard at a PDC half a dozen years ago). Since then, it's struck me that that's a pretty accurate description of the ones I've met.
"People who bite the hand that feeds them usually lick the boot that kicks them." Eric Hoffer "The failure mode of 'clever' is 'asshole'" John Scalzi
-
Far as I know books about architecture don't teach the skill but instead teach techniques. Same way, for example, that the "C++ Programming Language" book teaches one about programming in C++ but doesn't teach one how to program. Also architecture more of a soft skill than programming and consequently writing it down is harder. You must have the following. - Basic understanding of project management and task management (and understand the difference) - How to gather requirements and analysis them - How to do high level estimating - How to do change management. - Be able to talk to people, - Have a basic understanding of managing expectations. - Have a basic understanding of risk analysis. - Have a basic understanding of project cycles including inception, design, implementation, support and maintenance work. - Have a basic understand of how formal QA works. - Probably also need some basic skills in effectively managing people. - Probably have more than a basic understanding of how to put together enterprise systems (multiple systems) and understand alternatives for that. You also need a deep knowledge in one or more business domains. Some examples (and not even close to complete list) - How hospitals work - How inventory/sales work - How large volume systems work - How large image systems work - How complex work flow systems work - How a game console works - How telephony works - etc, etc, etc.
I think this is the only and single precise answer to the original question. These really are expected traits. However, I do have a request/suggestion. If you become an architect, please create an archi which is revolutionary and widely accepted. Don't miss out any good feature from any previous archi and do not include a feature which you and the rest of the dev fraternity hated. :cool:
-
Far as I know books about architecture don't teach the skill but instead teach techniques. Same way, for example, that the "C++ Programming Language" book teaches one about programming in C++ but doesn't teach one how to program. Also architecture more of a soft skill than programming and consequently writing it down is harder. You must have the following. - Basic understanding of project management and task management (and understand the difference) - How to gather requirements and analysis them - How to do high level estimating - How to do change management. - Be able to talk to people, - Have a basic understanding of managing expectations. - Have a basic understanding of risk analysis. - Have a basic understanding of project cycles including inception, design, implementation, support and maintenance work. - Have a basic understand of how formal QA works. - Probably also need some basic skills in effectively managing people. - Probably have more than a basic understanding of how to put together enterprise systems (multiple systems) and understand alternatives for that. You also need a deep knowledge in one or more business domains. Some examples (and not even close to complete list) - How hospitals work - How inventory/sales work - How large volume systems work - How large image systems work - How complex work flow systems work - How a game console works - How telephony works - etc, etc, etc.
I think such a person still needs to be born.
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
