DEV Community: Anand Safi

The power of saying “NO!”: A Software Engineering Superpower

Anand Safi — Mon, 01 Feb 2021 19:54:49 +0000

While becoming more proficient at coding and learning new frameworks definitely helps, there are some key superpowers which can make you stand out even more as a distinguished engineer. These help you not only to avoid burnout but also have long term continued success.

In this article, we will take a look at the “power of saying NO!” superpower — having the flexibility and willingness to stand by what is important and speak your mind at any given time in that regard.

To expand on this, here are the key benefits that you unlock by practicing this superpower:

1. Increased focus

A study reported via BBC a few years back shared an eye-opening stat.

The average focus time of a human is now 8-seconds, down from 12-seconds, over a mere span of 15 years & is shorter than that of a goldfish!!!

With such a short attention span, finding ways to stay focused on the task at hand is more important than ever.

If one simply continues to have a people-pleasing attitude by being “always available” to work at anything that is thrown to them, they will end up doing actually less. This might seem confusing but in reality, they will be spreading too thin across multiple things at once while completing or getting done with any one thing in its entirety.

The key point here is to have a questioning attitude. The questioning has to be both internal and external.

Internal — asking whether you are compromising something more important and urgent at hand/ in progress by simply trying to stay in someone’s good books? asking whether this is something you can delegate to someone else?
External — asking whether this is the top most priority? It might be a top priority to the person asking but is it truly important & urgent for the business, project, team etc.? asking details around what is being asked from you and why specifically only you?

If there is not a satisfactory answer to any of the above questions or similar, it should be within your power to decline or postpone that request in that moment. While doing so, it must be done in a polite manner with at least some high level context on why this ask is a lesser priority for now.

The above will help you to stay focused on your prior commitments, finish something completely and then move on to the next best thing.

Multi-tasking could be multi-distracting

Too much context-switching or multi-tasking might actually be distracting and cause more harm then help

2.Uplifting your team knowledge

The idea behind this is straight-forward and as stated. When you say “no” to a specific task/ type of request that you have been the point-person over a period of time, it creates opportunity.

It creates an opportunity for someone else to level up, get skilled at something new. This chance to learn something critical or be that alternate shoulder to tap on can be of immense value.
It creates an opportunity for you to mentor and coach. There cannot be a more apt situation to spread knowledge and share your expertise than this specific one.

Knowledge is power. Knowledge shared is power multiplied. - Robert Boyce

3. Growth opportunities

The “growth” in this benefit is in the sense of your individual growth. If you think about it, while you feel great that you are always asked to help with a specific type of request, need — it creates a narrow niche for you over time. The word to stress is “specific”.

It totally depends on whether you would like to stay a specialist or become a smart generalist (or better a versatilist!). In general, if you try to balance doing the same type of work with learning something new or expanding your area of focus, it could lead to more growth opportunities for you.

I personally would have a core area of expertise but equally be capable and aware of contributing to other aspects of product development vs being confined to an area, a type of work. Not only it gives you more interesting problems to work on, it gives you even bigger opportunities to collaborate while becoming a more favorable member to have on a team due to your ability to work and contribute in more areas.

4. Not being taken for granted

This is more important than ever. People, teams and organizations constantly fail to realize that “nothing lasts forever”.

If you feel awkward suddenly declining a request you have always helped with, think of this — you are actually helping the team by saying “no”. Do it for the greater good.

Unless the situation does not reach to a point where one is not taken for granted, they will no explore creative ways to solve the task at hand. There is a strong possibility that many teams and organizations continue to be “blind sided” by this notion.

Just because there is someone now that is handling anything directed at them, does not mean they will continue to be there forever or they will politely keep doing whatever they are told to forever.

I would be more than happy to chat and let me know your thoughts or current focus areas in the comments.

As always, feel free to connect with me on Linkedin - Anand Safi

Mastering a niche vs Smart Generalist — 5 things I wish I knew as a Software Engineer (Part 5/5)

Anand Safi — Thu, 07 Jan 2021 19:39:30 +0000

