DEV Community: Ajay Bhosale

Understanding levels of responsibilities to move up in the career ladder

Ajay Bhosale — Mon, 03 Aug 2020 02:24:25 +0000

If you have worked at a large software organization, I am sure you may have faced following questions at some point in time.

What is the difference between a software engineer and a senior software engineer? Or a between a team lead and delivery manager?
How to move up in the hierarchy?
What does it mean to really grow in career?

Many times the sense of progress is associated with a job title and the scope of responsibility. Job titles can be misleading, and organizations tend to create them just to give a sense of movement, without much change in scope or nature of responsibilities.

From my experience, there are four levels of responsibilities.

1. Responsibility of presence

Being there, both physically and mentally. This looks pretty oblivious, but whether you have just started a job or doing it for 10 years, once in a while you will find it difficult to fulfill this responsibility. Some organizations have ways to enforce the physical presence, but mental presence is still an individual territory. For a person who is new at a job or at the first level of the hierarchy, this is their primary responsibility. Be there, listen, learn, ask questions, and understand the context. Do note that you can’t keep lingering at this level forever.

2. Responsibility of efforts

Putting efforts towards the assigned task. Acquiring, and improving on competencies required to perform these tasks. One can also help their co-workers to move from responsibility of presence to responsibility of efforts. This will be the key responsibility for someone who can work with a little bit or no guidance.

3. Responsibility of output

From here you take ownership and start being accountable. You work with those who are responsible for efforts and ensure that those efforts have desired output, on time, on schedule, and with required quality attributes. It is also important to note that those who are responsible for efforts may or may not report to you directly or indirectly. You will also invest time in mentoring and building teams which can consistently produce the output.

At an advanced level of this stage, you also work as a translator who can translate the direction and vision from senior leadership into actionable tasks which can be performed who are responsible for efforts.

4. Responsibility of outcome

This is the last stage, where you are accountable for the desired outcome from the business perspective. If you are an experienced person, then you might have worked on a project which passed the output test but failed to produce the desired business outcome. At this stage, your primary job is achieving the output getting realized as outcome.

This responsibility demands that you provide vision, direction, advise and required resources to folks who are responsible for output. You need to be comfortable with the fact that your reward will be based on the outcome and not on efforts. Almost 99% of time outcome is measured objectively in terms of numbers like revenue, and profit.

Now moving up in the hierarchy can be simplified as taking the next level of responsibility as mentioned above, or increasing the scope of the current responsibility. Most organizations like to see the demonstration of your ability to perform the next level of responsibility before your official movement.

Don’t target role, target activities

One key advise I got from a mentor is instead of targeting for a next level role target for activities that you want to perform at that role. Come up with proposals to improve things or start/own initiatives which normally owned by the person at the next level. This will help to build your case, demonstrate your appetite as well as the capabilities for next level of responsibility.

So what you are responsible for?

Lessons learned while working as an architect — Part II

Ajay Bhosale — Tue, 14 Jul 2020 15:06:34 +0000

Few years back I wrote about lessons learned while working as an architect, you can read them here. Since then my role changed from an architect who works on implementation projects for a single customer to an architect who consults teams from multiple customers spanning different industries. Here are some new lessons I learned external consultant/architect.

Accept the fact that efforts realization will be low

While working on a single project, all you care about is details, and make it work. It’s a fulfilling job with a high realization of efforts, the outcome benefits end users, sometimes you need course correction, but you learn as part of that process which is also fulfilling. Consulting on the other hand is very different, you are always on the move, switching context, effort realization is very low, you spend time on things like POC, RFP, and RFI which may get scrapped suddenly. This impacts your motivation, and you may feel out of action. By accepting the nature of consulting business you will be able to cope with low realization.

Use/suggest patterns/styles/practices without naming them

Using loaded terms like Microservices to explain proposed design invites unproductive debates. The discussion moves to advantages vs disadvantages of said practice, everyone starts throwing buzzwords, and it derails the focus from the actual problem. What I learned is to just use the underlying idea, for example instead of saying “Microservice Architecture”, I say “Modular services holding their own data, using asynchronous channels and crisp messages for communication”. This removes unnecessary resistance and bias. This advice looks contrary to practice of naming patterns to ease the communication, but I found it very effective.

Connect with real decision maker(s) and end users

As an external consultant, it takes time to get access to real decision makers within the customer organization. Sometimes the org structure does not reflect real flow of decision making and influence. Finding the key decision makers, opening a communication channel with them, and establishing trust is key for success. There is no formula for this, you have to observe, listen, and follow the memos (like follow the money). On the other hand, finding end users is easy, but getting access to them is very difficult for external consultants. Organization policies, politics, and culture builds multiple barriers between you and the end users. Connecting with end users, and understanding their needs helps you to distill the problem statement. It helps you to ensure that you are building the right thing for the right people, and deliver it incrementally.

Understand and pick your battles

As an architect providing appropriate technology solutions to a business problem is your primary battle. Defining the problem is also a battle, navigating a complex org structure for information is another one, and so is selling your solution. Each battle requires different skills, you can’t master them all. You have to pick your battles, work with your team to augment skills which you don’t have and support them for remaining battles.

Thanks for reading.

Lessons learned while working as an architect

Ajay Bhosale — Tue, 14 Jul 2020 15:04:37 +0000

Over the last 12 years, I played role of solution architect on multiple projects. Here is summary of lessons I learned over the period.

Need for embracing ambiguity

As a developer, our demand for clear requirements is very logical. As an architect, it’s totally different story. For most of the projects, the requirements aren’t clear, partner systems aren’t ready, business analyst is in dual mind, and despite all this chaos you are expected to come up with a strong design. At start (especially if it is your first assignment as an architect) this becomes very frustrating, but as you start to live with this ambiguity your approach becomes adoptive. One key trap to avoid here is to build a design to satisfy imaginary future requirements.

