Is a Developer Truly Not Doing Their Job If They Don't Code?

I believe that a developer's role encompasses more than just writing code. While my primary job is software development, there are numerous instances where my responsibilities extend beyond programming. This raises an intriguing question: what defines a developer who isn't actively coding?

In the tech landscape, we often categorize professionals into programmers and engineers. A programmer's function is to write code, while an engineer's role is to design systems. However, if a programmer isn't coding, does that mean they aren't fulfilling their job? Similarly, if an engineer isn’t designing, are they failing in their role? I contend that the answer is no. Both programming and designing are just methods to achieve a larger goal—addressing the needs of customers and the market.

The realization that there are various ways to reach a goal suggests that even those who may not actively code can still contribute significantly. So, what does this look like in practice?

For instance, being a "non-coding developer" doesn't equate to idleness. I engage in tasks that require a developer's insight. Many salespeople, consultants, and managers may lack a deep understanding of systems. Even if they have some knowledge, it's typically limited compared to that of engineers.

This becomes evident when we analyze requirements, specifications, or design documents that aim to capture customer desires. Often, what the customer genuinely wants is not accurately represented in these documents.

Consider a scenario where a customer states: “We currently manage sales data using office software but want to transition to a web-based system.” Instead of merely switching to a web system to replicate the tasks performed with office software, it's crucial to explore the underlying reasons for their desire to migrate. They might want to:

1. Access the same data from various locations.
2. Visualize the stored data using a BI tool.
3. Collaborate more effectively with other systems.

In essence, the customer's request to move to a web system is merely a means to an end, and there are often deeper objectives that are overlooked in specifications and designs. Thus, it is vital to critically evaluate these documents.

A non-coding developer understands these true customer objectives and can propose alternatives beyond just system development.

For example, if the customer's real aim is data visualization through a BI tool, it may be more effective to utilize their existing office software for data input and then convert that data into a format suitable for analysis by the BI tool. This approach not only reduces costs but also lessens the burden on the user, as they wouldn't need to alter their input methods.

What I am advocating is not for engineers to take on consulting roles or meticulously scrutinize every specification for improvements. Instead, I encourage reducing the volume of code written. To clarify, this doesn’t mean simplifying code for aesthetic reasons or seeking to minimize lines of code for their own sake.

Rather than focusing on reducing the code itself, we should consider whether we can lower the coding requirements through thoughtful proposals. While I've mentioned that these suggestions benefit customers, they ultimately serve to improve our own workflow as well.

If a proposed solution is advantageous for both the customer and the development team, it is more likely to gain acceptance from consultants and clients alike. By making such proposals, we can streamline system specifications and minimize coding requirements.

Reducing the amount of code can decrease the likelihood of bugs and potentially accelerate delivery timelines. This is what it means to be a developer who doesn't code.

However, there is an important caveat: if a proposal does not genuinely benefit the customer, they may perceive it as a tactic to reduce coding burdens, thereby undermining your credibility.

In summary, a "developer who does not develop" is someone who focuses on refining system specifications and minimizing coding by clarifying the customer's true objectives and aligning proposals accordingly.

As a personal reflection, I believe that the most effective form of development for engineers is to engage in minimal coding. This approach enhances security, as bugs are less likely to occur without code changes. Let's strive together to become developers who prioritize insight over code.

Stackademic

Thank you for taking the time to read this. Before you leave, please consider showing appreciation and following the author! Follow us on Twitter(X), LinkedIn, and YouTube. Visit Stackademic.com to learn more about our mission to democratize free programming education worldwide.