In case you missed the first part in this 5 part series — you can read about it at: Key Point 4 — Communicate & Collaborate — 5 things I wish I knew as a Software Engineer

All the 5 key traits can be found at

Things to learn as a Software Engineer | JavaScript in Plain English

Anand Safi ・ Feb 8, 2021 ・
Medium

.
...

Honestly, this has been one of the most challenging topics in mySoftware Engineering career and I am certain for many others as well. There is really no right or wrong approach and the ultimate direction will matter a lot based on your preference, interests and operational style.

I will attempt to highlight key characteristics of each side below. Also, there is an added bonus at the end where I want to share a blended approach which I personally prefer (more on that later).

...

Generalists — also referred to as “Jack of all trades, Master of None”

Specialists — also referred to as being “T-shaped” i.e. growing vertically in a specific niche

...

Overall, Generalists can benefit from having a broader viewport, more skills at their disposal and skills that are easily transferable while moving jobs. On the other hand they could end up being on the surface of many skills but mastering none due to lack of depth and vice-versa for Specialists.

An area I want to highlight in the Generalist vs Specialist debate is in terms of Career Development and Growth. A key distinction that I believe is associated with each persona is:

Generalists — They do not have a Career Ladder per se to grow vertically in. They instead have a Career Rock-Climbing Wall which gives them the opportunity to change course and move up, down, left, right depending on their will, accelerated growth mindset and comfort.

Specialists — They have a definitive Career Ladder for the most part. The path may seem narrower, with pinpoint focus and locked down but there is always a solid next stage in sight.

...

BONUS

As promised, I wanted to share an interesting tidbit by Gartner. Beyond being a generalist vs specialist, there is a 3rd category which is being adaptable based on the situation, called Versatilists!

As you can see, Versatilists can scale as well as operate on-demand and as-needed. This is exactly the “wearing many hats” notion that is becoming popular in the field of Software Engineering.

Whether it is jumping on a PROD issue on one day to brainstorming the next product development iteration with the design team, the next day — the true difference in a programmer vs developer vs a SOFTWARE ENGINEER relies on this core skill.

I can personally attest that being a Versatilist myself gives me a strong sense of connection to the entire SDLC, company mission, enhances my communication and collaboration within and outside my team. While it is immensely valuable, there is a potential downside of this seeming as if you are “Spreading too thin” (there is a separate article as well I wrote regarding this at

Things to learn as a Software Engineer | JavaScript in Plain English

Anand Safi ・ Feb 8, 2021 ・
Medium

...

Let me know in the comments below on what are your thoughts with such an approach and when does it make sense to leverage this.

Communicate & Collaborate — 5 things I wish I knew as a Software Engineer (Part 4/5)

Anand Safi — Thu, 07 Jan 2021 18:52:59 +0000

In case you missed the first part in this 5 part series — you can read about it at: Key Point 3 — Not POCing enough — 5 things I wish I knew as a Software Engineer

All the 5 key traits can be found here in this article.
...
I love the following quote which seems apt for this key trait.

None of us is as smart as all of us. — Ken Blanchard

Software Engineering is an art and definitely demands creativity. Often times, due to the nature of work in this field, engineers tend to be cut-off or cornered from a more collaborative spirit. It might simply mean they are having heads down time or really need to focus on solving a particular challenge in a quiet, isolated manner.

While the above certainly makes sense and I agree with the approach, the problem manifests when that becomes a workstyle and mindset. When one continues to be a lone wolf and power through work on their own, they will be twice more resistant to seek help/ ask their teammates to unblock them. Pride can easily get in the way when you want to showcase your top-notch skills as an engineer.

Along with being hesitant to collaborate, it also leads to a communication gap. The team has less visibility in your work as the time passes and may struggle to work with you and intervene when to assist. Communication helps foster team building, speaking the same language and able to articulate any complex technical work in non technical fashion.

...

I would love to know your thoughts in comments below and if you have felt or experienced something similar.
On to the next and last Key Trait #5 — Mastering a niche vs Smart Generalist…

...

Not POCing enough — 5 things I wish I knew as a Software Engineer (Part 3/5)

Anand Safi — Thu, 31 Dec 2020 06:14:28 +0000

In case you missed the first part in this 5 part series — you can read about it at: Key Point 2 — Focused on Implementation only — 5 things I wish I knew as a Software Engineer

All the 5 key traits can be found here in this article.
...
POC = Proof of Concept

I can easily say this is often the most overlooked trait that I have seen across engineers even though the most imporant in my opinion.
▪︎▪︎▪︎
Personally, I learned about this the hard way when I realized I was working hard but not learning/ growing at the pace I thought I was. My manager back then made me aware of the importance of the art of POCing — the process of experimenting, implementing in a light weight manner and picking my own best solution that I was most proud of and one that made most sense to me.

Honestly, it took me some time to realize the benefit of this approach and I often felt I was being challenged or even questioned in my implemented approach for no good reason. Once I was able to gain clarity on some of the benefits (mentioned below), this became my primary approach for most mid-large size or complex tasks.
▪︎▪︎▪︎
Potential benefits of POCing vs a single implementation:
1) Increased ability to weigh pros and cons of various approaches
2) Developing critical thinking to approach a give problem with multiple solutions
3) Expanded coding chops and know-how since each solution might use a different approach or method or syntax
4) Increased ability to approach future refactors with ease and build for scale from get go
5) Increased focus on chosing the best approach vs just delivering a working solution

