Becoming a Lead Programmer and Journey towards an Aspiring Architect : Checklist

Its appraisal cycle in most of the companies. Suddenly there is a need to talk about technology (Appraisal Cycle gives us an opportunity to talk about technology once in 6 months).

When I was managing the CP Team, we created a checklist for team members who had the aspiration to become an architect.

If you are a Techie (aspiring to grow in the technical line) you can use this checklist and do an honest evaluation of where you stand. Your individual development plan can be decided based on that.

If you are a Manager managing Technical resources, you can use this as a checklist to evaluate your resources and help them define their development plan.

Working with Customer Day to Day Interactions
Requirements Discussions Negotiate Scope
Estimates Discussion
Technology Discussions
Architecture, Design and Development Infrastructure Operating Systems, Hardware, Networks etc.
Software
  1. 3rd Party Software/Controls
  2. Knowledge of available Open Source Tools/Software
  3. Knowledge of libraries, databases, frameworks etc.
  4. Load balancers
Design Principles
  1. UML (Create and Interpret Use cases, Class Diagrams and Sequence Diagrams, Able to convert them into code)
  2. Understand the Fundamentals of Domain modeling
  3. Object Orientation
  4. Cohesion/Coupling
  5. Programming by Intention
  6. Program to Interfaces
  7. SRP, OCP, LSP etc…
  8. IOC, AOP, DI
  9. Knowledge of POUT, TDD and BDD
  10. Knowledge of Design Patterns (GOF/GRASP/Microsoft .NET Patterns/Implementation Patterns/Integration Patterns/J2EE Patterns) – Able to co-relate a problem with a pattern
  11. DSLs
  12. Layers/Tiers (N-Tier/Multi-Tier Architecture)
  13. SOA
  14. Any other ….
Cloud Computing
  1. SaaS
  2. PaaS (Azure)
  3. IaaS (Amazon Web Services)
Software Development Methodologies
  1. Agile (XP/Scrum/Kanban)
  2. Waterfall
Writing Solid Code
  1. Unit Testing (POUT/TDD/BDD)
  2. Acceptance Test Driven Development
  3. Refactoring
    1. Code Smells
Debugging
  1. Working with Legacy code
  2. Identifying the core of the problem by simulating environment, scenarios
7-ities Usability, Maintainability (Flexibility/Testability), Scalability, Availability (Reliability), Extensibility, Security and Portability.
Knowledge of how to code for these.
Estimation Knowledge of FPA, Use Case Points, Wide band Delphi, Planning Poker
Technology Coping up with the trend Any technology for that matter. As of today (ASP.NET 4.0, ASP.NET MVC, ASP.NET Ajax, WPF, WCF, WF, SharePoint 2010, SQL Server 2008 R2, Azure, Dynamics CRM 5.0, DLR, Development using Dynamic Languages, Mobile Application Development)
Working with Team Interpersonal Skills
Influencing Others
Coaching Junior members
  1. Pair Programming
  2. Pairing with Junior members from design to development
Deliver on time / Meeting Commitments
Personal Skills Positive Attitude Can do things
Commitment Disagree and commit
Manage Conflicts
Constructive Confrontation
Presentation Skills
Communication Skills Written, Verbal, Listening
Value Adds Contribution to the Hiring process
  1. Understand how to filter resumes
  2. Technical Interviewing
  3. Behavioral Interviewing
  4. Deciding whether somebody will be a cultural fit to the organization
Contribute to Community
  1. Blogs/Articles/Reviews
Knowledge Sharing
  1. Trainings
  2. Knowledge Sharing Sessions

If you are serious about your technical career, use this throughout the year and not use them only during appraisal cycles.

Happy Learning!!!

Advertisements

Are you hiring a Technical architect: What to Expect?

We are currently in the process of recruiting a technical architect for one of our large team. In my opinion the Architect Role in Software is not a well-defined one and I do not think it’s a much matured profession today (at least in India).

