831 karma · joined February 15, 2016
Junior folks bring their own energy, flexibility, hunger for learning and the resilience to unclear future. As folks get more mature, growing egos, stability expectations, tendency to settle down can get in the way.
Overall, this boils down to the fact that teams and people are not just head counts and there's a factor of chemistry need to be considered depending on the culture, founders, geography and the business itself.
I tried checking the content with my kindle (a Kindle Touch paperwhite 6 inches) and the first chapter rendered pretty good, with images and text aligning as intended. However the second chapter did not render the first figure and beyond. Chapter 3 rendered OK, similar to Ch 1.
A few more feedback if that helps for enhancing the format even more: - Colors, and references to those do not work on a kindle. I only saw one minor use of colors (red, green) in Chapter 1 so that's not a blocker. - For some reason, the kindle browser doesn't put left and right margins on the page, so the text uses the full length of the device. - Links are rendered with a pale gray, sometimes hard to distinguish. - Figuring out why the Chapter 2 did not render would definitely help.
It allows me to quickly keep a GTD-ish list of stuff going on and action items needs to be taken and I can organize them as detailed as needed with labels, colors, etc. I find the simplicity/features ratio work well for me.
Getting Things Done method by David Allen
- Using voice, body and mimics properly
- Not putting lots of text on slides and just reading them
- Using bullets instead of paragraphs
- Tell a story and use a less formal more friendly style (not always but applies to majority of technical presentations)
A nice video about the topic: https://www.youtube.com/watch?v=vB2pl1QbY3I
It borrows all the best practices from PostgreSQL the naming of variables and functions are more self-explaining in general.
I also believe that the practices around PRs and code reviews are also good examples.
1) Relational databases are more flexible: you model your data according to the actual "relations" between them, instead of how you want to query them. This makes it easier to add new views/queries to your application.
2) Joins are necessary
3) In a very short time, you need complex authentication logic and it is very hard to do it without looking at the requested (and related) data directly. Best way to do this is a good-old rdbms + server app
4) Moving more logic from servers to clients forces you to be more careful about client versions, duplicate logic among different clients (iOS, Android, Web, Dashboard)
The subtyping feature I love the most. You see the benefit when you need to call a function which is taking many numeric arguments, all of them is a subtype so you can't give the arguments in the wrong order (latitude and longitude for example).
If it is so important to be able to find the pitch of a github repo, just put the link in README.md.