Hammock Driven Development - Rich Hickey

I was searching for exactly the same stuff yesterday, and I found this: [link] I usually keep notebooks, but I am ever more convinced of using one because of Rich hickey's talk: [this video] and we have a better chance of remembering something if we write than type. [link] . I have previously read that people like Martin Gardner had an awesome system of keeping notes. I would love to know more about your tips. How do keep your notes? How do you organize stuff, while retaining the freedom to doodle. How do you find stuff again(which is the killer feature for typed notes). Would love to learn from the masters - do you have any books to recommend?

The feeling you're describing is called anxiety. Some anxiety is normal, but constant anxiety that interferes with your life is a problem. I think it'd be worth trying that label on: call it anxiety, and ask "how do I reduce my anxiety?". About 1 in 4 people experience an anxiety disorder at some point in their lives, so there's a lot of research and good approaches out there. One thing that stands out to me is that you've made some pretty big and scary claims without a lot of evidence to back them up. Are you actually not a good developer? Are smart people really "capturing" the opportunity (ie there is less opportunity over time)? Do people who aren't working all the time fall behind and never make anything of significance? If so, prove it! Figure out what evidence you would need to definitively answer these questions, and research or experiment until you have that evidence. Anxious thoughts are like dreams: they seem perfectly reasonable in your head, but when you try to bring them into the real world they fall apart. As far as evidence goes, I'd point you in the direction of two of my favourite Richards. The one who did Clojure: [this video] and the one who got a Nobel for Quantum Electrodynamics: [link]

Nobody's stupid because they're not sure about something. It's totally cool to ask for help or opinions when you're thinking through a hard problem. To answer your question you should understand what creativity and practicality mean in your context. I would generally think that being practical and creative aren't at odds with each other. When working through a problem for work I tend to err on the side of practicality. We could be coming up with a new way to do data transformations, building out distributed tracing tools, or trying a new way of scaffolding our projects. Each of those solve a real problem and have practical implications. They also require creative thinking to imagine and design new tools and workflows. These projects are practical in the sense that they need to solve an actual problem (e.g. deliver a net benefit to customer UX or development velocity). Contrary to how they sound, they often aren't obvious projects to take on or straight-forward solutions. It usually required days or weeks of lateral thinking to cook up one of these. In this context, creative thinking complimented practical thinking and produced a better result than one of those modes taken in isolation. Sometimes it's helpful to circle around the problem you think you want to solve to better understand what your actual problem is. Be careful reading other's ideas since it will affect the way in which you see the problem. Your view of the problem may be skewed after reading other information. O

What a tale. This is such a key insight, such a core lesson on how the world tends to work. > At his next salary review Charles was given a raise which was about half the inflation over the period. He was not given a promotion. After about a year he became discouraged and left Consolidated. To be fair to Alan, spinning up an organization & knowledge system is real hard work. Legitimizing your projects is real hard work. But there's such tension over who steers, over how the work happens, and there's so many really good solid workers who slip through the cracks & never get appreciated. The corporate body is so often so very far away from the workers on the edge, sees the faults and problems, incompetent at appreciating and respecting many of the best acts done for it. Thanks for the share. This is a great article. I see a lot of relationships to other submissions. Jonathan Blow talking about work-life balance has some relationship here, on how we exert ourselves ( [link] [link] ). The "midlife crisis of a programmer" seems ultra-pertinent ( [link] [link] , 2 comments). "Hammock-driven development" made the rounds against ( [this video] [link] ). All of these deal with questions of time-base & commitment & application, all of these feel like they could be informed by The Parable. Worth pointing out that the parable is reportedly from (1985)! It's somewhat confirming to hear the struggles of the lowly engineer to get work done & fit in are not new.