So I have my consulting website on Notion made pub...
# thinking-together
t
So I have my consulting website on Notion made public with a tool called super.so…today, I got an email from a genuinely helpful person who alerted me that I had my projects/todos data available publicly. I told him it was on purpose for transparency sake (idk if its helpful for biz but that’s a separate conversation). He sends:
Copy code
"As a DBA (database architect) and developer for 23+ years, managing million dollar+ projects, I wouldn't use Notion in this public way. It's possible to run into sensitive info issues down the road when you forget to lock things down. You can't scale and maintain security because Notion simply doesn't have the features to provide scalable security for public facing Pages. I would instead create a fake project that you can demo and make public. And since the personal level is now free with unlimited blocks, you could create a separate "Demo" workspace without fear of ever showing sensitive data or running into block limits.

Best of luck... I'm seeing an increasing problem in the Notion community with non-programmers and those with little or no real-world Project Management or database experience setting up shop as Notion Experts. We were building database-backed websites in 1996-7 and by the early 2000's most of our jobs for large companies and State agencies and governments consisted of cleaning up the messes the early "web designers" created ... I fear we're seeing a similar situation with Notion and in 1-3 years there are going to be clients who have unusable systems that will have to be rebuilt in order to scale and handle new functionality..."
I feel like this could be a good discussion. What are your thoughts?
👍 1
w
Two topics are going on here... (1) If you are well aware that everything is public, that may just be the way you role. (2) Are we just talking about the age old problem that the inexperienced and incompetent can sometimes hack things together? The question for Notion as a particular tool is whether it incentivizes bad habits.
m
One problem I see here is good/bad pick of abstractions. Notion is not pure relational database, thus you can design data layer in a familiar way nor tune it for performance. It is easy to start and build something, but when complexity grow it will be harder and harder to maintain. This is true for any serious system, but if you pick not good abstractions from the start, it becomes impossible.
i
If these notion-wielding people are complete novices, and they're building systems that let a business run more effectively at their current scale, I think this is a phenomenal success. The "notion experts" have found a path that will eventually lead them to learn more programming. The businesses running on these notion setups have a working solution that likely didn't cost them nearly as much as hiring a traditional developer. And, best of all, another stuffy traditionalist developer who is obsessed with "scaling" and their own credentials has been frustrated, and some egg has landed on their face.
❤️ 5
t
@Ivan Reese, this reminds me of a debate I had with someone at Pixar. Internally, engineering is largely divided between "production" and "tools". The former are artists and technical people who are actually building the movie itself, and the latter are software engineers who are building and maintaining the high-powered software it takes to make the movie. Production often cobbles things together with hastily-coded scripts or node networks, and it's often fragile, ugly, duplicated— most complaints you could level against "bad engineering". Generally it's done under a deadline, though, in service of getting the best possible picture on the screen, and knowing the audience won't care about how the sausage is made. This other person was griping about a script they had to maintain (and— probably with cause— had several of those complaints), and was arguing that production TDs shouldn't be allowed to write code if they couldn't engineer it properly, and that this stuff should be given to the tools department. But the thing is, the tools engineers (and there are ~100 of them) all have their hands completely full on large-scale, long-term projects that are necessary to hit the highest level technical goals of a film, and beyond that, to keep the entire studio on the technological cutting edge. New projects are careful negotiations between all the films' needs and the tools department's limited resources. Bidding these projects takes time, and often they wait in line for several weeks (or months) behind critical bugs and features. If tools engineers had to do all "production" engineering, that work would simply never get done— or the studio would need an engineering department three times as big, and for the exact same result on the screen. Bashed-together scripts allow technical artists to solve a problem quickly and get back to making the movie. If they had to bid their project to an engineering team, prioritize it, get leadership support, and so on... they'd be waiting for weeks. They'd probably just tediously solve their problem by hand instead, and spend less time making the movie look good. The dichotomy frequently isn't "engineering things cleanly vs. cobbling things messily", it's "cobbling things messily vs. not doing them at all". If put into practice, that abstract complaint about the tidiness of how something is done— or gatekeeping about who gets to do it— would result in a worse movie. I don't have deep experience with Notion, but in general I think this principle extends to the outside world— there are lots of people who are spending hours doing things that should be automated, but there are way more one-off problems than there are engineers to architect tight solutions for each of them. "Messy and done" is better than "not done" or "done tediously, at the expense of solving more central problems".
💯 2
👍 1
😄 1
🌶️ 2
i
Your Pixar anecdote would map perfectly to many (most?) video game teams, too.
👍 2
y
Reminds me of the discussion in this great thread: https://twitter.com/geoffreylitt/status/1177607448682582016
a
My naive impression is that any tool that gives someone leverage is a good tool. If you did theoretically have to migrate from Notion to a more performant RDBMS, then you ran out of rope. But that’s fine, it’s what engineers are for. The question is just “does migrating notion data cost more than the total leverage you get by using notion”. Since the person using notion is probably not technical, I imagine they get a ton of leverage by having an easy to use DB system that “just works”. It looks pretty, it’s easy to edit, easy to add metadata, easy to change schema, and best of all integrated directly with your entire wiki, and all the institutional knowledge therein.
o
Very interesting discussion! Especially the Pixar anecdote (thanks @tbabb for sharing it 🙂 ). I guess that any "advanced" are the tools, you will always be able to use it in a messing way. And there will be always cases where it is reasonable to program messy things (as for the Pixar example). For me this is inherent to the act of programming: you are always making compromise between "perfect" (at least perceived perfection, but that is another subject) and "useful/actually used". And I guess it is important to have this central aspect of programming in mind when creating programming tool.