1. 37
  1.  

  2. 7

    The next level after negativity is the zen attitude of ratcheted progress through interactions with a computer. Get there faster by skipping the negativity step.

    This article is pretty nonsensical because the snark in programming communities doesn’t actually help matters much. Most programmer negativity is the age old externalization of internal frustrations onto those that can’t do anything about it. In this case the externalization is through the author(s) of legacy code. He seems to eventually get to that point but spends way too much time on therapy for himself.

    1. 6

      Exactly, negative emotion are a waste of time as they prevent clear thinking. It’s difficult to get there and takes experience but once you’re there it’s great.

      One big source of negativity are unreasonable deadlines. They can create a lot of unnecessary anxiety which is then directed towards the source code, whatever is preventing to reach the deadline. The important part of time estimations is that they need to be updated every time new data is being uncovered. This largely depends on the workplace if this is something acceptable or not. It’s totally unacceptable to expect somebody to predict the future and know in advance all the hurdles they are going to uncover.

      Another one is debugging. With the coder hat on, it can be difficult to switch to debugging mode. The feature is done but there is an obscure bug cropping up and hard to debug. Instead of raging against the bug, one strategy I really like is to apply a simple binary search algorithm on the source of the bug because it doesn’t take too much cognitive power. Establish the boundaries of the search space, split the problem in two and see which half fails. Take the failing side and repeat. This works surprisingly well in a lot of domains.