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…
Top comments (0)