"Am I an affective programmer?"

    Does my code make people feel good?
    Does it automate some user task?
    Does it make some user task easier?
    Does it amplify users' powers?
    Does it create value, by my definition of "valuable"?

Of course, these are outcomes/benefits, not the technical role of programming within an organization. But apt if you see yourself, fellow programmers and company members as "users" also.

> I read a study that measured the efficiency of locomotion for various species on the planet. The condor used the least energy to move a kilometer. And, humans came in with a rather unimpressive showing, about a third of the way down the list. It was not too proud a showing for the crown of creation. So, that didn’t look so good. But, then somebody at Scientific American had the insight to test the efficiency of locomotion for a man on a bicycle. And, a man on a bicycle, a human on a bicycle, blew the condor away, completely off the top of the charts. https://www.brainpickings.org/2011/12/21/steve-jobs-bicycle-... https://youtube.com/watch?v=0lvMgMrNDlg

> ... There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself. https://wikiquote.org/wiki/Alan_Turing

Wow, this is such an eye opener. I have always considered myself an ok programmer, but always struggling with trying to be effective.

Your four points on effectiveness happen to me on a daily basis, but I tend to see them as annoyances, mind you, I rarely refuse to help and advice. This gives a whole new light and meaning to all those interruptions.

Developers can often be "force-multipliers" even if they don't see it themselves. Yes there's the 10x developer that can get 10x done than the average person.

But there's also the 10x dev that can help others be 10x more effective. Those types see a problem, and write an insanely useful tool.

Also, welcome to thinking like a manager.

Aside from the first question (may first 2 questions), the top questions are arguably more qualitative than quantitative.

> Do I solve more problems than I create?

Who judges what constitutes a problem? How do you know when you've created a problem?

> Do I see simple solutions to complex problems?

Define 'simple'.

> Can I refactor terrible code to more easily maintained code?

Define 'terrible'. How does one know what code is more easily maintained?

> Can I avoid terribly written code in the first place?

See above.

> Can I effectively communicate with people in order to get the answers I need without wasting their time with needless questions?

What constitutes "effective" communication? What are "needless" questions?

I generally agree with the questions, but I would imagine most programmers could read them and think, "I must be pretty effective."

> Aside from the first question (may first 2 questions), the top questions are arguably more qualitative than quantitative.

What's wrong with that?

OP specifically asked for quantitative metrics.

> So, as a programmer, how do you quantify or estimate how good you are?

And I said he was asking the wrong question.

... and as in everything, don't trust your own instinct on this; work closely with others to get a true sense of where you stand.

You're compensated better than your peers, and there's no extenuating circumstances surrounding that.

The problem with measuring effective is that it is quite subjective. Politics can skew those results.

That's a skill like any other. If you're conspicuously bad at politics it can make you ineffective - you or your work will be sidelined or abandoned.

One of my gotos has been 'Can I avoid writing code in the first place?'

Zero code has zero bugs, and zero maintenance cost.

A great programmer is like a peaceful master samurai, he first tries all other options before resorting to violence (code) he may also reduce violence (code) where ever he goes ...

You'll appreciate this: https://github.com/kelseyhightower/nocode

This is the correct answer

No, it just means your boss likes you.

Disagree, I was the not in the "in crowd" with my boss at a previous location and yet I was the person (as suggested) in regards to everything backend related.

> You're asked for help often.

Could also mean you write unreadable code and, by extension, unmaintainable code.

> You're the go to person by the boss.

Could also mean you write unreadable code.

> Could also mean you write unreadable code and, by extension, unmaintainable code.

In this situation, I think the context is when a colleague is asking for help with their own code/writing a new feature and wants input from someone well-versed.

I agree, this is the situation in which OP has considered.

However, depending on the stage of the project, getting asked for help may be a red flag for me.

If it occurs too often, it can mean the following: - incompetent co-workers - someone did a terrible job documenting - modules, packages, functions, etc. do not provide a good abstraction layer for the task(s) they perform