From Application Architect to Consultant Application Developer

To be frank, this is not a technical post. May be first post in this blog without any code snippet.

Let me start with a quote.

"A developer can be CTO, if he switch from Google/Facebook to a personal portfolio site building company"

People may disagree to this as CTO position needs more skills than a hardcore smart developer. This is from my experience with the industry. Technical positions depends on nature of work especially how critical the projects are. We can see people doing coding only in mission critical applications/frameworks who gets more money than a CTO of portfolio web site development company.

This post is regarding my job and role change from Application Architect to Consultant Application Developer. The above is not to get a self satisfaction by saying its common:)

What I was doing earlier

By title I was Application Architect. But due to the nature of company or nature of me, I was doing developer++ jobs along with some architectural jobs such as preparing the technical arch document, leading the technology and cultural(At least sone amount of TDD) changes.

Why I change

I understood that Application Architect is not developer++. That is a different role requiring different skill set and mind set though development skills are very important.

Does the arch do estimations? I was thinking no. But now I understood that archs needs to do estimations at least high level as in the beginning of the projects only architects know what and how exactly the technical things are going to be.

During my arch role I strongly believed as an arch I should never draw some boxes and run away. Instead I should make sure the project is delivered in quality at all the levels. The challenging part was code quality. I had spend too much time to ensure the project has good code quality and because of that I was not able to give attention to many other areas. I took that as a challenge to bring code quality to a culture which built around the core principle of "deliver on time even if its 0% quality". Later I understood, there is no meaning in giving something which is not needed by the stakeholders/sponsors. More than that if we want to bring code quality, it should be a mission critical project where failure in the application will halt the business. But the advantage of working in just-deliver projects is a kind of job safety.

When I do code reviews, I felt sometimes the team members are not comfortable especially when I ask why this is class level variable or public? They started murmuring that I am also like other high level managers who don't know or forget coding and not able to understand developer feelings.  I became tech lead at the experience of 3.5 Yrs and arch at 5.5 Yrs. I feel it was too quick and may be I missed the developer days and that is the reason why I am not able to understand their feelings. There is no chance to get the developer days back in the current company from the arch position because there are no mission critical or real critical frameworks.

Offshoring is a great way to reduce cost for developed countries and its good for countries which gets new jobs. I was in offshore for long getting more money than my friends working for business / companies. But its little tedious when comes to onsite and deals with offshore teams. We have to make sure offshore is happy without reducing productivity. It can only be achieved by frequent interactions. Due to the timing(East cost US and India), either I had to spend my night time or they have to spend their night time to get enough 1-2 hrs interaction per day. Some companies do understand that when they do offshoring for low cost, the quality will reduce and time will increase. But some won't. Then the trouble starts. If we want to get things done next day by offshore, offshoring doesn't looks great to both the sides though what ever relation is there among the team. 

Should the architects give more important to coding or meetings and other things? My understanding was arch should eliminate most of the meetings as they are technical persons and focus only on tech stuff. But its not true. Architects should be able to sell what he done and that can only be done by meetings and other inter personal skills.

Of course money was also involved. When a company bring people to US from outside, there is a  tendency to give the minimum required to process the visa regardless of their importance or role. There are a good chunk of people who thinks their destiny is to reach US and they will stay back in whatever salary is offered at first. At least until they get green card. But I am not in that category.

The good thing here in US is, there are so many resources available such as glassdoor.com which gives a good idea about market rates. Since black mailing my company with a resignation letter for more money was not my way, I decided to move out. May be in future, if there are convincing reasons will join back.

Everything needs a last fire to start. In my case there was a fire. From the beginning of my career at the company, I was busy with tasks one after another. The situation was like if I quit, company will impact. As a professional I never wanted to give such an impact. But recently one of the flagship product's AngularJS conversion project was taken out from me when the first phase is about to complete. This gave a good gap to say bye without impacting the company. Till this time I never received any call about any issue / query in the project. From that I believe I neved created any dependency on me and I did the proper documentation. Or the person who took over the project or my team is really great and they can manage themselves.  

What I do now/What I gained

Pure development for mission critical application(s). Every variable and line counts. No line will be checked in without lead's code review. If there is a build/MSI change I have to do it myself.

I am really getting the feeling from the developer side after a long time. How do they think on code reviews etc... 

If the app breaks the business will halt and it may lead to firing. No offshore calls or no need to be accountable for other person's work.Since I am consultant developer, my job is mainly to make sure my code works though I try to ensure the post coding activities are going smooth. 

I am not a critical part of the team as I am still learning the system. Hope I should be able to learn the entire system at high level with in 6 months.

There are many more learning such as how an architect should see the code quality. They should be first worried about the contracts/interfaces in the system. Let the team does the implementation. Architect should be able to design the system by contracts to split the tasks and give to team to get the rest. Some kind of piece work approach. To the extent, an architect should not ask what is the purpose of a variable if its internal to class or function. Let that be a worry for the leads who maintain that module and after getting production support calls at night they will automatically change.

Another thing is the socializing. I was in the impression that when I sent a mail with new idea everyone will read it as professionals. But it never happens unless they report to me and I have direct impact on their appraisal. As an architect I have to socialize the idea duing informal meetings and get support from all. At the end the credits to the idea may be on different person's account. But that is fine if we had sent one mail initially to the boss or publish an article in company blog:) 

What I loose

Arch position has knowledge of end to end system. What are the components and how they interact etc...Doesn't needs to go into details of application till a defect or critical situation comes. Another privilege is to take decisions and move on which gives the feeling of ownership.