talk-transcripts

master/Hi... If you have inherent domain complexity, or a misconception on how to apply programming to a domain, those are 10x worse costs than any day-to-day practice of programming concerns ("the code"), and there's a 10x further reduction for trivialisms like typos. I think some of it must be cope since so many are in organizations where the more they get promoted the less they program, trending towards (and sometimes reaching) 0. In such an organization sure, code isn't the bottleneck per se, it's a symptom of an underlying cause. The bottleneck would be the bad incentives that get people to schedule incessant unnecessary meetings with as many people as they can to show leadership of stakeholders for promotion doc material, and other questionable things shoved on the best engineers that take them away from engineering. Remove those, and suddenly productivity can go way up, and code produced will go up as well. I've also always been amused by estimates of what constitutes "good" productivity if you try to quantify it in lines of code. There's a paper from 1994 by Jim Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality, and Productivity". It's summarized in the free book by Richard Gabriel, "Patterns of Software". (https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf pg 135) They were making new spreadsheet software for Windows, and had a group of "very high caliber" professionals, with a core group of 4 people (2 with important prior domain expertise) and then 4 more team members added after a year. "The QPW group, consisting of about eight people, took 31 months to produce a commercial product containing 1 million lines of code. This elapsed time includes the prototypes, but the line count does not. That is, each member of this group produced 1,000 lines of final code per week." Later on, Coplien was asked "what he thought was a good average for US software productivity", and the answer was "1000 to 2000 non-commentary source lines per programmer per year". Also: "this number was constant for a large in-house program over its 15-year lifetime -- so that original development and maintenance moved at the same pace: slowly". An average of 1k lines a year is 19 lines a week, or about 4 lines a day for a work-week. This was considered acceptable for an average, whereas for an exceptional team you could get 200 a day. Might not there be ways to boost the average from 4 to something like 12 or 20? If your organization is at 4, there is clearly a bottleneck. (For extra context, the QPW group was in C++, and Gabriel notes he had personal experience with several groups demonstrating similar productivity levels. "I watched Lisp programmers produce 1000 lines of Lisp/CLOS code per month per person, which is roughly equivalent to 350 to 1000 lines of C++ code per week." Of course language matters in lines of code comparisons.)

already working implementations towards better outcomes. And my heart tells me that corporations & work life as we know it are almost universally just really awful about supporting reflective contemplative work like this. Work wants output. It doesn't want you sit in a hammock and think about it. But increasingly I tell you the key to good successful software is Hammock Driven Development. It's time to use our brains more, in quiet reflection. https://github.com/matthiasn/talk-transcripts/blob/master/Hi... 996 sounds like garbage on its own, as a system of toil. But I also very much respect an idea of continuous work, one that also intersperses rest throughout the day. Doing some chores or going to the supermarket or playing with the kid can be an incredibly good way to let your preconscious sift through the big gnarly problems about. The response to the intensity of what we have, to me, speaks of a need to spread out the work, to de-concentrate it, to build in more than hammock time. I was on the fence about whether the traditional workday deserved to survive before AI hit, and my feels about it being a gross mismatch have massively intensified since. As I started my post with, I personally have a much more positive experience, with what yes feels like a token addiction. But it doesn't feel like an anxiety. It feels like the greatest most exciting adventure, far beyond what I had hoped for in life ever. This is wildly fun, going far far further out than I had ever hoped to get to see. I'm not "anxiously" pulling the lever arm on the token machine, I'm just thrilled to get to do it. To have time to reflect and decide, I have 3-8 things going at once (and probably double they back burnered but open, on Niri rows!) to let myself make slower decisions, to analyze, while keeping the things that can safely move forwards moving forwards. That also seems like something worker exploitative late capitalism is mostly hot garbage at too! Companies really try to reduce in flight activities. Sprint planning is about crafting deliberate work. But our freedom and agency here far outstrips these dusty old practices. It is anxiety inducing to be so powerful so capable & to have a bureaucracy that constraints and confines, that wants only narrow windows of our use. Also, shame on Tim Kellogg for not God damned linking the actual post he was citing. Garbagefire move. https://writing.nikunjk.com/p/token-anxiety https://news.ycombinator.com/item?id=47021136

a light gust of wind. A new model comes into our life; the old desires are gone. All of a sudden we want something else. Comparing the above conceptualizations with the ones offered by Westenberg (OP) could consume hundreds or thousands of words -- more than I want to spend at the moment -- but I will say this: both sets feel wrong, by which I mean they trigger my early warning detectors. I'm not asking anyone else to trust my intuition. But you should trust yours. Intuition is usually a good starting point, at least. With intuition alone -- without writing a full analysis -- we can see the above quoted explanations/definitions are highly complected. [2] Also, in my view, the offered metaphors don't carve reality at the joints. [3] When I put ~20 minutes of concentrated thinking into the problem, here are some of the constituent parts of "desire" that I can unpack. (These are only fleetingly glossed over in the article.) In no particular order, to what degree are desires: - conscious? - intentional? - intentionally trained and reinforced? - authentic? - ones we want to have? - situational? - pattern-matched responses? - evolutionarily-selected? - socially constructed? (imitative, mimetic) - moral? (positive, neutral, negative) - permanent, durable, lasting? - self-reinforcing? This is complex! Over-simplication can be a disservice. Adding another metaphor reminds me of the "N+1 standards" problem. [4] Maybe the new metaphor helps, maybe not. Either way, now we have more to sift through. [1]: https://bigthink.com/series/explain-it-like-im-smart/mimetic... [2]: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... [3]: https://english.stackexchange.com/questions/303819/what-do-t... [4]: https://xkcd.com/927/

