Tommabeeng

Dune was a 165M movie.

Even beyond Dogme 95, the 90s were such a great moment for independent and low-budget films.

And this was before the epoch of 24P and digital!

So indie and very low budget films should be much cheaper to make today than in that era of film.

But I feel like the innovation isn't there today, especially in America.

I feel like there should be a market for adult themed movies and writing. I know I am, and others are, hungry for such movies, and production quality doesn't have to be millions of dollars. The writing has to be very good, though.

Where is the Christine Vachon of this generation? Where are the low-budget indie production companies? Are we due for a renaissance here? Is it really just that no one cares about 2-hour films anymore, it's all content content content? (Hard to believe this, I feel the 3/multi-act dramatic experience is hard-wired in us, we need a return to cinema..)

Super excited about this. I've been using cljfx (https://github.com/cljfx/cljfx) to build a few apps and it's so developer efficient.

Decoupling

I find this such a shame. I think this reflects an increasingly consumer versus producer aspect of culture. I find that desktop apps support and foster creativity, and producing readily manipulable creative artifacts - with speed. Sass/webapps/etc tend to foster consumer-oriented, indeed mobile, usage, creation and creative operations are often subtly high-latency and subsequently & so are tacitly discouraged while consumption is encouraged.

I love the pitch found in https://www.inkandswitch.com/local-first/, but it doesn't seem like it's resonated much in the large - so far, at least.

I've made a few desktop apps in https://github.com/cljfx/cljfx (e.g., https://www.chronos-desk.com/), and cljfx (JavaFX + Clojure) is amazing and makes for rapid development, not to mention fun. I'm keeping an eye on https://github.com/HumbleUI/HumbleUI, which promises to be a step up.

This is incredible. I’ve got two JavaFX apps to try this out with this week. Figuring out Mac codesigning for JavaFX apps was a pita.

In prior talk(s) he’s famous for saying “IQ is a lead weight”.

He does say about coupling & cohesion that "if used, they are pulling a fast one on you".

That's wrong. I like the key to his talk but the plague of large complicated systems is exactly coupling and incoherence. Classes are NOT necessarily the way to achieve these.

Alan Kay expresses something similar:

http://tele-task.de/archive/video/flash/14029/

"Knowledge is silver. Outlook is gold. IQ is a lead weight." (~00:30)

"Improving the productivity of a software team is hard. It involves understanding the business, the team, the history, the obstacles blocking progress. It is a complex, context-sensitive problem."

TRUE.

Hiring more devs won't solve the complexity problem unless you happen to lasso a few certain devs with the right experience, perspective and willingness that can identify the true core of a problem and solve it fully and with expedience. Sadly many ("smart", "rock star") devs I've seen are content with shortcut, local maxima solutions that only buy a little bit of time before the team starts hurting again. I don't know why this is. Maybe b/c it's more fun (or feels safer) to code and produce behavior than to do the vigilant things required to stave off complexity. But this is a suicide run -- you feel the wind in your hair b/c you're hacking, coding, etc. but you're actually just running back and forth exhausting yourself and not pushing the line forward as fast as you hope. Don't let this evoke The Tortoise and the Hare fable. The team that does development right will be less like a tortoise and more like an elephant. Ground speed somewhere in between the tortoise and the hare, wise, and pushing the line at the greatest speed.

It should be noted that code reviews, though useful for catching defects, are incredibly expensive.

I think there are cheaper ways -- along the lines of automated testing and design reviews in lieu of code reviews -- to reduce risk and defects, and obtain high quality software, than to spend such massive time/$ on code reviews.

This is meandering rambling from someone who doesn't know how to write unit tests. He complains about bad unit tests ("many tests tend to...") as an argument against unit testing. Yes, there are bad tests out there. But there is a way to write good valuable unit tests that protect you from future regression (thus future pain and needless effort).

Get better at writing unit tests, don't use this article as an excuse to avoid a highly valuable practice.

I like this. "The only weapons we have are simplicity and convention." Well said. I think we need to espouse a new software paradigm: DFS-oriented programming. (Dead F*ing Simple-oriented programming.)

Layers of indirection (abstractions) aren't bad; bad abstractions are bad. A good abstraction should protect you from having to keep lots of implementation details in your head. And C and arrays are not the epitome of simplicity. An array is a terrible way to represent most state; the OO facilities of abstract data types and encapsulation are much better. Complexity is the enemy but "weaker tools", C and arrays are no solution to that.

no, for just pandas

glamour photos for pets

Would a rewrite necessarily benefit the business? Can you make a strong case for that?

If not, start writing tests, try small incremental refactorings, ask your manager to hire more people, maybe someone not as qualified as you but that can take on some more of the unpleasant activities. Maybe you can negotiate some 20% time? Use that time to build tooling to help you do your job better. Share it with the world. Management won't give you these liberties? Find another job. And ask the next company to show you their code metrics before you seal the deal.