This morning I was interviewed about being a software architect from the point of view of the general public. I have copied the questions and the (raw) answers here.
1. Why do you like this profession (Software Architect)?
The software architect position is the best position for someone who likes to build things in software. It is an extension of programming. I always describe programming as: “solving puzzles as a job”. The best way to understand this: do you like to solve Sudoku puzzles? or crossword puzzles? Programming is like having a job where you solve those puzzles full time. Software Architect is a higher level job to figure out how to break the system up into smaller pieces that can be solved by individuals on a team. A Chief Architect divides an even larger system into pieces that can be solved by teams. It is not easy to find the right solution which has the proper balance between power and usability. The satisfaction comes when customers actually use and like the result – that is the best proof that you have found the right solution.
2. What training is required to be a Software Architect?
A thorough understanding of software engineering and system design principles is required. The principles that guide system architecture are not naturally intuitive. There are many things that an inexperienced architect will do to attempt to make the system run faster or smoother, which actually has the opposite effect when the system is scaled up to high loads. Today, a good understanding of object oriented design and service oriented design are required, but in my experience the inexperienced architect is most often tripped up by an incomplete understanding of threading and transactions. Funny thing is that it does not seem to matter too much which programming languages you know and use. Everyone has a favorite for a particular task, but it is fairly easy to switch between them, and the worst mistakes/performance problems are at a higher conceptual level and could occur in any language. So focus on understanding how systems work, and not just a particular language.
3. What advice can you share with others in or entering into this profession?
Prepare to be misunderstood by the public. Most people mistakenly believe that programming and system architecture is a kind of manufacturing where basic requirements are input, and the code is produced in a left-brained factory-like way. Software development is more like the fine arts than it is manufacturing. A great programmer is better compared to Michelangelo than to Henry Ford. The reason is that every day the software developer creates something brand new that has never been invented before. Once that puzzle is solved, it never needs to be solved again. There is no repetition. Contrary to public perception, software development is an extremely creative, right-brained activity. The clearest evidence for this dichotomy is that struggle for acceptance of an Agile method for development of software. Those who understand software development know that an Agile approach is key to good software, but traditionally trained management is very uncomfortable, and want instead to run things like a manufacturing plant. My advice is to learn everything you can about the Agile approach, and avoid organizations that do not employ it.
4. Do you feel you are you over/underpaid or paid just right?
The interesting question about pay in the software field is how great a variability there is in talent. A famous Harvard study found that programmers will vary in productivity by a factor of 18. Other studies have found factors around 20, and even one extreme study that found a factor of 200. What this all means is that what one developer will take a month to accomplish, another developer will complete in a day. There are people that if you can get them for 3 weeks, they will outperform a full year of the worst programmers. The interesting thing is that while productivity varies over a range of ~20, the pay scale varies only a range of ~1.5. That developer that is producing 20x, is getting only 1.5x pay. The lowest performing developers are overpaid, while the highest performing developers are vastly underpaid. Some simple math tells you that your best deal is to pay a little more, and get a much better developer. A small team of capable developers will outperform an army of weak developers every time. The industry as a whole pays the average developer pretty well, but gets a tremendous deal on the high performers.
OK, I admit, I pretty much dodged this last question. But who is going to say that they feel they are over paid? Saying you feel under paid seems too self serving. I came up with the most interesting answer I could. :-)