g I have done a lot of, over a long period of time, and I am tired of trying to get right, because it is simply far too difficult. ( https://github.com/matthiasn/talk-transcripts/blob/master/Hi... )

how analysis & understanding, how development & problem solving iteration really work. And it works nothing like what a business wants. And what a business wants hurts the quality & doesn't permit ideal outcomes to emerge & surface. https://github.com/matthiasn/talk-transcripts/blob/master/Hi... And the human factors are that dwell and pondering are essential for creative and knowledge work. Time in the hammock opens possibilities, fuels the muses. > Spend 50% of your time on frontier stuff things that break your comfort zone. That would be so excellent. I still get that mandate a lot, but so often I see peers whose whole life is cranking out pre-digestrd ready-to-go tickets. I want to see a world where we raise up engineers & engineering, not just ticket technicians.

rds my time just reflecting & pondering one thing at a time, I think that would work. But what makes sense to me is to have a couple things in flight, ideally staggered at slightly different phases of development, and to shift between them as the whims take me. Give myself time to decompress & reflect on one thing, by picking up another item that I've been pondering for a while. It feels so unnatural & suboptimal, what we do to developers. The expectation of constant productivity in one task feels like such a recipe for bad code. I have no idea how so many people do it. It boggles my mind seeing folks able to stay to task, able to power through, without these pauses & times for reflection. I wish so much there was some affordances, some option, something available for those of us who don't work well one task at a time. I want to be juggling more of the world at once, switching on and off tasks, having intervals & spacing between working specific areas of the code. I just don't see this perspective mirrored at all in the world, don't see anything at all that reflects what works for me, that reflects how hard it is for me to feel good about my work when I'm managed down, as though a machine that just has to turn a crank until it's done. My mind just is not that fast & direct, not that quick to settle and resolve the complexities of system; I need some dwell times built in. I don't know what would happen to velocity, but quality would be much higher & I'd be so much better able to flow, to latch onto tasks I was much more primed for. Please, someone, give the Hammock Driven Devs a chance.

Clasp, but it's nice that Clasp exists in the same way it's nice ABCL exists to more easily integrate with Java stuff) because you will be using native libraries for some things, and it will suck to some degree because those are written in the world and mindset of dead, static programs. But the pure Lisp side will be great, and you'd be using those libraries or something like them anyway if you switched Lisp out. An underrated Hickey talk is his Effective Programs one: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... It's another entry in my personal (and useless time-wasting) fascination with wondering what could have been if CL won in the 90s. No need for Java to come around and "get C++ programmers half-way to CL", with excruciatingly slow followups year after year that finally by Java 8 and after got us something (when also using additional things like a giant IDE with good refactoring tools and simple code generation (no manually writing getters/setters or managing a giant list of imports), Spring, JRebel, and sometimes AOP frameworks) actually not too unpleasing compared to a CL experience. But most things were always there in the CL experience in the 90s, especially if you could shell out for the commercial systems, it really is just Java playing catch-up. And then you get in that talk and elsewhere a story about how non-technical decision making didn't even give Lisp systems a chance in production, so as a last resort Lisp was put on top of the JVM which was accepted. Clojure is a great achievement, and ABCL came too late, but it's kind of a shame either has to exist. Still, the thousands upon thousands of man-years have been spent, and because of that Lisp's advantages are fewer. However the Lisp world itself hasn't been static since the 90s either, and so the counter-advantages of vastly larger ecosystems have grown fewer as well. For example, it took until as late as 2010, but finally quicklisp was made and the problem of libraries and finding/getting them was dramatically lessened. For comparison, Perl's CPAN is from the 90s, Python's PyPI is from 2003, Maven 2004... Lisp was late. But the last 10 years of Lisp seem to be going a lot better than the 10 before, and while there are still problems, they don't really look like uniquely Lisp problems, and supposedly unique ones like supposedly not being able to do infix arithmetic are addressed with slow education to the contrary (while I'm here might as well link for the nth time, the solution available since 1993: https://github.com/quil-lang/cmu-infix). It was such education years ago from a HN comment that made me give CL another look and then never look back at Clojure/Scheme/etc. (though Java is still my preferred breadwinner should I find myself suddenly needing more income). (The comment was simple, just showcasing that yes in fact CL has typing support, the compiler is available at runtime, and with SBCL the compiler can report not just about wrong types / typos but dead code elimination and failures to apply optimizations. Cool stuff. Made me realize I never knew CL at all. Even CLOS, the OOP system, had some pleasant surprises when I finally got around to learning it and seeing it's far more than what other langs offer.) Meanwhile the advantages are still there.