Rust also seems like a great choice because of its close ties with WebAssembly. Web developers who learn it should have an advantage as the tooling starts to get better around WASM.
I guess it helps enforce the importance of certain aspects of the process that don't necessarily get hammered in, especially with large projects that can take a year or more to make (whereas I sometimes design 2 games and make prototypes for both of them in a single day).
One thing I never was really good about doing with system design was getting it out in front of actual users to test things as soon as possible, and the companies I work for often overdesign on the front end before getting it in front of users.
I recently was brought over to help on a project in a different department at work, and that project is now in UAT testing after about 2 years of design and development, and they're in the middle of redesigning a bunch of things right now, because the users finally got to sit in front of it and basically said, "Thanks, I hate it."
Like with board game design, you don't usually need to make things polished and good, just get something really basic made so you can show it to other people.
I always knew that was important before, but getting into the habit of doing it with board game design (and watching many things that I come up with and think are brilliant just bomb when getting in front of users) really hammered home that I can't always trust my instincts, especially since the software I'm making is really not for my use (I never use the enterprise software I'm working on right now, except to fix things), whereas some games I design I really do enjoy playing them myself as well.
Another thing with feedback is the concept of 'If multiple people are complaining about something, they're pretty much always right that it sucks. They're also almost always wrong about whatever idea they suggest on how to fix it.' Or basically 'The feeling is right, their solution is wrong.'
Many times I have designed a game just to see it crash and burn when it gets in front of other players (and other designers). They'll tell me they didn't like something and make suggestions on how to fix it, and often my brain will go 'yeah, but that kind of violates the core idea' or 'i'll try it' and you try it and it breaks further. But they're right that it's not fun, or that it gets too hard, or that it feels like they're not making interesting choices, or whatever. And you take all that feedback, you reflect on it, and often will come up with a better solution that addresses their concerns but is also more elegant and doesn't violate some principle of the design.
The same can be true with users of a software system. They can be right that something feels wrong, but there is a good chance the solution they suggest won't work for some reason. Either it technically can't be done, or it's clunky, or it'll violate some business requirements, or maybe it's an 'ok' solution but there's a better one that you can find if you think about it.
Another thing is that game designers can be very valuable to give feedback on the design, and can really point out some major issues with a design, but you have to take their feedback with a grain of salt, because they're not your target audience, and they also have their own particular design preferences and most of their suggestions will reflect that (I do it too, and have seen myself do it). If you incorporate too much of their feedback into the game, it will probably take the game into a very different direction and might not fit your audience anymore (one big thing is game designers tend to be big game players, and especially like more strategic games, so you have to be careful getting their feedback for casual games, that have a lot of luck in them. They'll complain about how much luck is in the game, and make suggestions to remove that luck, and if you did too much of that your game is no longer a light family or kids game anymore).
How that applies to system design is that other engineers probably have very useful feedback to give for your system, especially pointing out structural issues, but they are a lot more technically savvy, and their suggestions will probably lead to a more confusing and complicated (but more powerful) product that might not appeal to a mass audience because it's just too much going on, and a simple design would appeal to them more.
I'm sure I could probably sit down and come up with more. Maybe I should write a short Kindle book about it :).
I just realized I kind of wrote this backwards, i.e. things learned in board games applied to system design, but I think I first saw these ideas in software, and got to apply them more with the faster iteration process of board game design.
What kind of things are people using them for? It seems like most of the low-code stuff I see is more low-code tools and examples of things that can be done with low-code. Are there examples of things that are really novel with low code?
Why does it need to be novel? Simply being able to put boring but practical things together in hours vs weeks/months is more than enough imho. There are enough people who have to build a little crud tool and end up spending weeks/months adding features that these low/no code tools simply have standard. That + no deployment, no maintenance (besides the data models and business logic) etc. Sure it is far more expensive, especially when you get many users, but there is a sweetspot for these things, again, imho.
Totally agree. I feel like I trust Safari in terms of privacy as well, and it works so well in the walled garden of iOS/macos. I really hope they get it up to date with the latest web standards, it's a joy to use otherwise.
This is cool to hear. I've been interested in Haskell/OCaml to learn functional programming. Rust has other cool applications like WebAssembly too. I think I'll start learning it after I learn Clojure (trying to get into functional stuff first with Lisp).
I think of it as "zero ops" API endpoints. I have some serverless functions deployed on Vercel. I wrote some Typescript code, pushed it to a file in a directory called api/. Now every time I call my function endpoint, the function runs and returns my result. I don't have to provision anything or set up any ops. The serverless part takes care of spinning up whatever compute it needs, runs my code fully statelessly, and returns my result. I don't have to touch or think about scaling anything. I'm a developer who wants to spend time on features and code, and remove myself from the dev ops as much as possible. That's why I love serverless and use it whenever I can.
Thanks, still curious about data management, vendor lock in, what to do when complexity grows etc. Im sure they have all been thought off, will look into it.
As for vendor lock in, I think that is one of the bigger constraints with serverless. There are a couple tools that help make the transition easier, like Serverless Framework[0], but when you get into things like AWS Dynamo DB, which seems to be there perfered DB for serverless workloads, it can get tricky. Thankfully, it seems like the format of basic serverless functions is pretty standard across different platforms, but I think the real tricky part comes from other services on the platform you use, like data persistence.
This makes me feel like there's a good niche for "developer-friendly no-code". I'm a developer and I don't like no-code solutions for all the things you mention. These current tools try to abstract a lot but it ends up becoming severely limited and hard to debug/extend. They might be okay for things like internal business tools, which is what most of them seem to be targeting. On the other hand, I've been playing with Hasura recently. As a full-stack developer, it's amazing. It gets rid of tons of boilerplate for back end dev, and I can focus on building features rather than CRUD plumbing. It's easily extensible using serverless functions. It feels like it's helpful to me more than trying to replace what I do.
Is there a way to reconcile this? Web has such nice tooling to develop for, but it's also nice to have the discoverability and monetization opportunities of a centralized app store.
IMO, only when native apps dependency on smartphones are reduced we can see web apps maturing.
PWA, Linux phone's dependency on web apps can help a bit, but I don't see it beyond the enthusiast/privacy market.
Because App publisher - Appstore relationship is 'scratch my back, I'll scratch yours' type relationship. Top apps isn't going to get as much telemetry from web app as they get from native app, at least not without people knowing or fighting with ad-blockers.
The current answer here seems to be Electron, which unfortunately means that I have about 20 copies of Chromium/Electron taking up disk space and memory on my computer.
...really? Web development is the absolute worst development experience I've had since doing COBOL in college. I have difficulty believing anyone can claim this who has ever developed with proper tooling for anything else.
I guess I haven't done too much outside of web to know much else :). However I have done some iOS stuff and the tools are okay but much less open source, documentation, etc.
As a full-stack dev, I'm going to always reach for things like Hasura for building my backend from now on. It auto generates a full CRUD GraphQL API from my Postgres DB schema. Most of the backend boilerplate is eliminated this way. If I need to add additional business logic, I can use serverless functions that run between the GraphQL query from the front end and the DB operations (actions in Hasura). Most of the heavy lifting is through the front end anyways, and this keeps everything neatly in sync.
We're exploring a GraphQL serv(er/ice) for an internal back office system. It needs to combine multiple APIs into a single GraphQL interface. And everything just breaks apart :) (we have PoCs in C# and Java for now).
They have great recipes for authentication/authorization. It's much better IMO because it actually provides per-request authorization. There is also great support for transactions using the GraphQL mutations. I'm not affiliated with Hasura in any way, it's just changed the way I view backend development. Backends (in most cases, my day job is actually not part of this generalization) should basically be a thin wrapper around your database, and any work you can outsource to the database, you should do that rather than building business logic.
Those aren't hard to do if you declare up front what schema you need to conform to.
I'm working on a REST code generator (generates a Go backend and a typescript/react frontend) that reads your postgres/MySQL schema and some additional metadata you provide (should auth be enabled? Which table is the users table and which columns are username and password stored as bcrypt). I'm still working on authorization part but basically optional per-endpoint logic DSL for simple stuff and optional Go hooks for more complex stuff.
I've been really wanting to learn another language (been doing TS for the past couple years, would really like to see what else is out there). What do you think are other great languages to learn instead? I'd want something ideally with: functional paradigms (really want to learn these), good tooling, good ecosystem, good production deployment recipes, shared code between front end and back end. Any thoughts?
