bcbrown

I was camping in Badlands National Park when a thunderstorm rolled through and lightning struck about a thousand feet away. The next day I went exploring to try to find where it hit. After crossing a stream and hiking up a small butte, I watched what looked like a golden eagle soaring on the wind looking for prairie dogs. The coolest part was that because I was up on a butte the eagle was beneath me and I could see it from above.

If you're interested in trying Campari in other settings in order to acquire a taste for it, I would suggest trying a Jasmine: http://drinkboy.com/Cocktails/Recipe.aspx?itemid=88

Fantastic books. I highly recommend Mind and Nature.

https://github.com/bcbrown/bookreviews/tree/master/2016 https://github.com/bcbrown/bookreviews/tree/master/2017

I attended a talk at Strata a few years back by a Spark committer who was talking about how Spark was stretching JVM memory allocations far past how the JVM was originally designed. Do a couple searches for "spark JVM OOM" and you'll see some discussions about similar things.

Someone's already doing something like that: https://www.washingtonpost.com/lifestyle/home/this-florist-s...

I use index cards to write out quotes I want to preserve.

You might find https://en.wikipedia.org/wiki/Garden-path_sentence interesting.

You're not. Market makers really like filling orders for small-time investors because it's really unlikely that a small-time investor knows more then the market maker. They don't like filling orders for big institutional investors because those guys might know more than the market makers, and the market makers might accidentally give them too good of a deal.

Italo Calvino isn't an exact match, but you might want to try out The Nonexistent Knight or The Cloven Viscount to see if it's close enough.

I have two answers to that:

Measure and adjust: Find a source of high-quality code reviews; the easiest source may be the high-level engineers at your employer, but if that's not possible/helpful, I'm sure there's free/open sources. Make your own code review before reading others, then compare and contrast. What did they flag that you didn't notice? Can you generalize to categories you could prioritize more? What did you flag that they didn't? When you both flagged the same thing, whose phrasing was more helpful?

More personally, here's my approach, which may or may not be helpful for others:

* First, skim the entire PR. On a raw, visual level, get a sense of what it looks like. A couple big edits, or a bunch of small updates (like changing a variable/method name, changing an imported library, re-ordering some interaction, etc)? A bunch of indentation changes without much else? An extension of an interface? This is to familiarize myself with the general question of Just What's Going On Here, basic context to use as the foundation for the real review. This should take just a minute or two.

* Second, perform a close reading of the diff. Don't worry about high-level conflicts like ordering of operations or other semantic considerations; stick to syntactical-level concerns and context-free mistakes. Are the variables and other symbols well-named? Is exception handling done properly, is this library not initialized correctly? At the "fit and finish"/polishing phase, this might be the majority of the effort. At the early-draft stage, it may be counter-productive to actually note all the possible issues. Either way, to use an analogy to compiling source code, the goal should be to build an AST of the diff, so you can begin to build a model to manipulate through the rest of the review.

* Lastly, address the higher-level qualities. Depending on whether you prefer a bottom-up or top-down approach to design, you might order this section differently. I tend to try to identify where on the abstraction scale the highest-leverage feedback resides, and then focus on that level. Depending on context, that could mean discussing which component needs to change, which repository/module this change should live in, which classes should be changed/created, what's the behavior of specific methods, etc.

Whatever your feedback, consider what you hope to accomplish with the comment. Are you trying to educate someone about an idiom they don't know about? Ensuring correctness of a complicated interaction? Maintaining a common code style or test coverage threshold? Make maintenance/debugging simpler? Is this something that you view as blocking, or is it more of an FYI? If the latter, it's pretty important to communicate that clearly.

> Gabriel Garcia Marquez, Neruda, Borges, Italo Cavalo, Umberto Eco, Marukami, Junichiro Tanizaki

I know and love all those authors, but have never heard of Junichiro Tanizaki. Where should I start with him?

Read "How To Read A Book", it has a lot of good techniques.

That doesn't mean they had that amount of capital under investment.

If you bet $10 every week, and every week you win $11, at the end of the year you've bet $520 and made a profit of $52. But you never had more than $10 "invested".

If that $18 million was evenly spread out over 7 years, it would be close to $50k/week, or $215k/month. Those are probably more accurate amounts of working capital for calculating ROI.

