6 ms·

You're making the point that being competent at programming is in some way relative to the perspective of the asker, but that's just not the case. Competence is

by hnriot 14y ago

You're making the point that being competent at programming is in some way relative to the perspective of the asker, but that's just not the case. Competence is absolute. There are traits of a good programmer that are immediately evident to any experienced programmer.

siganakis 14y ago
If competence is absolute, then there should be some way that you can objectively measure it (otherwise how do you know its absolute?). What are the ways to objectively measure the competence of a programmer? If that was the case, then it would be much, much easier to hire and fairly compensate programmers than it is in reality.
- nadam 14y ago
  In my opinion programmer competence is not absolute, but a little bit more absolute than what ed's post suggest. :) A very rough measurement of programmer competence: The programmer is given a product specification. He creates the program in T time using S size of code. 1/(T * S * S) is a very good approximation of how good the developer is. (small size is more important than the taken time, that's why I've taken S square. We can tweak the formula of course. Maybe 1/(T * S * S * S) is even better in some cases.) TL;DR: the most common thing amongst good programmers in my opinion is that they are masters of the DRY principle, but they do not overabstract; in essence they write smaller code to problems (usually even faster) than not so good programmers. The bigger the system is, the more and more architectural/design skill is needed to keep the code base small.
  - EwanToo 14y ago
    I have to disagree sorry. If a piece of software is needed by the date of a major launch, and a programmer doesn't ship, all because he wants to reduce the amount of code involved, then he's an awful programmer as far as the business is concerned. Running over time can cost millions of $ of investment in other areas of the business: - Press organised - Advertising purchased - 1000s of hours of staff training underway - Suppliers informed of increased demand / new supplies purchased - Customers told to expect delivery by date Any one of these areas can cost 10x or more of the cost of developing the code. If you're not writing code which would be affected by that kind of criteria then cool, go for whatever metric you want to define. Time taken is almost always the number one criteria of any business requirement, or to put it another way, small size of code means almost nothing to anyone except the original developers.
    - nadam 14y ago
      I said that it is a rough estimate, and we can tweak the formula. My opinion is that programmer competence is not absolute, but also not terribly relative. I mean John Carmack is kind of absolutely a better developer than let's say junior average Joe. >small size of code means almost nothing to anyone except the original developers. No. Small size reflects the quality of the code: It reduces the time of future developments (non DRY code keeps growing agreessively and becomes even more non DRY and very time consuming to develop new features into). It is an investment in the future. Now you are right: sometimes it is not worth it to invest into the future, because maybe the code will be thrown away because it will turn out that the startup/product is not viable. Somtimes you know that product has a stable growing market and you will have to develop tons of features into it in the future. Then investing in the future is very important.
      - randomdata 14y ago
        I think I understand where you are coming from, but DRY tends to, at least initially, increase the size of codebases and development time. The programmer who hacks something together that works now, but is a nightmare to maintain later will score better in your formula. As you say, it is an investment in the future, which implies that you are giving something up now for something more later.
      - mercurial 14y ago
        > Small size reflects the quality of the code. Not always. Case in point: a week or two ago, I refactored some C# code. It was an installer generator, which was coded entirely in the controller. Yeh who want to add unit tests, abandon all hopes. So the code is now split into different pieces, according to responsibilities, with dependency injection, and I/O in its own layer. The result, in terms of lines of code, is a net increase. But according to your metric, I have decreased the quality of the code. I agree that generally speaking, less code is better than more code, but more code can mean reusable, more readable code.
        nadam 14y ago
        Ok, I accept this. I have experience in refactoring really bad code. Refactoring these always led to smaller code: yes sometimes some of the refactorings increased the code size, but there was enough redundancy because of the bad (or no) abstractions and design mistakes in the original code which compenstated for it. The bigger the system is, the more probable it is that you can make it better while decreasing the code size. Above 10.000 lines a bad code usually is not DRY enough so much, that it is very easy to decrease its size while increasing its modularity. Yes, code size is not a perfect indicator of quality. But reducing code size is a very central part of my design philosophy. When you very conciously refactor to smaller code size (using good design patterns) the code and the abstractions in your head can become incredibily clear. For example I write a software which deals a lot with rectangles. In the beginning my rectangles had four properties: left, right, top, bottom. After a while I've found out that my code gets more and more redundant; I have to find an abstraction which relies on the symmetries in the problems. So now my rectangle has this interface to get and set the 4 sides: void setSide(bool vert, bool isEnd, int value) int getSide(bool vert, bool isEnd) Not only my code size reduced dramatically, but because of this new abstraction I've understood the problem much better!
- kd0amg 14y ago
  I don't see why an objective ordering of programmers by competence would have to be a total ordering.
