DBCerigo

A much more in-depth, advanced, and more valuable imo, article on the same topic https://medium.com/@porteneuve/getting-solid-at-git-rebase-v...

@mtlynch what tool/service do you use to enable the "TinyPilot’s in-house developers report their hours at the end of each working session" part of your business's workflow?

"For data scientists and data engineers, d6tflow is a python library which makes building complex data science workflows easy, fast and intuitive. It is built on top of workflow manager luigi but unlike luigi it is optimized for data science workflows."

But they didn't really explain/sell what those optimisations are in the readme.

Very much echo this, specifically that I’ve found it’s always better to take a worse paying project I’m stoked about making happen than a higher date rate on a project I have no interest in. Having intrinsic motivation to work rather than having to _force_ myself to work on something is easily worth a drop of £100-200 p.d. imo. (That amount presumes the lower day rate is still something I can live off.)

I haven't found that this has hurt my CV, or more specifically my ability to get hired by subsequent startups, at all, in fact the larger amount and larger variety of my proven expertise from working at multiple startups for relatively short periods seems to have only increased my ability to land jobs. And further, the varied experience I got at them has very quickly removed the ross-tinted view of the startup world and taught me hugely on what to look for and what to watch out for.

Disclaimer being that in each instance I joined in good faith, worked hard and added value to the company quickly (at least in the companies eyes), did my best to pragmatically resolve any major issue that happen to arise, and left once those resolutions reached a roadblock and that I felt I had made all reasonable attempts to fix things. On reflection it was always just a case of losing faith in the leadership of the company.

My advice to anyone starting out would be to do your best due diligence (read about it) before joining, but knowing that you'll only get the real workings of place from actually working in it, and especially if you are inexperienced you will have likely overlooked some subsequently obvious warning signs (I sure know I did in the past!). Throw yourself into it 100%, get established, then assess the situation. Always do your best to give everything the benefit of the doubt, and be open to being wrong, until you really just have to admit that you're right (or in reality you _think_ you're right), then move on if you have to in the most considerate way possible.

Future founders/leadership that I would want work with would (hopefully) understand my decision-making at those times, and would be confident enough that they could instil the motivation in me to continue to follow them long term.

For those inclined to disengage with Google and its products, this is a previous HN post on exactly that: https://news.ycombinator.com/item?id=17280558

Wondering if we (as a group of people who will face many non-competes) could generate a standard response to these kinds of clauses in employment contracts, which could be more effective then everyone rolling their own.

I made a (pretty bare for now) repo for it if anyone is interested - https://github.com/DBCerigo/non-compete-standard-response/bl...

@FunTasKid: I hope we see can more software being made to help people work more harmoniously with however their brains work, rather than trying to change them to some norm...

Not Postgres, but I also found this significantly (if not more) enlightening while I was building my first RDB using SQLite http://use-the-index-luke.com/sql/anatomy

Could you tell us more about YC Research? Such as (but definitely not restricted to);

- Initial starting size

- How you will be picking researchers

- Any particularly novel initiatives/methodologies that will be encouraged

- How you will measure the group's success