5 ms·

If your doing similar work over and over again as a programmer, your not doing a good job.

by UK-AL 10y ago

jacques_chester 10y ago
Now suppose I substituted a different profession here: > If you're doing similar work over and over again as a civil engineer, you're not doing a good job. Hmm. Not sure I feel comfortable with that. > If you're doing similar work over and over again as a small business accountant, you're not doing a good job. Actually, I'd rather prefer you to stick to the basics, please, no need for discussions of complex derivatives of treasury stock. > If you're doing similar work over and over again as an orthopaedic surgeon, you're not doing a good job. Thanks, but I think I'll get a second opinion.
- taneq 10y ago
  The only one of those analogies that even remotely holds is the civil engineering one, and even then, it depends what the engineer (and the developer) are doing. If you're grunting out bridge foundations or pages of A CRUD app then sure, your job will be repetitive. If you're working on AGI or designing the Burj Khalifa then you'll be facing some unique challenges.
  - jacques_chester 10y ago
    Sure. I expect those engineers still gave estimates and were chosen because they had the most relevant experience and expertise.
    - UK-AL 10y ago
      And they probably got the estimates wrong for those unique projects.
      - jacques_chester 10y ago
        So to revisit an earlier question: do you think they should have not estimated? That all other professions should refuse to render estimates because -- gasp -- they might be wrong?
        UK-AL 10y ago
        I'm not saying you should refuse to estimate, I'm saying giving an accurate estimate is verging on the impossible. You can attempt to do it, but people shouldn't expect it to be accurate. I'm just saying they are probably way out, and probably arn't that useful compared to other methods of building software. A lot businesses people who get this, then ask why bother if they are going to be really inaccurate? Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. Or even better do the implement and feedback cycle continuously. If you are not happy on the progress of a feature, cancel it. Because you doing things in small intervals, and then adjusting. It won't go wildly of the tracks, before realising you have to adjust or cancel it.
        jacques_chester 10y ago
        > Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. I absolutely agree with you. I think we're closing on the key difference, which is the scope of the estimation. I am accustomed to estimating the smallest self-contained unit of user-facing value. I'm used to doing it weekly. I'm used to being in a room with my fellow engineers to do a simple points-based estimate of complexity, with projected dates derived from the velocity of the past 3 weeks. I am used to PMs who understand that sometimes we hit iceberg stories, but that most of the time, the projections are good into the next few months. What I don't have to do is build a magical estimate of the next three years. If I was asked, I would try to based on historical data and research, but the bands would be extremely wide. Thinking about the analogy that we often make back to construction, the problem is that classical project management is essentially an estimate of an integral. There is a discrete endpoint, and we can estimate (and re-estimate) leading up to that end point. Funds are committed in large chunks and the cheque-signers need high confidence to proceed. But software is never finished, only abandoned. Estimation has to be differential and constantly updated. If the software is developed to be releasable at all times, commitment can be incremental and early abandonment due to negative feedback is advantageous. I'm not saying anything new here. But I understand better where you were coming from.
- UK-AL 10y ago
  Civil engineering and software engineering are fundamentally different because software is digital. You can't download the building package. You actually have to build the building again. If it's the same building I would expect them reuse the same blueprints. So that holds true. Where as in software it's quite easy and desirable to reuse software. Which is why you should not be rewriting the same thing over and over. As a result, the problems you face are unique. Your not just stamping out the same building again and again.
  - jacques_chester 10y ago
    > You actually have to build the building again. You also have to factor engineering time into the plan. If you read Industrial Megaprojects, the author shows that projects which don't do a bit of upfront estimating and research tend to go off the rails on a scale that software struggles to match.
    - learc83 10y ago
      Some upfront planning is required but, there is an overall problem with comparing software to building construction. If you make a blueprint and give it to 2 construction companies to build the building, you'll end up with 2 very similar buildings. If you give a software spec to 2 separate software companies you'll get 2 completely different programs. You can't create a blueprint/spec that is sufficiently detailed so that 2 different companies/teams will build essential the same software. A blueprint/spec that detailed would be the code itself. The closest analog to software would be designing processes, or maybe designing a factory or assembly line. And the analog to the code in that situation would be the factory or assembly line itself.
      - timdev2 10y ago
        Software shouldn't be compared to building construction, more appropriately compared to building design. Building construction is analogous to software deployment: a largely solved problem that is predictable.
      - 10y ago
