Less known facets of a good software engineer

There have been numerous articles on how great software engineers can have a huge impact on product and company. You can add this article to that list. To minimize boredom, I’m going stick with those facets that are terribly under-appreciated.

They like to write readable code

A software engineer is likely to spend upwards of 70% of their time reading code depending on the maturity of the codebase. A good engineer recognizes this and strives to make things a little easier for future generations who will read and modify their code. They like breaking up long complex functions into smaller, re-usable ones. Check out articles on cyclomatic complexity for a more academic treatise on this subject.

They deliver big features in little chunks

A big feature brings many risks. It may not match what users are looking for or may break existing functionality because of how it interacts with other components of a codebase. A good engineer recognizes this and breaks it up into small deliverables which are merged to trunk routinely. This reassures the team that the existing codebase is safe and that there is tangible progress in delivering a big feature. In distributed systems parlance, that’s safety and progress. It also allows for an early preview of the feature and getting user feedback.

They like to test their code

This is closely related to the previous point of safety. Good engineers spend a good amount of time figuring out how to test their code. They don’t toss code over the fence and expect someone else to deal with it. They realize that finding a defect later increases the cost dramatically and strive to catch issues as early as possible.

IBM study

They sneak in broccoli projects

User facing features get a lot of attention from management, sales, customers and engineers are naturally drawn to them. Often, though, there are infrastructure projects that are not visible to the outside world, but have a big impact on developer productivity. I call these broccoli projects for obvious reasons. Examples include: using kubernetes for running your services or upgrading libraries. These are generally viewed as all risk and no reward projects. Good engineers know the value of broccoli projects and find a way to sneak these in along with user facing projects.

They sell

Good engineers know how to sell their idea or feature — to management, sales and, finally, customers. As my co-founder Yash wrote in his blog, selling is a life-skill. Good engineers conceive figure out a way to get people excited about their work. When they are out and about, they sell the company to their friends and try to recruit them. They write blogs and represent the company at events.

They want to know how their feature is doing in the wild

Good engineers keep thinking about a feature even after it is released to see if they could’ve done better. They keep a close watch on customer issues and proactively reach out to users. They like to measure the impact of their work — whether it is by reaching out to users or through internal metrics.

If you can relate to some of these points, we’d love to talk to you. You can view the available roles in angel.co or send us a note at jobs@fyle.in.