My job is designing SAAS software products. Big SAAS systems with enormous complexity and lots of parts, some of which are operating 'out in the wild'.
My biggest challenge? Getting software engineers to think about the problems they are solving with the right level of abstraction. They want to get into the weeds of detail, so they end up talking about how to solve the one particular problem right in front of them.
Whereas I want to solve the CLASS of problem.
> Writing Programs with NCURSES. https://invisible-island.net/ncurses/ncurses-intro.html
> Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine. Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable. https://github.com/jart/cosmopolitan
Working with JSON-Schema today. It's powerful and expressive enough, but why does the tooling not support sub-schemas on a file system naturally, without fuss, in the same way as for http URLs?
Only, if you use http URLs there's no good way to do a test/fix/test loop. You can use a web server running as localhost, but you need to fix all the URLs before you can roll out to production.
And then test in production to make sure you didn't miss something.
It's stupid as hell.
In the news (again): Package managers and shared libraries on CDNs being hijacked by darkside hackers.
Me for the last fifteen years: Package managers are evil. Only use libraries you vet and manage yourself. If you are compiling binaries, avoid dynamic linking and static link only to code compiled from source; no library obj files.
Me for the last ten years: NPM is especially evil and the reliance on it for everything Node.js related means you should avoid Node as well.
I've been writing software since 1982. If I've learned anything in that time it's that users often don't know what they actually want when you are building it. This is because they can't describe the problem space well and often focus on the wrong things.
But once they start using it, telling them they are using it wrong only indicates you don't grok the problem space either.
And, yes… This is a subtoot about the latest #Mastodon controversy.
This looks interesting, especially given my dislike of big frameworks. That said, it's in early days and possibly not ready for prime time.
One of the greatest challenges of #software product design is naming. What do you call the user-visible parts of the software? What terminology best drives conceptual understanding and ease of use? It's incredibly tricky to get right.
Then, once product development is underway, the Sales and Marketing teams finally pay attention to the emails and suddenly you are hearing, "We can't call this thing that because sales and marketing reasons."
And your naming problem metastasizes…
Back in the late 1990's Dave Winer observed how networked peripheral devices could expose their functionality via HTTP; thus doing away with things like proprietary drivers and weird protocols. Just one set of standard APIs for each device class.
Of course Dave was thinking in terms of WebRPC, not REST and it didn't make economic sense then. But in this day of cheap Linux-capable single-board computers you'd think the time had come for Dave's idea to re-emerge.
Software libraries should be *beige*. They should be boring and predictable and follow all the best practices. They should do whatever they do in the simplest and most time-tested manner, unless they can provably do it orders of magnitude faster.
Twice as fast isn't good enough when it doubles the learning curve as well.
> Programmers, Teach Non-Geeks The True Cost of Interruptions. https://daedtech.com/programmers-teach-non-geeks-the-true-cost-of-interruptions/
So true! #Programming can be like juggling a hundred balls at once and it takes a while to get them all in the air. When interrupted you drop all those balls and have to start over.
Not to mention the heart attack you have when you are deep in a debugging session and someone comes up and taps you on the shoulder because you were so focused you didn't hear them calling your name.
> #Python Best Practices for a New Project in 2021. https://mitelman.engineering/blog/python-best-practice/automating-python-best-practices-for-a-new-project/
> The Book of Secret Knowledge. A collection of inspiring lists, manuals, cheatsheets, blogs, hacks, one-liners, cli/web tools, and more. https://github.com/trimstray/the-book-of-secret-knowledge
Getting back into the swing of working and, along the way, inadvertently reminding myself I'm actually really good at software design – both in the doing of it and the communicating of it to others.
Software people: learn how to code in English (or whatever human language is used in your organization). Effective communication of ideas is at least as difficult – and as important – as designing secure and scalable systems.
And most people are quite bad at it.
> Mistune – A fast yet powerful #Python #Markdown parser with renderers and plugins. https://mistune.readthedocs.io/en/latest/index.html
Note: They include an AST renderer that gives you the basics of a simplified document object model.