5 ms·

Haha, what a great video. To some extent he's onto something. Sometimes you are in this zone when everything will work if you just do this one quick little hac

Haha, what a great video. To some extent he's onto something. Sometimes you are in this zone when everything will work if you just do this one quick little hack, and then the hack ends up not getting replaced with a proper solution, and in the end you end up with a harddrive right next to a speaker >.<

btschaegg 9y ago
There actually seem to be people whose default mode of operation seems to lie entirely in that zone though. I'm pretty sure everyone arrives at a similar conclusion if they realise that attempts to fix a certain person's code always end in a express trip to the 6th stage of debugging [1]... [1]: http://plasmasturm.org/log/6debug/ http://plasmasturm.org/log/6debug/
- jzwinck 9y ago
  Definitely. And that "quick hack by default" person will often end up being the favorite of management because they get so many things "done." So it's important to figure out what kind of manager you have, and try not to be the slow guy on a team full of quick-hack people. You won't look good and nobody will be happy.
  - chii 9y ago
    > the slow guy on a team full of quick-hack people isn't that called 'cultural fit'?
    - deleted 9y ago
      [deleted]
    - lostlogin 9y ago
      That assessment is best made by the People and Culture team, not you.
  - richmarr 9y ago
    > So it's important to figure out what kind of manager you have, and try not to be the slow guy on a team full of quick-hack people. You won't look good and nobody will be happy. I'd also add that it's important to understand the context in which your team is working. If I were managing this hypothetical team in a pre-product-market-fit startup I could see the 'slow' person as a potentially greater risk than the others. Not because of speed per se, but because he may be investing too much time in directions that don't help the company learn about their market, and he may be building grand architectural visions that are hard to delete when we realise the product is going in a direction that person didn't anticipate. On the other hand if I were managing the same hypothetical team in a highly defined context, for example a mature product or an open source library with a large userbase, the 'quick hack' people would need to change their ways. Obviously this analysis is incredibly shallow and would need a ton of conversation and observation; I'm just making the point that different phases of product market fit require very different approaches & it's worth being aware.
    - benjiweber 9y ago
      Kent Beck talks about this need for context awareness a lot in his 3x (Explore, Expand, Extract). https://www.facebook.com/notes/kent-beck/the-product-development-triathlon/1215075478525314/ https://www.facebook.com/notes/kent-beck/the-product-develop... https://www.facebook.com/notes/kent-beck/comparing-explore-expand-and-extract-topics-in-3x/1241983035834558/ https://www.facebook.com/notes/kent-beck/comparing-explore-e...
      - richmarr 9y ago
        Beck could have saved time by following tech strategy legend Simon Wardley ;) http://blog.gardeviance.org/2012/06/pioneers-settlers-and-town-planners.html http://blog.gardeviance.org/2012/06/pioneers-settlers-and-to...
        richmarr 9y ago
        Also note that Wardley was pushing past PaaS into serverless and per-function billing back in 2005 with Zimki... lightyears ahead of AWS, until it was designated 'non core' by Canon.
- whipoodle 9y ago
  We do ourselves a kindness when we skip to step 4.
  - khedoros1 9y ago
    Except step 5 needs two variants, then: "Oh, I see why it happens" and "Oh, I see that it doesn't, so let's find a way to communicate better with the user".
    - whipoodle 9y ago
      There are a lot of ways that things can go, but starting out with the disposition that either the bug report is wrong or the other machine is somehow made of worse silicon than our own, is rarely helpful.
      - khedoros1 9y ago
        Agreed. The direction I was going is this: If there's a bug report, then there is a problem. The problem might be the bug that was reported, or it might be that you surprised the user/tester in a way that they perceived as being a bug. Obviously something needs to be improved, even if it's just communication with the user, rather than changing the behavior of the program.
      - btschaegg 9y ago
        > starting out with the disposition [...] is rarely helpful. Of course, I fully agree. And yet I have witnessed enough developers stating the first stage almost verbatim as a response to a complaint that I grew really quite fond of the link. It is, actually, quite useful in that regard - it allows you to point out the absurdity of the statement in a humoristic way. That, and it wouldn't be a good parody of the Kübler-Ross model if it didn't start with Denial :-)
      - RugnirViking 9y ago
        However, investigating every bug report while a worthy cause is something not practical for most shops, especially when the underlying cause for these 'only sometimes and only on my machine' issues is some bizarre bug in some underlying dependency or even windows. Now fixing these issues can often lead to really lean mean software that flies, but if you're in the all too typical situation of overambitious deadlines then you're already in triage mode and long hard fixes are just about the bottom of the pile

