awesome!!!
The Tao of Programming (1987)
41–50 of 60 posts
Re: The Tao of Programming (1987)
#42I’ve stuggled with 7.1.
The shelter a massive enterprise with a sane middle-manager provides can be a beautiful place for innovation and creative freedom.
However, the older I’ve become the less corporate bs and re-orgs I’m prepared to live through.
Maybe my Tao is slipping...
Re: The Tao of Programming (1987)
#43Ha! I first came across this verse (7.2) early in my career, circa 2001 or so, and it always stuck with me. > 7.2 In the East there is a shark which is larger than all other fish. It changes into a bird whose wings are like clouds filling the sky. When this bird moves across the land, it brings a message from Corporate Headquarters. This message it drops into the midst of the programmers, like a seagull making its ma…
That feels like kind of a dangerous advice. Seems to me that means that if Google announces that they want to roll out a full cencorship in China so that they can enter the market over there, the most prominent developers will just silently continue to work on it..?
I think the context of where this came from helps explain the quote (beginning of chapter 1 of Zhuangzi):
> IN THE NORTHERN DARKNESS there is a fish and his name is K'un.1 The K'un is so huge I don't know how many thousand li he measures. He changes and becomes a bird whose name is P'eng. The back of the P'eng measures I don't know how many thousand li across and, when he rises up and flies off, his wings are like clouds all over the sky.
The big bird is so huge that it is alien to the smaller ecosystems below it. In the same way, CEOs and upper management are so "huge" (at the top of the hierarchy) that their choices seem incomprehensible from the point of e.g. a junior dev. Maybe they good or bad choices, but in any case their day-to-day choices are different from a single developer's.
> The cicada and the little dove laugh at this, saying, "When we make an effort and fly up, we can get as far as the elm or the sapanwood tree, but sometimes we don't make it and just fall down on the ground. Now how is anyone going to go ninety thousand li to the south!"
Here the small creatures make fun of the bird, not exactly understanding its world or experiences, but instead comparing the Peng's actions and natural inclinations to their own. A dove has no need to travel thousands of miles, which is a short trip for the Peng.
In the GP's comment, the novice programmer "stares in wonder at the bird" because - in the same way - his day-to-day experience is so different from the people who run Corporate Headquarters. The Master Programmer knows that CH is "doing it's thing" so to speak, or just following its own nature. Any attempt to understand the machinations and decisions of upper management from the viewpoint of a programmer simply doesn't work, so they do not bother to think about it.
Re: The Tao of Programming (1987)
#44Or get it in HTML: http://www.mit.edu/~xela/tao.html
And without the various typos, to boot.
Said typos are (for the most part) on purpose.
Re: The Tao of Programming (1987)
#45Earlier quoted context omitted.
That feels like kind of a dangerous advice. Seems to me that means that if Google announces that they want to roll out a full cencorship in China so that they can enter the market over there, the most prominent developers will just silently continue to work on it..?
I think the context of where this came from helps explain the quote (beginning of chapter 1 of Zhuangzi): > IN THE NORTHERN DARKNESS there is a fish and his name is K'un.1 The K'un is so huge I don't know how many thousand li he measures. He changes and becomes a bird whose name is P'eng. The back of the P'eng measures I don't know how many thousand li across and, when he rises up and flies off, his wings are like cl…
[deleted]
Re: The Tao of Programming (1987)
#46Ha! I first came across this verse (7.2) early in my career, circa 2001 or so, and it always stuck with me. > 7.2 In the East there is a shark which is larger than all other fish. It changes into a bird whose wings are like clouds filling the sky. When this bird moves across the land, it brings a message from Corporate Headquarters. This message it drops into the midst of the programmers, like a seagull making its ma…
That feels like kind of a dangerous advice. Seems to me that means that if Google announces that they want to roll out a full cencorship in China so that they can enter the market over there, the most prominent developers will just silently continue to work on it..?
They won't even start; theirs is the more important work.
Re: The Tao of Programming (1987)
#47Earlier quoted context omitted.
And without the various typos, to boot.
Said typos are (for the most part) on purpose. https://news.ycombinator.com/item?id=19024327
If they were deliberate, then that would imply that their existence is perfection. To recognize that the typos were accidental mistakes by the human typing them is to recognize the Tao.
Re: The Tao of Programming (1987)
#48Re: The Tao of Programming (1987)
#49. http://www.catb.org/jargon/html/story-of-mel.html .
And for the best of both worlds: http://www.catb.org/jargon/html/koans.html
The first one's my favorite:
A novice was trying to fix a broken Lisp machine by turning the power
off and on.
Knight, seeing what the student was doing, spoke sternly: “You cannot
fix a machine by just power-cycling it with no understanding of what
is going wrong.”
Knight turned the machine off and on.
The machine worked.Re: The Tao of Programming (1987)
#50I really get 4.4 for some reason: > True, sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke. I've started to debug like this. Sure, I also actively debug by adding print statements and manipulating my code. But there's something to be said about just thinking and waiting for the answer.
Interesting. Generally, what I do as the first step is immediatelly connect a remote debugger and debug the piece of code that I think is problematic (which is correct in around 90% of the times for me). Then, the answer is generally trivial. I started doing this because it felt way more time efficient than staring into the code and trying to think what goes wrong over there.
I've found that sometimes there's additional benefit to the "take a step back and think about what the code is actually doing" step, in the sense that doing so helps gain better knowledge about how the code actually works and often reveals opportunities to simplify the design (sometimes in such a way that ends up inadvertently fixing the problem, though admittedly it'll more often just introduce more bugs ;) ).