There are two kinds of Architect you can see in the market.
1. Non-Technical Architects
2. Technical Architects

I am sure we all know about the 1st one, so no need to talk about that. I am sure you would have seen the expectations from a technical architect from various sources.

My version looks something like this

Technical architect role Expectations

As a manager, I will have some expectations on this role and following is a summary of my expectations. Ofcourse my expectations are high, because I had the privilege to work with some real architects (Guys like Sendhil, Mike Knight).

1. A Technical Architect needs to be Hands-on. He should be able to code (better than the stars in the team). Why?
Let’s say you are building a house and you have approached an Architect. Architect speaks well, shows you design from a catalogue. So you decide to go with him. You ask him to give you a proposal. Whatever he mentioned in your initial meeting, if you don’t see the same quality, will you have any respect for him? Or he comes to you and says, I can only give you a blue print (design) but construction is not my job, will you go with him? I will never go with that person.
If it’s true for the construction industry, how will this be different to Software?
If your architect only speaks and doesn’t code, he is never going to get any respect from any of the team members. Assume, he reviews somebody’s code and gives his comment, if the team feels the architect cannot code better than this, and then they are not going to listen to him.

2. An Architect should have a very good understanding of all the technologies that you are currently working. Should be able to stay on Top of the Latest Trends.
Example: if you are in a .NET world, Architect should know how to code on the following
OOP, ASP.NET 3.5, ASP.NET MVC, Silverlight, SaaS, PaaS, IaaS, SOA, WPF, WF, WCF, ASMX + WSE, ASP.NET Mobile Development, NHibernate or Entity Framework, Office based application development, Test Automation (Unit and Functional), Continuous Integration & Delivery, UI Patterns, GOF and other EA Patterns.

You can ask me, are you expecting a superman?
In my opinion, the architect position should have both depth and breadth of technology so that he can contribute to the solutions. An architect must be able to take a step back and look at a higher level, which is difficult for developers and projects managers as they are often too focused on the current project and immediate needs. Unless, the person can have a bigger picture it will be very difficult.

I will definitely expect my architect to convince my clients on why to use a particular technology? Say for example: if we are proposing Silverlight and client is asking why not HTML 5, I would expect my architect to try on why we proposed Silverlight (Not just accept whatever is told).
I cannot definitely listen from an Architect that we will use WPF for Web.
What this means is as an architect, one need to learn continuously. When looking for an architect, you should make sure whether he has the ability to learn continuously.
Earlier, I used to think that an architect should know multiple platforms (Java, Microsoft). But with the current trend, there is a quite bit in Microsoft Stack itself and if an architect can do well in Microsoft stack, it will suffice.

3. An architect should help the team achieve more with less. Now, it may look like a Manager talk. Let me explain what I mean here.
Assume you are working on a team where you do builds once in 3 days. Every time there is a build, there are lot of manual operations to build and deploy which is creating lot of frustrations. Now if you are an architect, you should be able to at least get the basic build operation automated and hand it over to the team so that the team can take it forward from there.
I have seen people talking about doing POCs. In my experience, teams will take things forward only if they see the benefit and POCs will not give them the benefits. Some basic work has to go in to convince team members.

4. I would expect the architect to be more involved with the team, so that the team can work with him and learn.

5. An architect should be able to Multi-task. He is the technical guru in the unit/company and everyone will look at him for help. Hence, multi-tasking becomes a key.

6. I would expect a technical architect to design, develop and test the application throughout the development. I normally hear this from people saying I have been coding for years and I want to only design. IMHO, if you do not code, you cannot design or architect. Unless whatever defined in boxes are translated to code and it works all it remains is boxes. An architect should be able to implement what he has designed.

7. Finally, should be able to help in proposals. Technology is important, but to implement technology we need money and it comes only through business.

Useful References:
Coding the Architecture Blog
Role of an Architect

Happy Learning!!!