Consistency in decision making with the help of guiding principles

Consistency will help you to quickly gain trust with team and customers. The guiding principles should be based on good practices, non-functional requirements, specific project needs etc. Note that principles should not be rigid but evolve over the period, and needs to be followed in the spirit (and not the text). As the team understands the reasoning behind your decisions and starts adopting the principles, bottleneck on you for every other decision will be reduced.

Some of the examples of guiding principles — “Lower memory footprint”, “Performance over data duplication”, or “No single point of failure”

Be there on shop floor

There is no point in being a visio architect, who keeps churning out fancy diagrams. As an architect, you must work with engineering teams, let them be involved in decision making. If possible, do pair programming with them to get first-hand experience of their challenges and how your own design is getting implemented.

Influencing without authority

Recently during a mentoring session, a senior developer told me that he doesn’t wants to be a manager because it involves lots of communication and interaction with others, but as an architect, he can work alone. This is a huge misconception. As an architect, one must learn to communicate and influence. As a manager, I don’t need to explain (most of the times) logic behind my decisions, I can simply dictate the things. But this is not a case with architect, you need to communicate to various stakeholders, understand each view point, influence developers/testers who don’t report to you.

On a lighter note, most difficult task as an architect is to convince developers and other parties to move to a better design from the current design, which you yourself has created few months (or days) back.

Thanks for reading, feel free to like, comment and share.

async, await, and keeping your promises

Ajay Bhosale — Fri, 15 May 2020 03:58:15 +0000

The async function and await keyword introduced as part of ECMAScript 2017 do provide very useful syntactic sugar on top of promises. Promise in itself provides alternative to callbacks when writing asynchronous code. Promises can be chained, its inbuilt methods like all, any, and race helps to manages multiple asynchronous tasks.

Check the following example, here getData function mimics asynchronous behavior. In real world, you can think it as your data layer, using functions like fetch or a 3rd party library which still using callbacks for asynchronous programming.

const getData = (n: number) => {
    return new Promise<number>((res, rej) => {
        if (n === 3) {
            rej('Can not use 3.');
            return;
        }
        res(n * n);
    });
}

If I have to, fetch data for 2, and based on that response fetch data for 3 and 4, then the code will look like something below.

const check = () => {
    getData(2)
        .then(x2 => {
            console.log(x2);
            return getData(3);
        })
        .then(x3 => {
            console.log(x3);
            return getData(4);
        })
        .then(x4 => {
            console.log(x4);
        }).catch((ex) => { // This is catch handler
            console.log('Error occurred : Check with Promise.');
            console.log(ex);
        });
}

If we used async and await, same code will be more readable and easy to understand.

const check = async () => {
    try {
        const x2: number = await getData(2);
        console.log(x2);
        const x3: number = await getData(3);
        console.log(x3);
        const x4: number = await getData(4);
        console.log(x4);
    } catch (ex) { // This is catch block
        console.log('error occurred : check with async and await.');
        console.log(ex);
    }
}

Error handling, is still a challenge. If a promise is rejected, then either the catch handler get executed, or an exception will be thrown. With await keywords, only way to handle rejected promise is try-catch block.

This may work for some cases, but what if you are fine with errors while loading data for 3 and 4. The catch block does not give a good way to handle control flow. You may end up having separate try-catch blocks for each await, and that will worsen the problem.

Languages like go, has a different philosophy to handle errors. It segregates error from exception, and communicate errors with ordinary values as return parameters.
Lets see what happens when we try that philosophy here.

Always keep your promises

Let change the getData function so that it can never reject the promise. The promise will be always resolved, and errors will be reported via a return type.

type PromiseResponse<T> = Promise<[string] | [null, T]>;

const getData = (n: number) : PromiseResponse<number> => {
    return new Promise((res) => {
        if (n === 3) {
            // no reject here 
            res(['Can not use 3.']);
            return;
        }
        res([null, n * n]);
    });
}

I have declared a Type here PromiseResponse, which is a Promise returning tuple, and will assist TypeScript for better syntax checking.

First item will be error : string or null.
Second item will be actual result of Type T or undefined.

const check3 = async () => {
    const [e2, x2] = await getDataV2(2);
    // Here for TypeScript x2 is either number or undefined
    if (x2 === undefined) {
        console.log('Error while fetching data for 2');
        return;
    }
    // As x2 is checked for undefined
    // at this line x2 is number
    console.log(x2);

    // now fetch data for 3 and 4
    const [e3, x3] = await getDataV2(3);
    if (x3 !== undefined) {
        console.log(x3);
    }

    const [e4, x4] = await getDataV2(4);
    if (x4 !== undefined) {
        console.log(x4);
    }
}

With the new approach, code don't need to use try-catch block and we have better control over flow.

I am using this techniques for application layer, which seats between UI and underlying data, and its make life much easier.

Based on your requirements, you can extend the Type PromiseResponse into a class, and with helper methods like Success and Error to make your code more readable.

I have a utility function, named as aKeptPromise on propose. With this function getData is more readable.

function aKeptPromise<T>(
  callback: (
    success: (result: T) => void,
    failure: (error: string) => void
  ) => void
): PromiseResponse<T> {
  return new Promise((res) => {
    callback(
      (r) => res([null, r]),
      (e) => res([e])
    );
  });
}

const getDataV3 = (n: number) : PromiseResponse<number> => {
    return aKeptPromise((success, failure) => {
        if (n === 3) {
            failure('Can not use 3.');
            return;
        }
        success(n * n);
    });
}

TypeScript Playground

Thanks for reading. Let me know if you have comments.