1. 30

  2. 12

    Really great read, but I think the advice about “worry about the success of the project instead of your visibility” is a little misplaced. If you’re the CTO, sure it’s okay to be humble and let others get credit–but it’s really bad to internalize this as “I shouldn’t be visible in my work and it’s okay not to get credit if the product ships successfully!”. Waaaay too many folks get screwed by letting themselves get lost in the shuffle.

    The other thing that is a little annoying is the insistence on estimates. We should all be able to give most pessimum bounds on how long things should take, but after near a half-century of software development I think it’s pretty clear to everybody that estimating how long software projects take is a great deal harder (for whatever reason) than, say, setting up the logistics for framing a house and pouring concrete. At some level, it’s pretty obvious to everyone that most of the internally-imposed deadlines in a business are arbitrary, and it’s really easy to do a disservice to our profession if we represent our work as something that can be as trivially and reliably scheduled as baking goods or something.

    Otherwise, an excellent read.

    1. 5

      The other thing that is a little annoying is the insistence on estimates.

      Recently, at $work, we started doing collaborative estimates during our planning meetings. A collaborative estimate is where one person briefly outlines a technical task, and then everyone in the meeting simultaneously puts up a estimate, in days, using their fingers.

      Before we started doing that, estimates were just some number that one of us put into a ticket. I have to say, switching to collaborative estimates was a really enlightening process for me personally. We don’t track whether we’ve gotten more accurate or not (and therefore, I’m not actually disagreeing with you, just sharing a related anecdote), which is fine. The most interesting thing about this process is that it has become a really sharp knife for determining whether we’re all (roughly) on the same page or not. 95% of the time, our estimates are all really close, but occasionally one of us will be really different from the others. Thus far, there have been two reasons:

      1. There was a key misunderstanding in either the requirements of the task or how one ought to implement it.
      2. Some of us are more/less comfortable with certain parts of the system than others.

      So ya, I find this interesting because estimates are no longer just about giving the business folks some rough timeline, but it’s also about the process for coming to a consensus on that estimate and thereby getting a better shared understanding of the task at hand.

      Some caveats… Our planning meetings currently consist of four programmers. I don’t know whether this process scales to more people or not.

      1. 1

        everyone in the meeting simultaneously puts up a estimate, in days, using their fingers.

        Sounds like you don’t plan tasks that take longer than 10 days.

        1. 2

          We do. We either break them up or just vocally say our estimate. Most tasks are below 10 days.

    2. 5

      Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.”

      What’s wrong with saying “I told you so”? I am frequently right but overruled, so I say it a lot. My impression is that if I don’t say it, people forget that I was right but overruled. Shouldn’t reminding them of the fact help them make better decisions next time?

      1. 5

        As with many things, it depends less on what you said and more on how you said it. Most people don’t like being wrong and they like even less the person waiting to say “I told you so”. But if one puts a positive spin on it they can get a similar message with probably a better outcome. Also, logically, if person A says “do it X” and person B says “do it Y”. If X is chosen and fails that does not necessarily mean Y would have succeeded. So “I told you so” is not necessarily evidence that what one said would have resulted in a better outcome.

        1. 3

          I gave my professional opinion in my previous project, saying I don’t want to end up saying told you so if something gets overruled.

          I had to say told you so.

          But it was an environment where no one really wanted to overrule, they saw my point, but it was what you’d call an executive business call, and they did not hear the told-you-so.

          Maybe they should have, but this is the way of things.

        2. 4
          1. 6

            We really need to come up with a better way to handle reposts.

            1. [Comment removed by author]

              1. 9

                FWIW I this was my proposal.. Similar to your idea, I think.

              2. 2

                Holy cow Lobste.rs is over four years old

              3. 5

                Since the previous discussion is from 4 years ago, I don’t see the problem in having a new post/discussion here.

                1. 3

                  I don’t think there is a problem with there being a new thread/post here but it would be nice to have a list of all the prior discussions as well.

              Stories with similar links:

              1. On Being A Senior Engineer via tobym 6 years ago | 6 points | 2 comments