Hence, I would highly recommend folks to start this approach ASAP if they are not doing it or contiuing to build on it if you are practicing it in some form.
▪︎▪︎▪︎
Let me know in the comments below on what are your thoughts with such an approach and when does it make sense to leverage this.
On to the next Key Trait #4 — Communicate & Collaborate…

Focused on Implementation only — 5 things I wish I knew as a Software Engineer (Part 2/5)

Anand Safi — Wed, 30 Dec 2020 22:12:07 +0000

In case you missed the first part in this 5 part series — you can read about it at: Key Point 1 — Spreading too thin — 5 things I wish I knew as a Software Engineer

All the 5 key traits can be found here in this article.
...
When I think of Focused on Implementation only, I attribute it to being myopic i.e. not seeing the bigger picture. Undoubtedly, the top deliverable for a Software Engineer is implementing a given feature request/ implementing a bug fix.
However, the real benefit or growth as a Software Engineer depends on some level of involvement within the entire SDLC framework.
...
Below are some ways to be involved in each phase outside of implementation/ writing code and the potential gains that lie with it.
...

1)Pitch/ Discovery phase:
The context here is Customer interaction. Knowing your end users have immense value in terms of software development which I cannot stress enough. From understanding what you are building towards (goal of the user), whom you are building for (the user), why you are building it (the user pain point the implementation will address) helps you when you think of how to build it (the implementation itself!). Along those lines, your involvement as a Technical expert from the start of the process can help determine the technical feasibility and a rough timeline check on what is being promised and communicated to the customers.

Note: If the project/ task you are working on is B2C and has thousands of users for example, you can still get the desired value mentioned above. In such a scenario, the UX team and/or the product team can shed some light on the target market and user personas that the implementation will be geared towards.

2. Technical Work Kick-off phase/ Sprint Planning:
As an engineer/ IC, this is the prime phase where you should seek clarity and ask any questions you may have. This may be related to What, Why and When primarily for the task at hand.
I see many teams have this phase missed out all-together or do this between a tech lead/ EM and a product person counterpart only.It is essential for the engineer who might end up working on the code implementation itself to be exposed to and made aware of the task as early in the planning as possible. This will help reduce any misunderstandings and silos later in the process.

3. QA + Deployment Phases
These phases are post-implementation.

QA Phase: If you have a traditional setup with a dedicated QA team, this could still make your agile process waterfall in some ways. As a Software Engineer, you should be able to have reasonable competence of all the levels on the TestPyramid to avoid any potential silos. Doing the critical thinking and due diligence on what could be breaking scenarios for your implementation is a key skill to possess.

Deployment Phase: In case you have a dedicated DevOps team that takes care of the build process and releases, there might be gaps in terms of your knowledge of e2e software delivery. At a minimum, you should be aware of how your code implementation gets bundled, packaged and shipped to the end user. Having fundamental understanding of this workflow will help you write better software when performance and bundle size are some key code metrics of interest.
...

