Those are Clover machines from a company they acquired like 15 years ago. They're very good and in my opinion a big improvement over their traditional batch brew-and-store coffee. There are more roasts available to order, the coffee is guaranteed to be fresh, and most of the time they still "skip queue" and hand you your coffee at the register.
The conclusion that you should wait to build anything is an illustration of the danger of economic inflation that the author started with. I'm not sure why he thinks the economic version is toxic but the technological version is a good idea though.
The answer to should we just sit around and wait for better technology is obviously no. We gain a lot of knowledge by building with what we have; builders now inform where technology improves. (The front page has an article about Voyager being a light day away...)
I think the more interesting question is what would happen if we induced some kind of 2% "technological inflation" - every year it gets harder to make anything. Would that push more orgs to build more things? Everyone pours everything they have into making products now because their resources will go less far next year.
> I think the more interesting question is what would happen if we induced some kind of 2% "technological inflation" - every year it gets harder to make anything. Would that push more orgs to build more things? Everyone pours everything they have into making products now because their resources will go less far next year.
Government bonds already do this for absolutely everything. If I can put my money in a guaranteed bond at X%/year then your startup that's a risky investment has to make much better returns to make it worth my while. That's why the stock market is always chasing growth.
If I read your suggestion correctly, you're saying the exam is basically a board explaining their decision making around their code. That sounds great in theory but in practice it would be very hard to grade. Or at least, how could someone fail? If you let them use AI you can't really fault them for not understanding the code, can you? Unless you teach the course to 1. use AI and then 2. verify. And step 2 requires an understanding of coding and experience to recognize bad architecture. Which requires you to think through a problem without the AI telling you the answer.
If you grade on pass/fail it’s easy to grade. Not every course uses letter grades…
If you let people use AI they are still accountable for the code written under their name. If they can’t look at the code and explain what it’s doing, that’s not demonstrating understanding.
Exactly the same as in professional environments: you can use LLMs for your code but you've got to stand behind whatever you submit. You can of course use something like cursor and let it go free, not understanding a thing of the result, or you can step-by-step do changes with AI and try to understand the why.
I believe if teachers relaxed their emotions a bit and adapted their grading system (while also increasing the expected learning outcomes), we would see students who are trained to understand the pitfalls of LLMs and how to maximise getting the most out of them.
I agree. However, so many of my use cases include a one-to-many relationship that I was outgrowing excel/sheets too quickly. Once a project added a VLOOKUP, it hit an inflection point in complexity.
I spun up a local Grist instance in my org, using SAML with our org's email authentication. It's intuitive enough that I've replaced a few shared spreadsheets with it (now with rowwise permissions) and powerful enough that I've also replaced a few internal CRUD apps.
While Grist is a brilliant product, I really dislike the spreadsheet marketing they use.
It's not in any way a spreadsheet, you can't use rows correctly and everything is stuck in columns. Not to mention the forms you use for input are not user friendly compared to a simple understandable coloured cell
Just rank by date needed order on a kanban board and work your way through everything in order. If it's constant fight to meet deadlines it will be clear enough that things are backed up.
Its not so much as estimation as a whole work style, but
Make it work -> Make it right -> Make it fast
is arguably the best way to go about things, then structure your work around that.
Ive done this with greenfield projects when I used to work for Amazon (while still ironically operating under scrum), and was able to get SD2-SD3 promo within 2 years (entering an an SD2).
In terms of planning work, you basically allocate people as necessary. The first part deals with a lot of unknowns, so estimation is pointless - basically everyone is on board in terms of getting software up and running and talking to other software.
Once you have that, making it right is a lot easier to estimate because you can do a lot more fine grained planning (like for example, a certain team member that worked on a feature can add all the correctness and unit testing way faster than someone who has not)
Then making it fast is basically just optimizations, which can be done by a subset of team members while the rest work on adding features (and adding features needs to be done in the same way - make the feature just work, make it correct for all use cases, and then make it optimal)
reply