nateberkopec 14y ago
That's just like, your opinion, man.
lifeisstillgood 14y ago
Replace the word programmer with writer. What is absolute competence in writing novels? Writing magazine articles. Publishers want good writers that sell lots of books, young writers want good writers that critique their books. There is a base level of competence, but even that is often local culture
- Draiken 14y ago
  Even tho IMHO coding is an art, like writing, you cannot compare those two in this case. You write code that will almost for sure, live on for 10+ years and will be changed by a lot of people. Good code will be maintainable and easy to extend/change. Bad code is just... every programmer's nightmare. Bad code will still be bad even if it made the product go live, and good code will still be good even if it took a few more days/weeks to produce it. The balance between quality and speed is completely product dependent. But sooner or later bad/fast code will claim it's price.
  - rizzom5000 14y ago
    This is spot on. And to go further, where the OP argued that product quality and development time are mutually exclusive; I submit that they are not. In the right hands, good code can be written quickly and efficiently, just as good novels can be written as quickly as bad ones are, or good music can be written as quickly as bad music is.
    - flyinRyan 14y ago
      But most companies aren't going to have "the right hands". Many wouldn't want them even if they could get them because they want programmers they can replace easily.
  - beeneto 14y ago
    I agree with your parent, and think you're trying to read it in an over-specific way, it's like saying "You can't compare writing and programming, because writing doesn't have comments." The parent was making the point that, like writing, good and bad coding style is entirely subjective - necessarily so because many parts of it are simply conventional. There are some specific constructions in programming that can be shown to be better than others through complexity theory, but even the guidelines we have for these aren't global optimums.
cobrausn 14y ago
Then why is there such variety of style, brevity, documentation, and technique among good, experienced programmers?
- Draiken 14y ago
  Even tho it's not a tangible thing, it still exists. You can't measure it with a ruler or some lines of code formulae, but good programmers are easily recognizable by other good/experienced programmers.
ww520 14y ago
Competence is in the eyes of the beholder. If I need someone to crank out a report by afternoon which will never be used again and he was able to do it, he's very competent. If I need someone to crank out a car control system and he took one year to do it but has very low defects afterward, he's very competent.
john_flintstone 14y ago
>There are traits of a good programmer that are immediately evident to any experienced programmer. Replace the word 'programmer' with 'coder' and you might have a point. Whenever I hear the word 'coder', all I can think of is shelf-stacker. A coder writes lines of code, a programmer builds products or 'things'. All the rules and standards regarding code belong to coders - they have nothing to do with finished, shipped, or successful products. But what do I know? I've only been building products for 13 years. And I'm drunk.

by hnriot 14y ago

siganakis 14y ago

If competence is absolute, then there should be some way that you can objectively measure it (otherwise how do you know its absolute?). What are the ways to objectively measure the competence of a programmer? If that was the case, then it would be much, much easier to hire and fairly compensate programmers than it is in reality.

