handbook | yeti | |
---|---|---|
13 | 1 | |
6,276 | 8 | |
0.2% | - | |
8.7 | 4.3 | |
3 months ago | 7 months ago | |
Haskell | ||
GNU General Public License v3.0 or later | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
handbook
-
The 37signals Employee Handbook
As of the writing of my comment, 2 days ago:
https://github.com/basecamp/handbook/commits/master/
-
Designing a team that would produce software of good quality: set up dogfooding
37signals went even further, they build products for themselves first:
- Realizing I actively dislike this industry, but feeling trapped by the salary. Anyone pushed through this? What kind of roles does this skill set transfer to if you wanted to leave tech?
-
Spas Were a Mistake
That's definitely true at the organizational level, and it's an argument with some merits.
In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it!
My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".
- Basecamp Updates Code of Conduct
-
POS CEO? Piece of shit CEO?
The link: https://github.com/basecamp/handbook/pull/106
- “About one-third of Basecamp employees accepted buyouts today”
-
Basecamp implodes as employees flee company, including senior staff
https://github.com/basecamp/handbook/blob/63e97c8210465a5e7f1731eac76e6d9d9e20d29b/benefits-and-perks.md#profit-sharing
-
Basecamp can't seem to touch base with some very public updates to their company's rules.
No more paternalistic benefits. (Benefits like fitness allowances, wellness allowances, and notably not mentioned in their blog post, charitable donation matching. Instead that's changing to 10% profit sharing. As an aside from yours truly, this means those benefits only will do as well as the company does. Company has a year with a loss? Whoops! No profits to share.).
yeti
-
Spas Were a Mistake
I agree. I've been thinking about this lately, and have implemented something I think is interesting in Haskell.
https://github.com/seanhess/juniper
It's an implementation of Elm (imagine React if you're a JS dev), but all logic is executed on the server. State is passed back to the server whenever you choose to listen to an event. The view is then re-rendered and virtual dom diffed on the client. Non-interactive pages are just views. If you want them to be interactive, you add a Message an update function.
I used it on a client project and it was pretty delightful.
It probably isn't documented well enough yet to make total sense, but I think it's a step in the right direction.
What are some alternatives?
live - Live views and components for golang
Novo-Cantico - New kind of web development framework
inertia - Inertia.js lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers.
Apache Wicket - Apache Wicket - Component-based Java web framework
react-rails - Integrate React.js with Rails views and controllers, the asset pipeline, or webpacker.
htmx - </> htmx - high power tools for HTML
sanity - Sanity Studio – Rapidly configure content workspaces powered by structured content