Systemantics/The Systems Bible, by John Gall, for a lighthearted, whimsical introduction through real-world examples across a range of industries. An Introduction to General Systems Thinking, by Gerald Weinberg, for a more rigorous/structured introduction.

I've heard good things about Donella Meadows, but I haven't read anything of hers yet.

I'm a pretty decent touch-typist, but I have some hiccups when using the symbols on the number bar (@#$%^ etc), or brackets, or other stuff that's common when programming but uncommon in most texts used by touch-typing programs.

So I wrote a little program to download source code from Github and allow you to type along with it, and measure the number of typos. It's super old, half-finished and was one of the projects I used to learn Python, so the code is hot garbage and unmaintained, but it might be an interesting thing to look at and use if anyone wants to practice touch-typing on source code:

https://github.com/bcbrown/CodeTyper

Hell, if anyone's interested in using it, maybe I'll pick it back up and improve it.

> We have looked for more Elixir developers. They are rare beasts. But we have a lot of Python developers.

Was there any consideration of training up the Python developers on Elixir?

That's one thing that the concept of federalism addresses. The ability for cities and states to experiment with different policies allows the federal government to wait and see which experiments bear fruit before rolling them out nationwide.

The best way I've found to handle that is while scheduling the final interview. The one that's further along, ask for the in-person to be a week later then they'd proposed. Try to schedule the two in-persons at the two companies within a week of each other.

The other (risky) way to handle it is to say "I understand that you need a timely response because you may have other candidates you need to get back to. If you need a response this week then unfortunately I'll have to withdraw from consideration, as I won't be able to get back to you by then." Of course, you have to really mean it, and you have to be ok with them going ahead and withdrawing the offer.

Ad-hoc polls, for one. Also useful for quietly acknowledging a message without sending a noisy notification. If I report an update to a supervisor during a production incident I'd rather get thank-you reaction then a reply that triggers a notification.

Do you have any resources or suggestions for better types of questions to ask, especially for individual interviewers without control over the overall process?

I try to avoid those sorts of questions, but it's hard for me to come up with better alternatives.

> But for example, when I write a particle system, how would I test that? Do I test all combinations of parameters and then compare them with images, which takes a million years?

Look up pairwise-independent combinatorial testing: https://github.com/Microsoft/pict

> But what if your "escape string" function has a bug that kicks in at exactly 15 characters?

Equivalence classes: Analyze which groups of inputs all exercise the same codepath, and test each group once. Boundary value testing: Anywhere there's a boundary between two different types of behavior, test the boundary, one less than the boundary, and one more than the boundary.

I added Lost Languages to my reading list, thanks for the suggestion.

If you're in Seattle, (or don't mind buying online) check out https://www.davidsongalleries.com.

Note, that last link is to a crappy "unofficial" copy of the book that looks like it was printed from Notepad; every page has a header of "On War.txt". Do not buy it, it's practically unreadable.

One of the things I really like about this approach is how well it lends itself to separating what needs unit testing from what is unsuitable to unit testing and should instead be validated by higher-level end-to-end/functional testing.

I think it's also related to the concept of building a DSL in which to implement business requirements. Once you have the right 'primitives' you can then combine them in useful ways that are easy to verify (by reading the code) that the implementation matches the requirements.

> js "wat" lightning talk (which I now can't seem to find...)

https://www.destroyallsoftware.com/talks/wat

Have you heard of the ideas in https://www.destroyallsoftware.com/screencasts/catalog/funct...? Essentially, his position is that it's only worth unit-testing those tricky bits, and the rest is inherently not worth unit-testing, because you'll almost-certainly embed the same assumptions you're attempting to test into the tests themselves.

In other words, I agree with you, but would question why you're even _trying_ to unit-test those other areas that aren't conducive to unit testing.

This seems like a good place to plug one of my favorite pieces of writing on communication and how it can go wrong: http://jkorpela.fi/wiio.html

I'd love to hear more about "A serverless Apache Spark environment". How is that set up? How long do those jobs tend to run for? Are those written in Java/Scala or Python? What are the pros and cons for choosing to go serverless instead of a dedicated cluster or ephemeral on-demand clusters?