limist

Back in the late 2000's I looked around for the right tool for my Ph.D. dissertation and quickly ruled out Word, Libre (or Open Office) Writer, or any wysiwyg tool, because they 1) lacked fast, easy ways to work at the structural (tree) level of the document, which is important when you have many sections and subsections to organize thoughts and arguments; 2) couldn't do mathematical notation well; 3) didn't integrate well with the reference management tool I was using then, Mendeley.

As an Emacs lover, I soon found Org, and it was (and remains) the perfect tool, for working in plain text — which will never be obsolete, and works easily with git or version control. Then and now, nothing could match Org speed and flexibility: structural editing (creating nodes, moving nodes, promote/out-dent a node, demote/in-dent a node) was and is fundamental to Org (unlike Markdown etc), and it's ridiculously easy to reorganize thinking and writing as you go. You can export to LaTeX (or HTML) and customize formatting as needed, while also including code blocks from multiple languages. Integration with BibTeX was tight, and made handling hundreds of references easy.

Where other writing tools for complex documents previously made me cringe and cuss, Org makes writing a pure joy, freeing the mind to work entirely on content and its structure.

Character (integrity, drive to learn & improve) and skills that you respect or admire. Then shared values and life situation: the startup should be the #1 priority for everyone on the core (full-time) founding team. Missing any of those requirements increases the risk of failure.

Unfortunately for those without a wide/deep network of college friends, former colleagues, etc. it's hard to judge character and skills without a previous friendship or shared work environment, etc. If you're forced to evaluate a potential co-founder in the absence of shared history, work on something small together for a few days/weeks and see how it goes.

Another thing to do in all cases is to discuss downside/failure scenarios right up-front, and see if there's a sense of openness and fairness. Check out the books The Founder's Dilemmas and Slicing Pie for structuring the conversations, as they give vital ideas and precedents around formalizing the founders' relationships. It's much easier to chat about failure and equity before real work starts, and I've seen many times that it flushes out assumptions and behaviors that you won't want on your team (assuming you're the reasonable and fair one :-).

It's not bad - I read this book a while ago to boost my Python-fu. But it left me feeling like most software/language books - unsatisfied, i.e. here are the pieces (syntax), here are a few (boring, trivial) ways to put the pieces together, etc. To give a really strong CS foundation, SICP still rules. :)

Short answer: There's a mix of people, and a few are students (college or graduate school). Some are remote coders. Some are doing startups. And some quit their jobs to come to Berlin. :)

Thanks for the compliment. We certainly enjoy socializing, but effective learning and working take precedence, and we expect an atmosphere of "enthusiastic intensity" at HRet.

The people at MSV have been cool with us. And while they certainly want to have visibility for their program, they've given us all the freedom we need in using their space.

Yep, they target a different audience. They're more for beginners who want an apprenticeship in coding. Whereas Hacker Retreat is for intermediate and advanced coders who have their own projects, and want to learn and apply advanced techniques.

No. There's no product showroom there, just a cafe on the ground floor. Hacker Retreat is happening in the space above, where MSV's incubated startups usually are. They agreed to let us use the space in between their startup rounds.

Thanks! We think at least a few people from our last Fall batch would agree to that. We're intending more people to say that when this next session/batch is done.