btschaegg 9y ago

There actually seem to be people whose default mode of operation seems to lie entirely in that zone though. I'm pretty sure everyone arrives at a similar conclusion if they realise that attempts to fix a certain person's code always end in a express trip to the 6th stage of debugging [1]... [1]: http://plasmasturm.org/log/6debug/ http://plasmasturm.org/log/6debug/

jzwinck 9y ago
Definitely. And that "quick hack by default" person will often end up being the favorite of management because they get so many things "done." So it's important to figure out what kind of manager you have, and try not to be the slow guy on a team full of quick-hack people. You won't look good and nobody will be happy.
- chii 9y ago
  > the slow guy on a team full of quick-hack people isn't that called 'cultural fit'?
  - deleted 9y ago
    [deleted]
  - lostlogin 9y ago
    That assessment is best made by the People and Culture team, not you.
- richmarr 9y ago
  > So it's important to figure out what kind of manager you have, and try not to be the slow guy on a team full of quick-hack people. You won't look good and nobody will be happy. I'd also add that it's important to understand the context in which your team is working. If I were managing this hypothetical team in a pre-product-market-fit startup I could see the 'slow' person as a potentially greater risk than the others. Not because of speed per se, but because he may be investing too much time in directions that don't help the company learn about their market, and he may be building grand architectural visions that are hard to delete when we realise the product is going in a direction that person didn't anticipate. On the other hand if I were managing the same hypothetical team in a highly defined context, for example a mature product or an open source library with a large userbase, the 'quick hack' people would need to change their ways. Obviously this analysis is incredibly shallow and would need a ton of conversation and observation; I'm just making the point that different phases of product market fit require very different approaches & it's worth being aware.
  - benjiweber 9y ago
    Kent Beck talks about this need for context awareness a lot in his 3x (Explore, Expand, Extract). https://www.facebook.com/notes/kent-beck/the-product-development-triathlon/1215075478525314/ https://www.facebook.com/notes/kent-beck/the-product-develop... https://www.facebook.com/notes/kent-beck/comparing-explore-expand-and-extract-topics-in-3x/1241983035834558/ https://www.facebook.com/notes/kent-beck/comparing-explore-e...
    - richmarr 9y ago
      Beck could have saved time by following tech strategy legend Simon Wardley ;) http://blog.gardeviance.org/2012/06/pioneers-settlers-and-town-planners.html http://blog.gardeviance.org/2012/06/pioneers-settlers-and-to...
      - richmarr 9y ago
        Also note that Wardley was pushing past PaaS into serverless and per-function billing back in 2005 with Zimki... lightyears ahead of AWS, until it was designated 'non core' by Canon.
whipoodle 9y ago
We do ourselves a kindness when we skip to step 4.
- khedoros1 9y ago
  Except step 5 needs two variants, then: "Oh, I see why it happens" and "Oh, I see that it doesn't, so let's find a way to communicate better with the user".
  - whipoodle 9y ago
    There are a lot of ways that things can go, but starting out with the disposition that either the bug report is wrong or the other machine is somehow made of worse silicon than our own, is rarely helpful.
    - khedoros1 9y ago
      Agreed. The direction I was going is this: If there's a bug report, then there is a problem. The problem might be the bug that was reported, or it might be that you surprised the user/tester in a way that they perceived as being a bug. Obviously something needs to be improved, even if it's just communication with the user, rather than changing the behavior of the program.
    - btschaegg 9y ago
      > starting out with the disposition [...] is rarely helpful. Of course, I fully agree. And yet I have witnessed enough developers stating the first stage almost verbatim as a response to a complaint that I grew really quite fond of the link. It is, actually, quite useful in that regard - it allows you to point out the absurdity of the statement in a humoristic way. That, and it wouldn't be a good parody of the Kübler-Ross model if it didn't start with Denial :-)
    - RugnirViking 9y ago
      However, investigating every bug report while a worthy cause is something not practical for most shops, especially when the underlying cause for these 'only sometimes and only on my machine' issues is some bizarre bug in some underlying dependency or even windows. Now fixing these issues can often lead to really lean mean software that flies, but if you're in the all too typical situation of overambitious deadlines then you're already in triage mode and long hard fixes are just about the bottom of the pile