People tend to like the shortcuts. There’s nothing really surprising about that - actually modern corporate standards favor people who are goal-oriented and "know what they want". I’m not gonna condemn this path (as I find myself a pretty ambitious and impatient individual as well …), but if as long as we’re talking about the path of technical excellence - leave all hope: there’s no easy short-cut.
What do I refer to specifically? Every now and then I meet people who ask me what should they do to become a software architect. Which book should they read? Which training should they take?
Such people are not really interested in developing their programming skills. They’re not good developers already either - they just think that being a software architect is a step above typical software development and when you make this step, you leave the bog of dull low-level code work and introduce yourself to shiny meadows of merry assembling architecture blocks. They won’t have to care about all those pesky details, finally free to focus on drawing high-level diagrams, charts, blueprints …
If you’re one of such people, I’m afraid I have to disappoint you - it doesn’t really work this way. There are 3 things you have to commit yourself to, to become a successful software architect:
- code, …
- code, …
- … and code.
It’s all about understanding the low level details and how you could make them fit in altogether. Learning from other people experience is fine, but it’s your own experience that makes you able to tell if given compoents will work together in a satisfactory way.
You don’t just have to remain a software developer, you have to be the best in your team. Simple as that. An eternal struggle of keeping yourself up-to-date.
