You're asking the wrong question. You should be asking "Am I an efficient or effective programmer?"
Do I get things in on time / under budget?
Do I avoid common programming pitfalls?
Do I solve more problems than I create?
Do I see simple solutions to complex problems?
Can I refactor terrible code to more easily maintained code?
Can I avoid terribly written code in the first place?
Can I effectively communicate with people in order to get the answers I need without wasting their time with needless questions?
Then you know you're effective when:
You're asked for help often.
You're the go to person by the boss.
You're often asked for your opinion for engineering decisions.
Your opinion holds weight with others.
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.
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 ...
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.
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
Comments
You're asking the wrong question. You should be asking "Am I an efficient or effective programmer?"
Then you know you're effective when:"Am I an affective programmer?"
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.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.
Who judges what constitutes a problem? How do you know when you've created a problem?
Define 'simple'.
Define 'terrible'. How does one know what code is more easily maintained?
See above.
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."
What's wrong with that?
OP specifically asked for quantitative metrics.
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.
Could also mean you write unreadable code and, by extension, unmaintainable code.
Could also mean you write unreadable 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