- 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].
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).
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.
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.
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.
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).
> 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."
