bcbrown

I've worked with a S3 + SQL system. It was used for serving data for a reporting dashboard where the stored data was in the 0.1-10 TB range. As the use case was only semi-interactive (users didn't mind waiting 1-10 seconds for a report), and all the queries were pre-defined, this solution was a good fit.

I think it makes sense when there's no in-place updates; either querying write-once data like logs or the output of batch data processing roll-ups that replace the previous data. The less you need the relational model (like joins), the better, but some of those needs can be met through careful design of the storage schema and denormalization.

I wouldn't advocate this sort of solution if your requirements include in-place updates of existing data, frequent/granular updates of new data, expressive ad-hoc queries that use the full capability of relational algebra, or tight latency requirements. You also lose the safety net of referential integrity and table-level constraints, as those are now enforced in custom code that can have bugs.

I would say maintaining this system cost about a half-engineer for ongoing maintenance and new functionality.

Look at the books published by the Harvard Negotiation Project:

Getting to Yes in 1981. Getting It DONE: How to Lead When You’re Not in Charge was published in 1998, Difficult Conversations: How to Discuss What Matters Most in 1999, and Beyond Reason: Using Emotions as you Negotiate was published in 2006

https://en.wikipedia.org/wiki/Harvard_Negotiation_Project

I've experienced this phenomenon. While competing at powerlifting, my field of vision shrunk to just the platform I was on. I couldn't hear the crowd or my family cheering. It was an incredible, transcendent experience that I would liken to an out-of-body experience.

I credit the experience to the immense amount of visualization I went through in the two months leading up to competition. Every night I would visualize the entire day of the meet, every little detail of the whole process.

I also spent a lot of time reading Zen and the Art of Archery: https://news.ycombinator.com/item?id=17417410, and absolutely used those techniques. The whole motion should be effortless and spontaneous, "like a dewdrop slipping off a leaf."

You can use regex ranges to match every line between two regexes: https://www.gnu.org/software/gawk/manual/html_node/Ranges.ht...

Another option might be to use multi-line records (https://www.gnu.org/software/gawk/manual/html_node/Multiple-...). First pre-process the file to add an empty line before each header, then use blank lines as the record separator and newlines for the field separator.

I actually wrote a sed utility to collapse arbitrary whitespace before piping into cut before I learned about Awk. I never knew about -w before, but looks like neither of the systems I'm currently using for work support it.

Ask people to give you demos of what they're building. Schedule 30 minute 1:1s with as many people as possible, 1-2 a day. Write down what people tell you as much as possible; even if you don't go back and read it, the act of writing helps it stick.

I found it just to be a good reminder that chasing "GitHub streaks" is ephemeral meaninglessness, although it was counterintuitive behavior.

However, it gets removed when you're removed from that private repo, I believe. A prior employer used Github, and my worked showed up on that activity graph thing, but when I left, it all disappeared.

> the Swallows and Amazons series

Wait, that was a series? I vividly remember reading that book growing up, but I never knew there were more. I know what I'm going to be reading this summer!

Wittgenstein, Gerry Weinberg, Korzybsky, and The Systems Bible by John Gant. Gregory Bateson.

One approach I sometimes take is to make the refactoring in one commit and the change in another. They can go into the same PR (within reason), but they're clearly separated out.

> it is nightmarish to toil through some tightly coupled mess and try to rewrite it in a manner that is more maintainable.

I'm doing that right now, and it's great. There's several responsibilities that are all tightly coupled, and I'm pulling them into multiple components. It's requiring a lot of code archeology and reverse engineering of intent, but it's incredibly satisfying at the end.

One mentor of mine taught me the "rule of three". The first time you have to do something, you write it in-place. The second time, same thing. The third time is when you refactor into a common module all three components can use.

When you're writing it the second time, you're accruing technical debt. You pay it off when you refactor for the third component.

> A philosopher is not necessarily made by a fork dispenser, but it is initialized by a fork dispenser.

That made me laugh. When a fork dispenser dispenses philosophers, your data modeling took a wrong turn somewhere.

Here's a neat bit of Python abuse I stumbled across recently... you can define a method to return itself:

    >>> def recurse():
    ...   return recurse
    ...
    >>> recurse
    <function recurse at 0x1083b5f28>
    >>> recurse()
    <function recurse at 0x1083b5f28>
    >>> recurse()()()
    <function recurse at 0x1083b5f28>

Along the same lines, decide what the bar will be for promotion, tell them where they're lacking, and when they reach that bar, promote them.

> It makes me wonder how we communicate at all when no two people ever quite speak the same language.

You should read about Wiio's Laws: http://jkorpela.fi/wiio.html

Read https://www.amazon.com/Flow-Psychology-Experience-Perennial-.... Turns out it's actually mostly about finding meaning in life.

You might find this book interesting: https://www.amazon.com/Seeing-Systems-Unlocking-Mysteries-Or.... It's a great view into the differing perspectives of executives, middle managers, and ICs.

Ask for examples of good reviews to emulate. Look at the PR without comments first, and give your own review. Then compare with the original review, and see what areas you emphasized more, and emphasized less than the original review. Talk with the original reviewer, and ask about mindset behind why they asked for the changes they did.

Also, read a lot of code reviews. Just like reading a lot of code is helpful for becoming a better developer, reading a lot of reviews is helpful for becoming a better reviewer.

By definition, any car that makes an update to a map has experienced an out of date map.

I'm reading the Aeneid right now, the Fitzgerald translation, right now. It's good but the poetry isn't as enthralling as I found the Iliad and the Odyssey.

One aspect I found really interesting was how Virgil was claiming Trojan heritage for Rome. I don't think that claim has any factual basis, but I haven't researched it. Another interesting aspect is how it's a vehicle for promoting religious and cultural behavioral norms. Occasionally Virgil steps out of the narrative briefly to praise or condemn someone for following or breaking behavioral norms.

I greatly enjoyed The Hero with a Thousand Faces. Reading it caused me to buy collections of folk tales from several different cultures.

I really like this method: https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78...

> Anything that can be reversed, I reverse roughly 50% of the time

For me, it's any arbitrary, binary, convention. Left and right. Clockwise and counterclockwise. \ and /. Whether time zone offsets are added or subtracted from the UTC time. Interestingly, < and > never gave me a problem, perhaps because I've internalized the alligator mnemonic you mentioned.

pavlov's account was created 3130 days ago; that's 8.5 years. BartSam's account was created 37 days ago.

¯\_(ツ)_/¯

The sci-fi book The Dark Forest (sequel to the Three Body Problem) discusses this problem. I don't want to give away any spoilers, but I found a lot to agree with in the book.

> > Call your shot. Before you run code, predict out loud exactly what will happen.

> M, okay, but what exactly do you mean by that?

I frequently do a variant of this, although not always out loud. One way to debug a problem is to randomly vary various bits of the program until the problem no longer appears. Another way to debug a problem is to use the scientific method: develop hypotheses, then test those hypotheses with an experiment. I think he's saying to develop hypotheses, and then run code to test them.

edit: https://news.ycombinator.com/item?id=11859090

I have dry eyes, and I've been been working as a developer for close to a decade now. I use eye drops several times a week, and about once a week, in the shower, I use this: http://www.theratears.com/sterilid/. It hasn't been much of an issue for me.