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.

Siva Narayanan

I am known to be "the CTO of one, the father of two, and the roasting baba of many."

More of our stories from

How we created a Medium-like blurry background effect

Here's how we improved user experience, decreased load time and made Fyle accessible for users without a fast internet.

Bye bye WordPress, welcome Webflow.

This blogpost documents our journey as we bid goodbye to WordPress and migrated to Webflow.

How we reduced our website build time by 59%

I came up with five 3 second changes to reduce the build time by over 59%. Here's more about my experience.

Hello, Web Technologies!

I’m a first-time entrepreneur and I’ll be recording my learnings and experiments over time. I am always eager to interac

The Non-Boring Guide to OAuth 2.0

If you’re developing an application that needs access to a user’s Google / Facebook / LinkedIn information, you’ll need

Dealing with Nested Objects in your Web Application

A couple of weeks ago, I ran into a peculiar problem that I think might be useful to talk about. It took me a bunch of

Eliminate Boilerplate Java code with Lombok

I’ve been writing a lot of boilerplate Java code, lately — getters, setters, hashCode, equals and toString. Actually, I’

Hello, Web Technologies! — Part II

This is a follow-up to my first post about technology choices I made while building out our product. I wanted to pen my

Sharing Files using S3 Pre-signed URLs

Amazon’s S3 is a reliable, cheap way to store data. We use it to store user-uploaded images and documents as s3 objects

JSON Web Token Concepts

There are many technical articles about JSON web tokens (JWT) on the interwebs, but I haven’t found one that explains...


All Topics