xapata 10y ago
That's odd, both you and the other commenter made the same spelling mistake.
stevewilhelm 10y ago
For example, look at the user experiences of LinkedIn, Facebook, and Twitter? Massive amount of very similar work being done. How much shared code?
- UK-AL 10y ago
  Err, not really. Completely different workflows. Solving different problems. For different types of people. They have probably spent a lot of time and money paying UX guys trying to optimise for their unique situation. I would assume they reusing either in house or 3rd parry libraries in their code, but that stuff isn't where estimates go wrong. It's usually experimentation of trying to get UI right for the user. I mean could tell you how long it would take to make a html page, if you tell me what tags and elements you want in it. It's a whole different ball game, if you ask for a estimate of creating a complete feature because it will probably involve a little trial and error and feeback from multiple people. The first few stabs at it won't be quite right etc
ewjordan 10y ago
Whatever you're doing, if you're honest with yourself, are you really doing something new and interesting every day/week/month, or are you just digging deeper into what you already know? I've found that without straight up hopping jobs, it's almost impossible to do truly new things rather than settle into a role where you're too valuable to not exploit for the same old crap you've done before. I'd still call that doing a good job - businesses need people that can pump out good but similar work. People that always need something new once they master the old thing can be liabilities, depending on the context.
- UK-AL 10y ago
  I dont think most people have issues with estimation of day to day stuff, like changing some text on screen. They have issues with, let's integrate x product with our product.

If your doing similar work over and over again as a programmer, your not doing a good job.

by UK-AL 10y ago

If your doing similar work over and over again as a programmer, your not doing a good job.

Now suppose I substituted a different profession here: > If you're doing similar work over and over again as a civil engineer, you're not doing a good job. Hmm. Not sure I feel comfortable with that. > If you're doing similar work over and over again as a small business accountant, you're not doing a good job. Actually, I'd rather prefer you to stick to the basics, please, no need for discussions of complex derivatives of treasury stock. > If you're doing similar work over and over again as an orthopaedic surgeon, you're not doing a good job. Thanks, but I think I'll get a second opinion.

taneq 10y ago
The only one of those analogies that even remotely holds is the civil engineering one, and even then, it depends what the engineer (and the developer) are doing. If you're grunting out bridge foundations or pages of A CRUD app then sure, your job will be repetitive. If you're working on AGI or designing the Burj Khalifa then you'll be facing some unique challenges.
- jacques_chester 10y ago
  Sure. I expect those engineers still gave estimates and were chosen because they had the most relevant experience and expertise.
  - UK-AL 10y ago
    And they probably got the estimates wrong for those unique projects.
    - jacques_chester 10y ago
      So to revisit an earlier question: do you think they should have not estimated? That all other professions should refuse to render estimates because -- gasp -- they might be wrong?
      - UK-AL 10y ago
        I'm not saying you should refuse to estimate, I'm saying giving an accurate estimate is verging on the impossible. You can attempt to do it, but people shouldn't expect it to be accurate. I'm just saying they are probably way out, and probably arn't that useful compared to other methods of building software. A lot businesses people who get this, then ask why bother if they are going to be really inaccurate? Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. Or even better do the implement and feedback cycle continuously. If you are not happy on the progress of a feature, cancel it. Because you doing things in small intervals, and then adjusting. It won't go wildly of the tracks, before realising you have to adjust or cancel it.
        jacques_chester 10y ago
        > Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. I absolutely agree with you. I think we're closing on the key difference, which is the scope of the estimation. I am accustomed to estimating the smallest self-contained unit of user-facing value. I'm used to doing it weekly. I'm used to being in a room with my fellow engineers to do a simple points-based estimate of complexity, with projected dates derived from the velocity of the past 3 weeks. I am used to PMs who understand that sometimes we hit iceberg stories, but that most of the time, the projections are good into the next few months. What I don't have to do is build a magical estimate of the next three years. If I was asked, I would try to based on historical data and research, but the bands would be extremely wide. Thinking about the analogy that we often make back to construction, the problem is that classical project management is essentially an estimate of an integral. There is a discrete endpoint, and we can estimate (and re-estimate) leading up to that end point. Funds are committed in large chunks and the cheque-signers need high confidence to proceed. But software is never finished, only abandoned. Estimation has to be differential and constantly updated. If the software is developed to be releasable at all times, commitment can be incremental and early abandonment due to negative feedback is advantageous. I'm not saying anything new here. But I understand better where you were coming from.
