> On a personal level I feel the fastest way to feel unhappy is to worry too much about whether I am happy
These are wise words that I needed to hear after a hard day and feeling like I've always been getting the short end of the stick lately. Thank you for writing them.
Epsilon sandwiches is a great speech, with advice that I wish I could follow—but it pre-supposes students for whom the referenced very easy proofs are indeed very easy conceptually, and the struggle is only to put those concepts into words. I can believe that this is true of students in a UPenn first analysis course, but it is not true at the less prestigious university where I teach students who are encountering proofs for the first time (well before analysis)—and I have long struggled with how to break down this two-step complication into separate manageable steps with students for whom, say, it is still a real challenge to understand (in the context of proving facts about sums and products of even numbers) why 2(x + y) = 2x + 2y is true, but 2(xy) = (2x)(2y) is not. If anyone knows how to adapt Wilf's advice to such students, then I—and they, in my fall class!—will be grateful to hear it!
Thanks for the suggestion, which I think is exactly the right way to address this particular issue.
Indeed, now that I've learned from a few times teaching the course that it always comes up, I will address it. But, if I spend my time building up basic-algebra proficiency at this level, then I'm never going to get into the meat of proving things. Perhaps the answer is to view the very act of writing your argument as a proof—and I like that perspective (because it genuinely is!); but, if I were to break that down to its full details, then I would have to write 2(x + y) = (x + y) + (x + y) = x + (y + (x + y)) = x + (y + (y + x)) = x + ((y + y) + x) = x + (x + (y + y)) = (x + x) + (y + y) = 2x + 2y, and writing down proofs of that sort risks alienating students who are eager for a conceptual picture, and guarantees giving the wrong idea of what sort of activity proving is. (And it also risks confusing why later I will say that, for a silly example, π(x + y) = πx + πy "by the distributive law"—I can't think of multiplication by pi as repeated addition, so I must cite the distributive law; and then why didn't I just do that before?)
This has confused me a bit about the US education system. Shouldn't this be taught in highschool? Where I live if someone wants to study maths in university, and they haven't done the B2 math track, the university would simply not accept them into enroll into that major. The student would have to get a highschool degree that includes the maths B2 track, if they're under 18 they could simply return to highschool, or if they're older then there's adult (night) schools.
> This has confused me a bit about the US education system. Shouldn't this be taught in highschool? Where I live if someone wants to study maths in university, and they haven't done the B2 math track, the university would simply not accept them into enroll into that major. The student would have to get a highschool degree that includes the maths B2 track, if they're under 18 they could simply return to highschool, or if they're older then there's adult (night) schools.
It's not that they haven't been taught this; it's that they haven't conceptualised it, so that 2(x + y) = 2x + 2y to them is just a meaningless rule, and there's no particular reason why it should be true but not 2(xy) = (2x)(2y), or 2^(x + y) = 2^x + 2^y, or whatever. Of course ideally one would only have students in the course who have conceptualised this, but that's not how it happens, and it's not fair for me to teach the course to the students I wish I had.
You can find proofs by making analogies in almost any direction, but it helps to know which direction leads towards solid intuition the student already has and can build on, rather than just leading to more abstract nonsense that's equally unfamiliar.
In the case of having no intuition about algebraic manipulation, you can suggest a geometric interpretation to connect to intuition that's more likely to be there. For 2xy != 2x2y, draw two xy rectangles and one 2x by 2y rectangle.
Now the students all see the problem. Now they just have to connect the geometric intuition back to the algebra. This helps motivate the algebraic rules and shows why they must be what they are. Just the idea that geometric intuition exists -- that you can solve problems by putting pictures together in your head -- this isn't something every incoming freshman already consciously knows they have as a technique always available to them.
(This is just a wordy re-telling of Polya's "Draw a figure", from How to Solve It; if you haven't read, drop everything and get a copy.)
Somewhat orthogonal to your point, but it is interesting to me how easily some will dismiss perspectives or ideas by referring to them pejoratively as "western".
I think you’re projecting. I’m not sure how I could have caveated my statement more than I did — I am not dismissing the perspective I describe as “western” at all, merely noting the existence of alternatives that may offer other perspectives on the question at hand.
> The main point of the proposal was always clear up front. I was not the one deciding on KPI's it was a joint choice.
Which is exactly the parent's issue with their statement "I always make it clear". Many rev share negotiations break down quickly due to the nature of these deal:
- The profit maximizing buyer of said services has little incentive to pay you your "fair" share, EVEN if they do in fact create more revenue because of said services effect. They'll find every way to pay you as little as possible within the bounds of your contract.
- A buyer of said services rarely will rarely let you into their financial systems to validate. Even if they do, financials notoriously are easy to manipulate/game (ever heard of Adj. EBITDA?). The overhead of financial clarity is rarely worth the headache. Heck, most businesses internal operations rarely can create clear ROI their projects when they used internal resources much less using external resources.
- There are so many hidden variables that it's nearly impossible to control for your impact. Let's say you help reduce a company's EC2 instances from 10 to 7. Savings...great! Now the company grows and they need 8 EC2 instances. Did you still save them money? Down the rabbit hole we go...
I get what you're saying but you're living in a vacuum if you think you can universally demand that type of contract. They're possible but require the stars to align.
Note - I'm talking specifically about professional services / consulting work.
Hmm, I found it uplifting. I'm not in the startup space, but I feel like I have been struggling with prioritization, without really understanding what I was struggling with. In my case, the constant tugging from one operational crisis to another has made it difficult to focus on long-term goals, and I need to learn to let others fight their own fires from time to time so I can prioritize tasks I know will have an out-sized effect later. Guess it's just a matter of perspective!
good thing you brought that up. I have not read the article, so not sure if I like it. However, a lot people read articles not for thee information, rather style or flavour. I guess this is one those for you. Most stuff online don't really have anything new to say, it is also mostly PR or marketing sometimes.
I always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and mock a set of back-end REST apis, while another team builds out a the back-end. There are absolutely tradeoffs, and being a good software engineer is about understanding where and when those tradeoffs apply.
That's definitely true at the organizational level, and it's an argument with some merits.
In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it!
My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".
that sounds like a mismatch between the architecture and how work is getting planned no? if the backend is in the critical path to delivering the user value of a feature then the backend and frontend engineers need to be developing (and testing) the feature together
They ALWAYS need to be building and developing the feature together or this happens. Decent API design without deep understanding of Client implementation or performance needs is nearly impossible.
They generally should all be in the same team, but that often doesn’t scale.
Not having them in the same team pretty much never works well though either.
It's not about being unique, or what you can/can't do. You certainly can mock a front end with a ssr app, but it gets messy when you are building a rich client app and need to start sharing state back and forth.
Why not eliminate that organizational bottleneck by using a full-stack framework that lets one person do it all? DHH recently described Rails as a one-person framework [1]. I think Phoenix fits that category as well.
Yeah whenever these SPA-slamming posts come up, I just try to imagine carpenters posting about why they switched to hammers from screwdrivers. They're just different tools that excel at solving different problems.
To use your analogy, what if a popular screwdriver company started a trend among young carpenters to use their screwdriver handles as hammers? And then large numbers of carpenters were driving nails with screwdriver handles instead of hammers?
That is where the SPA slamming is coming from.
It's not that people fail to grasp the concept of different tools for different jobs.
As I said in a sibling comment, the problem is that some SPA-developers then see everything as one type of problem (I said nail there, but using your analogy, screw works better). Carpenters will tell you that screws aren't really superior nails - certain applications actually hold up better with nails (interesting enough for this analogy, those with a lot of side load, where screw heads may actually shear off)
I don't have anything to contribute or collaborate on, but just wanted to thank OP for the excellent idea, this looks like it really hit upon a community need.
I basically have all the collaborators that I need, for the projects that I'm working on, but I think that it is a great thing, to encourage altruistic development.
It is my experience, that free work should be as good as (or better than) paid work. This is code quality, executable quality, documentation and support quality, user experience quality, etc.
I have found that many altruistic projects have great heart, but can sometimes fall short, in quality. Maybe as a result (or maybe it's a cause), they are often not taken seriously by the people that could most use them, and this can also make it difficult to get folks to take high-quality work seriously (I have a lot of experience with that).
When looking for collaborators. Tecchies often seek out engineers, but maybe they are better served, seeking out advocates, artists/designers, writers, testers and integrators.
In my experience, recruiting evangelists in the user community is incredibly valuable (and difficult; especially if "people skills" aren't our top talents).
We can also do damage, by pissing off these folks (I have done that). Free/Open/Altruistic projects can often be rather fragile, as motivation and engagement are the currencies we use. These are easy to dismiss or denigrate, when we are used to the traditional motivators of paid work.
It's by far not the first scene done in any ray tracer, rather an early test scene for radiosity (diffuse-only global illumination, before path tracing was developed).
I'd guess the Utah teapot, it's been around since 1975. Cornell box is from 1984, and test scenes for materials are in some way a pretty recent thing, at least how they are used now; to me the modern versions started with Maxwell Render.
These are wise words that I needed to hear after a hard day and feeling like I've always been getting the short end of the stick lately. Thank you for writing them.