The above 3 phases are just a short summary and some ways you could expand your reach and skill development beyond just writing code as a Software Engineer.
...

I would love to know your thoughts/ feedback on the same in the comments below. On to the next Key Point #3 — Not POCing enough…

Spreading too thin — 5 things I wish I knew as a Software Engineer (Part 1/5)

Anand Safi — Mon, 28 Dec 2020 20:53:13 +0000

All the 5 key traits can be found here in this article.
...
The first key item in the list is Spreading too thin
I attribute this trait to our wandering minds. ‘The grass is always greener on the other side’ notion seems apt for this.
...
• When I started doing Frontend web development, I felt I should also learn Backend Technologies (Java for ex.) since that might be more valuable.
• Next, when I started doing a little more full-stack development, I really felt I should level up my DevOps skills and get familiar with AWS/ Azure/ Google Cloud, Deploying code, Bundling code, Package Management etc.
• Next, when I started focusing on these aspects, I felt I need to establish my presence in the open source community i.e. do some side projects, contribute to existing projects, speak at meetups, conferences and so on.
...
The list almost seemed never ending as I tried to jump from one thing to the next to get more skills under my belt. This is exactly what I believe led me to spread too thin for a brief period of time. I was scratching the surface on a variety of things but not really solid or expert with any.
...
It was during my 1:1 meetings with my then manager that we realized I might be trying to excel at too many things at once. It is great to have a growth-oriented mindset of continuous learning but it has to be meaningful, phased out and planned carefully. One must pick their battles in order for quality development and skill building.
...
I would suggest each of you to reflect on the same i.e. list down what are your areas of focus for growth. If the list seems too big, then you are in the spreading too thin bucket and need to downsize it to the top 1-3 items depending on time and resources at your disposal. If there is not a concrete list that you can come up with, that is an indicator as well. You need to ideally come up with the list on your own or work with your manager/ mentor on one.
...
I would be more than happy to chat and help with your growth goals. Let me know your thoughts or current focus areas in the comments.
...
On to the next Key Trait #2 — Focused on Implementation only…

Software Engineering done right — 5 things I wish I knew as a Software Engineer (5 Part Series)

Anand Safi — Mon, 28 Dec 2020 07:20:23 +0000

Software Engineering is one of the most talked about and sought after career paths in the current world. During my journey as a Software Engineer, I worked with some wonderful people, latest technologies and great projects. As I reflect on my humble beginnings and gradually progressing to be an Engineering Manager currently, I wish I knew some key aspects of the craft of Software Engineering back then.
...
Below is a list of those 5 key traits. We will explore each trait individually as a separate topic in a series of posts.
...
Key Traits:
1) Spreading too thin
2) Focused on implementation only
3) Not POCing enough
4) Communicate & Collaborate
5) Mastering a niche vs Smart Generalist
...
Do share what other key traits one should consider in the comments below!
...
On to Key Trait #1 - Spreading too thin...

DEV Community: Anand Safi

The power of saying “NO!”: A Software Engineering Superpower

Mastering a niche vs Smart Generalist — 5 things I wish I knew as a Software Engineer (Part 5/5)

Things to learn as a Software Engineer | JavaScript in Plain English

Anand Safi ・ Feb 8, 2021 ・ Medium

BONUS

Things to learn as a Software Engineer | JavaScript in Plain English

Anand Safi ・ Feb 8, 2021 ・ Medium

Communicate & Collaborate — 5 things I wish I knew as a Software Engineer (Part 4/5)

Not POCing enough — 5 things I wish I knew as a Software Engineer (Part 3/5)

Focused on Implementation only — 5 things I wish I knew as a Software Engineer (Part 2/5)

Spreading too thin — 5 things I wish I knew as a Software Engineer (Part 1/5)

Software Engineering done right — 5 things I wish I knew as a Software Engineer (5 Part Series)

Anand Safi ・ Feb 8, 2021 ・
Medium

Anand Safi ・ Feb 8, 2021 ・
Medium