nadam 14y ago
In my opinion programmer competence is not absolute, but a little bit more absolute than what ed's post suggest. :) A very rough measurement of programmer competence: The programmer is given a product specification. He creates the program in T time using S size of code. 1/(T * S * S) is a very good approximation of how good the developer is. (small size is more important than the taken time, that's why I've taken S square. We can tweak the formula of course. Maybe 1/(T * S * S * S) is even better in some cases.) TL;DR: the most common thing amongst good programmers in my opinion is that they are masters of the DRY principle, but they do not overabstract; in essence they write smaller code to problems (usually even faster) than not so good programmers. The bigger the system is, the more and more architectural/design skill is needed to keep the code base small.
- EwanToo 14y ago
  I have to disagree sorry. If a piece of software is needed by the date of a major launch, and a programmer doesn't ship, all because he wants to reduce the amount of code involved, then he's an awful programmer as far as the business is concerned. Running over time can cost millions of $ of investment in other areas of the business: - Press organised - Advertising purchased - 1000s of hours of staff training underway - Suppliers informed of increased demand / new supplies purchased - Customers told to expect delivery by date Any one of these areas can cost 10x or more of the cost of developing the code. If you're not writing code which would be affected by that kind of criteria then cool, go for whatever metric you want to define. Time taken is almost always the number one criteria of any business requirement, or to put it another way, small size of code means almost nothing to anyone except the original developers.
  - nadam 14y ago
    I said that it is a rough estimate, and we can tweak the formula. My opinion is that programmer competence is not absolute, but also not terribly relative. I mean John Carmack is kind of absolutely a better developer than let's say junior average Joe. >small size of code means almost nothing to anyone except the original developers. No. Small size reflects the quality of the code: It reduces the time of future developments (non DRY code keeps growing agreessively and becomes even more non DRY and very time consuming to develop new features into). It is an investment in the future. Now you are right: sometimes it is not worth it to invest into the future, because maybe the code will be thrown away because it will turn out that the startup/product is not viable. Somtimes you know that product has a stable growing market and you will have to develop tons of features into it in the future. Then investing in the future is very important.
    - randomdata 14y ago
      I think I understand where you are coming from, but DRY tends to, at least initially, increase the size of codebases and development time. The programmer who hacks something together that works now, but is a nightmare to maintain later will score better in your formula. As you say, it is an investment in the future, which implies that you are giving something up now for something more later.
    - mercurial 14y ago
      > Small size reflects the quality of the code. Not always. Case in point: a week or two ago, I refactored some C# code. It was an installer generator, which was coded entirely in the controller. Yeh who want to add unit tests, abandon all hopes. So the code is now split into different pieces, according to responsibilities, with dependency injection, and I/O in its own layer. The result, in terms of lines of code, is a net increase. But according to your metric, I have decreased the quality of the code. I agree that generally speaking, less code is better than more code, but more code can mean reusable, more readable code.
      - nadam 14y ago
        Ok, I accept this. I have experience in refactoring really bad code. Refactoring these always led to smaller code: yes sometimes some of the refactorings increased the code size, but there was enough redundancy because of the bad (or no) abstractions and design mistakes in the original code which compenstated for it. The bigger the system is, the more probable it is that you can make it better while decreasing the code size. Above 10.000 lines a bad code usually is not DRY enough so much, that it is very easy to decrease its size while increasing its modularity. Yes, code size is not a perfect indicator of quality. But reducing code size is a very central part of my design philosophy. When you very conciously refactor to smaller code size (using good design patterns) the code and the abstractions in your head can become incredibily clear. For example I write a software which deals a lot with rectangles. In the beginning my rectangles had four properties: left, right, top, bottom. After a while I've found out that my code gets more and more redundant; I have to find an abstraction which relies on the symmetries in the problems. So now my rectangle has this interface to get and set the 4 sides: void setSide(bool vert, bool isEnd, int value) int getSide(bool vert, bool isEnd) Not only my code size reduced dramatically, but because of this new abstraction I've understood the problem much better!
kd0amg 14y ago
I don't see why an objective ordering of programmers by competence would have to be a total ordering.

nateberkopec 14y ago

That's just like, your opinion, man.

lifeisstillgood 14y ago

Replace the word programmer with writer. What is absolute competence in writing novels? Writing magazine articles. Publishers want good writers that sell lots of books, young writers want good writers that critique their books. There is a base level of competence, but even that is often local culture

Draiken 14y ago
Even tho IMHO coding is an art, like writing, you cannot compare those two in this case. You write code that will almost for sure, live on for 10+ years and will be changed by a lot of people. Good code will be maintainable and easy to extend/change. Bad code is just... every programmer's nightmare. Bad code will still be bad even if it made the product go live, and good code will still be good even if it took a few more days/weeks to produce it. The balance between quality and speed is completely product dependent. But sooner or later bad/fast code will claim it's price.
- rizzom5000 14y ago
  This is spot on. And to go further, where the OP argued that product quality and development time are mutually exclusive; I submit that they are not. In the right hands, good code can be written quickly and efficiently, just as good novels can be written as quickly as bad ones are, or good music can be written as quickly as bad music is.
  - flyinRyan 14y ago
    But most companies aren't going to have "the right hands". Many wouldn't want them even if they could get them because they want programmers they can replace easily.
- beeneto 14y ago
  I agree with your parent, and think you're trying to read it in an over-specific way, it's like saying "You can't compare writing and programming, because writing doesn't have comments." The parent was making the point that, like writing, good and bad coding style is entirely subjective - necessarily so because many parts of it are simply conventional. There are some specific constructions in programming that can be shown to be better than others through complexity theory, but even the guidelines we have for these aren't global optimums.

cobrausn 14y ago

Then why is there such variety of style, brevity, documentation, and technique among good, experienced programmers?

Draiken 14y ago
Even tho it's not a tangible thing, it still exists. You can't measure it with a ruler or some lines of code formulae, but good programmers are easily recognizable by other good/experienced programmers.

ww520 14y ago

Competence is in the eyes of the beholder. If I need someone to crank out a report by afternoon which will never be used again and he was able to do it, he's very competent. If I need someone to crank out a car control system and he took one year to do it but has very low defects afterward, he's very competent.

john_flintstone 14y ago

>There are traits of a good programmer that are immediately evident to any experienced programmer. Replace the word 'programmer' with 'coder' and you might have a point. Whenever I hear the word 'coder', all I can think of is shelf-stacker. A coder writes lines of code, a programmer builds products or 'things'. All the rules and standards regarding code belong to coders - they have nothing to do with finished, shipped, or successful products. But what do I know? I've only been building products for 13 years. And I'm drunk.