More than (Just) a Developer

What’s the opposite of modest? Pompous, huge, convoluted, inconsiderate, disproportionate, unbounded.

That means a modest approach is truthful, small, adequate, considerate, proportional, bounded.

Where are you writing this JavaScript anyway? What kind of company are you in? What’s the business model?

“Well I don’t have any effect on the business model, I’m just a developer”.

If you’re just a developer, then you’re reading the wrong book. If you’re here, you obviously also affect some choices, and that means you’re involved in designing, “decisioning” something. Here’s what you can help make decisions on:

  • The structure of a component;
  • The infrastructure of your code base;
  • The testing approach;
  • The limits of what’s possible with your code base (surely, there are trade-offs);
  • The trajectory of your overall architecture (e.g. toward simple rather than convoluted);
  • The return-on-investment of your choices;
  • The performance considerations;
  • The speed of development (how many people can be working on its different parts);
  • The cadence of development (how you funnel in your work).

In all these cases, you can choose to take a modest approach, or you can choose a convoluted approach. You can choose to be intentional, considerate, incremental, approachable.

You can also make the case for being closer to the decision-making of the company.

Up the Chain

“What is this for?” If you’re decoupled from the design of the solution, if in your mind you’re just an implementor, there really isn’t anything you can do.

But that question “what is this for?” is always a valid one. It’s one of the good questions you can ask up the chain.

These other questions are good too:

  • At the end, what will this do to our company’s top line?
  • Let’s say this thing is done and pushed to production, what are we going to be able to say we’ve accomplished two months from now with it?
  • Where is this taking us?
  • We’re about to build all this for X price (time, people allocated to the project, dollar amount). Is there anything else we could do that would achieve the same thing with the same budget?
  • Is there any way we can connect to the end goal we’re trying to get to with something smaller, more modest?
  • Can we build half the UI?
  • Can we make the time-frame fixed and the price fixed, but be given control over the scope of how we’ll achieve that same goal? Can we try the practice of scope hammering?

If the company where you work is large, convoluted or immodest, the only way you’re going to bring in more modesty is by talking the language of business with those questions above.

But maybe the founders’ values aren’t tuned to yours. In which case, you won’t move a needle there. Best to find some execs at another company who are a better match.