rcoder

Re: perks, based on my own experience working remotely, in traditional offices, and those with very nice perks I have to respectfully disagree.

Invitations to "casual chats" over breakfast or dinner in the office cafeteria are IME quite common in the latter, especially if you're seeking access to senior leadership or flagged as someone whose opinion/buy-off is important to a project.

Even without an explicit invitation, if you're at the office already there's no real barrier to someone pulling you in to a project-related discussion. At that point you're effectively on the clock whether you intended/wanted to be or not.

It really comes down to the fact that commitments, decisions, and requests for assistance made across a cafeteria table are not considered any less binding, which means you can't just "relax and enjoy the free food" when it's provided at work by your employer.

(Conversely, if you're someone who tries to protect your personal time and set clear boundaries between work and non-work hours, you miss out on a lot of these ad-hoc meetings, which can result in a persistent lack of access and influence compared to your colleagues who spend 12+ hours a day on-site.)

One of the most competent contract lawyers I've ever had the pleasure of working with came to every meeting we had in jeans and seasonally-appropriate "outdoors" shoes, coats, etc.

He charged a healthy but not exorbitant amount for his legal services, and made no secret of the fact that he liked to go for a hike during his lunch hour and return to his exurban house on a few acres to do a bit of gardening and animal care after work each day.

Dude was calm, professional, and utterly ruthless about protecting our business interests while not putting on any pretense of being a slick trial lawyer.

Law is not inherently a "flash" field any more than sales is, unless you actually spend all day every day in a courtroom before a judge.

We bought a small one-bedroom condo in downtown PDX for my brother to live in ~3 years ago b/c it seemed like a better investment than random stocks/ETFs. He lived there for a year, and we rented it part-time for another four months.

Purchase price was $145k. Sale price (after only 16 months) was $190k.

We used to proceeds from that sale to buy a two-bedroom house for my parents move into for their retirement. Paid $250k last October; recent sales in the neighborhood suggest it's worth $310-325k now.

So yeah, agreed re: bonkers Portland housing price inflation.

/me sighs

The Equifax site appears broken in at least some browsers. Transunion wants me to sign up for an online account, and Experian charges a $10 fee in my state to place a freeze.

All three want to collect my name, DOB, SSN, etc. _again_ in order to sign up.

This is complete and utter BS. Credit reporting agencies are one of the greatest/worst rackets in the modern financial system.

My family lives in Portland, OR, which isn't nearly as expensive as (say) SF or NYC but has seen significant housing cost increases in the last 5-10 years. My wife works as a transportation consultant, which is a solidly white-collar/"knowledge" gig but pays far below what most tech gigs do. We could probably afford our essential costs (mortgage, taxes, car, insurance, etc.) on her income but we wouldn't have been able to buy a house here without the down payment that my technical work allowed us to pay, or the cash gift her parents gave us for our first (USDA-backed, 3.5%-down) home purchase.

My strong feeling is that most places with a robust employment market price most single-income households out b/c the expectation is now that you at _least_ have two earners. Kids take another chunk out of your "competitiveness" because of childcare, cost-of-living, and increased demands on your time (making it harder to really "excel" at work).

Also also: Be Inc. was founded by another ex-apple exec, Jean Louis Gassée. It was in many ways a better fit for Apple's core market (design pros and students who wanted a really slick, single-user multimedia workstation) but Gassée wanted too much money and (speculation here) likely still had bad blood with too many other Apple execs.

The tooling and engineering required for a modern car (even just a refresh of an existing model) costs hundreds of millions of dollars. Ignoring that cost automation might be cheaper, but if you expect to produce thousands, not millions, you're almost certainly better off using old-school machine-shop equipment and processes.

Going that route also lets you do manufacturing closer to the intended market, vs. requiring supply chain, power, and other infrastructure that could be in short supply in the developing world.

I think the barriers to getting ZFS into OS-X were probably legal, not technical ones. There's long history of the CDDL tripping up reasonable attempts to use ZFS and I doubt Apple would have wanted to proceed without approval and/or alternate licensing. Likewise Oracle has no real reason to let them do that without writing a check with lots of zeros on it.

There's also a decent chunk of what ZFS supports (particularly flexible volume pool management) that would be useless on almost every machine that Apple makes and sells. Your example of pulling a drive out of one machine and putting it in another is either impossible (soldered-on storage) or highly unlikely (user-serviceable SSD, but hidden behind a bunch of pentalobe screws) with their modern hardware lineup.

I think it could be a really interesting model for folks who need to run legacy Windows software in the future, as well. Instead of keeping a few XP machines around (lack of security patches and all) why not just spin up a lightweight ReactOS VM for just that one application?

Think of all the weird desktop apps, custom databases, etc. that small businesses, schools, and other non-technical orgs have baked into their workflow. Yes, eventually we'll have wonderful legacy-free versions of all of these available on the web but in the meantime wouldn't it be nice to give them some outlet to use them w/o paying an MS tax or dealing with the infinite upgrade treadmill?

This happened to me a week or so ago. Unlike the OP, I searched for "Nest Protect false alarm" and was sent directly to this helpful page: https://nest.com/support/article/Nest-Protect-sounds-false-s...

After blowing the visibly-accumulated dust out of the interior everything was back to normal.

I wonder if the OP uses similar debugging tactics on servers that send alerts? "Hmm. 'CRITICAL: disk full' alert? Guess I'll hit it with a hammer until I stop getting paged."

I know I'm feeding the trolls here, but this just demands an answer:

"Given the data is 3 years out of date, it's possible employment rate has jumped to 63% (the highest its been since 1998!) and that 14% is exactly on-par for the course for having no gender discrimination (against or in favor of) women."

This is basically middle-school level math and you're doing it wrong.

Whatever percentage of newly-minted CS PhDs go on to teach, the ratios of men and women working as professions should be roughly the same as those earning degrees: 78% and 22%, respectively. Instead, it appears that a disproportionate number of women are "somehow" not ending up in teaching positions.

In a truly fair world those numbers would be much closer to 50/50, but that's a separate discussion.

/me sighs

Where to start?

First, to your (horribly sexist) implication that women opt out of the workforce by studying "Gender or Women's Studies": it isn't even in the top 10 majors for women. You know what the #1 major for women is? Business. http://www.forbes.com/2010/03/02/top-10-college-majors-women...

Biology, math, and physics are all also popular majors for women: http://www.npr.org/sections/money/2014/10/28/359419934/who-s...

Calling out "previous work experience" is similarly just so much BS. If women are excluded through systematic bias in hiring (hint: they are!) then they literally can't earn that experience. Furthermore there's a compounded effect, as fewer and fewer women make it up through each tier of the hiring/promotion filter.

Even the article you cited calls out gender disparities in academia. While only 22% of CS PhDs were given to women, they made up an even more minuscule 14% of CS faculty.

tl;dr: the system is rigged and women don't get a fair shake. Stop victim-blaming.

I've been part of three teams who attempted monolith->microsystem transitions. Two succeeded (though at wildly different costs in terms of engineering time and delay) and the other was abandoned after person-years of effort.

The common aspect of the successful migrations was their incremental nature: rather than "killing" the monolith all at once, there was a careful and gradual migration of performance-critical sections into services running atop dedicated machines/storage/etc.

Neither of the successful moves happened all at once, or indeed ever 100% replaced the monolith.

It wasn't just a question of planning, either. The failed migration had a team of three engineers spend ~six months writing detailed component specs, migration plans, etc. The business simply couldn't stop (or even maintain the status quo) to let them build the shiny new V2, so it kept getting pushed out and restarted long enough that the plans and specs bit-rotted and the whole thing got scrapped.

It's totally reasonable to say you wouldn't want to work in a company that prioritized unsurprising, proven technology over novelty and in-house solutions. That's a far cry from it being unilaterally a "terribly place to work" headed by a "moron".

Some programmers are more motivated by solving business problems than they are by inventing and adopting shiny new technologies. At this point in my career I'm definitely more interested in applying proven languages and systems to novel product problems than I am inventing new frameworks and debugging cutting-edge runtimes.

So: different strokes for different folks. Insulting people who disagree on issues for which there's more than one answer is just unnecessarily snarky IMHO.

I seriously disagree with just about every point in this.

First off, transparency != lack of negotiation. It just means that your colleagues might be able to see the outcome of that negotiation. Even with salary bands you still need to determine where in the band you land on day 1, and those bands are often wide enough (10-15%) to allow quite a lot of flexibility. Also, most "large corporations" will have many job descriptions and titles indicating seniority: an Engineer II will have a wildly different salary band from Principal Engineer, leaving plenty of room for negotiation on hire.

Second, there is basically no way to determine that someone is a "10x" engineer (if such even exists) via an interview. Decades of studies across the industry have shown that interviews are a terrible means of assessing potential performance, and unless you've worked with someone on an essentially identical product in a similar company before you can't predict their output now. (Also, see above re: strawman argument about not being able to move $20k for an exemplary candidate.)

Third, if you can't build trust across teams (with or without visible salary info) you have much deeper problems than your comp being public. Fix this before everything else. If you're building "cohesiveness" by implying to your staff that every other teams makes less money (and is therefore less valued) you're setting yourself up for real problems down the road.

Finally, salary negotiation is a very different beast than feature and scope negotiation. The former assumes a selfish if not antagonistic stance ("get as much as I can") while the latter should be collaborative ("deliver the best possible outcome given our constraints"). People who are good at the former may or may not have the empathy and vision needed to deliver on the latter.

Huge +1. This is one of the best and most informative books about engineering process I've ever read.

The numerous real-world examples from airplane crash investigation also help put into perspective the relative unimportance of the "critical bugs" and "extreme pressure" most of us building the kinds of products discussed on HN actually experience.

How does this make it harder to move out of AWS?

If anything, their use of NFSv4 means there are plenty of competitive offerings if you decide that performance, security, or physical access constraints dictate migrating off their service.

If you don't want to manage your own Linux/BSD/etc. NFS infrastructure, Oracle, Netapp, and EMC will all happily sell you a storage appliance that supports it. I don't see much lock-in here.

While I agree with the basic tenet that experienced developers make better direct managers for other developers, I strongly disagree that "any programmer can do it", or that "biz guys can't learn programming", much less the assertion that "business" is somehow trivially easy compared to coding.

Doing a good job as a manager is hard. You need to triangulate between a lot of disparate opinions and viewpoints, negotiate compromises, and help your team develop and advance without hurting the larger group's goals. It takes empathy, good communication, and the ability to squelch your own opinion when circumstances call for it. None of those attributes are universal in engineers.

In fact, just about everything in a startup is hard: sales, recruiting, design, marketing, etc. Pretending otherwise or asserting that only engineers have something special to contribute is IMHO toxic and short-sighted.

Re: storage engines, my apologies; those mean something very specific in the MySQL world and the more appropriate term for Postgres-land would be foreign data wrappers.

I stand by my point about flexibility regardless.

Rather different, actually. If I decide your inbound SMTP mail is spam, I can block it. Ditto for blog comments, XMPP contact requests, or really most any protocol in use on the public Internet b/c of course there will be griefers and spammers and all kinds of bad out there and we need tools to filter and protect against it.

You have the right to say anything you want (though not without consequences). Conversely, I should have the right to literally not see/hear it once I've decided it is causing me harm.

Claiming that your platform/protocol makes this impossible just sounds naive at best and nefarious at worst to me.

This. The project homepage literally claims (as a good thing) that "...no one can censor you. No one can remove your posts. Your account cannot be blocked."

So not only does this not help with abusive behavior, it states that abuse will live forever and be impossible to block or filter.

/me shudders

PostgreSQL displays an amazing and rare combination in _any_ software, much less a free (beer/libre) product: reliable, predictable performance and usability for standard workloads combined with an extensible, flexible platform for experimentation and development.

Rock-solid "classic" OLTP database? Check. Rich geospatial data platform? You betcha. Structured document store? That too. Pluggable storage engines and column stores? Why not!

Don't get me wrong: there are definitely workloads for which Postgres is a poor choice. Its replication features are far behind MySQL, much less its pricey commercial competitors and the more reliable NoSQL options (Cassandra, HBase, etc.). There's also been little work that I know of* to optimize the storage engine for SSDs. (*- I'd love to be learn this is just my ignorance and someone is really focused on large-scale SSD-backed Postgres deploys and tuning. Links/references appreciated.)

If you can work within those constraints though it's an awesome product.

If you honestly believe your lifestyle is no different from someone getting by on $10 per hour then I doubt there's much I can do to dissuade you. That being said, I still believe you're underestimating just how much more stability and confidence you have as a product of your income.

I personally have very clear memories of the years where I worried constantly about finding and keeping enough work to pay rent, left problems with my health unaddressed because I couldn't afford to fix them, and stayed in a bad relationship because my partner had a place to me to stay and a car I could take to job interviews.

If you had asked me then I would have said my life was fine b/c I had friends, plenty of cheap beer, and didn't really know any better. Now that I'm also solidly in the middle class and can afford luxuries like an entire house I share with just my wife, regular meals out, and leisure travel I would describe those years as "strained" and "challenging" at best.

Please re-read what you just wrote about race and consider whether it might have interpretations other than the one you intended. To me you seem to be asserting that race is a priori indicative of socioeconomic status, rather than the (likely intended, but more nuanced) assertion that a larger portion of minority children will come from lower-earning households.

Second, I don't necessarily accept the argument that "people who go to college make more money" proves that "college is a good investment". For example, this study found that direct transfer of assets and emulation of behaviors exhibited by wealthy parents had a much stronger contribution to the lifetime earnings of children than education level: http://www.nber.org/papers/w9314

Lastly, the article you posted makes it very clear that the earnings gap for Latinos and African Americans is significant (20% or more) and pervasive no matter what level of education they attain.

If you're making an order of magnitude more than minimum wage that puts you at $72.50 per hour, or about $145k per year. That might not sound like a lot to the regulars on this site, but it's almost triple the median US household income ($52k) and should put you comfortably in the middle class in almost any developed part of the world.

You also probably don't have to worry about getting sick or injured (health insurance and sick leave are basically assumed in most careers that pay >$100k/year), getting access to money (whether savings or credit) for emergencies, or being able to support a loved one when they have problems.

There's nothing "glamorous" about scraping by month to month, working an hourly job with no benefits or paid leave, or having to lie to get access to social services to support your family. It might not be as bad as living in medieval-era poverty, but it's still miles away from your six-figure professional lifestyle.

Life can be (and often is!) fine day-to-day when you're poor, but the complete lack of an effective safety net means the difference between "doing okay" and "living on the street with no options" is razor-thin.

My wife is a transportation planner with ~10 years' experience working with city and regional governments all over the US.

As she has explained to me, urban planning (esp. in denser cities) is very much about increasing density, improving transportation options (e.g., walk/bike/transit), and ensuring neighborhood access to essential services (groceries, medical care, etc.). Equity is a huge concern for most planners as well.

The problem isn't so much "improving urban planning" as "making elected officials and taxpayers listen to what the planners are saying".

While I appreciate the convenience of this, I think you may be misunderstanding how Julia does method dispatch. Rather than dispatching purely on the type of their first argument (as in Python) or into a class hierarchy/namespace based on that argument, then by parameter types (ala Java) Julia methods are fully qualified over every parameter type.

Sadly, that makes it hard to ask the question "what methods can I call on an object of this type?" because the answer might include functions with that type in any parameter position. In many cases that wouldn't be a meaningful answer - as in the case of, say, a numeric type which could be used for all kinds of indexing, iteration, and offset methods involving collections, IO handles, etc.

You might benefit a bit more from using the 'apropos' builtin to lookup functions based on simple keyword matching. Given a type name it lists methods that take or emit objects of that type (which may or may not be exactly what you want, but it's a starting point at least).

Wow. That's a fun one.

It's also a perfect example of why even really amazing teams reinventing a language/tooling ecosystem from scratch stumble over problems that were solved years (or even decades ago) in preceding platforms. I leave it as an exercise for the reader to decide if the "reinvent from scratch" critique is more deserved by Docker, Go, or Linux.

That being said, I'm pretty sure even the broken Setuid behavior described there would be good enough to sandbox a thread or child proc that was just handling buffered I/O into and out of the xz binary.

I agree strongly this is the best way to interview a candidate. It's even relatively easy to set up for a new grad or junior candidate who isn't currently working. They should of course also be local or have no family or professional commitments that make a week-long non-work trip difficult.

Sadly, many of the best engineers I've worked with do have families, are working, don't live in the same town, and would absolutely balk at the idea of taking a week away from all that to "try out" a new job.

Of course, there's a wide spectrum between "work together for a week" and "write some C++ on a whiteboard for 40 minutes" that gets dropped from most screening processes. That's the zone where I'm most interested in finding creative evaluation tools.

The difference here is that apt-get and its ilk need to modify critical system state basically every time they run, and that state isn't controlled by a persistent daemon. I actually consider this a great tradeoff: yes I have to use sudo to run that one command, but I don't have a long-lived process sitting around pulling data down off the Internet and doing stuff with it while humming along as uid 0.

It's also literally one line of code in most UNIX-based languages (syscall.Setuid(<uid that isn't root>) in Go, FWIW) to drop root privileges before doing something unsafe. Even if the main Docker daemon absolutely has to run as root most of the time, it can and should fork and drop that access for anything dealing with moving data between unstrusted (e.g. the Internet, user input, etc.) and trusted (verified, read-only local state) security domains.