Two reasons that come to my mind:
1. legal burden of hiring globally
2. while allowing remote work, the company might not be set up for asynchronous communication
I tried to follow the concept of minimalism a few years ago. For everyone else who is struggling with it: don't stress out because you can't live with one backpack.
Yes, you can get rid of a lot of stuff and you should do it, but don't do it too extreme. I don't want to live without my music instruments or my sports (which requires a lot of gear) - don't fall into the trap as I did and feel bad for owning it.
Start small and collect all the stuff you didn't touch for more than 1 year - don't throw it away, just put it in the cellar and after a few months realising you don't need/want it give it away.
There are also probably a few things you want to keep even if you use them less than once a year, just because either a) when you suddenly do need them you really want them on hand, or b) they're really expensive to replace every couple years, and a PITA to borrow or rent. There are also (c) some things with fuzzy definitions around the term "use" and (d) items with sentimental value.
For me, category A includes things like the toilet plunger, flashlight, certain OTC medicines and first aid supplies, and the like. A few flattened cardboard boxes. A couple faded old towels. That step stool in the back of the closet. An extension cord.
Category B includes a minimum quantity of formalwear (tuxes may be easy to rent; heels that don't cause bleeding are another story), snow gear or an emergency generator in certain climates, perhaps certain types of cookware, etc.
As for category C... you don't use houseplants, but having a couple around can work wonders for your quality of life. The same goes for a poster/painting or two to liven your environment, or a few framed snapshots of family and friends. These aren't things that complicate your life - once you have them they don't cost money or significant time to maintain; there's no real pressure to keep accumulating more - and they're good for the soul.
Which is also why category D is important. Yes, you need to let go of things, and no, you shouldn't keep that takeout carton just because your ex touched it. But there are some things - that art project your kid made, or the cufflinks your grandfather left you, or the scarf your mom knit you the year before she died - that have value far beyond their utility. The challenge there is to decide which ones are really important.
But there is stuff most of us should be much more ruthless about getting rid of (living in a small apartment can help develop the ruthlessness habit; so can moving frequently). Top of the list for many of us is clothing. Stuff for hobbies we wanted to take up or just never get around to. Small kitchen appliances. Electronics and gadgets. Knick-knacks and collectibles. All the stuff you keep accumulating more of but that don't actually add anything to your life.
> but they definitely seem to be underpaying in general
Interesting that you say that. I can't speak for US area, because I live in Europe. Looking at the Spain salary, which is about 110k seems pretty good to me.
Working as a senior frontend dev in my area (which has similar costs of living as Barcelona) gets you payed about 30-40% less than that.
How good is the "Blueprint for Phoenix Context" part? I am already working with phoenix/elixir on a daily basis and would be only interested in good examples with contexts.
The costs don't hurt, because everyone's pay is good. (Example: Cleaning personnel and waiters make more after taxes than engineers in Germany...) and taxes are so much better than anywhere really. And you meet smart people mostly.
When checking out a new branch or planning a new feature - ask yourself, if you would deploy it today and the customer sees it - will he notice it/benefit from it.
Of course this does not work for all features/long-term things, but it helps to look at it from a customer perspective.
First focus is: customer gets his job done (core features & UX)
Second focus is: customer is happy using your product (these are all the other things that are nice to have + UI).
Serious question: How would you suggest to write a test that prevents this?
You wouldn't make an assertion on clearTextPassword !== passwordHint. While developing I would think "Who will ever do that? That would be insane".
But yes, even if there is no test, this should have been caught in code review or latest when testing the OS.
Yes, with 'example based testing' this is hard to come up with. With property based testing, it's not so hard to test this kind of UI things:
You test a UI by basically throwing sequences of interactions at it. Some of the properties you'd want to assert:
* Given two interaction sequences that only differ in what they do to the password hint field in the UI, the result should only differ differ in the returned password hint. (Or alternatively neither should finish the UI dialogue.)
* As a dual: two interaction sequences that share the same interaction with the password hint field should yield the same password hint field. (In this case it is acceptable for them to differ in whether they actually finish the dialogue.)
Those two are fairly generic, so you can imagine setting that up as a general framework for all your data input fields in your UIs. It should work backwards as well, eg to assert that eg the UI should look the same no matter what password (/ password hash) is stored, to make sure you are not leaking any information.
As for 'should have been caught in code review': yes, but humans are fallible and they should get all the help we can give them. To see for yourself, have a look at the example (a simple runlength encoding) at the top of http://hypothesis.readthedocs.io/en/latest/quickstart.html and see whether you can spot the obvious error just by reviewing the code.
I think I might have stumbled upon a new category of common properties here. (At least new to me.) Basically, test that some subset of your output variables is a function of a specific subset of your input variables. And conversely, test that some subset of your output variables is independent (under some conditions) of some subset of your input variables.
My go-to example for property based testing isn't addition, but idempotence. Idempotence is a concept well known from REST apis to the general programming public, and also in sorting or clean up data. And it's easy to state in code, eg: sorted(sorted(x)) == sorted(x).
It seems like the error was in the creation of an intermediate data structure ( minimal dictionary something) in a storageKit framework. I’m not talking about the disk util app ( which doesn’t contain any bug in itself apparently)
To give a better answer : I’m not knowledgeable of the whole source for the framework, but there are only two cases :
- either the outputs of your critical function are testable and then just test it.
- or they’re not ( most often because of side effects), in which case you should extract the critical part in purer function, and test that.
It’s a great benefit of unit test : they force you to isolate side effects from business logic, to be able to test the latter.
In that case, if the function isn’t testable, then maybe the creation of this intermediate minimal dictionary should belong in its own function that just does the data mapping.
You wouldn’t need to test it like that. What’s missing here is simply a test of that StorageKit API that the GUI uses. The test would be straightforward: set all the options and see if the resulting volume is created correctly. So for the hint your test would generate a value — a good test will exercise a range of values over multiple iterations — and verify the hint on the created volume.
No doubt this basic test was done on the command line API, which works correctly. It’s likely the problem here is they created a separate StorageKit API just for Disk Utility to use and got sloppy with the unit test for that. A good example of why it is a good idea to try to have GUIs and command lines use one code path whenever possible.
I have developed a UI test automation software years ago, it should be getHintFromUI() == passwordHint.Here getHintFromUI is a function which get string from User Interface directly.
I noticed when I upgraded that they block you from setting your account password to the same as your iCloud password, so they've obviously considered that people will do stupid things.
How about a simple test giving the function a set of parameters and then asserting that the output dictionary (besides the password hash) equals the expected output? That would have caught this case with ease.
For VIM: I am using CAPS Lock now as ESC key, because there is no physical ESC Key with the touch bar anymore.
Generally: I configured my touch bar to match the old keyboard function keys layout & they never change, no matter if I switch the program. I just don't want to change my behaviour + can't deal with the fact that I can't quickly change volume/brightness + hit play/pause/forward/backwards keys.
Isn't a dealbreaker if you use it like I do and set a global touch bar configuration, which doesn't change.
Only useful feature of the touchbar is Touch ID (which works very well).
However, regarding your question about productivity: no it doesn't increase nor decrease with the touchbar (especially if you can work with caps lock being the ESC key in vim).
