Ask HN: As a programmer, how do you know if you're a good one or not?
100 comments
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?
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."Am I an affective programmer?"
> 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
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
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.
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.
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."
> 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?
What's wrong with that?
... 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.
One of my gotos has been 'Can I avoid writing code in the first place?'
Zero code has zero bugs, and zero maintenance cost.
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
> 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.
> 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.
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
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
Programming 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.
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.
This. After 15 years as a professional developer I have a fairly good idea where my boundaries are, and that's about it.
Expect to learn new things every day, and from every conceivable source: your fellow developers, junior and senior, of course, but also your PM (for example, prioritization, techniques to organize work), designers (information flow, HCI), business analysts (how the client ticks), etc.. Very likely everyone you ever worked with could teach you something, and you'll never have time to learn it all.
Expect to learn new things every day, and from every conceivable source: your fellow developers, junior and senior, of course, but also your PM (for example, prioritization, techniques to organize work), designers (information flow, HCI), business analysts (how the client ticks), etc.. Very likely everyone you ever worked with could teach you something, and you'll never have time to learn it all.
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.
Stop trying to measure yourself or others, get in there and code.
I put in the work. I once heard a very good fencer say that the way they keep calm during competitions is to tell themselves that they've put in the hours of training and the blood, sweat and tears necessary to win. I spend hours of my days writing code, reading about how to become a better programmer, constantly analyzing my work and finding ways to improve. I'm not going to spend my time worrying about whether I'm a good programmer. I will be a good programmer.
Hours of deliberate practice is said to be the deciding factor in how good you are. Or at least, we can't be good without it. So yes, counting the hours we spent writing and analyzing code gives us an idea of how good we might be as programmers.
This is a general problem.
In sports, for most people, staistics are meaningless. I climb 5.10 okay... am I good climber? I'm not world class, but I do stuff that I like.
I've been an academic. I know I was a bad one, because in retrospect I had to step away from a lot of my ideas and research... at the end, I didn't see value in the projects I was doing.
As a programmer... who knows. I don't usually have a lot of problems coming back to old projects and building new stuff. I don't have a lot of systems I put together breaking down and requiring work. I know that there are at least 10-20 other folks think I am good, because I've solved things for them and they have told me I am good.
But I just build CRUD apps, admin some linux servers, and put together custom code for WordPress. Some folks would look at that pile of day-to-day tech cruft and say that I am not even a "real" programmer (even if I do know how to implement a buffer with TTL and I've written toy mouse drivers and serial implementations).
All that comes down to this: it really comes down to you and your goals, and what you want to get out of your life. You are the only measure of what you consider to be a good person. Most of us are sane enough to peg that estimation to feedback we get from other people. But fundamentally the metrics are still our own.
In sports, for most people, staistics are meaningless. I climb 5.10 okay... am I good climber? I'm not world class, but I do stuff that I like.
I've been an academic. I know I was a bad one, because in retrospect I had to step away from a lot of my ideas and research... at the end, I didn't see value in the projects I was doing.
As a programmer... who knows. I don't usually have a lot of problems coming back to old projects and building new stuff. I don't have a lot of systems I put together breaking down and requiring work. I know that there are at least 10-20 other folks think I am good, because I've solved things for them and they have told me I am good.
But I just build CRUD apps, admin some linux servers, and put together custom code for WordPress. Some folks would look at that pile of day-to-day tech cruft and say that I am not even a "real" programmer (even if I do know how to implement a buffer with TTL and I've written toy mouse drivers and serial implementations).
All that comes down to this: it really comes down to you and your goals, and what you want to get out of your life. You are the only measure of what you consider to be a good person. Most of us are sane enough to peg that estimation to feedback we get from other people. But fundamentally the metrics are still our own.
Programming is an open ended non competitive (generally) activity. I don't think there is any meaning in trying to quantify "goodness" and in fact might blind you to possibilities.
So, for myself, the thing I pay attention to is my ease of expressing the things I want to create. I also pay attention to my ability to produce things with certain "qualities" correctness, simplicity, and how modular and composable my code is. There is no objective measure of those things and my understanding of those things constantly expands. I learn these things through by my own experience and looking at what other people are doing and having in depth discussions about programming ( and outside of programming ).
So I have no idea how good I am, but I have confidence in what things I can create and confidence in my ability to learn more.
So, for myself, the thing I pay attention to is my ease of expressing the things I want to create. I also pay attention to my ability to produce things with certain "qualities" correctness, simplicity, and how modular and composable my code is. There is no objective measure of those things and my understanding of those things constantly expands. I learn these things through by my own experience and looking at what other people are doing and having in depth discussions about programming ( and outside of programming ).
So I have no idea how good I am, but I have confidence in what things I can create and confidence in my ability to learn more.
Does my code still make sense to me 6 months later?
Did I introduce new bugs?
Are people using my building blocks to add features or working around them/ redoing them?
These are not good metrics. I have researched this and it seems there is no good way to measure coding improvement except subjective measurements.
Did I introduce new bugs?
Are people using my building blocks to add features or working around them/ redoing them?
These are not good metrics. I have researched this and it seems there is no good way to measure coding improvement except subjective measurements.
There are many ways to quantify how good of a programmer you are.
- You can compare yourself to other developers (there are plenty of qualities to compare)
- You can review your statistics (commit frequency, average file size, accuracy of time estimates)
- You can compete in programming competitions
- You can evaluate yourself using the Programmer Competency Matrix: https://sijinjoseph.com/programmer-competency-matrix/
Also, "Good" is subjective. Some programmers are "good" in certain contexts, but "not good" in others.
- You can compare yourself to other developers (there are plenty of qualities to compare)
- You can review your statistics (commit frequency, average file size, accuracy of time estimates)
- You can compete in programming competitions
- You can evaluate yourself using the Programmer Competency Matrix: https://sijinjoseph.com/programmer-competency-matrix/
Also, "Good" is subjective. Some programmers are "good" in certain contexts, but "not good" in others.
Wow, this competency matrix is very useful. Thanks for sharing!
1. read others code. think. ask questions. why and how certain code is written in certain way.
2. Read more code.
3. Write more code.
4. If your code which you wrote few years back looks bad to you, then you are on right path.
5. How much you understand the core concepts. New languages and frameworks are more of an glitter.
6. You want to be better version of yourself, then your progess is your stats you need look at. How many books did you read year on year? How much code you read year on year ? How much code you wrote ? How much fun you had :)
7. Adding, if you can think of the future maintainer of your code in mind and code, then you are lot better than many programmers out there in business.
8. Try to be a clean code enthusiast.
2. Read more code.
3. Write more code.
4. If your code which you wrote few years back looks bad to you, then you are on right path.
5. How much you understand the core concepts. New languages and frameworks are more of an glitter.
6. You want to be better version of yourself, then your progess is your stats you need look at. How many books did you read year on year? How much code you read year on year ? How much code you wrote ? How much fun you had :)
7. Adding, if you can think of the future maintainer of your code in mind and code, then you are lot better than many programmers out there in business.
8. Try to be a clean code enthusiast.
> 4. If your code which you wrote few years back looks bad to you, then you are on right path.
What if the recent stuff looks bad too? :)
What if the recent stuff looks bad too? :)
Then why are you writing it?
Because you have a working, but ugly, solution to a problem and can't figure out a solution that does look good. Or because it's a trade-off: the thing you think would be better requires more work than you think the feature is worth. Maybe you want to tractor to make it more reusable, but decide it is unlikely to be reused, so not worth the effort.
if you able to differentiate this is bad from good, that by itself is a progress :)
Then you're normal?
The more experience I get, the more I realize that I'm pretty average.
I just purchased a coffee mug that says “World’s Okayest Developer” so I’m right there with you.
In all seriousness, though: I’ve learned that it’s better to just accept that sometimes you’ll do really good or exceptional work, sometimes you’ll do awful work, and most of the time you’ll do work that’s pretty good and gets the job done but isn’t perfect.
In all seriousness, though: I’ve learned that it’s better to just accept that sometimes you’ll do really good or exceptional work, sometimes you’ll do awful work, and most of the time you’ll do work that’s pretty good and gets the job done but isn’t perfect.
I consider myself okayest because I can fix the stuff I break or improve something I did months ago. Believe it or not, a lot of people I have worked with can’t.
Every once in a while you need a signal flare, but most of the time what’s required is a lightbulb.
There are no such things as good programmers. Humans have no idea how to program computers, and anybody who tells you differently is lying.
The most honest person here is https://news.ycombinator.com/item?id=18538092
The most honest person here is https://news.ycombinator.com/item?id=18538092
If people are explaining stuff to you all the time, you're the dumbest guy in the room.
If you're explaining stuff to people, you're the smartest guy in the room, and you should find a place to work where you're the dumbest guy in the room.
If you're explaining stuff to people, you're the smartest guy in the room, and you should find a place to work where you're the dumbest guy in the room.
This is a very complicated thing to answer concisely, but I'll take a stab at it from a product development perspective.
You know you're a good programmer if the things you build "just work." It should be near impossible to find flaws in your solutions. This is actually rare. Most developers I've worked with will declare something "done" well before all of the flaws have been worked out.
You know you're a good programmer if the things you build "just work." It should be near impossible to find flaws in your solutions. This is actually rare. Most developers I've worked with will declare something "done" well before all of the flaws have been worked out.
You know you're a good programmer if the things you build "just work."
How do you quantify, "just works?" For a large enough project, perfection, or even just getting pretty close to it, ends up being pretty expensive.
It should be near impossible to find flaws in your solutions.
I had a boss who declared he could find a bug in any page of code, so long as you let him lawyer the specs in great enough detail. Granted, we were working in a pretty complex domain, but as far as I could see, he was always right about that.
As Matt Easton keeps saying: "Context!"
Maybe the company you're working for finds it much more valuable to do lots of iterations so they can tinker with the product and keep refining it. In that case, it might be even better than "perfection" if the things you build mostly work, but that you can respond to change and bugfix requests quickly. (Without introducing regressions.)
How do you quantify, "just works?" For a large enough project, perfection, or even just getting pretty close to it, ends up being pretty expensive.
It should be near impossible to find flaws in your solutions.
I had a boss who declared he could find a bug in any page of code, so long as you let him lawyer the specs in great enough detail. Granted, we were working in a pretty complex domain, but as far as I could see, he was always right about that.
As Matt Easton keeps saying: "Context!"
Maybe the company you're working for finds it much more valuable to do lots of iterations so they can tinker with the product and keep refining it. In that case, it might be even better than "perfection" if the things you build mostly work, but that you can respond to change and bugfix requests quickly. (Without introducing regressions.)
> It should be near impossible to find flaws in your solutions.
The number of open issues in most OSS repos would make me hold my tongue before saying something so farfetched.
The number of open issues in most OSS repos would make me hold my tongue before saying something so farfetched.
I've used, worked on, and depended on an enormous amount of software and I have literally never seen such a thing.
Depends on how you measure it, if you gave me a programming test that measured how much i knew and if i knew the intricacies of a language and memorised the manual, while also testing me on computer science questions that only get talked about in universities, then i'd probably perform poorly.
However, i'm a get shit done developer, while i've been doing this 14 years and know my area very well, i dont know it nearly as well as someone who has rigorously studied it and has been doing it for only 3-5 years. What i can do is deliver, and thats whats valuable to businesses.
So, is "good" an academic measurement or a business one? Its all context.
However, i'm a get shit done developer, while i've been doing this 14 years and know my area very well, i dont know it nearly as well as someone who has rigorously studied it and has been doing it for only 3-5 years. What i can do is deliver, and thats whats valuable to businesses.
So, is "good" an academic measurement or a business one? Its all context.
Ha! So, so many definitions of good. But, at a basic level, you can boil it down to:
* Does my code work?
* Does my code look after itself and its user when things don't go according to plan?
* Is my code simple?
* Can my code be maintained?
There are very serious sub-plots involving (ie) what does "work" mean? are simple and maintainable the same thing? But if you hit the four points above and don't fart in the office, you're good to go.
* Does my code work?
* Does my code look after itself and its user when things don't go according to plan?
* Is my code simple?
* Can my code be maintained?
There are very serious sub-plots involving (ie) what does "work" mean? are simple and maintainable the same thing? But if you hit the four points above and don't fart in the office, you're good to go.
I knew I wasn't very good when I worked as a programmer. I based that on watching others, and how often I could figure out problems without asking for help. I could see I was waaaaaayyy behind even the newest people around me. That was a long time ago, I'm still in IT, but not a coder now. I do ok with the basics still, but I ask for help all the time.
Some basic heuristics I use for determining the capability of other programmers and myself:
1.) Does the code have a good bus factor i.e If the maintainer dies tomorrow by being knocked down by a bus, can other people pick up where he/she left off? Further research into the Bus Factor can be found here: https://www.youtube.com/watch?v=0SARbwvhupQ
2.) Is the code well documented? This is so obvious that it is painful to write this comment, but it is a very simple heuristic for determining capability. Documentation can include code comments.
3.) Is the code resilient to weird input? The code should perform well under heavy fuzzing and where possible, sanitize different input. It should be tested against this: https://github.com/minimaxir/big-list-of-naughty-strings
1.) Does the code have a good bus factor i.e If the maintainer dies tomorrow by being knocked down by a bus, can other people pick up where he/she left off? Further research into the Bus Factor can be found here: https://www.youtube.com/watch?v=0SARbwvhupQ
2.) Is the code well documented? This is so obvious that it is painful to write this comment, but it is a very simple heuristic for determining capability. Documentation can include code comments.
3.) Is the code resilient to weird input? The code should perform well under heavy fuzzing and where possible, sanitize different input. It should be tested against this: https://github.com/minimaxir/big-list-of-naughty-strings
If your employer is happy with your performance then you are probably "good enough" as you say.
However if you truly do always want to be improving your ability as a software engineer, then you are in luck, this field is so vast and deep that you can easily spend more than a lifetime improving! Finding out how and measuring it is another matter.
However if you truly do always want to be improving your ability as a software engineer, then you are in luck, this field is so vast and deep that you can easily spend more than a lifetime improving! Finding out how and measuring it is another matter.
I would recommend contributing code to a well known FOSS project, or at least an existing project that you use or respect. I think hacking on meaningful projects will be clear milestones for yourself, which seems to be what you’re looking for.
To encourage you, here are a couple of contributions I have to Linux and Hadoop:
https://github.com/torvalds/linux/commit/0bef71093d446165964... https://github.com/apache/hadoop/pull/114
If you read through the commit messages and look at the patches, I think you’ll find that reaching these clear milestones doesn’t take an unattainable amount of skill; just a bit of patience and curiosity.
To encourage you, here are a couple of contributions I have to Linux and Hadoop:
https://github.com/torvalds/linux/commit/0bef71093d446165964... https://github.com/apache/hadoop/pull/114
If you read through the commit messages and look at the patches, I think you’ll find that reaching these clear milestones doesn’t take an unattainable amount of skill; just a bit of patience and curiosity.
I find as I get more experience I realize my limitations as a programmer so I can predict much further out where I'll run into trouble. It usually ends up being avoiding bad architectural choices, avoiding bad abstractions, avoiding introducing bugs into code that works. It's easy to spot a bad programmer, I find that a lot of the time a good programmer will be known for their faults in other areas (ie. Bad communicator) but people take their skill for granted. And then there's the rare programmer who can solve things that others can't understand. There's way more bad programmers than star ones, but my guess is a lot of people here fall into the good not great category unless their track record is exceptional. A lot of people try and fail early, much like companies, so if you've been in the game for a while it's a good indication.
Granted, I'm a lone wolf (mostly) scientific programmer, not a commercial software developer. I look at a few things:
1. Keep an eye on how big or elaborate my programs get before I lose control of them, and have to either stop development, start from scratch, or massively refactor in order to know what the heck is going on. Being able to maintain a larger program, or participate in a larger project, without doing too much damage, seems like a reasonable informal metric.
2. Look at programs that I've written months or years ago and critique my own work. A year-old program should hopefully look better than a decade-old program.
3. Try to stay abreast of improved programming techniques, incorporate them in my work, and have faith that my programs will gradually improve.
I just realized these things are not about how good I am, but about the rate of change of my skills.
1. Keep an eye on how big or elaborate my programs get before I lose control of them, and have to either stop development, start from scratch, or massively refactor in order to know what the heck is going on. Being able to maintain a larger program, or participate in a larger project, without doing too much damage, seems like a reasonable informal metric.
2. Look at programs that I've written months or years ago and critique my own work. A year-old program should hopefully look better than a decade-old program.
3. Try to stay abreast of improved programming techniques, incorporate them in my work, and have faith that my programs will gradually improve.
I just realized these things are not about how good I am, but about the rate of change of my skills.
Just 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)
— 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)
I believe that you get good by getting better. And I think it's easier to tell that you've gotten better than it is to tell that you've gotten good.
Look back 6 months, a year, 2 years. How have you grown? What can you do now that you couldn't do then? Are there things that you'd do differently? Things you wouldn't do at all? That might give you a sense of where you are now.
Repeat the process of getting better many times. Then one day you'll take some call, draw some diagram, write some code and you'll know. For a brief shining moment you will know without a doubt that it is good and you are too. Then the moment will pass and you'll spend a couple of years trying to find the next one.
Look back 6 months, a year, 2 years. How have you grown? What can you do now that you couldn't do then? Are there things that you'd do differently? Things you wouldn't do at all? That might give you a sense of where you are now.
Repeat the process of getting better many times. Then one day you'll take some call, draw some diagram, write some code and you'll know. For a brief shining moment you will know without a doubt that it is good and you are too. Then the moment will pass and you'll spend a couple of years trying to find the next one.
> But as a programmer at work, I often receive feedbacks from 1 or 2 persons at most
Oof, yeah, that's rough. It's hard to say something conclusive with little data, and most of the data is likely biased (yourself). I'd recommend finding opportunities to work with other devs. Open source is a good path forward.
Otherwise, estimating your performance is super hard. Are you right more often than you're wrong? When you're wrong, do you consistently fix your flaws? Are you learning? Are you contributing more and more business value? These are all very opaque questions, and even if you answer all of them you're likely to have gaps.
Get more data!
Oof, yeah, that's rough. It's hard to say something conclusive with little data, and most of the data is likely biased (yourself). I'd recommend finding opportunities to work with other devs. Open source is a good path forward.
Otherwise, estimating your performance is super hard. Are you right more often than you're wrong? When you're wrong, do you consistently fix your flaws? Are you learning? Are you contributing more and more business value? These are all very opaque questions, and even if you answer all of them you're likely to have gaps.
Get more data!
If your code 1) runs the first time with no non-trivial errors or obvious bugs, 2) does at least what you intended it to do, reliably, efficiently, and isn't easily de-railed...
then you're getting close. If 3) you find you can easily and quickly modify it to add features... months later... that's closer still.
Of course if you have to answer to someone about why you did it this way or that way, or who can't comprehend your code, then (in that environment) you may have farther to go.
Longer, bigger, harder projects may test your skills. Be your own best critic, always strive to do more with less.
then you're getting close. If 3) you find you can easily and quickly modify it to add features... months later... that's closer still.
Of course if you have to answer to someone about why you did it this way or that way, or who can't comprehend your code, then (in that environment) you may have farther to go.
Longer, bigger, harder projects may test your skills. Be your own best critic, always strive to do more with less.
How do you define "good" and "quality"? This is the difficulty in measuring skill or productivity in this kind of work. Is it the number of uncaught bugs that have been released? How well what you produced matches with what the askers (product mgrs, customers, etc.) asked for? How much test coverage you have?
As others have suggested, it's useful to look at code that you wrote 3, 6, 12 months ago and ask yourself: do I understand this? Could I write it better now? What would I do differently now? You might try keeping track of these reflections in a journal.
As others have suggested, it's useful to look at code that you wrote 3, 6, 12 months ago and ask yourself: do I understand this? Could I write it better now? What would I do differently now? You might try keeping track of these reflections in a journal.
Do you mean programming as a job, or programming as an activity/art? They seem two very different things; some people are answering one or the other or a combination.
I noticed some refer to programming as a craft - maybe programming as a job is usually a craft. For myself, I am motivated to write a program because I don't know what the output will be - i.e. not a craft, where the end result is known and aimed for. It's like an experiment - it's worth doing because I don't know what will happen.
I noticed some refer to programming as a craft - maybe programming as a job is usually a craft. For myself, I am motivated to write a program because I don't know what the output will be - i.e. not a craft, where the end result is known and aimed for. It's like an experiment - it's worth doing because I don't know what will happen.
This can only be answered with context.
Someone may or may not be a good programmer depending on a whole bunch of factors, the project being built, their familiarity with the codebase, familiarity with the technologies used, how happy they feel in their job, how happy in their personal life, if they really like the project they are working on, whether they get time/space to concentrate. It goes on and on.
There's no answer to "is person X a good programmer" within context and even then it's purely subjective.
Someone may or may not be a good programmer depending on a whole bunch of factors, the project being built, their familiarity with the codebase, familiarity with the technologies used, how happy they feel in their job, how happy in their personal life, if they really like the project they are working on, whether they get time/space to concentrate. It goes on and on.
There's no answer to "is person X a good programmer" within context and even then it's purely subjective.
If you can manage to stay interested in what you're doing, you're going to learn and improve over time.
If you lose the passion, and get bored with what you do, you're not going to care, and that's a worse fate than even staying still skill-wise. It's a very common fate for those who have to work at this 8 (or likely more) hours a day, nearly every day of the week for years or decades.
So I'd just try to keep the flame alive, focus on always doing what you genuinely enjoy, and not sweat the rest.
If you lose the passion, and get bored with what you do, you're not going to care, and that's a worse fate than even staying still skill-wise. It's a very common fate for those who have to work at this 8 (or likely more) hours a day, nearly every day of the week for years or decades.
So I'd just try to keep the flame alive, focus on always doing what you genuinely enjoy, and not sweat the rest.
My favorite definition of a “good” programmer is someone who ships! Done is better than perfect. Knowing what compromises to make in order to ship without creating a future nightmare.
Oh my gosh, no. That might be a "good" software developer, but I'd probably think not on that, too.
I've had to follow behind such programmers who wrote their code with the primary goal of getting done as fast as possible never expecting to have to come back to it. It's literally the worst code that exists.
Usually they no longer work at the same place they created such code, because later they were asked to maintain it. That's why I got the job. Usually we start over.
I've had to follow behind such programmers who wrote their code with the primary goal of getting done as fast as possible never expecting to have to come back to it. It's literally the worst code that exists.
Usually they no longer work at the same place they created such code, because later they were asked to maintain it. That's why I got the job. Usually we start over.
> Knowing what compromises to make in order to ship without creating a future nightmare.
Sounds like they were bad at that part
Sounds like they were bad at that part
The majority of software developers are payed to ship product to a deadline. It should meet the requirements of your customers and be thoroughly tested. There are always trade offs but the biggest impediment to shipping is the procrastinator or the perfectionist.
If you miss deadlines then you are failing at your job.
If you miss deadlines then you are failing at your job.
"...the biggest impediment to shipping is the procrastinator or the perfectionist."
I don't necessarily think that it's the "biggest" but I'll agree it's certainly one of the problems. I think I'd put "unclear specifications" as the biggest problem.
I've seen a lot of code delivered on time to meet the deadline that clearly was not ready but was delivered anyway. I've never the temerity to say, "I told you so," but I thought it. There's a balance to be had. Sometimes the deadline and the customer requirements and future maintainability cannot all be satisfied. Something has to give.
I don't necessarily think that it's the "biggest" but I'll agree it's certainly one of the problems. I think I'd put "unclear specifications" as the biggest problem.
I've seen a lot of code delivered on time to meet the deadline that clearly was not ready but was delivered anyway. I've never the temerity to say, "I told you so," but I thought it. There's a balance to be had. Sometimes the deadline and the customer requirements and future maintainability cannot all be satisfied. Something has to give.
Yeah I agree with this, finding balance between risk and productivity. Although doing something beautiful is the exception.
If you work in a moderately sizeable organisation and manage to delete more lines of code than you add, while still adding features, you may be a good programmer.
Easy, I know I'm a bad one
If you know that, then you might be a pretty good one...
It comes back to:
"The only true wisdom is knowing that you know nothing"
Problem is - hubris is generally considered a virtue.
"The only true wisdom is knowing that you know nothing"
Problem is - hubris is generally considered a virtue.
It'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.
Would you hire yourself?
There is no point in measuring yourself against other people, even in sports.
You should measure yourself against yourself. Your goal should be to become your best self, not the best X in the room/world. X is mostly picked arbitrary.
This means you should always try to become better at what you value.
You should measure yourself against yourself. Your goal should be to become your best self, not the best X in the room/world. X is mostly picked arbitrary.
This means you should always try to become better at what you value.
When you maintain a piece of code, that only you have written, for a couple of years, and making changes to it is as easy as the first day, then you're a good programmer.
If every change to the code feels like adding another twist to the maze, then you're not a good programmer.
If every change to the code feels like adding another twist to the maze, then you're not a good programmer.
Late but we don't have stats on world's best plumber/doctor either. It becomes a practice at one point and your results/impact becomes the true measure.
I don't think it makes sense to compare a profession to a sport.
I don't think it makes sense to compare a profession to a sport.
If 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.
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.
Somewhere I read a measure of intelligence is: the ability to achieve your objectives efficiently. You could say the same about coding. Are you achieving your coding objectives efficiently?
What’s a programmer?
I’m very good at breaking down old code and making it modern. Does that mean I’m a good programmer? For that task, yes. In general, the jury is still out.
I’m very good at breaking down old code and making it modern. Does that mean I’m a good programmer? For that task, yes. In general, the jury is still out.
My 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.
Do you do any of the following things?
Start a project by "hitting the ground running" and writing code. Fail to write documentation unless under external pressure. Deeply aware of the powerful and superior features of your favorite languages. Have a considered view that long term systems maintenance irrelevant to most software design. Frequently roll performance optimizations in to your code.
If so, you are probably a bad programmer.
Start a project by "hitting the ground running" and writing code. Fail to write documentation unless under external pressure. Deeply aware of the powerful and superior features of your favorite languages. Have a considered view that long term systems maintenance irrelevant to most software design. Frequently roll performance optimizations in to your code.
If so, you are probably a bad programmer.
I agree on the other points. Can you elaborate on how "Deeply aware of the powerful and superior features of your favorite languages" makes one a bad programmer?
Not trying to be sardonic, just want to know how to improve my programming skills.
Not trying to be sardonic, just want to know how to improve my programming skills.
It is generally accepted that "right tool for the job" is a desirable philosophy.
If you are "Deeply aware of the powerful and superior features of your favorite languages", then you probably are too deeply caught up in language fanboy-ism to actually understand the merits and disadvantages of your favorite languages compared to the alternatives. (You're probably also being a jerk to people who aren't fans of your languages.)
They're tools. They're not rock bands. Don't get caught up in fanboy-ism.
They're tools. They're not rock bands. Don't get caught up in fanboy-ism.
Do you solve the solution to the user's problem or just accept the solution given by the business?
Are you a team player?
Are you a team player?
Your development speed keeps being a constant even as your software evolves and you add many new features.
Go back and read code you wrote 1, 2, even 5 years ago. If it's still clear and logical, and you don't think "who's the clown that wrote this?" then you're good. If you can hand it to someone else and they don't think "who's the clown that wrote this?" then you're very good.
I 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.
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.
Can you add anything specific to Data Scientists in particular? I am in this field and would like to improve further. Any pointers would be helpful. BTW, Nice post. +1
A common mistake is to judge yourself in a vacuum. You aren't a rockstar because you have achieved a certain number of years employed (this is more common than you would think). The Dunning-Kruger effect is very real.
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Objective measures of competence are:
* speed of delivery. Do you deliver faster than your peers?
* extreme problems. Are you able to solve problems nobody else can solve?
* originality. Are you able to demonstrate problems nobody else can see or solve problems in a new way?
* write software everybody wants. Do people frequently consume your software or beg you for certain features?
---
Sometimes a low aggression (aggressive as far as product not angry people) environment can trap you into a tightly contained cocoon of suck from which there is little or no self-improvement potential. Be aware of this.
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Objective measures of competence are:
* speed of delivery. Do you deliver faster than your peers?
* extreme problems. Are you able to solve problems nobody else can solve?
* originality. Are you able to demonstrate problems nobody else can see or solve problems in a new way?
* write software everybody wants. Do people frequently consume your software or beg you for certain features?
---
Sometimes a low aggression (aggressive as far as product not angry people) environment can trap you into a tightly contained cocoon of suck from which there is little or no self-improvement potential. Be aware of this.
Good programmers don’t concern themselves with such trivialities.
If you're questioning yourself, then you're alright.
Try leetcode the hard ones
[deleted]
I can answer the specific question for you easily: you are not good enough yet. That answer applies no matter how good you are :-) But to be serious, it's very, very important in this industry to cultivate that attitude because as soon as you think you are "good enough", the industry moves under your feet. This is a job of endless learning and self development. For those that are new to the field, take note. If you are the kind of person that just wants to show up at their job, do what they know how to do and then go home, you are at extreme risk to be unemployed and even unemployable in this field in about 10 years time. There is nothing inherently wrong with wanting a job like that, but a programming job is not that (at least not right now -- maybe come back in 20 or 30 years).
On the other hand, I could also say that no matter how bad you are, where you are today is fine. There are so many roads in this industry it's incredible. It is counter productive to judge yourself harshly. I know many very talented people who I never, ever want to work with. I know very many people who don't have so much talent that I am extremely happy to work with. I'm sure most people can relate. No matter what kind of natural talent you have at programming, try to cultivate the sense that others want to work with you.
I saved the most complicated bit for last. How do I know what I suck at so that I can make sure to improve it? This is really difficult. I've seen many people feel very secure about their abilities in one way or another, when in reality the things they were most proud of were part of their weaknesses, not their strengths. If I'm really, really honest with myself, I've gone through patches of that myself. I think everybody does (although some are much more delusional than others).
The best thing to do is to try to work with a wide variety of people who have different backgrounds. When someone disagrees with you, make a note of it. Even if you end up convincing them that they are wrong, try to understand why they had that idea in the first place. Is there anything you can learn? Look for ways to invalidate your current view point.
The most difficult piece of advice to follow, I think, is to celebrate when you are wrong. It is easy to convince yourself that you are right and to put your head in the sand. It is difficult to understand that you are wrong and to figure out how you came to your mistaken conclusions. More importantly, if you really are right, then there is nothing to learn and nowhere to grow. It's only when you are wrong that you can make substantial progress. Cherish that process.
One more thing: I believe that every good programmer must, at some point in their career, build a system of significant size all by themselves. Thing of it as your master project (the project that journeymen do to be recognised as masters). One of the best things you can do is to build that system and maintain it for many years. With that you can see where your weaknesses lie -- all your assumptions will be laid bare. Be very critical of the result. If it isn't perfect, why isn't it perfect. You only have yourself to blame, and that's a wonderful piece of perspective.
On the other hand, I could also say that no matter how bad you are, where you are today is fine. There are so many roads in this industry it's incredible. It is counter productive to judge yourself harshly. I know many very talented people who I never, ever want to work with. I know very many people who don't have so much talent that I am extremely happy to work with. I'm sure most people can relate. No matter what kind of natural talent you have at programming, try to cultivate the sense that others want to work with you.
I saved the most complicated bit for last. How do I know what I suck at so that I can make sure to improve it? This is really difficult. I've seen many people feel very secure about their abilities in one way or another, when in reality the things they were most proud of were part of their weaknesses, not their strengths. If I'm really, really honest with myself, I've gone through patches of that myself. I think everybody does (although some are much more delusional than others).
The best thing to do is to try to work with a wide variety of people who have different backgrounds. When someone disagrees with you, make a note of it. Even if you end up convincing them that they are wrong, try to understand why they had that idea in the first place. Is there anything you can learn? Look for ways to invalidate your current view point.
The most difficult piece of advice to follow, I think, is to celebrate when you are wrong. It is easy to convince yourself that you are right and to put your head in the sand. It is difficult to understand that you are wrong and to figure out how you came to your mistaken conclusions. More importantly, if you really are right, then there is nothing to learn and nowhere to grow. It's only when you are wrong that you can make substantial progress. Cherish that process.
One more thing: I believe that every good programmer must, at some point in their career, build a system of significant size all by themselves. Thing of it as your master project (the project that journeymen do to be recognised as masters). One of the best things you can do is to build that system and maintain it for many years. With that you can see where your weaknesses lie -- all your assumptions will be laid bare. Be very critical of the result. If it isn't perfect, why isn't it perfect. You only have yourself to blame, and that's a wonderful piece of perspective.
So, as a programmer, how do you quantify or estimate how good you are?
Thank you,