This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: From Proudly Serving My Corporate Masters:
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
I once had a dream where I had an approved checkin I was trying to make to the NT source control server, and I kept running around to different offices trying to do it, but at each office there was some reason why I couldn't do it -- one machine was broken, another was being used, the third couldn't connect to the source control server, and so on. What is amazing is that I had this classic anxiety dream not about finding or fixing some particularly heinous bug, but about checking in the fix -- a sad testimony to the counterproductiveness of the way the process was constituted. NT management was essentially saying, "Yes, we are paying you a high-five-or-low-six-figure salary to write code for us, but we don't trust you to decide if your code should be checked in or not." This led to a typical case of lack of trust causing loss of confidence, with the result that many NT developers lacked the experience to make good decisions about whether fixes should be checked in. The environment became one of developers against management, with developers trying to sneak in as much as they could and management trying to keep things out. The attitude from above was, "If you don't like the rules, don't write code with bugs in it, "which was an absurd simplification of the debugging cycle. All we developers wanted was the benefit of the doubt, to be considered innocent of build-breaking until proven guilty.
I'm about 2/3 through Adam Barr's memoir of his years as a programmer at Microsoft. There are many interesting passages like the above. Mostly, it's just fun to read about the work-life of a programmer, esp. from the early 90's before the Internet craze hit. For example, there's much discusion about the early days of the Video Toaster and the Play spin-off.