ben_straub

Likewise. Pro Git 2e was written using Asciidoc, and it made it easier/possible to do things like indexing and figure titles.

Whoops, terrible formatting.

- 2004-2006: $40-45k. Writing C in an embedded context (barcode scanners). Local company.

- 2006-2011: $50k-70k. Writing C++ for device drivers and control panels. Japanese company, local subsidiary.

- 2011-2012: $80k. C# and SQL Server for an FBA/eBay selling tool, local company.

- 2012-2014: $130-145k. Working remotely for an SF company, writing C. Got some stock options which were worth 2 years of salary when the company was recently acquired.

- 2014-2016: $125-130k. VC-funded all-remote startup which didn't really go anywhere.

- 2016-present: $140k salary, yearly RSU grants worth about $50k at our current stock price. Public SF company.

OK, I'll do it. White male, living in Portland, Oregon. All my roles are software engineering.

- 2004-2006: $40-45k. Writing C in an embedded context (barcode scanners). Local company. - 2006-2011: $50k-70k. Writing C++ for device drivers and control panels. Japanese company, local subsidiary. - 2011-2012: $80k. C# and SQL Server for an FBA/eBay selling tool, local company. - 2012-2014: $130-145k. Working remotely for an SF company, writing C. Got some stock options which were worth 2 years of salary when the company was recently acquired. - 2014-2016: $125-130k. VC-funded all-remote startup which didn't really go anywhere. - 2016-present: $140k salary, yearly RSU grants worth about $50k at our current stock price. Public SF company.

None of these companies has required more than 40 hours of work each week, and starting in 2012 I've never had a vacation accrual or cap, and I usually take ~5 weeks off each year. I've been lucky.

Yeah, this makes me sad. I mostly listen to music when I'm working, and hearing the same mix of 50 "top hits" gets tiring really fast. 45-60 minutes of music that has some similarity and continuity is WAY better.

We've been reading aloud to our kids for _years_ now, and it's a great way to all share an imaginary world together. A great resource we found is the Read Aloud Handbook [1], which includes an enormous list of great books, and the appropriate age at which to first encounter them.

Also, since my son had an extended stay in another state, we recorded ourselves reading books aloud to his sister, packaged them into audiobooks, and put them on his iPod. This really helped us feel connected as a family. I wrote a blog post about how to do it [2].

[1]: http://www.trelease-on-reading.com [2]: https://ben.straub.cc/2017/05/12/audiobooks/

Yeah, LaTeX is great, but mostly you won't need the superpowers that a document-programming language gives you. When Markdown doesn't quite do what I need, Asciidoc usually does (Pro Git 2 was written in Asciidoc).

Pause Ghostery and reload. This is unfortunate.

You effectively build your configuration file into the thing that knows how to run your container. If you're running Kubernetes, this is either a secret or the replication controller definition file. For docker-compose, this is the `docker-compose.yml` file. Or it's the script that starts your container.

But it's pretty common to put service credentials into a config file, so it's an anti-pattern to version-control them. It's _way_ safer not to, which means you shouldn't be version-controlling the thing that runs your container? This is sort of tricky. We're doing it by volume-mapping a non-version-controlled file for database credentials, and storing the rest of the configuration in the database.

This chapter was updated for the 2nd edition:

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

If you read something in Pro Git that could be better, or if you find a mistake, we're taking contributions at https://github.com/progit/progit2. The only requirement is that you agree to license your contribution under the CC BY-NC-SA license.