UK-AL 10y ago
Civil engineering and software engineering are fundamentally different because software is digital. You can't download the building package. You actually have to build the building again. If it's the same building I would expect them reuse the same blueprints. So that holds true. Where as in software it's quite easy and desirable to reuse software. Which is why you should not be rewriting the same thing over and over. As a result, the problems you face are unique. Your not just stamping out the same building again and again.
- jacques_chester 10y ago
  > You actually have to build the building again. You also have to factor engineering time into the plan. If you read Industrial Megaprojects, the author shows that projects which don't do a bit of upfront estimating and research tend to go off the rails on a scale that software struggles to match.
  - learc83 10y ago
    Some upfront planning is required but, there is an overall problem with comparing software to building construction. If you make a blueprint and give it to 2 construction companies to build the building, you'll end up with 2 very similar buildings. If you give a software spec to 2 separate software companies you'll get 2 completely different programs. You can't create a blueprint/spec that is sufficiently detailed so that 2 different companies/teams will build essential the same software. A blueprint/spec that detailed would be the code itself. The closest analog to software would be designing processes, or maybe designing a factory or assembly line. And the analog to the code in that situation would be the factory or assembly line itself.
    - timdev2 10y ago
      Software shouldn't be compared to building construction, more appropriately compared to building design. Building construction is analogous to software deployment: a largely solved problem that is predictable.
    - 10y ago

xapata 10y ago

That's odd, both you and the other commenter made the same spelling mistake.

stevewilhelm 10y ago

For example, look at the user experiences of LinkedIn, Facebook, and Twitter? Massive amount of very similar work being done. How much shared code?

UK-AL 10y ago
Err, not really. Completely different workflows. Solving different problems. For different types of people. They have probably spent a lot of time and money paying UX guys trying to optimise for their unique situation. I would assume they reusing either in house or 3rd parry libraries in their code, but that stuff isn't where estimates go wrong. It's usually experimentation of trying to get UI right for the user. I mean could tell you how long it would take to make a html page, if you tell me what tags and elements you want in it. It's a whole different ball game, if you ask for a estimate of creating a complete feature because it will probably involve a little trial and error and feeback from multiple people. The first few stabs at it won't be quite right etc

ewjordan 10y ago

Whatever you're doing, if you're honest with yourself, are you really doing something new and interesting every day/week/month, or are you just digging deeper into what you already know? I've found that without straight up hopping jobs, it's almost impossible to do truly new things rather than settle into a role where you're too valuable to not exploit for the same old crap you've done before. I'd still call that doing a good job - businesses need people that can pump out good but similar work. People that always need something new once they master the old thing can be liabilities, depending on the context.

UK-AL 10y ago
I dont think most people have issues with estimation of day to day stuff, like changing some text on screen. They have issues with, let's integrate x product with our product.