Here are a few things I’ve learned about being a Software Engineer over the handful of years I’ve been an invidivual contributer.
Undoubtedly, the most important thing I’ve learned as working as a Software Engineer is the ability to start and finish tickets. After all, this is what we’re paid to do. We’re not paid to over-engineer solutions or give our opinion on frameworks. We’re paid to deliver features and fix bugs that create value for the business we serve.
I know this from being that guy who is slow to deliver, preaching that software engineering is a craft and we should be treated more like artists instead of engineers. Its not a good look nor does it make you easy to work with. This came with maturity and experience. You want be the guy who can be assigned a wide arrange of tickets with a healthy amount of story points a week. The person who is dependable and produces high-quaility commits each sprint. I believe this is the most trait of an Software Engineer. At a base level, if you can’t do this you’re two things:
- An Engineer who is difficult to work it
- A burden to your team. This sounds critical but we’ve all worked with that guy, I’ve been that guy and aim to not be.
Mind you, getting to this standard of Software Engineering does not come easy. To be able to sit through backlog grooming and fully comprehend what the feature or fix requires a degree of fundamental understanding that only comes with experience and time.
In my view, there is pyramid of skills that need to understood in order to achieve this level of proficiency. At the bottom of the pyramid you have domain knowledge. This is hard computer science knowledge, information that I believe that can only be acquired through formal education or years of self study. This is knowledge of algorithms, networking, general programming, web architecture etc.
In the middle is knowledge of the codebase and archictecture of the applications you’re working on. Lets be honest, every codebase we’ve worked on has its quirks and flaws. Whether it be some refactoring or restructuring here and there. It could use a bit of love. Only when you’ve worked on it for some time can you quickly point out its pitfalls and quickly impelement a solution.
At the very top of the pyramid is programming skill. This is where you junior code vs. senior code, the implementation of the solution. Does it need multiple reviews from other engineers? The more pass-throughs your code requires, the more time is taken from the team.
In the end, developing the ability to crush tickets is the important trait I’ve learned in being an efficient Software Engineer.