This post was authored by Anand Safi, one of our very own technical mentors. You can find Anand’s profile on MentorCruise here.
Below are some key traits (more will continue to be added!). We will explore each trait individually in depth below.
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.
Focused on Implementation only
Focused on Implementation Only
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.
Pitch/ Discovery phase
The context here is Customer interaction. Knowing your end users has 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.
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.
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.
Not POC(Proof of Concept)-ing enough
Not POCing enough
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 important 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:
-
Increased ability to weigh pros and cons of various approaches
-
Developing critical thinking to approach a give problem with multiple solutions
-
Expanded coding chops and know-how since each solution might use a different approach or method or syntax
-
Increased ability to approach future refactors with ease and build for scale from get go
-
Increased focus on choosing 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 continuing to build on it if you are practicing it in some form.
Communicate & Collaborate
Communicate & Collaborate
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.
Mastering a niche vs Smart Generalist
Specialists vs Generalists
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
Generalists vs Specialists trade-offs
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!
The era of 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”.
Thanks for reading!
You can connect with me at: LinkedIn — Anand Safi to chat more regarding this, tech mentorship and other interesting topics!