cramey

Location: Anchorage, Alaska

Remote: Yes

Willing to relocate: Yes

Technologies: Android, Bash, C, CSS, Docker, Elasticsearch, Git, Go (golang), HTML, Java, JavaScript, Linux, Lua, macOS, MariaDB, MongoDB, OpenLayers, Oracle, PHP, PostgreSQL, Python, Redis, Solr, SQLite

Resume/CV: https://binarythought.com/r/e/sume.html

Email: cramey@extraarms.com

I'm a skilled generalist with over 20 years of professional experience in software engineering, across multiple languages and platforms. My favorite part of my current position is mentoring junior developers. I work best in small groups where team members wear many hats. I enjoy learning new things, and would relish the opportunity to work on ML systems or learn Rust, but I'm open to anything.

I did the exact same thing, 100% to charity every time. It makes me wonder if there were a lot of people also doing that. It would certainly explain the new 15% cap.

I'm not sure I fully understand what your outrage is. It seems like you're concerned that judgements of acceptability change over time. Is that not to be expected?

Anecdotally, most effective managers have fired around 1 out of every 7-10 people they’ve ever managed.

That's a 10 to 14% hiring failure rate, which is absurd. In what other context would a failure rate that high be acceptable? Those sound like sweatshop numbers.

There's definitely benefits to having a tightly integrated team with plenty of knowledge sharing. My problem with pair programming is that it is frequently an attempt to create those benefits via force.

Also, with traditional pair programming (one driver, one navigator) you're allocating two programmers on a single task, meaning that pair will need to generate at minimum the equivalent work of two programmers operating independently. I've never seen that work out to be true.

The only argument for pair programming I've ever subscribed to is that it can be used to more rapidly educate inexperienced programmers. If you compared the relative costs of inexperienced vs experienced programmers that math might pan out. Of course, then you have skilled programmers you're potentially underpaying, which is a problem in and of itself.

"Open source" does not mean "all patches immediately published."

The source to their server seems open source licensed and available: https://github.com/signalapp/Signal-Server

Wikipedia also says their server is open source: https://en.wikipedia.org/wiki/Signal_(software)

All substance abuse, including smoking, is a comorbidity[1]. While it's hard to find exact statistics, the US Department of Health and Social Services estimates that 50% of non-elderly Americans have a pre-existing condition[2]. Those conditions don't necessarily represent a comorbidity, but a nasty systemic infection like Covid-19 leaves little space for non-overlap.

1: https://en.wikipedia.org/wiki/Comorbidity

2: https://www.cms.gov/CCIIO/Resources/Forms-Reports-and-Other-...

Alright, I'll bite. How do you feed and shelter people without feeding and sheltering them?

Professions like pilots, doctors and CPAs are bad examples because they have a certifying body that exists outside of the relationship between employee and employer. It's true they're not getting paid for that certification, but once they have it, it's valid and transferable between jobs.

Musicians and actors are better examples, as they do have auditions, but lots of actors and musicians get jobs based on their previous body of work, rather than an in-person audition.

I'm curious, can you name more professions that use what is essentially auditions for hiring, besides artist-types?

I can tell you what's worked for me when hiring experienced programmers:

Ideally the candidate offers code samples, I then pick through the code samples to find things that strike me as unusual or problematic and ask questions about those parts. This gives me a great deal of insight about how people think, and their relative level of skill. I firmly believe this is the best way to interview.

Failing that, candidates frequently provide details on projects they worked on. I'll then ask questions about those projects like, "What language did you develop it in and why?" and "What do you think was the most difficult part about this project and why?" These questions are a gateway to the same kind of details you get from code samples. For example, a candidate once mentioned he had worked for the Navy, and had done water simulations for them and I asked, "What's so difficult about water simulations?" and he gave me a 20 minute lecture on how water simulations work, which won him the job. It's probably worth noting that the job had nothing to do with water simulations, but his lecture made it clear he had passion and knowledge and could do the job.

The worst interviews are ones where the candidates worked in an environment where they can't offer code samples or talk about previous projects (military contractor, for example) - these you just kind of muddle through by talking about programming in general.

How many people do you think can afford to fail 10 times?