主要当然是跟架构相关的事情吧（好像是废话哎），具体一点就是架构设计，讲解推广，然后再做一些代码方面的工作。说起来，讲解推广可能是很多人不太重视的，但其实它的比重还是比较大的，基本能到三成。
而这三者的比例，5：3：2也是很经常的。也就是说，团队到达一定的规模，java架构师可能80%的时间都不在编程而在思考上。想（设计）不好，团队就会走很多弯路。很多时候我们太忙，看起来是事情太多，但其实可能是想得太少。
会写代码么？会写，但可能不是核心代码。这实际上取决于每个团队的成熟度。例如，我会在早期阶段编写一些核心代码，但后来由于团队功能更强大，如果我没有为某个功能分配足够的精力，那么在实现方面，为了不拖累总体进度，我倾向于编写一些边际代码，主要是为了了解团队的代码质量和实现进度。现在可以编写更多实验性代码并使用一些新技术。
这里面还有个很特殊也很重要的工作，就是故障处理。对于一个系统来说，实现出来只是第一步，真正做成高可用的系统，还有相当长的路要走。这个过程中，你会遇到各种各样的情况，遭遇系统宕机、服务崩溃等等。基于故障的改进是架构演化很重要的一种形式。我们经常说，故障是推动技术进步的重要动力，就是这个意思。在处理故障的过程中，才会更容易体会思考当前系统的缺陷，后续改进的方向也会更加明确清晰。
前面这些事情基本都是属于输出型的，是个人对团队的贡献。个人层面，我还是需要不断地输入，学习新的知识，保持对行业、领域内新技术的更新。这里也向大家推荐一下，看论文可以认为是架构修炼的一个捷径，因为很多论文写得比较严谨，也会比较系统，了解一个系统实现的细节甚至是思想都很方便。
推荐阅读：《java架构师指南》架构师需要掌握的知识结构有哪些