It isn’t about your skills now, but if you are improving. If you look back back in code you created 6 months ago and thinks it is a disgrace, then you are very well becoming a good developer.
Ask HN: As a programmer, how do you know if you're a good one or not?
61–70 of 101 posts
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#62You'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…
"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"?
> 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
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#63My general rule is that if I look at code from 1 year ago and I'm not disappointed with year-ago-me, I'm not growing as a programmer.
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#64It's a question I've asked myself too. I've also wondered how often others are being aggressively pursued by former colleagues to join them at another company. I've seen team strongly believe they hire strong candidates only, but rarely seem to pursue these same people after moving to a new company.
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#65If someone pays you a lot of money to program and are happy with the results.
That might mean you are a good negotiator and salesman.
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#66Earlier quoted context omitted.
> 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
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#67I wouldn't describe myself as a programmer, but I have spent a considerable amount of time and energy thinking about how to become 'better' as a data scientist (as well as how to encourage others to grow their skills and knowledge, and how to measure that growth). So, I can share some tips about learning in general (i.e. metalearning--"learning how to learn") that should apply no matter your field. If you devote yourself to (effective) learning and improvement, you are as 'good' as you can be, and that is what matters.
1. People learn best by a) effortful 'doing'/practice and b) spacing that effort out over time. (Actually, not just people...almost every organism seems to learn more effectively this way.) Generally, the marginal benefit of learning time is greater when you expend effort directly applying knowledge/skill to a difficult and meaningful, rather than ingesting the output of others. An hour spent solving programming puzzles is more effective than reading an hour of others' puzzle solutions. 10 hours spent doing either is better spent if it's spent as [10 x 1hrs] vs. [1 x 10hrs]. Spend more time working on side projects that motivate you, solve book problems, solve coding challenges, practice explaining a technical concept to someone, etc. Spend less time gliding above the vast wilderness of what there is to know, observing the work of others--hit the ground and blaze the trails yourself (but don't rush it).
2. Programming, like data science or research or basketball, is not really a discrete skill you can directly improve at. Each is composed dozens/hundreds of sub-skills, and mastery of the field is a lifelong endeavor of building up these individual skills as well as connections between them. What strengths form the core of your identity as a programmer? What about areas for improvement? (relative to what you want to be, not compared to coworkers/HN folks/world-experts)
3. If you find yourself sharpening the same swords again and again (as I have), then look for an area of both weakness and interest to reallocate effort to. The learning benefit per unit of time is greatest when you spend it on something in your 'zone of proximal development'--not too easy, not too hard, not too irrelevant, but just right. Sometimes, this may mean diving headlong into the difficult thing you believe you "should" know, but have been avoiding. Other times, being "better" at your field means improving at something that seems tangential (communication/presentation, documentation writing (!), time management, domain knowledge, mathematical skill, whatever). Just don't fall into the trap of 'oversharpening'--expand your arsenal.
4. Teach/communicate what you know to others. Interact and network with others both at, above, and below your general level of experience. This not only helps solidify your knowledge into something permanent, but incidentally is one of the best (only?) ways to be perceived (rightly or wrongly) as knowledgeable. You don't even need to do this 'for real' for it to work--I imagine myself explaining code / mathematical concepts to some imaginary audience, whether it happens or not. And if it does, you'll be prepared...(While backpacking in Yosemite recently, I encountered a professor that asked me to explain a ROC curve to him. Another time, I awoke on the train to an elderly lady, seeing the title of book that I fell asleep on, asking me what a stochastic ["stoychistick"] process was.)
5. Beware that the 'better' you become, the more inferior you may feel. Climbing higher gives you an unobstructed view of the yet taller peaks in front of you, and the canyons blocking your way. Remember to take pride in the struggle.
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#68Just from pure introspection, you might be able to glean an answer by thinking about these questions:
— Are you capable of distinguishing opinion from fact? Are you capable of distinguishing _your own_ opinion from fact?
— Any project will have easy bits and hard bits. How accurate are your predictions of which bits are easy and which bits are hard, for projects within your domain of expertise?
— When you think about your software, how good an idea do you have of what's "cheap" to achieve, and what's "expensive" (e.g. which endpoints or queries are fast and which are slow)? What's easy, what's hard? Do you understand how the people who consume your software use it? Do you know whether common operations for them are cheap and/or easy? Do you understand why (or why not)?
— Turn the previous question around — do you understand the design behind the software that you consume? Are your own common operations things that are cheap and/or easy to achieve using that software? Do you know why (not)?
— When you think of technical choices, do you tend to think in terms of absolute right and wrong, or do you prefer thinking in terms of tradeoffs? If the latter, how capable are you of articulating why a given tradeoff makes sense in one situation but not another? Are the tradeoffs you consider limited to technical matters, or do you consider "softer" aspects in your analysis (such as recruiting costs, time to market)?
— How well do you know your tech stack of choice? How well do you understand your own limitations within that stack? How does your stack of choice measure up against the alternatives? Where is it better, where is it worse?
— And, finally — why does any of this matter? Do you genuinely want to work on the sort of project that _actually_ requires so-called "rockstar" engineers, or are you happy working on projects where good enough really is good enough? How much effort would it take to actually become a rockstar? What would it cost you? (you might want to go over the bit on tradeoffs above again)
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#69Programming is a craft once you reach a certain level their is no checklist or metric that can be used to measure you ability. Only experience and battle scars tell how good you might be when solving the next problem.
Only ever measure yourself against yourself. As long as you make sure you are a better programmer today then yesterday then you have nothing to worry about.
Re: Ask HN: As a programmer, how do you know if you're a good one or not?
#70Programming is a craft once you reach a certain level their is no checklist or metric that can be used to measure you ability. Only experience and battle scars tell how good you might be when solving the next problem. Only ever measure yourself against yourself. As long as you make sure you are a better programmer today then yesterday then you have nothing to worry about.
100% agreed. At the risk of sounding dismissive (not my intention) it doesn’t matter whether you’re a “good” programmer or not.
Stop trying to measure yourself or others, get in there and code.