We need both! In the meantime, I like the idea of ending subsidies for fossil fuels since it incentivizes building a moonshot technology that everyone can adopt, and curbing our reliance on them so that we have time to build better technology.
In certain cases. For example, there are some people at Equifax that should be held accountable. Doctors and perhaps civil engineers can be held liable in the US.
I can definitely understand why a team could dissolve. But there are really only upsides for employees to understand why they're being paid X and to be able to model their behavior after the person that gets paid Y.
Not necessarily. I once found out how much one of my team members made that started on the same day in the same role as I with the same amount of experience (the HR manager left his most recent offer letter open on her screen about a year and a half after we started). He was making about 66% more than I was (not an exaggeration) and our output was pretty comparable. Needless to say, modifying my behavior to be more like him wasn't the first (or 100th) thing that came to mind.
Was it fair? Who knows, it's not really possible to debate that because it all depends on your definition of "fair". But in my experience, it's not very realistic to assume that employee A sees what employee B makes and objectively understands how they need to improve to make what employee B makes. Especially since that's not really how pay is negotiated anyway.
The point is that what a person is paid isn't entirely determined by their behavior at work. Much of it is, in fact, determined by their charm, network, prior history and negotiating skills: none of which necessarily have anything to do with their day to day.
but the external market breaks that you might need to hire a new person when the market is hot and they will be paid more than some one hired in a recession
A friend told me about their big company's interview process for interns from Ivy Leagues, which was getting flown out to a party and then getting an internship. The candidates weren't asked any technical questions, since they were assumed to be smart enough to learn how to code in bootcamp. It made me feel confused about myself for a while, since I didn't have a job or much experience and it was hard enough getting a phone screen.
Did you come up with a solution for recompiling the clojurescript files only when cljs and cljc files were changed? The watch task fires whenever a file in the resources or src directories changes.
Tasks in Boot cache their own products, so while the watcher task fires the rest of the pipeline whenever a source file of any kind changes, each task is smart enough to use its own cached compiled files. This is because only the tasks themselves can ever really know the relationship between source files and the compiled artifacts they produce.
So in practice things are only recompiled when they need to be recompiled. Even though the watcher task is firing, no real work is done unless it needs to be done.
No I haven't. Is this a big issue? I guess it would be nice if watch could take a filter. Since cljs uses incremental compilation it shouldn't do anything if non-cljs files changed.
I retract the statement that Rich uses Cursive. I misinterpreted a tweet a while ago, and hope that I didn't cause too much harm. Instead, I'd like to say that Cursive is extremely nice and that you shouldn't let Emacs scare you away from Clojure.
I don't understand. That's exactly what domain modeling is. Putting names to the data you need to store and, in this case, capture at a particular moment in time.
Let's put it this way. Do you think it is reasonable to store the taxes as a reference, or the shipping cost? We would never consider it appropriate to say, "Go look up the shipping cost for a 5lb package from here to here." Oh, and by the way, this is using a live reference to a customer object, for which the shipping address might very well have changed.
Of course we would not do this. So why would it appropriate for a product price? An invoice is the capture of all this information at the moment the purchase is made. That is its purpose. If we did not need this moment-in-time capture, then the concept of an invoice would not even exist.
Coming up with names for groups of data that we want to consider as atomic is what object orientation does, it seems to me.
I also think that that is its Achilles heel - by giving names to groups, only those privy to the internal representation of the atom can combine their functionality with its data. So you need to either merge your functionality with the atom's data (aka define an instance method) thereby coupling "things" with "actions", or you need to leak the atom's internals to outsiders (aka write a method somewhere else that "knows too much" about the atom's internal representation).
