[gregjor]

You don’t get paid to write code. That’s a means to an end. You get paid for adding value to the business, solving problems, and multiplying the overall effectiveness of your team and the organization.

Taking a narrow view of what you can or should be doing — “that’s not my job” syndrome — is a sure way to get stuck in the lower rungs and feel like you don’t make a difference.

The programmers who mainly think their “productivity” depends on removing “trivial” things so they can focus on themselves and “DX” are hunting for jobs right now. Employers are getting wise to that nonsense. Productivity is not the goal, adding business value is.

[Jaedon_Proctor]

I agree with pretty much everything you’ve said. However, do you think that within most organizations there are workflows that could be made more efficient? That’s where I find some disagreement with your last point. By removing what’s seen as trivial, the focus shifts more towards the overarching goal of adding value, which, for most programmers, is often about shipping or refactoring code.

[cebert]

> focus shifts more towards the overarching goal of adding value, which, for most programmers, is often about shipping or refactoring code.

Shipping and refactoring code doesn’t necessarily add value. What business objective is it solving? What are what are the requirements? Where are the design/research artifacts? All of these “trivial” tasks are what help enable you produce something valuable.

[Jaedon_Proctor]

Your viewpoint is 100% understandable and agreeable. I also don’t consider the tasks you mentioned as trivial. However, for the sake of discussion and my own learning, do you view these tasks as directly critical to adding value as a programmer? Or do you see them as essential for establishing alignment, which, in turn, facilitates more efficient value creation? Personally, I believe the examples you mentioned are important but it’s hard for me to value the plan over the execution in such a rapidly adapting ecosystem. Not to tangent but I believe in the words of Mike Tyson everyone has a plan until you get punched in the mouth. We can plan, research and document but if the insight is found in the execution shouldn’t bottom line by trying to ship and iterate. My main point is objectives can often be succinctly summarized,and while the task you mentioned are important I think the weight we put to them discounts the value of just shipping. Our differing views might also stem from our backgrounds—I’m assuming (please correct me if I’m wrong) that you have more experience with larger development teams.

[gregjor]

Yes, most organizations have inefficiencies. Reducing or removing those would likely add business value. But those inefficiencies don’t go away when people ignore them as trivial. If you identify an inefficiency do something about it. That may be in the code, or it may be in a business process.

[Jaedon_Proctor]

This captures the essence of the discussion I’m aiming to foster. I realize that labeling tasks as “trivial” might undermine their perceived importance, as highlighted by the examples in my title and the primary discussion here. However, my goal is to spark a conversation about those simple, mundane, or “trivial” tasks that are crucial to your workflow, yet, in an ideal scenario(perfect information/100% aligned team), you’d prefer to allocate your efforts and time elsewhere. Additionally, I recognize that describing these tasks as both trivial and essential might seem contradictory, creating a bit of an oxymoron.