1. 23

If you want to become a better programmer, how do you measure your progress? Do you have performance indicators that go beyond “my employer is happy with me” or “I feel like I’m better today than I was last year”? For example:

  • Productivity measured by things like how fast you finish a task or how often you make commits
  • The popularity of projects you’ve built measured by things like download rates, page visits, or Github stars
  • Contributions to open source projects
  • Job offer from a company with a low acceptance rate (e.g. Google)
  • How much the market will pay you for your skills (e.g. salary, hourly rate, Patreon donations)

Note that I’m not sure any of these examples are reasonable measures of “good”.

  1. 22

    The first problem I see is that you believe that quality is measurable with hard metrics. This is something any programmer should be skeptical of, especially if they worked with data and they have seen countless projects spit out bullshit because of wrong assumptions over the meaning of the metrics.

    Then also your reliance on the feedback from above (or from customers) is quite problematic: programming is a craft that doesn’t necessarily have to become a job. One can be a very good programmer without a job.

    For me a good programmer should:

    • be able to learn new knowledge (in any field) and possibly in less time than the average person: being a programmer is being a learner
    • be able to apply abstract reasoning rigorously and effectively
    • have taste in design
    • be empathetic and able to project themself in the user’s position
    • know their tools well
    • have the social and organizational skills to participate in a team (preferably without the involvement of the management or other external authorities)

    The growth should be holistic and involve all these charateristics, that are intertwined and inseparable. How do I “define being a good programmer”? Well, if me and my peers share positive opinions on all these aspects of a colleague, probably he’s a good progammer.

    1. 2

      The first problem I see is that you believe that quality is measurable with hard metrics.

      Did you read the last line: “Note that I’m not sure any of these examples are reasonable measures of ‘good’”?

      Then also your reliance on the feedback from above (or from customers) is quite problematic: programming is a craft that doesn’t necessarily have to become a job.

      Huh? Measuring speed/productivity doesn’t involve receiving feedback from anyone. Contributing to open source projects involves receiving feedback from peers.

      One can be a very good programmer without a job.

      What are you responding to here? I made no comment relevant to this. Some of the performance indicators I listed apply only to professionals. If you aren’t a professional, then obviously those don’t apply to you.

      Well, if me and my peers share positive opinions on all these aspects of a colleague, probably he’s a good progammer.

      My experience is that programmers who evaluate the performance of their peers based on the kinds of criteria you listed often select for programmers who remind them of themselves.

      1. 5

        My experience is that programmers who evaluate the performance of their peers based on the kinds of criteria you listed often select for programmers who remind them of themselves.

        That’s what humans do anyway and it’s fine. You can wrap your opinions in a layer of mathematics and call them objective, but in the end who agreed on the metrics decided who’s a good programmer and who is not according to their subjective definition of good programmers. If they are programmers, probably they will pick metrics that reflect their own skills or the skills they would like to have.

        What are you responding to here? I made no comment relevant to this. Some of the performance indicators I listed apply only to professionals. If you aren’t a professional, then obviously those don’t apply to you.

        I’m not responding directly to what you said but to the broader idea, common in IT, that productivity in a startup/corporate environment define what a programmer should study or be. Same for all the other comments: they are more about the discourse than your post specifically but it’s always good to address them.

    2. 12

      You should never measure yourself by things you can not control. So things like page visits, likes, retweets, mentions, acceptance to a company, salary etc. These things have external factors, so to rely on them exposes your enjoyment of life to those external factors that you cannot control.

      Self-improvement metric should be quantifiable, has high resolution (daily/weekly improvement resolution), high ceiling (so you can keep going).

      One thing I find useful is a knowledge delta-log. You write down what you learned today at the end of the day, and then now and then you look back and see all these things you learned, now you know them and you didn’t know them before.

      With programming you can always do projects, challenges, etc. Keep logs of new techniques or processes you tried and then you can look back and say “hey i did this thing and now my test coverage is bigger” or “i tried that and it didn’t work so now i know not to do something like that again”.

      1. 2

        You should never measure yourself by things you can not control.

        I agree with this statement on its face but I’m not sure that the kind of things I listed are completely beyond one’s control. Of course, it’s not completely within my control to hit a target for page views or salary. My success there is constrained by external factors. But given a realistic target, I can do things to increase my chances of success. The outcome will always be probabilistic but things I do control, like increasing my skills through the practice you describe, gives me better chances.

        1. 4

          What he’s trying to say is that you should detach your definition of worth from your ability to impact the world.

          Personally I think this is good for two reasons:

          1. it’s healthy: a capitalistic society tends to assign worth to people according to their productivity. This leads to so many disfunctional behaviors in order to cope with the pressure. The only winning move there is not to play. In order to avoid playing, define your own definition of worth and stick to it.
          2. The world is out of your control and judging your impact on it is a very noisy measurement, if we want to stick to engineering lingo. So many things can go wrong without you even noticing and lead to your failure, that it doesn’t really make sense to judge your worth based on the results you achieve.

          This doesn’t preclude you from improving your ability to impact the world, but always treat as a factor distinct from your perception of selfworth.

          1. 1

            What he’s trying to say is that you should detach your definition of worth from your ability to impact the world.

            When did I say anything about defining self-worth? I just asked about how to define being good at programming. I haven’t connected this to self-worth, nor would I.

            1. -2

              a capitalistic society tends to assign worth to people according to their productivity

              And that drives people to be productive, leading to more stuff and more capabilities and a better planet for everybody. Is there such a thing as overwork? Yes, and we do not say people should kill themselves in pursuit of being productive.

              What the economy and what people see as worth do not need to collide. That’s partly because government is a) necessary, and b) not capable of capitalistic efficiency. Its mission must be different than that of the economy.

              1. 2

                it also alienates people from their work, from politics and from reality, creates poverty, disrupt communities, hurts physical and mental health, leading to depression, alcoholism, caffeine addiction and so on and so forth. And no, it doesn’t create a better planet. We are on the verge of extiction after just 300 years of capitalism.

                The existence under capitalism is bad even without overworking. It’s bad if you have a job, it’s bad if you don’t have it.

                1. 1

                  Can I ask, when you say poverty, do you mean relative to other people?

                  1. 2

                    Relative poverty in the Global North, absolute poverty in the Global South

                    1. 1

                      So were people rich through history and only now that we have capitalism are people poor?

                      1. 1

                        Material poverty? obviously not. Capitalism brought net material wealth almost everywhere but the price to pay is too high. Poverty is not just material poverty.

                        1. 1

                          I don’t understand what other types of poverty there are.

                          1. 1

                            Poverty of time, poverty of dignity, poverty of spirit, poverty of freedom, poverty of health.

                            1. 1

                              Poverty of material is the one that kills people, is the one that leads to significant numbers of deaths of people at very young ages.

                              We are living in amazingly healthy times. Some countries now are amazingly free, even including the US. Capitalism does not cause poverty of time, women of today have more time than ever before in history due to capitalistic inventions. Capitalism does not cause poverty of dignity. People are dignified whenever they have provided for themselves, or done anything for themselves. Capitalism simply requires it in the course of a life.

                              1. 1

                                You clearly don’t have the tools nor the interest to learn that your opinion and your experience aren’t the norm. Also maybe you should more history: as every regime does, the past created by the modern neoliberal regimes is very different from the one assessed by historians.You might reconsider most of your statements.

                                You might also consider to go speak to one of the many homeless people that you probably meet everyday and ask them their opinion on this. When is the last time you did it?

                                1. 1

                                  So that’s back to material poverty, isn’t it. You are saying that capitalism causes material poverty. Which is false on its face.

                                  Capitalism is the ability of a person to exchange for the goods or services they can provide. Have enough of it, you have the Economy. The Economy doesn’t exist outside capitalism.

                2. 1

                  People who downvoted as troll, please explain why

          2. 8

            This might be a controversial stance, but I see a good programmer as someone who can take a set of requirements and produce, using code, an implementation meeting those functional requirements with the following properties:

            • confidence in its correctness (ie, well tested, not formally verified)
            • “quick” delivery—starting with broad strokes, and then filling in details.
            • resilience to swooping requirements changes—it’s impossible to be perfect here, but a good programmer has made design choices that minimizes the code gutting for most eventually requested changes.

            A good programmer can do the above over and over independently or with a team, helping get the team meeting the above properties.

            Explicitly not included are skills that a “software enginner” should ideally have: ability to gather requirements, make well argued design / architecture choices, and be able to push back on product owners with wild delusions.

            That is to say, I choose to define programmer as in the original, almost mechanical, way. That’s not to say that programmers can’t be SWEs or vice versa, mind you, which is usually the case, but it provides the possibility.

            1. 5

              A good programmer, in my eyes (not a rock star programmer mind you), should be able to estimate how much time it would take to accomplish a programming task by himself reliably. This is one of the skills I believe a good programmer should possess, and .somewhat in short supply.

              So, measuring your progress is simple enough. Estimate any given task at hand, and see if you can finish it within the estimate (without overtime).

              1. 1

                I assume this is about short tasks in the order of days or weeks, and not months or years? Wouldn’t that be teachable in a matter of months practice? Like, some loose variation of scrum is already enough to get you in a rhythm, and repeatedly work on your planning and estimates.

                1. 4

                  short tasks in the order of days or weeks, and not months or years?

                  No lower or upper limits specified :). Good programmers do exist on a continuum after all.

                  Wouldn’t that be teachable in a matter of months practice?

                  Indeed like most of things in the programming world, you get better by practice. However, you can challenge yourself by increasing the scope (i.e how large the chunks are).

                2. 1

                  This is an interesting idea. Why do you think this is a heuristic for “good”. It seems like correct time estimates don’t indicate anything about effectiveness, just predictability.

                  1. 1

                    Replied here.

                  2. 1

                    I have one collegue whom I like to work with. He is really effective in his domain and faster than anybody else. However, I learned to not even ask him to estimate the time. He is hilariously bad at it. Is he a good programmer? I think so.

                    Also, I agree with you that this skill is in short supply. Most developers I know are bad at it and reliably underestimate the time. The usual cop out is “I’m estimating raw focused development time without interruptions”. Ok, but with some experience you should be able to estimate how much of that you have per day and adjust your planning.

                    1. 2

                      Is he a good programmer? I think so.

                      Could he have been a better programmer if he was better at estimating the time required? All I am saying is that estimation is one of the axes with which to measure a good programmer (and an often overlooked one).

                      People tend to have a one dimensional view of programming, that it only involves skill in coding. But I believe that a number of other aspects such as the ability to estimate, the ability to work well with others, the ability to understand and prioritize things etc should be considered part of being a good programmer. Each of these makes a person more effective at programming.

                      1. 1

                        Any advice on how to do that? I’ve been paid to write code for 20 years and I still run into surprises if I don’t try to write a small version of the thing before I give an estimate.

                        1. 2

                          I have two concrete ideas apart from mere experience.

                          1. Calibrate yourself, so you can estimate risks better. At least you will quickly learn that being even 90% sure is rare. It is also a nice skill for other opportunities where you deal with probabilities (security, safety, finance, etc).

                          2. Try story points.

                    2. 5

                      I don’t think a job offer from a company like google is the sign of a good programmer. Neither is contributions to open source.

                      IMO a good programmer is one that self-dogfoods the tools they write in their free time (ie, developing tools for their own needs instead of just developing things they heard others might need).

                      A good programmer knows how difficult a task is intuitively but may not necessarily be able to put it into numbers.

                      Progress as a good programmer is the difficulty of the tools you implement for yourself.

                      1. 1

                        This closely describes the people I know who I’ve felt to be the best programmers.

                      2. 4

                        I think most of the metrics you listed are easily corruptible because they’re proxy measures and they accumulate enough error over time to deviate from what you really wanted to measure.

                        The longer I write code the more sure I am that it doesn’t matter how good I am as an individual programmer. What really matters is how good programmers are collectively because asymptotically collective constraints overtake individual constraints. I don’t think there is an easy way to measure that and the sensible thing to do is to help fellow programmers get better without worrying about your own personal goodness metric.

                        1. 7
                          • Professionalism. This means treating coworkers with respect, treating customers with respect, treating yourself with respect, and providing adult feedback when you don’t feel respected. Respect comes in many forms.
                          • Service to your team. Typically this comes in the form of volunteering to do tasks that don’t yield immediate gains, but indirectly help your surroundings. This can mean signing up to do hiring interviews, delving into an unpopular cleanup task, or agreeing to cover for someone on paternity leave. Note: going back to “treating yourself with respect,” you can’t let these tasks consume you (especially if you keep doing them in lieu of “what you get paid for”). A proper balance between scheduled work, unscheduled work, and life is critical.
                          • Keeping your eyes open. It’s extremely easy to become established and set in your ways, especially if you’ve been at the same company or working on the same codebase for a long time. I’m not saying you should pay attention to every new fad, but it’s good to keep tabs on general trends in the industry. Outside of switching jobs, good sources are: Lobsters itself, conferences, new hires (especially ones new to the industry), and trying new programming languages/tooling “just to see what it’s like.”
                          • Keeping in touch with the world outside of programming. Maintaining hobbies or interests outside of programming spawns creativity and keeps you out of bubbles. Steve Jobs’ classic example was the calligraphy class he took that inspired him to have great typography on the original Mac. But you can’t force it! You never know when these things will intersect, so don’t take up photography because it will help your programming. You need to find things which genuinely drive you, and the connections will form later.
                          • Avoiding Second System Effect. The second system effect pops up everywhere, and I’m sure you will see it kill a promising project sometime during your career. Avoiding it means identifying when “perfection” is preventing a project from shipping, and also identifying when “perfection” isn’t actually perfection at all – sometimes it can just be a strong preference and orthogonal to the actual problem at hand. Rearranging deck chairs on the Titanic is perhaps a bit dramatic, because this kind of waste happens even for successful projects.
                          • Not being a hero. Hero developers are the ones who didn’t heed the advice given in the “service to your team” section. They always jump in and fix emergencies, often gleefully so. It isn’t even limited to fixing application errors, heroes can swoop in and fix planning emergencies or fill in gaps in documentation and training. It’s awesome that they have capabilities to do that, but as the linked article says: “crisis management is not the same as crisis prevention,” and “having a hero on call makes those real problems seem less urgent than they really are.”
                          • Properly handling Unicode. Yes it’s hard. We need to do it anyway.
                          • Service to your community. There are a lot of imbalances in the tech industry: minorities, women, and LGBT people face a lot of structural imbalances (in addition to outright discrimination and harassment). If you’re in a position of privilege, it’s on you to read up about these imbalances and how to correct them. In addition to being the right thing to do, not doing so means keeping qualified people out of jobs and driving qualified people away from the jobs they have. It’s a long road but we can get there.
                          1. 3

                            Thanks for such a thoughtful list. Even when good is defined qualitatively, as you have, it’s interesting to consider how to measure success towards manifesting those qualities. I think it’s interesting not as a way of measurement for the sake of measurement, or measuring to keep score, but as a way to identify unrealized potential or areas to improve.

                          2. 3

                            For me, a good programmer is someone who can influence their peers. A good programmer’s style and approach to solving problems is initially imitated by others until at some point it becomes “common sense” for them. Such influence can result in both horrible and excellent programming practices.

                            1. 2

                              You have confidence in your skills. Quality over quantity.

                              Want a real world metric?! Others come to you for assistance or advice – because they can see your a master of your craft (programming – not necessarily tool X or Y). Conversely, you don’t often ask others for assistance or how to do something, not that it’s wrong or you can’t, but given time you can/could derive a competent solution on your own. Although, let me stress, there is nothing wrong asking for help occasionally.

                              1. 2

                                Remove all externalities on your metrics, and break it down to things you can completely control.

                                How many challenging books did you read last year? Blogs are fine, but rarely get deeper than chapter two of a book. If you’re a Python programmer, and you rarely touch the database, get a great book on SQL and dive deep. Don’t just skim the tenth C# book in a row. Be uncomfortable, push your boundaries with each book. Minimum read one a year. I recommend books with exercises to complete, and do them all. Here are my favorites I recommend: http://deliberate-software.com/page/books/

                                Make a daily practice routine, maybe 20 minutes every day on the train. Sit and actually write software. Start with small tightly constrained problems, then build out something big.

                                Peter Norvig has some great examples on how to improve: http://norvig.com/21-days.html

                                1. 2

                                  You should consider yourself fortunate if you are allowed to enjoy what you’re doing. And there’s a good chance you become good at what you are doing when you enjoy it. Just try to enjoy it.

                                  1. 1

                                    I do enjoy programming. I also enjoy getting better at programming. As with a lot of activities, measuring my progress can be instrumental to getting better. Measurement of skill is not exclusive of enjoyment.

                                  2. 2

                                    I’d say a good programmer produces good code in good time. What is good code? It is easy to change correctly. Real world code gets randomly changed by people all the time. If you can write code that can quickly and correctly (as in minimum bugs) react to those change requests, you’re doing OK in my book, at least from the technical side.

                                    The non-technical stuff is probably focused on not being an arrogant jerk…

                                    1. 1

                                      Bug count is an interesting one I overlooked. I agree with your bigger idea that good code is code that can easily be changed.

                                    2. 2

                                      I use the very vague metric “I am proud of the work I do?”

                                      For me, this expands to:

                                      • Are the users of my software happy with the work I’ve done for them?
                                      • Do I think I could have done my work better than I did, given the same constraints?
                                      • Has my software caused pain for the people who use it, operate it, or maintain it?
                                      • Am I happy to show or talk about my work to other people?
                                      1. 1

                                        I think the most important skill of a programmer is the ability to learn.

                                        Year over year this can mean

                                        • knowing things you didn’t know last year
                                        • not making the same kinds of mistakes you made last year
                                        • understanding the difference between those kinds of mistakes

                                        For example, if you’re new to async programming you may make entire categories of errors that wouldn’t happen to you if you have a solid grasp of what the code actually does because you wouldn’t write the kind of broken code that is causing those problems in the first place (and the problems were inevitable given how you wrote the code because it was based on a flawed understanding of what the code does).

                                        You won’t stop making mistakes. If you no longer make mistakes that’s a good indicator you’re no longer learning because you’re no longer pushing the boundaries of your knowledge. You may want to make fewer mistakes but especially you don’t want to keep making the same mistakes – because making the same mistakes likely means you have some underlying knowledge gap that leads you to make those mistakes (or you simply don’t know how to avoid them – e.g. using the proper tooling rather than just winging it).

                                        There are no reliable metrics. This is not only true for competence, btw, this is true for most things.

                                        Frequency or speed in isolation is a garbage metric as it can be influenced by too many metrics that are unrelated to competence or skill. Salary is highly contextual ($100k in SF is unimpressive, $100k in most parts of Europe is obscene). Applying to companies like Google is neither (universally) desirable nor is acceptance a good indicator of competence (just of matching the specific criteria they have for consideration for a given role).

                                        You can set goals or milestones for yourself but chances are when you start out you lack the actual knowledge to pick goals and milestones that are actually meaningful or relevant to you. If you do set milestones for yourself, you should not only reevaluate your performance but also the milestones themselves – feel free to adjust or replace them if you feel they were a mistake.

                                        And don’t forget that your job is about more than just pushing buttons on a computer. The knowledge you want to gain is not only technical, you also need to understand the social aspects. How your users use your product, how your team members work together to create the product and how the product impacts society. And don’t forget taking care of yourself either: learn your limits and when to rest before your body forces you to rest.

                                        So what is a good programmer? I’d say most importantly they’re a good person and they’re a learner.

                                        I’m not sure this is the advice you were looking for, but after 25 years of learning to be a programmer this is all I can tell you.

                                        1. 1

                                          If you do want a simple metric, this could be one: How often do you make the same mistake twice, rather than finding a way to minimize the chance of it happening again?

                                          1. 2

                                            Another interesting one. I wonder how common it is for a programmer to make the same mistake many times. I have done this a handful of times, but it’s usually because the mistake is uncommon enough that I forgot having made it years ago.

                                            1. 1

                                              I have been cleaning up infinite loops left by a colleague in many a place, so some mistakes seem to be more like… habits.

                                              I sure have also been cursing at myself for repeating mistakes, and then I tell myself to take the time to make a unit/regression test, so at least the test will tell me, rather than the users of the system.

                                              One user gives quite frank feedback, to the tune of: “Didn’t you fix this before? How come it is broken again?” Which is both scalding and - maybe - also kind of fair enough.

                                          2. 1

                                            FULL MATH MODE

                                            To answer your question we should ask if we can “create a good programmer”, a witness for the proposition that you will write for your manager (I guess). Creating a witness implies a process of construction that is known in CS and math as proper of intuitionistic logic. This kind of logic is mostly “paradox free” and we can reason quite well about it. You may not be able to “create a good programmer” to prove your definition correct. It may be that the definition you can come up is “experimental” (based on experience) or even impredicative and that is fine.

                                            END MATH MODE

                                            As everything that takes practice you are a better programmer than yesterday if the feedback you are getting from someone you trust shows that you are improving. Sometimes it may take examples to show you that you are improving as we are very stubborn in nature, find someone that can provide these examples.

                                            Take also care in distinguishing between programming and software engineering, everyone can program but you would not want everyone to be on your engineering team right?

                                            1. 1

                                              It may be that the definition you can come up is “experimental” (based on experience) or even impredicative and that is fine.

                                              I appreciate that. Perhaps I should have mixed in some qualitative metrics. But one still needs a heuristic to identify the presence of a qualitative characteristic.

                                            2. 1

                                              Taste. Intuition about how to decompose logic into orthogonal functions. Data structures.

                                              1. 1

                                                I don’t know what a good programmer is, but I know I’m better when I return to a problem or category of problems I once grappled with and say “hang on, I know how to solve this”.

                                                1. 1

                                                  Primarily I think it’s about being about to deliver technical solutions that solve actual problems at the highest level of quality possible within the constraints of the project.

                                                  There is no use delivering a perfectly architected and tested solution that doesn’t solve the problem, or that is delivered too late or at too high a cost. Included in this is the ability to understand the problem domain almost as well as the subject matter experts.

                                                  If I were going for a list of traits, it’d be something like curiosity, flexibility, technical skill and focus on delivery, all roughly equally weighted.

                                                  When it comes to measuring this stuff, it’s tricky. Something I realised a while back is that I don’t have the requisite knowledge (or objectivity) to judge my skills, particularly in comparison to other devs. So this is something I largely outsource to the people I work with, using the following heuristics:

                                                  • do people listen when I speak?
                                                  • do people seem to want to work with me?
                                                  • do I get asked for my opinion on areas outside my direct work (by peers, bosses and clients)?
                                                  • am I involved in client meetings/interactions or kept “in the back room”?
                                                  • do my bosses actually want me to stay? (eg they’re proactive in making sure I’m staying, or try to convince me to stay if I’ve decided to leave)
                                                  • do I get offered (or can I negotiate) competitive pay rates?

                                                  I’m coming up on 20 years experience as a dev. Some of this (around delivery especially) I’d worked out 10 years ago, but a lot of the other stuff has been more recent.