How to Master Your Software Engineering Journey, Part 1
Learn key aspects of the craft of software engineering gained from one engineer's humble beginnings to the gradual progression into an engineering manager.
Join the DZone community and get the full member experience.Join For Free
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 have worked with some wonderful people, the latest technologies, and great projects. As I reflect on my humble beginnings and the gradual progression to my current role as an engineering manager, I wish I knew some key aspects of the craft of software engineering back then.
This article is the first of a series where we will explore some of these traits. We will look individually in-depth at each trait, and this article contains the first three below:
1. Spreading Too Thin
Spreading too thin
I attribute this trait to our wandering minds. The notion of ''the grass is always greener on the other side" seems apt for this.
- When I started doing front-end web development, I felt I should also learn back-end technologies (i.e., Java), 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.
- When I started focusing on these aspects, I felt I need to establish my presence in the open source community by doing some side projects, contributing to existing projects, and speaking at meetups/conferences.
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 myself too thin for a brief period of time.
I was scratching the surface on a variety of things, but not really getting solid or to an expert level with any of them. 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 carefully planned. One must pick their battles in order for quality development and skill-building.
I would suggest each of you to reflect on the same by, for example, listing 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. Ideally, you need to come up with the list on your own, or work with your manager/mentor on one.
2. Focused on Implementation Only
When I think of "Focused on Implementation Only," I attribute it to my being myopic or 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.
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), and why you are building it (the user pain point the implementation will address) all help 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 provide 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 missed this phase altogether, or instead, 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
The phases below are post-implementation.
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.
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 three 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.
3. Not POC(Proof of Concept)-ing Enough
POC = Proof of Concept: I can easily say this is often the most overlooked trait that I have seen across engineers, even though it is 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 at the time made me aware of the importance of the art of POCing: the process of experimenting, implementing in a lightweight manner, and picking my own best solution that I was most proud of or made the 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 given problem with multiple solutions
- Expanded coding chops and know-how, since each solution might use a different approach, method, or syntax
- Increased ability to approach future refactors with ease and build for scale from the get go
- Increased focus on choosing the best approach vs just delivering a working solution
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.
To Be Continued. . .
We will cover Part 2 of these and the remaining 2 critical traits in a future upcoming article. Stay tuned!
Published at DZone with permission of Anand Safi. See the original article here.
Opinions expressed by DZone contributors are their own.