Think Software Engineers Just Write Code? Think Again.

November 17, 2021

Some coders do the bare minimum: write code that meets the requirements. However, great software engineers know their job involves much more than writing code.

If you want to be a great engineer (and get ahead in your career), it pays to know all the “hidden” work that goes into being good at your job. In fact, for most top engineers, writing code is just one small piece of their overall job.

Unfortunately, most of this work is never taught or talked about formally when you’re learning to code. That’s a shame, but in this article I’ll show you all the “hidden” work great engineers are doing to build awesome products, and careers!

Coders vs. Engineers

Software developers generally fall into two groups: coders vs engineers

Coders like to write code and sometimes they’re good at it! Give them a problem and enough time and they’ll write you some code to solve your specific problem.

Engineers also like to write code, but they mostly love to build useful things for people! Give an engineer a problem and they’ll immediately ask you questions about why the problem exists, what you’ve already tried, and if there are any other related problems that could be solved all at once.

Coders are great for a limited set of tasks, but they often miss the big picture. Engineers on the other hand always look for the big picture first. They write code once they understand the problem space.

So, what do great engineers do that most coders don’t?

1. Discover requirements behind features

Often, building a new feature for an application requires more than just adding a button or some logic.

The Product Manager can’t possibly know all the technical details, so the job of great software engineers becomes discovering the underlying technical challenges that need to be solved:

  • Does this new functionality require us to add a new table or column to the database?
  • Should we resolve this issue using JavaScript to build the feature perfectly on the front end or should we instead update the API to support the new functionality holistically?
  • When planning out a group of features, what order should they be developed and do any tasks block others?

There are hundreds of ways great engineers help discover requirements and make sure they’re surfaced so that teams can plan and release better features faster.

2. Think through edge cases and test them

Most companies have testing standards for new code. In order to be merged, the new code has to meet some coverage threshold.

Decent coders will throw together a quick set of tests that check the happy paths work as specified in the requirements.

Great engineers will think of edge cases and larger scenarios where the code might produce unexpected results. The best engineers write really robust tests (and they often practice test-driven development).

3. Consider user experience (UX)

Designers and product managers can’t possibly anticipate every detail of a new feature. In many cases, a requirement will be missed or a design might exclude some detail.

In these cases, a good engineer often has to make a judgment call about the intention of the feature and what a user should expect. Maybe it’s a missing button, a dialogue to prompt the user, a confirmation email, handling of a specific error…

When you’re developing a new feature, you’re often the first person to see it fully working. As a good engineer, you have a responsibility to consider UX at every step and resolve any issues that the design team didn’t foresee.

4. Architect deployment & adoption strategies

Perhaps you have a brilliant proposal for how to solve a thorny technical challenge at work — problem solved, job done, right?

Not so fast! Great engineers don’t just think up solutions, they also think about how those solutions will be adopted, deployed, and maintained.

A well-planned adoption strategy for a decent idea is better than a botched execution of a perfect idea.

5. Resolve technical debt in existing code

A great engineer leaves code cleaner than they found it.

Moreover, when an engineer encounters a piece of code or architecture choice that no longer fits within a larger understanding of how the product should work, the engineer is capable of explaining the problem and its implications to the team and stakeholders in the company.

Note: A good engineer does NOT go rogue on large refactor work. Taking on a large refactor without asking is a sure sign of a coder with a big ego. Instead, good engineers talk it over, plan it out, and prioritize the refactor with the team.

6. Read & write documentation

Documentation about how the code works is so important for sharing information and onboarding new developers. Great engineers understand the value of documentation and write documentation for the projects they work on.

What is good documentation?

  • Great variable, function, and class names that make it clear what the code is doing. Naming things well is one of the hardest parts of software engineering.
  • Inline, function, class, and file-level comments and docstrings that explain why the code works the way it does.
  • READMEs and other internal documentation that explains larger concepts and usage in the project
  • External documentation like API docs, public packages, and help articles

Good documentation doesn’t have to be long or complicated! In fact, great engineers know the best documentation is short and clear.

7. Review other engineers’ code

Code review is a huge part of an engineer’s job! During code review, great engineers look for:

  • Does this code meet the requirements of the ticket?
  • Is it technically correct and handle error cases?
  • Is the implementation as simple/straightforward as it can be while still being flexible?
  • Is there good test coverage and do the tests cases reflect actual usage?
  • Does the new code include good naming, docstrings, comments, and type hints?

Being a good code reviewer helps set a standard of quality for your team. Of course, great engineers should be expected to meet their own standards in the pull requests they open!

What’s more, code review is a great opportunity to mentor other developers and expand their thinking/skills. Good engineers provide empathetic, actionable feedback in their code reviews.

8. Interview candidates

Engineers that understand the whole software development lifecycle are much better prepared to interview candidates to join the team.

They understand that it’s not worth hiring a great coder if that person isn’t a good team player. By the same token, they’re willing to see the promise in a weaker coder if that person shows potential.

Hiring is hard, and being an interviewer requires a high level of emotional intelligence. Being a good interviewer is just another way that great engineers contribute to their team in hidden ways.

9. Coach junior engineers and pair program

Truly great engineers want to share their knowledge! They help others on their team get better at building useful products with code.

Sometimes that means pair programming. Other times, it’s one-on-one mentoring. Even code review comments can be considered a type of mentorship.

Coaching other members of the team and collaborating on work is a big part of an engineer’s job. While it means the engineer isn’t spending time developing new features, coaching leads to better facilitation of work across the team. Even though individual throughput might go down slightly, the whole team’s throughput improves when engineers share best practices with one another.

10. Respond to incidents

Engineers do their best to thoroughly review and test code, but incidents and bugs can still arise for customers.

A coder might be able to respond to an incident, too, but engineers take their response a step further. Great engineers ask:

  • Why was the incident able to occur in the first place? What are we missing in our unit tests, QA process, code review standards?
  • Who else might be affected by this incident? Could other customers possibly experience the same issue? Do other services rely on the affected component?
  • How do I document the incident, its resolution, and followup steps? If something similar happens in the future, how do I make it easy to find the solution?

Engineering: Much More Than Just Coding

Engineering involves much more than writing code. There are a whole host of hidden jobs that great software engineers do on a daily basis.

Hopefully, this article sheds some light on what it takes to become a truly great engineer. However, this is certainly not a definitive list. There are even more tasks that software engineers undertake!

Take this article as a challenge to focus on all the work that’s adjacent to coding and just as important! Getting great at the hidden work of engineering sets you apart from the pack in your ability to build great products and get ahead in your career.

About Bennett

I’m a web developer building things with Python and JavaScript.

Want my best content on web development and becoming a better programmer?

Join 500 other developers currently in my email series.


Profile picture

I write something new every day for 2k software developers. You should sign up for the daily email.

© 2024