"Concepts, Techniques, and Models of Computer Programming" is considered the natural successor to SICP. I haven't tried it, but apparently it's a good deal harder.
I too am looking forward to that. 99% of the time `&>:not(:last-child) { margin-right: 4px; }` does the trick, but that 1% (usually wrapping) normally leads to compromises.
My parents have a wood fired, and I have an Ooni Koda. I can compare:
- The base is better on the wood fired oven. The Kodas stone doesn't get hot enough. I've read recommendations to replace the stone with a steel, because it's more conductive.
- The koda heats up in a timescale I'm ok with. Like, 20 minutes. For the wood fired oven, it usually takes about 2 hours for the oven itself to be hot enough, but you really want the oven to be completely saturated with heat. This can take over 4 hours.
- I've had the Koda about 6 months now, and used it about 20 times. It hasn't really registered on the meter attached to my 13 kg gas bottle, and this is the only thing I use it for. I'm not at all concerned about the gas usage, even when its used a refill is cheap.
- The wood oven, in contrast, goes through wood significantly faster than our wood burning stove.
- I can do more with the wood oven, like bread, or roasts. The profile of the Koda means my normal cookware doesn't fit, and while I'm ok with buying Ooni's low profile cast iron, I just haven't done it yet. That said, while I like the idea of cooking food under real fire with smoke and intense direct heat, I don't see that with essentially a big gas oven. I have other tools.
- I can take the Koda anywhere, but when my parents move house there's no chance the wood oven moves.
I think it's more about your intent. I'm not too bothered I don't care about soccer any more, I'm not after therapy to change that.
In this case though, I see someone who badly wants to be enjoying programming, but for whatever reason they don't understand they don't. It's probably a good time to talk to someone. Usually I'd start with my girlfriend, maybe my mum, perhaps take a few weeks off and then see how I feel. If that doesn't sort it, I'd probably want to talk to a therapist.
Also we need to remember what the relevant pre-existing conditions here are.
I think most people are immediately thinking severe asthma, COPD, recent or current cancer treatment; and while all of those elevate your risk, they aren't the most common comorbidities.
The key co-morbidities are high blood pressure, heart disease and diabetes.
Only heart disease seems obvious - high blood pressure is almost standard, and diabetes is often managed well to the point of invisibility.
The cardiac link appears interesting. Patients who are given ECMO, a complete lung bypass alternative to ventilators, have still died after their lungs recovered.
Really? I have a rule with Anki where the question is one line and the answer is no more than 3. No cards take longer than a minute to write, or more than 10 seconds to remember.
If it's anything longer, then it's probably not a subject you should be using anki to learn or you're trying to remember too large a bloc of information at once.
I have absolutely no idea how this could be a form of procrastination, or how I could more efficiently memorize information that must be memorized.
> I have absolutely no idea ... how I could more efficiently memorize information that must be memorized.
Outside of a schooling/testing context, memorization alone is rarely beneficial. You need to be able to practically apply the knowledge, which happens through experience; looking details up when you need them forms a natural kind of spaced repetition anyway that’s tuned to what you actually need to know.
I don’t agree. I was for a long time of the school that understanding is the only things that matters, and the details can always be looked up. Then during my post doc ( physics) I worked with a couple of Russian guys who had been forced to memorise a lot. What they gained was an enormous speed. They could try six different ideas in their mind while I still looked up the details necessary to try my first. So don’t underestimate root learning.
There’s a third category here, and that’s functional skill. It’s quite a separate thing from either understanding or rote learning. They all feed into each other, of course, but the point I tried (and apparently failed) to make is that it’s functional skill that’s useful in real-world contexts.
Sometimes the thing holding you back from improvement is a lack of facts, and sometimes it’s poor understanding of theory. In my experience, however, the fastest way to get better at doing something is almost always to practice doing that thing; most of the time a sufficient collection of facts and theoretical understanding will come along as a side-effect of that work.
How much of their prior training was memorizing specific facts, and how much of it was drilling the mechanics of solving typical problems? The former is what most people use spaced repetition for and what I believe is of limited utility; the latter is incredibly valuable and I never meant to imply otherwise.
Well, as a counterpoint, imagine how much time could be saved if you were able to recall from memory not just the most-used functions that you need for a problem, but the next level down of sometimes or rarely used ones. Or for patterns, or for other such things that can be simplified down into memorizable / recallable blocks.
Regularly looking things up is ok, but actively re-experiencing the thing you're trying to learn is a better way to make it stick.
In many cases less time that what I spend looking it up. I regularly look up things I haven't needed before, a few minutes of reading and I know it. Many of those things are something I expect to never need again in my lifetime. The few seconds to memorize all those things is greater than the time saved. Particularly since I don't know what I will need next week and so I'll be spending a lot of time learning things I turn out to never need.
For programming, memorisation doesn't matter that much. Not knowing the argument order for a function isn't a big deal. You use an IDE or you get a good offline docs viewer (Dash, DevDocs etc.) or you learn to Google efficiently.
Language learning is an obvious use case.
Also: law and medicine. Having knowledge mentally 'to hand' is pretty important if you've got a patient under general anaesthetic, or a judge asking you a very difficult question.
Memorizing word pairs can certainly be done with spaced repetition, but it’s unclear how much that translates to actual language ability. Second-language acquisition appears to be primarily dependent on reading (or listening to) the target language for content, and most words are learned via seeing them in context instead of being looked up in a dictionary.
I have no experience with law or medicine, but I expect the story is similar: practical knowledge is what you need to hand, and not book knowledge. Book knowledge is what gets you through the exams and into the practical part of your training.
Beyond the very basics necessary to extract some meaning from a second language, I’d be shocked if time invested in spaced-repetition drills of any design had better returns than reading the target language for pleasure.
Anki has two benefits: memorization and understanding. Memorization is what comes from going over the cards, which is what you allude to. Understanding comes from the process of creating the cards, where you think hard about the atoms of information in the text, and their interrelationships, and cast them into simple questions. Then memorization gives you a much deeper understanding than if you hadn't ankied the text.
I concur, what you describe is a very effective use of spaced repetition. It is different from what ‘ProstetnicJeltz described, where cards should take less than a minute to write — that describes memorization without first putting in the effort to understand.
This is a hard one to answer, and what works for someone might not for another.
The most useful advice for me has been to find a method, and stick with it. This is most important for organisation.
I prefer handwritten notes, and I only take notes on things I don't understand. I'm not writing a textbook - I don't need my notes to be a complete reference manual on the subject. Moreover, notest that explain how you went from 'eh?' to 'oh, yeah...' are so much more useful, and if you already understand something you don't have that moment to talk about. It's also a waste of time.
I use hardback notebooks. If I'm studying 3 things simultaneously, I have 3 notebooks running. When I finish one subject, I start the next a few pages later. I write the subjects on the spine (normally need a sticky label). The growth of my 'notebook library' has been quite satisfying!
My method of note-taking has varied a bit, I generally use the so-called 'Feynman technique'. I write the subject, leave a few blank lines, then go through the steps needed to understand the subject. I then write the 'summary' that I now understand in the blank space.
I might write a few exercises underneath, or reference a textbook, or something. Basically anything that will help me when I inevitably forget.
Often my notes are rewritten - my lecture notes are borderline unintelligable. After a while (at university) I gave up taking comprehensive notes, preferring to remain active in the class and then deliberately rewrite my notes using other sources later. This fuelled a powerful cycle - my other sources put me about half a lecture ahead, which helped me stay engaged in the lectures themselves, so I got more out of the lectures, and needed less study after. Lectures are like Shakespeare - knowing the plot enhances the experience.
'More modern' these days appears to be the 'thousand papercuts' approach - many SaaS products that collectively provide the same feature set.
It's still hell, just a different kind of hell.
Bespoke is a genuine competitor. In the UK it's not uncommon for SAP implementations to cost several million £s, this could be used to build bespoke software.
There's a massive risk here though - there are thousands of ways bespoke ERP can go wrong. Underfunding the project causes problems, but arguably the worst projects were overfunded. Then there's recruiting the right people and developing the right culture - archaic business hierarchies are almost mutually exclusive with good software teams.
In other words, there isn't really a very good option. You can understand why business leaders, who are often not technology experts, would go with something that has 'worked' for them in the past.
Bespoke is expensive but sometimes the least expensive option. I worked at a company that just hired an auditing consultant firm to certify their existing system. It took a year of locking down existing processes and slapping approvals and change management on everything, but at the end the system stayed more or less the same with minimal changes in business process required. I think they made the right choice, but they had the personnel, time, size, and money to do it. I think it would have been riskier, taken longer, and been more expensive to buy an ERP (NetSuite and SAP were evaluated), and the business came to the same conclusion. However I would not recommend this for for any company with less than half a billion in revenue already!
M&A (mergers and acquisitions) is a big factor - for most large corps it happens all the time, you haven't finished integrating all your acquisitions before you get new aquisitions or get acquired yourself. So if you go the bespoke path, you have to continuously migrate departments and their data off of SAP or something like that. And when you get acquired, you'll likely have to migrate to SAP or something like that - and, more interestingly, you may come to a situation where you need to migrate to SAP or something like that before an acquisition to remove a potential risk factor for the acquirer you're targeting; that's going to cost a lot but it's worthwhile given the expected M&A money.
True! But than, when Amazon started, there was no solution for their problem, e-commerce with an integrated logistics software suite, available. Which gave Amazon a huge advabtage over competitors. That changes since a couple of years if you ask me. Which could be a problem for Amazon in the long run. Very long, so.
We tried to use a result type in C# for cases like this. For example, we want to save an object, returning the updated object (on success), or an error on failure.
Unfortunately in static languages this leads to an unholy amount of boilerplate:
public Result<SomethingGood, SomethingBad> PerformUpdate(int goodThingId, UpdateForm form) {
...
return new Result<SomethingGood, SomethingBad>(error);
... return new Result<SomethingGood, SomethingBad>(obj);
}
The type annotations were hell. Sometimes there were three cases we wanted to consider. We went back to using exceptions, and are keeping a keen eye on the new C# features.
So ultimately - I agree with the author that throwing exceptions is fine, when things actually go wrong. It's also not that bad when things kinda went wrong, but sometimes the effort required to fix it isn't worth it.
which is considerably less boilerplate-y. When there are three cases you want to consider, that's no longer a sum type consisting of just success or failure - that's a different sum type. Maybe even represented as Result<ThreeCases, Error>.