We use Atlas to build the e-book versions of Pro Git (which you can download at https://progit.org/). We don't use their editing system, though; it's basically a continuous-deployment system for the book, and it does a pretty great job at that.

The `for...of` and `for...in` loops are much more readable than their pure-Javascript versions. The author is also leaving out really nice things like comprehensions.

Is this supposed to be "Hubot, but usable without hiring a developer?" There are lots of non-software companies that could benefit from chat-ops-like automation.

The images are pretty big, so they'll look good in print and on retina screens. If you run the build locally, you could include a step that ImageMagicks them down to a more reasonable size for a Kindle.

Huh, we'll have to fix that. You can find the pre-order for the 2nd edition if you search for it:

http://www.amazon.com/gp/product/1484200772/ref=as_li_tl?ie=...

Honestly, the reason is size. If you're a newcomer to OSS, it's very likely that you'll end up with a GitHub user account, and much less so with BitBucket.

We do mention BitBucket in the [forking workflows section](http://git-scm.com/book/en/v2/Distributed-Git-Contributing-t...), and many of the lessons from the GitHub chapter will carry over; the two sites have a lot in common.

A lot. (Coauthor here.)

Not every sentence was rewritten, but 4 years is a long time. There was a lot of content that was either inaccurate or out of date. We added content about two-way bridges and migration to other VCSes, graphical clients, shell integration, and lots more. There are also new chapters on GitHub and embedded Git (Libgit2 and JGit).

You mean like Excel actually does? http://i.imgur.com/kMPKnqO.png

> The biology of the human body and food is so complex, science is nowhere close to understanding it helpfully enough to design a diet

To me, this is an argument for eating real foods, and a reason to be skeptical of things like soylent. But I don't think you can get from there to saying it doesn't matter what you eat, or that anybody with a rationale behind their food choices is delusional.

Todays grains are actually a highly-processed food that you can't really digest when they're raw. There's no one simple rule for food on paleo/primal, but one rule of thumb is "feel free to cook, but only eat things you could eat raw."

Fruits and vegetables. Starchy roots are heavy on the carbs, and so are apples and strawberries. Primal allows dairy if you're not intolerant, and milk has lactose (a sugar).

I've seen this done by locking the room, too. That way, everyone in the room when you make the change sees everything (and can check your work), but it's not recorded in the transcripts.

Spot on. What you're describing is leadership, which is pretty deeply wired into human nature. We don't try to avoid this; rather, we want to recognize it as a discipline, and help people become better at it.

Authority, however, is totally different. It's the power to make someone do something they don't want to, and we try our darnedest to avoid that kind of situation. (Also note that "having authority" is different from "being authoritative".)

Note that I didn't say salary, I said raises. ;)

Every other job I've had uses some sort of stressful review as part of the salary process. You get a good review, your raise is bigger; bad review, smaller raise. This seems like it works, but it actually doesn't.

What's the goal of a review? To provide feedback. Shouldn't you be interested in feedback so you can get better, not just so you can get paid more? If so, shouldn't you be getting it all the time, instead of twice a year?

What's the goal of a raise? To keep you from being effectively paid less (because the cost of living keeps going up), and to make sure you feel satisfied with how much money you're making. There's nothing in there about making sure some people feel less appreciated than others. So pick a percentage number, preferably one that's above COLA, and just give everybody that. If that's not enough, your base salary isn't enough.

Note that none of these goals overlap. Feedback and salary don't really have common goals. If you're trying to get people to do better work by dangling the salary carrot, you're taking away intrinsic motivation – see DHH on mixing open-source and money, he did a good job with this topic – and you'll end up with less performance and motivation, not more.

Heh. Whoops. Thanks. :*)

(Disclaimer: Hubber.)

Here's the thing about "management work": it turns out you don't necessarily need management to do it.

Setting priorities? This can be done through consensus.

Making sure schedules are met? Don't have schedules. (1)

Hiring? Have everybody do it.

Giving out raises? Set up a deterministic system and forget about it.

Giving feedback? Everybody can do this.

Running meetings? Don't have meetings.

Communicating with the other parts of the company? We have technology for this.

1) EDIT: forgot my footnote. Of course, we're in sort of a fortunate situation here, and not every company can just not have a schedule.

I love the concept. What if the cashier's finger brushes the button, and now I just expensed lingerie on the corporate card?

Also, I wonder if there are any plans for chip-and-pin. A swipe-card is very out-of-the-ordinary in the UK and Europe, I've found.

Whoops, my mistake. You get the option after you add them as a collaborator. I'll fix my comment above, too.

Collaborators can have "Read", "Read/Write", or "Admin" privileges. You can choose after you add them.

Git doesn't track directories directly, but you can create files in subdirectories. Go to <user>/<repo>/new/<branch> (or click the little "+" box where the path is displayed), and type "foo/bar" in the filename box.