1. 30
  1.  

  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.

          1. 1

            Pah, ten fingers is enough to count to 1023, if you do it in binary.

            1. 1

              Fair enough. And, after a decade of typing on a keyboard, you can actually bend individual fingers without affecting others. And 1023 is four years worth of work days (five days a week, no holidays).

      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. 6

          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.

            1. 1

              See, I’m not sure you’re actually helping them make better decisions when you do that. All you’re teaching them is that they should let you make the decision the next time. Then comes a day when you’re not around, and they’re no better than they were in the first place.

              Instead of saying “I told you so”, it would be much more productive to approach it from a perspective of, “This was interesting. I could foresee something they didn’t; that could indicate a fundamental misunderstanding on their part, or maybe they thought of something I didn’t, and they just turned out unlucky, or there’s a strong emotional component to this that I failed to recognise and address in time. Let’s learn something from this together!”

              Remember that if you never managed to convince the one who made the decision, and it turned out you were right, then both of you share a part in the failure – you for not communicating your correctness enough, and them for not seeing you were correct. It’s something you work on together, not something you lecture them in.

            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