Why are you still deploying overnight? - <AUTHOR> http://briancrescimanno.com/2011/09/29/why-are-you-still-deploying-overnight/ <comment><USER2> Sometimes, it's cheaper to live with 10 minutes of scheduled maintenance at a low-traffic hour than to re-engineer your application to have 99.999% uptime.

Even if you have unit tests, continuous integration, a staging environment, and fast rollbacks, deploying to production can still be tricky:

1) Do you want to run MySQL, PostgreSQL, Oracle or SQL Server? Watch out for ALTER TABLE; it may sometimes hold table locks or invalidate open cursors. Of course, you could always rewrite your application to use a schema-free NoSQL database and migrate your records at read time. But that has a lot of consequences. Maybe 10 minutes of scheduled maintenance is an acceptable tradeoff?

2) Does your staging environment exactly match your production environment? Can you generate a full-sized, real-world load on your staging servers? Alternatively, have you built all the tools required for a phased deployment of your back end?

Now, I'm all in favor of deploying to production 5 times a day. That's pretty easy for any group with good unit test coverage and a fast rollback mechanism. But it's _expensive_ to eliminate the occasional 10 minute maintenance window. And if you're going to take the site down for maintenance, it makes sense to do it at an off-peak hour.

<comment><USER3> I don't think the author's point is that everyone should be doing middle-of- the day seamless deployments from day one. I think the point is that if you continue to do deployments at 3am indefinitely you are hurting yourself.

There are lots of things that make sense at the appropriate scale. Not having any tests. Completely manual processes for builds and deployments. Having only one server. Making backups every day or maybe even just every week. Etc. However, as your business grows you need to recognize that it's important to change these things and move to better processes. Because if you don't then those things could become a very serious drag on development velocity and even business capability. You could find yourself spending all your time drowning in process when you should be spending your efforts more efficiently.

You stay up until 3am to perform a risky manual deployment, sometimes you spend some time fixing problems afterward. As a consequence you either spend a day in zombie mode with limited productivity or you start working much later. In either case you've taken away a fairly decent chunk of time that could have been used for productive work. Similarly, perhaps you spend too much of every day fighting your build system, or recovering from your build always being on the floor, or excessive operational support because your platform doesn't have sufficient redundancy at every tier. Etc, etc, etc.

<comment><USER4> _middle-of-the day seamless deployments from day one_

From my experience, it's easier to start there from day one than to try to get there after years of dysfunctional deployment processes.

<comment><USER5> Is there any way to do fast database schema migrations? This is not a nitpick, I've posted a question on SO about this ([http://stackoverflow.com/questions/6740856/how-do-big- compan...](http://stackoverflow.com/questions/6740856/how-do-big-companies- like-say-facebook-do-migrations-without-having-downtime)).

As is suggest above, you could use NOSQL. But NOSQL still has schemas, in a sense - if you decide to restructure anything you may still need to knock the db out for a while (or write _really_ hairy code to work around two different versions of your data, but be unable to restructure stuff because you're too scared to change anything on the db).

<comment><USER6> I'm being serious, but also snarky: Don't do schema migrations.

I saw a talk by Brett Durrett, VP Dev & Ops at IMVU last week. They don't make backwards incompatible schema changes. Ever. Also, on big tables, they don't use alter statements ever, because MySQL sometimes takes an hour to ALTER.

Instead, they create a new table that is the "updated" version of the old table, and then their code does copy-on-read. i.e. they look for the row in the new table, if it's not there, copy it out of the old table and insert into the new table. Later, a background job will come through and migrate all old records into the new table. Eventually, the old table will be deleted and the copy-on-read code will be removed.

It's a lot of extra work, but they think it's worth the effort.

I need to finish my blog post on the rest of the talk...

<comment><USER3> This x infinity. Any time you have a thought to do something that will lock an entire table that is active in production you should think about another way to do it. The read-through "cache" with rolling back-compatability method is a great way to make such breaking changes without causing significant downtime.

No matter what you end up doing it'll be extra work. It's best to find a way of working that provides enough flexibility to continue developing at a good pace without being an operational nightmare. Generally that means you'll have to take things a bit slower, but that'd be true almost regardless of the technology you're using, schema changes rarely have a trivial impact.

</comment></comment></comment></comment></comment></comment><comment><USER7> While there is some truth in there, I feel like some of the advice is pretty reckless:

"Problem 1: You presume there will be problems that impact availability. You have no confidence in your code quality; or (or maybe, and), you have no confidence in your infrastructure and deployment process."

Or you're playing it safe. You absolutely cannot guarantee that every update you are deploying will have zero problems. If your business absolutely relies on users making payments online or anything of that ilk, you could lose a lot of money.

"Imagine, for a moment, that your team is rolling out an update to a service that monitors life-support systems in hospitals."

What? Why? Throwing out hypothetical "what if" scenarios that would affect 0.1% of your readership isn't a very useful thing to do.

<comment> brown9-2 But I think the author's point is that if you find yourself worrying that a deployment has even a sliver of a chance of causing downtime, you should be spending your energy on finding ways to eradicate that risk rather than proceeding in the middle of the night.

Besides, in the small event of deployment-caused downtime and problems, who is to say you have enough time to restore service by the time your customers come online? By taking advantage of the clock you've only given yourself a few more hours to deal with any problems, rather than finding ways to not have any problems in the first place (canary-in-the-coalmine-style deployments, etc).

<comment><USER8> >But I think the author's point is that if you find yourself worrying that a deployment has even a sliver of a chance of causing downtime, you should be spending your energy on finding ways to eradicate that risk rather than proceeding in the middle of the night.

Right, and that's where I strongly disagree with the author. Sometimes finding and taking care of that last 0.1% risk of failure just isn't worth it. Sometimes you're better off babysitting the deployment for 30 minutes once or twice a month rather than spending valuable development hours updating your deployment scripts to be fully automatic and handle every possible contingency.

<comment><USER4> _Sometimes you're better off babysitting the deployment for 30 minutes once or twice a month rather than spending valuable development hours updating your deployment scripts to be fully automatic_

If your deployment scripts are fully automatic, you can enjoy the (many) benefits of deploying more often than once or twice a month.

<comment><USER9> Given no other dependencies, sure.

</comment></comment></comment></comment></comment><comment><USER10> I was hoping the author would have some deeply insightful answer to the argument, "because the deployment requires the site to go down for a few minutes and we want to avoid inconveniencing customers" but he avoids that topic entirely.

That's the number 1 reason for an overnight deployment, by far! If you can deploy code without bringing the site down, then of course, do it during the day!

<comment><USER11> Bingo. Deployment with us is automated. I don't actually stay up to 3 AM. However, during the deployment the machine is automatically updated with new packages and the new version of the software, caches are cleared, it's restarted, etc. All of this probably takes 5 minutes at most, but still ... why do that in the middle of the day?

Also, we do a daily backup around midnight. If the deployment is botched, I can come in early in the morning, notice it and simply do a roll-back using the backup. Very easy.

Now, if you're actually staying up until 3 AM and doing things manually ... you need to automate things.

<comment><USER12> Depends on the type of site/application. If your application is managing customer data that can be updated 24 hours a day, a few minutes of down-time might be okay, whereas rolling back 6 hours of data (and losing it) is definitely not okay.

</comment></comment></comment><comment><USER13> This is incredibly reckless and naive advice.

You roll out when it least impacts customers because:

1\. Impacted customers affects your bottom line. Minimize that and you minimize losses if something screws up.

2\. Murphy's law. I don't care how much testing and QA you do; stuff will ALWAYS creep through, and sometimes it'll be nasty. QA works to minimize this, but it can't eliminate it entirely due to diminishing returns. Show me your guaranteed bug free deployed code and then I'll consider changing my view.

3\. If you've designed and tested your rollback procedure prior to actually doing it, the chances of not being able to roll back in the real deployment is orders of magnitude lower than the chances of a failed deployment requiring a rollback, which in turn, if you've done your testing and QA, is orders of magnitude less likely than a successful rollout (but not 0, thus the midnight rollout).

If you're worth your salt, you have a tested rollback procedure, laid out in simple to follow instructions (or better yet, an automated rollback mechanism with a simple-to-follow manual process when the automated method inevitably fucks up).

You rollout, and if it fails, you roll back. And if that fails, you use the manual procedure. You should have the entire process time boxed to the worst case scenario (assuming successful manual rollback) so that you know beforehand what the impact is, and won't need to go around waking people up asking what to do.

<comment><USER14> Rollbacks are a myth. You can never rollback. Always be rolling forward. Enabling a culture and environment that allows for small frequent changes solves that problem.

The way to not impact a customer is to make deploys trivial, automated and tolerant to failure because everything fails.

<comment><USER4> _Always be rolling forward_

I basically agree with this idea, but when I'm selling people on the idea of making deployments trivial non-events that happen in the daytime, having the notion of "if something goes wrong, you can very easily jump back" gives people a sense of security.

In practice, when things go wrong, I've found it easier to roll forward than to roll backwards.

</comment></comment></comment><comment><USER15> I'm befuddled by these sorts of posts that are big on theory and light on details. I run tests, via a continuous integration server, and have high confidence in our code when we deploy However, we do updates at night because we often need to take our sites off line for a while, to merge our changes into the live codebase. If we didn't, changes to the database structure would bork the db as visitors clicked around. Nighttime is our lowest volume of visits, so that's the best time to deploy.

I'm sure this is a noob reaction, but can anyone point me to some good technical walkthroughs about how to deploy to live without taking your site down or interrupting your database connection? Is there a tool/term/practice I'm missing?

<comment><USER16> There won't be general-purpose walkthroughs, because the general answer is "don't change the database structure of a database that's serving live traffic: You'll never enumerate all the things that could possibly go wrong."

In most _specific_ cases, there are alternatives to stopping the show during an upgrade. First, you check your backups! Then, there are various strategies. You can make many simple schema changes while the system is running. Or put the DB in read-only mode and still mostly manage to serve pages -- perhaps with an occasional HTTP 503, so hopefully that's okay -- during your upgrade. Or phase in changes over several releases, carefully architecting for backward compatibility. Or bring up a parallel system and gradually migrate active users to it. Depending on what you're doing, you may find yourself having to write a special upgrade script that migrates old formats to new formats, or even using database triggers to keep "old" and "new"-format tables in sync during the transition. A well-constrained database may help keep things sensible during the transition -- or, you may have to drop half of your supposedly-sensible constraints just to make the transition work.

Moral: Even if you know exactly what you're doing, live updates are more work: More planning, more code, more infrastructure, and/or more stress. In many real-world cases, you should just take the system down for a minute. Focus your engineering effort on making sure that "minute" is as short as possible, and in making sure that you can detect problems and roll back as quickly as possible.

<comment><USER17>
        > the general answer is "don't change the database
        > structure of a database that's serving live traffic:
        > You'll never enumerate all the things that could
        > possibly go wrong."

And what if you need to? Even adding an index on a large table can slow down the things tremendously. Let alone adding/deleting columns with indexes.

"Don't do it" is not really an answer.

        > Or put the DB in read-only mode and still mostly
        > manage to serve pages

Of yeah, let's put our credit card processing app in the read-only mode during the day. What can possibly go wrong, just those silly 503s.

<comment><USER16> Perhaps I need to reiterate:

The reason there aren't a lot of general-purpose walkthroughs is that _there is no general case_.

The closest thing we have to a general-purpose solution is: Take the system down, do the upgrade, put the system back up. But, yes, this is often not a very good answer. It is often a lousy and expensive answer. In which case you hire engineers to build a better strategy. And I can't tell you, dear reader, what that better strategy is going to be, because it's different from case to case, and I don't know what your problem is.

And, yes, of course you shouldn't use the sloppy strategies on your financial- transaction processing app. Just as you probably shouldn't spend three engineer-weeks designing a complex zero-uptime rollout strategy for your blog comment system.

</comment></comment></comment></comment><comment><USER18> The only good point is #2: you want your people to be awake during the deployment so they can deal with any problems. The others basically amount to "You should have other processes in-place to avoid the same problems you're trying to minimize."

Three words: Defense in depth. You don't always need every advantage you can get, and this is a pretty costly one. Still, it's simply wrong to assume that a particular precaution is always needless.

Interestingly, you hit a bit of a sweet-spot if your primary customer base is located halfway around the world. You can roll out updates when your people are most wide awake, but when you'll only break things for a few users if something goes wrong.

</comment><comment><USER19> I deploy and update certain things at night because they REQUIRE down-time. I can't have people making certain updates while something is being moved, for example, so things have to be shut down for a few minutes.

That whole line about trusting your infrastructure, etc, is hog-wash. I say, don't trust your infrastructure. Don't trust your code. Be safe, be smart, do things at a time when the least number of people could be affected by a problem.

Humans are responsible for everything that is happening in a deployment, and humans make mistakes. So, no, I don't trust my servers or my code at a time of deployment.

It would be irresponsible of me to do so even if I had the most talented developers, and the most solid and secure platform in the world.

<comment><USER12> Others would argue that you can architect your infrastructure/application so that you don't require down-time for changes, ever.

</comment></comment><comment><USER20> It's also interesting how U.S.-centric this thinking is: your sneaky 3am deploy in the valley could mean a mid-morning outage in London.

Actually, an 8am deployment in Europe has the advantages of a rested brain and a few hours before America hammers the Internet ;-)

<comment><USER21> Many US based software companies either A) have a mostly American user base or B) have a regional distribution setup for their app. So if you are a non- American in camp A, that is a problem for you. However, remember the goal is to be the least disruptive. If you are a non-American in a region that the server is deployed in, there is probably a night-based take down of the system in your region.

If the software company is either A nor B, then the software company need to notify the non-user users that they may experience a disruption.

</comment></comment><comment><USER22> I do think 3AM is a terrible time to do a release. I'm personally a fan of doing releases in the early morning instead of late night. I'd rather get in the office at 6AM & push the release. Plan for a light day and let everybody leave early if things went smoothly. If things do go wrong it gives you about 2-3 hours before the rest of the office start showing up to roll back or fix the situation.

Choosing the time should be a balance of off-peak usage time and a reasonable time for the developers. If you're a global business then you may not have a perfect time, but you can usually still choose a day and time that is less likely to cause inconvenience.

</comment><comment><USER23> There are deploys and then there are deploys. 99% of your deploys should be fine to go live whenever the code hits the repo. I definitely still prefer scheduled overnight deploys whenever significant infrastructure changes need to go live. Downtime should still be minimized, but sometimes a maintenance window is necessary.

</comment><comment><USER24> I attended a git workshop by Scott Chacon and was surprised to learn that github's production site can be deployed by many folks on the development team, and at any time during the day. In fact, he mentioned that github.com can be updated as many as a dozen or more times per day as small features or fixes are pushed live.

There is a great description of their web server stack[1] that allows them to seamlessly push new code live without downtime (see the second Slow Deploys section.) It's a great idea about how to continue serving during a deployment, and I'm looking into using Unicorn like this for some projects I'm working on.

[1] <https://github.com/blog/517-unicorn>

</comment><comment><USER25> The article discusses deploying to a percentage of your user base at a time. I have an idea on how to do this, but it is probably the wrong way.

Anybody know of any articles explaining this process for a rails app?

<comment><USER26> I am also interested in this concept. What if a change requires a migration of my database?

<comment><USER27> A near-instantaneous switchover is possible if you're migrating a database to a new schema, but it's pretty hard work.

For this to work, every action that will result in a database write needs to go in log, and that action log needs to be replayable be the updated version.

In the context of a web application, you have:

1\. Take your database backup, start recording action log.

2\. Perform your database migration against your database backup.

3\. Install your updated web application (not available to users yet).

4\. Test your updated web application.

5\. Disable your existing web application.

6\. Replay the contents of your action log using the updated web application.

7\. Making your updated web application available to your users.

It's definitely not a trivial matter to sort out: it means lots of time working on your deployment process, for example you have to be set up to have both versions deployed simultaneously, which likely means a lot of mucking about with URL rewriting. The application also has to be built to support it.

Maybe there is a better way?

<comment><USER14> There is a better way. It's to stop deleting and start deprecating. Write your code in a backwards compatible way. If your storage engine, whatever it is, can't handle it then switch storage engines.

The author makes some amazing points that I'm surprised intelligent people are missing.

Let me give an example. We are currently migrating from storing blobs of data in Voldemort (a key/value store) to storing them in S3. They should have never been in there in the first place but whatever. We're going to do it with "zero" migration time. In fact we're already doing it.

\- Set up a job that copies existing data in Voldemort to S3.

\- Deploy a minor release of our code that multiplexes the current writes to both Voldemort and S3.

\- Continue migrating existing data

\- When existing data is finished migrating, deploy a new release that forces all traffic to S3 instead of Voldemort.

\- Profit

People need to learn to do things like dark launching and feature flags. Dark launching let's you exercise new code paths with no impact to the user. Feature flags give you the ability to enable to features to some or all of your users. Feature flags are awesome ways to A/B test as well.

People need to stop doing stupid shit like redefining what some property means mid-release and instead define NEW properties and deprecate old ones in subsequent releases.

Same goes for schema changes. If some part of your code base cannot tolerate an additional column that it doesn't need, that's a bug.

You can also adopt some configuration management that allows you to provision duplicates of the components you're deploying so you can swap back and forth between them in the case where you might have a breaking release. That's what we do and it's one of the upsides of using EC2.

All of this requires discipline and dedication but the benefit is so worth it. You have to stay on top of dependencies. You can't let bitrot take hold by going 4 major revisions without upgrading some package. We did and it bit us in the ass.

This is why we adopted the swinging strategy of duplicating our entire stack (takes about 30 minutes depending on Amazon allocation latency) on major upgrades.

</comment></comment></comment></comment><comment><USER28> _"...I sincerely hope you're not living in the Stone Age..."_

Whether or not you agree with the entire article, for me, the statement above was the most important one. There is no excuse why any software development team does not have an automated build and deploy process.

There may be valid business reasons to deploy in the middle of the night, but there's no business reason to deploy by hand.

Also, I am assuming that the posting only reflects application source code and not database changes, which is a different beast in terms of deployments.

</comment><comment><USER29> Couldn't agree more.

I worked somewhere that only deployed during business hours because it was all hands on deck. We just kept the users primed with information and reminders prior to go-live, and when it happened everyone knew about it.

But there's a more fundamental point. We're dealing with IT, and for internet businesses and global enterprises the issue is the same: business is 24 hours a day 7 days a week. You cannot avoid deploying somewhere in the world that's awake.

All you have to do is plan a rollback and just get on with it.

My experience of companies who are timid about rolling out, changes is that they're state of advancement is completely unstable. They are too scared to change meaning that some technologies become out-of-sync with the current state of play. You only have to introduce a new piece of wiz-bang software and issues come pouring out, and it's a frantic race to upgrade random components in the hope you might plug the leak. This is far far worse in every way than doing regular "risky" upgrades.

Small incremental changes can be easily rolled back, because you know what you just changed.

</comment><comment><USER30> Why in the middle of the night? The economics of things, mostly.

At my previous job, we were still in process to get session migration to work so servers within a cluster could update while others were running.

At my current job, we don't have a cluster (we have a single over-provisioned server), and that method simply isn't in the budget for the foreseeable future. However, 3:00 AM PDT is 3:30 PM IST (India), which is where most of my team is, as well as the support staff they need (most staff there are on swing shift, as well). Thus, an early morning release is actually a very convenient, as well as lower cost, time to do the release. As the site is mostly US customers in both a B2C and B2B use case, this timing (around 6:00 AM EDT) works very well, and I don't see it changing.

I realize this doesn't scale for a global app, but it explains the lack of pressure to spend much consideration on higher tech, more expensive, deployment methodologies.

</comment><comment><USER31> Or may be a client simply insists that customers absolutely can't tolerate a several seconds delays during the deployment ;(

</comment><comment><USER32> Its not just cause ur developers are tired, which is a big issue, its also because you may not have access to the people you need to make decisions in the middle of the night if something needs to be escalated. Good luck trying to get an executive or VP up at 4am to make a decision...

</comment><comment><USER33> "Why are you still deploying overnight?"

Because you don't hire a system admin to do that job for you. :}

</comment><comment><USER34> I think a point also missed in the article is the startup notion of burning the midnight oil and pushing stuff live.

"Release early, release often" is great, but that same call to action can be what motivates people to push code live at 3am when they're tired, just finished it, and perhaps skipping QA.

Otherwise, I think the article as put is empty and seems more straw man. Assumes you have no confidence in your code, assumes it is complicated, assumes you can't roll back.

Simply put, deploy small stuff often, make plans for big stuff, and don't be stupid.

</comment><comment><USER35> I rarely have issues but is always a chance that something is going to go wrong, so everyone is sitting there waiting for the all clear. I was able to make the case that having developers, DBAs, and sysadmins sitting around in the middle of the night was counterproductive. It was fraught with tension during the middle of the night after a long day at work. Now we do it at 1pm on saturday, it is amlost leisurely now. Just a quick call to check in. Some people even call the voice bridge from the beach!

</comment><comment><USER36> Let's be realistic. Many applications have 24 hour availability, but almost every application I've worked on was for people in the US and core usage was sometime between 7AM and 9PM.

If it only takes 5 minutes to deploy your app why not do it at 2AM when few users are online? Deployments should be simple, easy, and NOT require any problem solving by the deployer. Midday deployments with all hands on deck to handle issues seems like a bigger problem to me.

</comment><comment><USER37> The best reason not to do overnight deployments is that if something goes wrong, you want your developers to be alert and sharp, not dazed and sleep- deprived.

</comment><comment><USER38> Because our environment is non-trivial. It has nothing to do with confidence in application code, and everything to do with service-level agreements, impact to existing customers, and our own psyche. Ask SalesForce if they do their maintenance updates on weekends because of a lack of confidence in their codebase.

We're not doing 2am deployments, but we're certainly doing them "off-hours".

<comment><USER14> Triviality has nothing to do with it.

Nothing in your SLA says you have to have servers 1, 2 and 3 available. It says you have to have service X available. You can do that with out taking a downtime hit.

<comment><USER38> Wow, thanks for having better insight into our production environment than myself.

<comment><USER14> Feel free to correct me then. I have YET to work anywhere in any industry (financial primarily) that stated we had to have specific hardware up and running as part of an SLA.

It's an "SERVICE LEVEL AGREEMENT" not a "SERVER LEVEL AGREEMENT".

<comment><USER38> > I have YET to work anywhere in any industry

Sounds like your experience is the only one that matters, then.

</comment></comment></comment></comment></comment><comment><USER39> I started writing a reply but it turned into a blog post, here: ([http://casestatement.tumblr.com/post/11598425762/why-we- are-...](http://casestatement.tumblr.com/post/11598425762/why-we-are-still- deploying-overnight))</comment>


Unhosted - Freedom from web 2.0's monopoly platforms - <AUTHOR> http://www.unhosted.org/

<comment><USER2> <http://news.ycombinator.com/item?id=2021908>

</comment><comment><USER3> "Our web has been taken hostage and monopolized."

I'm not so sure that sensationalist line from their website is true. Currently I use AWS for a LOT of our latest work and I love how they (Amazon) keep pushing out new and exciting features/products. Amazon, I personally feel, championed the whole 'cloud' model that others are jumping into and I don't see this as being monopolized. Frankly, the Amazon entry made the difference to us of either bootstrapping a product or searching for VC funding - we would never have been able to run our system using traditional hosted machines and scaling up / down using EC2 helped us in a major way

<comment> mich-unhosted yes, that's a good point. in cloud services there are at least 3 options, and no monopoly (yet). also, we understand the big value that SaaS if offering people. that's exactly why we want to offer free software alternatives in that area. if MS Windows would not have been valuable to people, then there wouldn't have been a need to develop linux as a free software alternative to it. As I sometimes say about Google, "it wouldn't be so bad, if it weren't so good". while pleading guilty on the count of sensationalism ;) that line was more about monopolies like facebook, youtube, google docs, where there is only one provider.

</comment></comment><comment><USER4> Does anyone know how would this platform support messaging between users? Since each user encrypts his own data, any broadcast would have to be encrypted with every destination's public key... doesn't seem to work for stuff like a message forum.

<comment> mich-unhosted like in PGP, you would use a session key: symmetric encryption of the thread, then encrypt that symmetric key once for every thread- or forum member. you can only add people to this; to remove people from a thread you would need to send the remaining people a new session key. that's the rough idea we have, we are still waiting for someone to implement a research app so we can test how well this works.

<comment><USER4> Yeah, I see it now. I was stuck thinking about private/public keys only for some reason :(

</comment></comment></comment><comment><USER5> One thing that isn't immediately clear to me is if there is are provisions for "dynamic" allocation of storage providers. That is to say, instead of selecting one host to store the encrypted application data, could some sort of routing/load-balancing layer be used to allow the application to automatically select and use a provider (and recover when a provider disappears unexpectedly)?

<comment><USER6> From a purely technical standpoint I believe the answer is "Yes". Whether or not it makes sense from a performance and cost standpoint is another matter.

I find the idea really intriguing though. We already have a general strategy of trying to spread our infrastructure between different providers even if it's just as simple as pushing backups of our Rackspace hosts to S3.

</comment></comment><comment><USER7> This is interesting, I was just discussing a similar idea with a friend only a month or so ago. Our "inspiration" was the Wikileaks ordeal, to see if there was a way to sort of crowd source web pages, similar to how bittorrents work. Could a site such as wikileaks eliminate the problem of finding supportive hosting if they could just have their user base host their app instead? It'd be a cloud app hosted by the crowd.

Its an interesting idea, but one that is full of complicated issues, as mentioned in other comments here. Either way, I'd love to see a project like this get some traction, even if it provides a somewhat limited platform for development.

<comment> mich-unhosted it is definitely full of complicated issues, but we have already found solutions for some of them (not all yet). please join our mailing list and help think about the remaining ones. it will at least be interesting to have a place where people talk about these things. i can also recommend the p2p-hackers mailinglist to you in that respect.

</comment></comment><comment><USER8> The majority of web apps do at least one thing extra: they try to correlate user data to provide something more out of it (be it Google for improving search, be it facebook for providing social related suggestions, aka. ads)

This seems cannot be done at least in the current stage of Unhosted. I don't see how this can be done with encrypted storage that the provider can't do a lot even with polymorphic encryptions.

<comment> mich-unhosted you would need decentralized search algorithms. i haven't looked at that much myself, but there are some projects out there that seem interesting. to give an idea: when my friend is logged in, his browser could run algorithms that send me recommendations. think about how you receive information on twitter: not through centralized algorithms, it works through peer-to-peer retweeting. at least as a research topic, it is very interesting :) but you are right, there is stuff that's hard to do. i think the most challenging one would be google search.

</comment></comment><comment><USER9> So this is Freenet, only less secure?

<comment> mich-unhosted i can see your point, but there are some differences. the main one is that freenet is anonymous, and unhosted is not. i think unhosted is, if anything, most similar to SMTP: a protocol with which an application, that is inherently 'hosted' (uses persistence on online servers), can be 100% decentralized (bar its dependence on DNS). Instead of centralized, as is the default these days for internet apps. All its weaknesses apart, we should thank SMTP for being an alternative to a centralized facebook-messages. ;) Unhosted wants to create a decentralization layer for web apps to run on.</comment></comment>


The employee experience at Microsoft: Aligning benefits to our culture - <AUTHOR> http://blogs.microsoft.com/blog/2015/08/05/the-employee-experience-at-microsoft-aligning-benefits-to-our-culture/

<comment><AUTHOR> The benefits:

\- Extending parental leave to 12 weeks for new fathers, and 20 weeks for new mothers.

\- 2 additional paid holidays (Martin Luther King Day and Presidents Day).

\- Increased 401(k) match from 50 percent of the first 6 percent that employees defer, to 50 percent of all regular deferrals.</comment>


"Culture fit" is a two way street (2018) - <AUTHOR> https://rachelbythebay.com/w/2018/04/25/notequal/ <comment><USER2> This is a great post and so spot on. At some point in my career my 'review prep' (which was the time I spent working on my own evaluation of my year at a company) became answering the question, "Do I still want to work here?" I categorize my 'review' in four sections (which are each rated at one of five levels, needs improvement, sometimes meets expectations, meets expectations, sometimes exceeds expectations, or consistently exceeds expectations)

I start by reviewing how I'm being managed, I expect someone managing me to be clear in their expectations of my work product, provide resources when I have identified the need to complete jobs, can clearly articulate the problem I am expected to be solving, and can clearly articulate the criteria by which the solution will be evaluated.

Second I review my co-workers, using a three axis evaluation, can I trust what they say to be accurate/honest, can I count on them to meet their commitments, and are they willing to teach me when I don't understand something and conversely learn when their is something they do not know.

Third I review what level of support do I get to do my job. Am I provided with a workspace where I can get work done? Do have have the equipment I need to do what is being asked? Is my commute conducive to the hours required? And finally and most important, does this job allow me to balance work obligations and non-work obligations?

Fourth I review whether or not the company mission, ethics, and culture is still one that I wish to be a part of. Am I proud of the company's mission? Do I believe that the leadership will make ethical calls even if doing so would mean less profit margin? Can I relate to and am I compatible with the values that my co-workers espouse and the actions they take? (this is the "company culture" theme, is it still a company that fits me culturally)

A company that receives lower than a 3.0 rating I put on a 90 day "company improvement plan" (CIP). I bring issues to the leadership who are in a position to address the situations that I've found wanting and try to secure their commitment to change. If after 90 days they haven't been able to (if they choose not to they're done right away), then I "fire" the company and work to process my exit as expeditiously as possible.

<comment><USER3> Is this something you've always done or only something you've done as you've gained higher level positions? I'm imagining that compensation is always at some minimum satisfactory level as well (and it must be rather high unless you're wealthy or bought a home decades ago or live in some really LCOL area?). Do you only work at places that you truly want to work at from the get go?

I can't imagine implementing this at an IC level at a startup. (Which is where I've been mostly) I could see it at some places where you could switch teams in a big company and not deal with those same people again. (thus not having to reinterview fully) I've found that people will change their ways very rarely unless your loss would ruin them. They're much happier to lose ICs than change.

<comment><USER2> Not always, when I got out of school I just went to work.

It helped that my wife was doing similar work (she was a computer programmer) and we compared notes about our jobs. Now I personally think getting married was a good choice in my life but for this conversation it was extremely valuable to have someone at a different company with whom I could be completely honest and exchange thoughts and ideas with. When my wife left Xerox for Tandem one of the books she got was called "Divorcing a Company." We both read it. I would say that book was when I stopped looking at companies being a "one way" kind of thing, either they want me or they don't.

The book's thesis was that you are in a relationship with the company you work for, it can be a good relationship, and it can be an abusive relationship. Looking at your choice to leave, and the things that keep you from leaving, as you might a divorce from a spouse, can put into perspective who is more "at fault."

I started thinking about why I was working at a company more critically at that point and then as time progressed developed a set of things that were the key factors in my job satisfaction.

To this point, _" They're much happier to lose ICs than change."_ I agree completely. And that is why for me it was important to accept that people who won't see a reasonable request for what it is, are not worth wasting your time with. I doubt I will die thinking "I wish I had worked for an abusive boss longer" :-)

</comment></comment></comment><comment><USER4> Throwaway account for obvious reasons.

I'm mid-way through my first experience with this. Some warning flags to add for anyone wondering if it's them or you:

\- You're beginning to wonder if it's you that's crazy, despite successful previous roles.

\- Their conversation has moved from "we" to "I" (or "you" and "us").

\- Your number of known unknowns (usually people- or business-based) suddenly spikes for no apparent reason

\- Other people become (comically) formulaic in their response to questions.

\- Feedback channels are quietly shut down because they're "not really needed/too much process/etc"

I've started thinking of it as "professional gaslighting", though its motivations may not be that sinister. My main mistake was not listening to that feeling that "something is wrong". It's surprisingly prescient.

<comment><USER5> I've had that (the gaslighting) happen to me so many times.

"You didn't do this assignment"

"Er, yes I did, here it is"

"Well, you didn't keep me up-to-date on it"

"Er, here are my weekly status report e-mails"

"But you know I don't read my e-mails"

Huh?

Another good one was the following: I had assigned one of my reports a task before going on vacation. During said vacation, my "manager" pulls said report from that task. Then afterwards dings me for that task not being completed.

Huh?

"We're not paying you your bonus"

"Why?"

"You have to know that yourself".

"I do not, and no, that's not how this works"

"I won't tell you"

Fortunately that was in Germany, so not just crazy, but also illegal.

<comment><USER6> I'm intrigued: What part of German labour laws make it illegal to not tell you why your employer does not give you a voluntary payment (e.g.: A bonus)?

<comment><USER5> As the other commenter wrote: bonuses are variable compensation that is part of the negotiated contract/wage, so not at all 100% voluntary.

So the employer can refuse to pay the bonus, but they have to give a valid reason. There are two levels to this: first, basic employment law, which places very hard limits on what you can do. Second, many companies (like this one) have agreements between the works council and the company, agreements that regulate these and other matters and become part of the employment contract, and are therefore also legally binding and enforceable.

In all cases, the employer has to have valid, provable performance-related reasons, these have to be communicated to the employee in a timely fashion and the employee given a chance to improve their performance.

In my case, management was so clueless that they knew none of this, they thought that bonuses were gifts they can shower on people they favour on a whim, just like a king to his subjects.

It was a bit of a rude awakening. :-)

They then tried to create a "case" retroactively, but apart from the fact that there was no case, it also wouldn't have mattered at that time.

</comment></comment></comment></comment><comment><USER7> I'm self taught and have been doing this for 20 years. Most of that in a sort of survival serial startup mode that eventually stabilized into me having a clue around the time I turned 30.

I got hired a few years ago for a senior dev/architect/ops + engineering manager position at a ~5 person startup despite the fact that I was "a bad culture fit" because most of the staff was phds or masters level educated. At the time I found it really offensive that they'd even say that. The CEO said in the same breath "I think hiring you is the closest thing I'll get to cloning myself." Talk about mixed signals!

As it turns out, that assessment was solidly right. They were entrenched in policies and behavior that basically guaranteed a tragic failure. And because of those policies the rescue from mistakes always fell on my doorstep well past when it would be trivial to solve the problem. This created a horrifically unpredictable work environment.

All and all, it was a growth experience and I probably gave the company a year of life it wouldn't have had otherwise. I would never take another job where that was said to me though.

</comment><comment><USER8> > Also, due to the continued rampant mistreatment of people under our visa > situation (ranted about elsewhere), a lot of them have to put up with far > more shit.

That is perhaps the understatement within the whole article.

The ability to push some people further than others before they tap out, results in an environment where that is the normal level of stress.

And those who can survive it, but don't want to tend to be marked out as "problems", instead of acknowledging that the insanity is temporary and everyone should/will take a break to recover instead of just burning out one person at a time, while keeping the hiring pipeline trickling in to cover that.

<comment><USER9> First they came for the socialists, and I did not speak out ...

</comment></comment><comment><USER10> Cuture fit is a blank check to fail a person's interview just because you didn't like them in the first 30 seconds. Short of the candidate showing some glaring interpersonal issues (I once had a guy who used the word "fuck" during his interview like 100 times) it is categorically impossible to establish in a 45 minute interview whether a person is actually a "fit" or not. So it's mostly a legitimized form of hiring bias. Too old? That's a poor "culture fit" right there.

<comment><USER11> > Cuture fit is a blank check to fail a person's interview just because you > didn't like them in the first 30 seconds.

I hear this all the time. Yeah, that might be true in some cases, but it's also valid in quite a lot of instances (like the example you provided).

> it is categorically impossible to establish in a 45 minute interview whether > a person is actually a "fit" or not

I've run/sat in on several trainwreck interviews over the years (for ad account manager roles and logistical analyst roles mostly). Here are a few examples of candidates that were perfect in every way until the interview based on culture fit:

* The guy that mentioned he only traveled to Thailand because ladyboys do it better.

* The guy that mentioned he wouldn't work with anyone that drank alcohol because it's "the retardant of the masses". Fair enough opinion. About 20% of our ad sales came from alcohol-related businesses. I asked if he would have a problem dealing with liquor businesses. He explained that wouldn't be a problem as long as they didn't ask if he drank.

* I was sitting in on an interview with the Marketing Director for an account management gig on a Monday morning. We asked the candidate if she did anything noteworthy over the weekend. She told us she went dancing with her friend "Molly" at a music festival and laughed.

* The analyst that mentioned he scrapes NSFW subreddits in his spare time and links throwaway accounts to main accounts based on comment history, similar subreddit crossover, posting times, and vernacular (his tool was pretty impressive -- it sent him an email whenever it had a hit with over 50% accuracy or something which he received during the interview).

<comment><USER12> What's the problem with dancing with Molly?

<comment><USER13> Molly is a drug, so basically they said they got high all weekend. I don't have a problem with it personally, but a lot of workplaces do.

<comment><USER14> To be absolutely fair, being all into drugs myself - if someone actually used a phrase "I danced at a festival with my friend molly", I would absolutely never want to spend my time with them again.

That literally is the trashiest thing you can ever say.

<comment><USER15> What's your definition of trashy here if its not simply using drugs?

<comment><USER16> There's a big difference between using drugs discreetly and using drugs and talking about it in an inappropriate situation.

<comment><USER15> If its not immoral to use drugs it shouldn't be immoral to talk about it. "Trashy" is just an label for behavior deemed unwanted or associated with low class. But the parent (presumably) deemed using drugs not trashy by his own admission of using them.

<comment><USER17> It's also not immoral to have sex. It would be, at a minimum, very odd to share the blow-by-blow details of such activities the prior weekend with an interviewer. I don't think I'm being a prude to say I would probably close out that interview as soon as reasonably possible and move on.

<comment><USER14> By my definition of "trashy" - it's only "cool" to share the fact that you had sex with someone when you're 15.

Same is here: I can imagine many situations where discussing the effects of drugs and your experiences of them to be interesting. But "I spend a weekend dancing with molly" sounds more like a 15-year-old just got access to sex for the first time.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> The company I work for definitely hires people who are not a "culture fit" and our company is better for it. People who bring different perspective make your products stronger.

<comment><USER19> I think the word "culture" is overloaded, such that it's really hard to talk about and you can make it mean whatever you want, but there's a use for it that I don't know a better way to describe in a word. Yes, there is "culture fit" in terms of things that don't matter, and where it does good to push a company outside of a comfort zone in order to get the best people and new perspectives.

But at a certain point, you need to get alignment between what work you find rewarding/fulfilling/exciting and what work a company tends to recognize and reward. This essay I think gets at the heart of it:

[http://yosefk.com/blog/people-can-read-their-managers- mind.h...](http://yosefk.com/blog/people-can-read-their-managers-mind.html)

If you are a programmer, which kind of organization do you think you would tend to want to work at, all things being equal: one where the organization's culture is set by people who come from programming backgrounds or sales backgrounds? It's not the same answer as if you were a salesperson. (And of course, there are programmers who probably prefer the culture at a place driven by salespeople, and vice versa. And you can start to think about why that might be.)

As an employee, what a good culture fit means is "someplace that values and rewards the things I want to be doing." As an employer, a good culture fit is someone who responds well to the incentives you have in place for them. Sometimes, cultures are just objectively bad; anywhere that judges programmers by how many lines of code they write alone is establishing perverse incentives. But sometimes cultures are not better or worse objectively, just different. Some people work better in a research culture and some people work better in a product culture, for instance. That's fine. But that's where finding out if you and an employee are a culture fit can benefit both parties, not just be an excuse to hire only people you like. It's not about beliefs, it's about what work is valued and how it's valued.

<comment><USER20> Another point of alignment is social protocols. The point of a protocol is commonality. "let's agree to disagree" isn't a solution.

</comment></comment></comment><comment><USER21> Any kind of "fit" should be a two-way street but it usually isn't (or maybe it's nine lane super highway one-direction and pitted gravel road in the other direction). They have lots of money that they might spend on your arguably good skill set. You have a bit of money you might use to hold out until one better fit comes along.

They (for a sad portion of "they") can afford crappy "fits" in terms of competence if it flatters them in one or another fashions or a person shows a willingness to throw umpteen hours into the cause. What can you afford?

<comment><USER22> > You have a bit of money you might use to hold out until one better fit comes > along. > What can you afford?

I've done contracting work in between W2 jobs. In the full swing of contracting I make ~25% more money but I prefer the stability and simplistically of working a full time salary position (guaranteed two paychecks a month, better health insurance, fully clocked out by 6pm). I absolutely won't go into a full time salary position unless the company and culture is a very good fit and the pay is competitive.

If you know how to code and have something that proves you do (CS degree, work history, github etc) you should never feel stuck at one place. If a company isn't treating you with excellence you can make more money as an independent contractor.

<comment><USER23> Why Only 25% ?

I just had to point out in the UK to a recruiter pitching me a short term contact at straight time instead of at contract rates is taking the piss.

</comment></comment></comment><comment><USER24> I think that like any category of evaluation, it works best if it's specific, consistent, and planned.

Eg "Part of our culture is that we are collaborative; when we discussed code reviews and the candidate said they think they are a waste of time, that raised a flag because constructive and timely code reviews is an expectation for all our our engineers" That's pretty good.

"Our culture is collaborative. This candidate didn't feel like they'd be a good fit here." That's not so good.

Have an evaluation criteria going in. Rate candidates on the the same criteria. In debriefs, use specific examples from the interview to explain why you rated them as you did. Otherwise, it's just post-hoc rationalization of a snap emotional decision.

</comment><comment><USER25> Absolutely. Azure? "We take care of technical debt as we go"? You don't know your engineers retention off the top of your head, but half of the projects I'm supposed to interface with have lost their tech lead and you can't replace any? I've asked a non-technical executive what is a rollback and they didn't know?

It's not me, darling, it's you.

</comment><comment><USER26> For all the rhetoric in the tech industry over diversity, "Culture Fit" seems a bit of a catch all exit hatch and anything but diverse.

<comment><USER27> Well, let's be real - there's good diversity and bad diversity. No one says "We need more diversity" and means "At the moment everyone in the office has good hygiene standards, let's bring in someone who smells".

The problem is that "Culture Fit" is often undefined - rarely is it explicit enough for us to say: "Our culture is x,y,z. This person showed this behavior so it's a no".

Although one thing I will say as an interviewer is I've had to reject candidates on "Culture Fit" in the past based on things like "This candidate talks way too much and it's so disruptive and frustrating that I literally can't get through the competency part of the interview". However, there is no way I'm going to feed that back to the candidate- so often Culture Fit is used as a neutral way of rejecting someone.

</comment></comment><comment><USER28> As someone who has built and led many engineering/product teams interviewing & evaluating for/on culture is super important.

One key thing though is making sure everyone on the team understands our culture, and applies is somewhat fairly.

Personally I define "culture" as following the values set by the company and the department.

At my current place what are the core culture concepts we look out for (in a nutshell):

\- Valuing the delivery of functional & sustainable products over checking boxes or coming up with impressive/resume-building solutions

\- Everyone is expected to support, teach, and grow one another and everyone has something they can teach.

\- Valuing receiving & giving honest, direct, and valuable feedback.

Many engineers would NOT fit this culture and in some interviews that becomes very apparent. We also send our values to our interviews before we bring them on site and reiterate them strongly before giving an offer letter... Thoes who have ignored this have never lasted to 6 months due to clashes with deliverables and with other team members.

</comment><comment><USER29> This is very true, but it's also important to remember that the drift might not indicate that anyone has lost their way. The needs at a company of twelve people are different than the needs at a company of a hundred, a thousand, ten thousand. At the disruptor vs. the incumbent. Pre-profit vs. post-profit. I know people who have been first developer or first COO/CMO/VPE at multiple companies, leaving each without any rancor whatsoever when those companies outgrew their own ideal skillset and working style.

Sometimes people and companies _naturally_ grow apart. While the OP's point that it's not always your fault is a good one, the conclusion (that if it's not your fault it must be the company's) does not follow. Sometimes it's not a fault. It's just a thing that happened.

</comment><comment><USER30> > Look at a statement of equivalence. You might say that "A is equal to B" or > "A == B". There are two "flows" going on there: A has to match up with B, > sure, but B also has to match up with A.

Weird way to describe the symmetric property of equality from discrete math 201

<comment><USER31> Math? Me? Not so much.

If it sounds like some profound theorem then I assure you it's entirely coincidental.

</comment></comment><comment><USER32> > If really good people who are able to literally work anywhere are still at > your company even though they don't have to be, it's probably doing pretty > well. If those same people then turn around and leave the company, you > should worry. They are the canaries in the coal mine, and fail first. It > takes much longer for it to filter down to the folks who don't have the > privilege of having so much flexibility and so many options.

Reminds me of this advice as well; [https://steveblank.com/2009/12/21/the- elves-leave-middle-ear...](https://steveblank.com/2009/12/21/the-elves-leave- middle-earth-%E2%80%93-soda%E2%80%99s-are-no-longer-free/)

</comment><comment><USER33> To paraphrase Joel Spolsky, using cultural fit for dismissing a candidate has a high risk being a form of discrimination: [https://www.stackoverflowbusiness.com/blog/the-trouble- with-...](https://www.stackoverflowbusiness.com/blog/the-trouble-with-culture- fit)

</comment><comment><USER34> [http://mathworld.wolfram.com/PerpendicularBisector.html](http://mathworld.wolfram.com/PerpendicularBisector.html)

</comment><comment><USER35> You'd be amazed at corporate ability to find excuses for their canaries departure. Sometimes to the degree that you could be forgiven for assuming their goal was downsizing without layoffs.

<comment><USER36> _> downsizing without layoffs_

It's the most destructive form of downsizing for the company, as the competent staff who have options jump ship and only the dregs are left hanging around.

<comment><USER37> And the good people _will_ bad-mouth you later. Losing you further potential good hires.

</comment></comment></comment><comment><USER38> I think "culture" is a vague word that can be made to do a lot of work, a weasel word. Culture as a reason for not hiring someone strikes me a very suspicious. There should be a concrete reason the person is not fit for the work as part of a no-hire decision.

"Culture" should be an emergent property of the people who work at the company.

</comment><comment><USER39> The thing is, homogenous teams perform better than diverse ones, contrary to the common agenda these days. But you can't say I want everybody in my team to be more or less same as me, same culture, same behavioural codes, same common sense and all those things that makes a team perform smoothly like a well oiled machine. So instead they invent all kind of terms and roundabout ways to get to the same results while preaching to the masses about diversity and all kind of nonsense like that.

<comment><AUTHOR> > homogenous teams perform better than diverse ones

What evidence do you have for this, and how do you define "homogeneous"? (Homogeneous in terms of what attributes?)

Maybe you've just been on teams where the people aren't very good at getting along with people who are different from themselves. For example, if adding a well-qualified woman to a team of men causes the team to lose productivity, that's probably a sign of immaturity in the team, not a problem with the new member.

</comment></comment><comment><USER40> "Culture fit" is a cop out for discrimination.

</comment><comment><USER41> Companies don't have cultures. They have ways of demanding more of workers though propaganda.

That's why this stuff always feels hollow and twisted.

<comment><USER42> Companies stated culture != it's actual culture.

The employees of any organization develop culture in how they interact (this is the real org culture), but some organizations also try and steer towards the culture they consider 'ideal' (the false culture you allude to). This attempt is often ham-fisted, and often fails.</comment></comment>


Show HN: My first webapp. Yikes! Read and Post Stories anonymously - <AUTHOR> http://www.sam-the-man.com/yikes

<comment><USER2> _This Project is here to help me learn PHP & MySQL_

If this is a project to learn PHP and MySQL (and maybe Javascript) you should not build it using bootstrap (you've lose all the fun ;). But this is only my opinion.

<comment><AUTHOR> How is bootstrap holding back when it comes to PHP an MySQL? JS, sure, I can understand, since most of it is just using their API, but how is it holding me back when it comes to PHP and MySQL?

<comment><USER2> Because it is not necessary to learn PHP/MySQL. And if you add JS, even worst, don't use bootstrap at all. Don't use any PHP framework too at this stage.

<comment><USER3> It's a framework that makes things look decent enough by default though.

If your goal is to learn something other than web design (eg. PHP / MySQL), then surely you want something that can do things well in that department by default so you don't have to mess around with it too much?

<comment><AUTHOR> That was my intention: Learning the practical side of PHP and MySQL, without having to deal with too much design and markup. At the same time I didn't want my project to like a POS, which is the main reason I used Bootstrap.

</comment></comment></comment></comment></comment><comment><USER4> The color of the large top banner is killing my eyes but otherwise it seems to work as intended. Did you seed the stories yourself or did you get some actual users to write them?

<comment><AUTHOR> It's killing your eyes because it's too damn ugly or because it's too bright? The stories are all from actual users. Family, friends, friends of friends, etc.

</comment></comment><comment><AUTHOR> I made this to get into php and mysql. Constructive Criticism, and suggestions are welcome and appreciated :).

<comment><USER3> Probably needs a Recaptcha or similar (<http://www.google.com/recaptcha>) on the form to slow down those pesky webspammers a bit. Maybe think about nofollowing (<http://en.wikipedia.org/wiki/Nofollow>) any links in the story too, so you don't get used as SEO juice. My link didn't work out too well either (changed to <http://www.sam-the-man.com/yikes/www.google.com>)

Also, make sure to filter your user input to avoid XSS attacks. I just posted a story and your page will print HTML and JS verbatim, meaning I could do malicious things. See here: <https://www.owasp.org/index.php/Cross- site_Scripting_(XSS)>

Apart from that, looks pretty good, well done :)

<comment><AUTHOR> Thank you very much. I was hoping that the mysql_real_escape_string() function would be enough, but it did seem too easy.

I will definitely look further into it! Thanks again

<comment><USER3> I'm not a PHP / MySQL guy, but this might help: <http://stackoverflow.com/a/110576></comment></comment></comment></comment>


Dear Startup: I'm not going to create an account to send you my resume - <AUTHOR>

The last thing I'm going to do is create an account at some 3rd party HR/JobAd site just because you're too lazy to handle the few resumes you're likely to get for a $high_demand_position.<p>Some of your companies sound interesting at face-value, but the fact that you've succumbed (I'm assuming) to the sales pitch of Captain Recruiter, JobVite, or whatever parasite service tells me you don't have a very good understanding of friction, and therefore by your use of these sites I assume your company is not viable at the least, and at most the interview process would be similarly cookie-cutter. Good luck. <comment><USER2> My experience (as an employer/customer) with this outfit (jobvite) was like time travel back to 1998 or so--not retro in a good way though. First, the custom "candidate reports" delivered to us were often poorly parsed versions of the actual candidate CVs. Second, the have no interest in aggregating information from community resources (linkedin, StackOverflow, SO Careers, etc.) nor even in allowing a candidate to include their accounts on those Sites. And finally, because the candidate contacts the company via jobvite, when the interested employer replies via email, it's likely to get flagged as spam or ignored because there is no email in the candidate's outbox with this email domain (this seemed to happen about 25% of the time to us).

</comment><comment><USER3> As someone thats' just finished going through a job search, one of the biggest turnoffs that I found was companies that made you jump through hoops to even get to the interview stage. Whether it was dealing with recruiters (who with few exceptions were not worth the time to talk too), annoying applicant sites like jobvite or telos (my personal fav...not), or having to give your resume through their homerolled system that never parsed your resume right and you had to bring it with you anyways to the interview, it does nothing but sour people on your company. Doubly so for folks that are looking to get in on a startup.

A startup should be hiring themselves, they should be meeting with potential applicants themselves, and they should realize that people that are looking at startups are usually doing so because they DON'T want the trappings that the megacorps have. Throwing up barriers right at the offsets will scare the A and B level talent away to your competitors, and all you'll find is the C level talent, and the megacorps leavings.

</comment><comment><USER4> Personally when applying for a start-up I would never go through recruiters. I don't want to go through that process. I rather meet with the company in person over coffee and show them the work I've done and discuss things like that. If it is an early stage start-up then I want to work there because I like what the company is doing and want to be part of it. If it can't happen on a personal level without going through millions of hoops then its already a very bad sign.

<comment><USER3> I'd go one step further and say that if a startup can't be bothered to be personal in their dealings with their potential employees, is it really a company that you even want to bother applying too? In my latest search there were jobs that looked great, but since they were with recruiters I was either leery or didnt' bother at all. Too many headaches and hoops to jump through, and in the area I'm in right now it's a buyers market for talent

</comment></comment><comment><USER5> I've recently run into a couple of:

Them (first contact): "We're really interested in talking with you."

Me: "Okay, tell me more."

Them: {20 questions}

<comment><AUTHOR> I have a standard reply in those situations where I come clean and say, "in order to weed out mindless recruiters, could you tell me a little bit about the position?" Legit recruiters, especially in our lines of work here on HN, will always have a job description and typically a company name (ask twice if they don't give you the latter). Resume-collecting recruiters typically don't reply to that email.

<comment><USER5> I was unclear. I asked about the position.

I'm used to either no response or a couple of job descriptions, as you suggest.

They replied, but with 20 questions. This is new (to me).

<comment><AUTHOR> Did they tell you what company it was? That's the clue that you're dealing with someone legit, but it sounds like they reacted by trying to snow you under?

<comment><USER5> > Did they tell you what company it was?

Yes. In fact, both appear to be internal recruiters. (Their e-mail addresses are at the company in question.)

</comment></comment></comment></comment></comment><comment><AUTHOR> As if on cue, a sponsored Tweet:

<https://twitter.com/#!/Jobvite/status/195248446020661248>

</comment><comment><USER6> Just saw a blip for a recruiter's startup "job fair" where the applicants have to go through a pre-screening to be allowed in. Yea, I'm going to take my time to subject myself to recruiter BS so I can possibly be offered some equity and a low ball salary. Why? Why would anyone, who knows what they are doing and are truly skilled, subject themselves to a recruiters process like this. You want rockstars you better be a rockstar yourself. Brogrammer startup job fairs are not going to cut it.</comment>


NewMogul → Markenomics → Forlue - <AUTHOR> http://forlue.com/

<comment><USER2> I miss NM every day.

Could you add an RSS feed to forlue?

<comment><USER3> Yes, this is something that I'll add soon.</comment></comment>


OpenMediaVault: FreeNAS on Debian - <AUTHOR> http://www.openmediavault.org/

<comment><USER2> This is not really FreeNAS on Debian. Its ooooooold "FreeNAS" with maybe 30-40% of the features and less stability. There's no reason to want this when FreeNAS is free and a lot better.

<comment><AUTHOR> Thanks. I posted this specifically to get such critiques of these various flavors of FreeNAS: FreeNAS, NAS4Free, OpenMediaVault.

<comment><USER2> I would really only recommend the official FreeNAS frankly.</comment></comment></comment>


Did Dell just outdesign Apple? - <AUTHOR> http://www.alleyinsider.com/2008/7/dells-new-mini-pc-looks-good

<comment><USER2> I don't know if Dell wins, but they are certainly in the game. I think the biggest difference is that these Dells are designed to be seen where the minis are designed to be invisible.

The Dells are quite a bit larger than a mini, about twice the volume. The Dell has better specs, but the current mini is late in its product cycle, so that is to be expected.

Bluray is a real win if you are the sort of person that uses physical media and plans to use Bluray.

Windows is a win if you are the sort of person that uses Windows.

The hard drive size is a big win if you need disk space.

HDMI is nice, but that is more about supporting the DRM of the blue-ray drive since the mini has the non-crippling DVI port (as does the Dell).

I wonder about the fan noise. On the back port picture you can see a lot of heat sink behind the fan.

<comment><USER3> _Bluray is a real win if you are the sort of person that uses physical media and plans to use Bluray._

I want to not use physical media, but it's the only way to get most HD content. We have a NetFlix account, and watch a lot of the instant content, but even on fat cable broadband (36Mbits, I think) we get far less than HD resolution. Hulu only serves up 480p in HD mode. I've been trying to make use of Amazon Unbox, but the client is broken...and the one thing we did buy wasn't HD. Likewise iTunes. I guess in another six months or a year, we'll be able to stop getting movies via the mail.

</comment></comment><comment><USER4> Not even close. The Dell has lots of venting, beveling, and recessing that Apple's products don't. Also the way the pieces of plastic come together isn't too neat. Also, the typography isn't good. Etc.

Here's a detailed pic: [http://www.dell.com/downloads/global/corporate/imagebank/des...](http://www.dell.com/downloads/global/corporate/imagebank/desktops/studio_hybrid_ruby_vh_300.jpg)

</comment><comment><USER3> Not really, but they certainly outspecced them. It looks good, but not as good as Apple designs...Apple has an almost magical approach to subtle design (doesn't make up for the other negatives that come with Apple products, IMHO, but they certainly do look pretty).

I checked out the Apple TV thing and the Mac Mini, and when I found they couldn't drive my girlfriends 1080p TV at full resolution (the lack of a BluRay drive was also a factor) I built a Windows Vista based box (cost a couple hundred bucks more, admittedly, due to the BluRay drive). If this had existed at the time, I would probably have bought from Dell, instead. It's a solid effort, though I'm not actually sure if it'll play 1080p. It seems right on the borderline with regard to graphics horsepower. But it certainly looks nicer than the HTPC I built (it's in a nice case that looks like a high end HiFi from the 70's, but it's kinda huge--quiet, though, which is the primary concern). And as a bonus, it can play pretty much all of the latest PC games at nice high resolutions (maybe not full 1080p, but pretty close to it).

<comment><USER5> I'm not sure where you got your information, but the TV and Mac Mini can both display 1080p. And the mini can decode 1080p h264 video without breaking a sweat - even a core duo 1.83 has no issues there.

</comment></comment><comment><USER6> No, not really. But by comparison to Dell's usual Stalinist aesthetic it's fairly nice.

</comment><comment><USER7> They look awesome!</comment>


Apple's first employee: The remarkable odyssey of Bill Fernandez - <AUTHOR> http://www.techrepublic.com/article/apples-first-employee-the-remarkable-odyssey-of-bill-fernandez/ <comment><USER2> This is how you tell what kind of guy Woz really is:

 _Around the time of the Apple IPO in late 1980, Woz decided to give away stock options to the earliest Apple employees who had never gotten options -- including Randy Wigginton, Chris Espinosa, Kottke, and Fernandez. He gave them each a stock grant out of his own chunk of shares. It was a generous move, especially towards Wozniak 's old neighbor and friend with whom he'd built his first computer and helped become Apple's first employee._

<comment><USER3> If you have not yet already read JL's interview of Wozniak in Founders at Work, the Floppy drive story is priceless.

[http://www.foundersatwork.com/steve- wozniak.html](http://www.foundersatwork.com/steve-wozniak.html)

<comment><AUTHOR> Also great retelling by Andy Hertzfeld on the 3.5" Sony floppy disk drive:

"Quick, Hide In This Closet!"

[http://www.folklore.org/StoryView.py?project=Macintosh&story...](http://www.folklore.org/StoryView.py?project=Macintosh&story=Hide_Under_This_Desk.txt)

<comment><USER4> You don't hear too many stories like this about Steve:

"Steve swallowed his pride and thanked them for disobeying him and doing the right thing."

<comment><USER5> Actually you do. There are many cases of Steve realizing he was wrong and changing his position. In his Eulogy Jonny Ive talked about it as one of his best known features.

But this doesn't fit the "steve jobs is a tyrannical asshole and apple's success is only a fluke of marketing and apple is evil" narrative that is so popular among google worshipers.

<comment><USER6> Who mentioned Google? Stop making technology companies your sports teams.

<comment><USER7> That person was arguing against the simplistic story lines that are created when we treat tech companies like sports teams. It came off some what badly but I believe it was correct. There are tons of stories of steve jobs swallowing his pride and admitting he was wrong but they are not spread as widely because they don't fit the public perception of him.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> >> _He said Omnibotics will "build smart home electronics and I'm hoping that we can finally make it possible to make your house more responsive to you, to give your house a user interface other than mechanical switches and knobs."_

Wondering how that vision loops back to his childhood in the Japanese styled home. What kinds of interface? What definition of simplicity?</comment>


Ask HN: Equity for first employee unpaid? - <AUTHOR> Startup consist of 2 founders, they were at this for the last year+ - building a B2B product. 1. industry expert / sales 2. data scientist / cto (part-time)
One of them is my friend.
I joined 3 months ago, helped accelerated the growth - research, sales support, marketing, and products.
However I did not know enough about the industry (which I caught up understanding through reading; [experience needed]) nor I have data science expertise.
Last 3 months, we spoken to clients. Soon to closing early BETA deals. Marketing materials developed. Prior, we did not have any of this.
We still will not see substantial revenue until the next 3 months.
So for 6+ months, with little or no income. I am okay for now since I still live with my family and have savings. However risk is being incurred...
Option A: Look for a product manager role at another startup.
Option B: Stay, if 10%+ equity? No income for 6+ months?
EDIT Option C: Do some freelance gig till then. (Not a big fan of this one.)
FYI, I am a self-taught developer, designer, and sales & marketing. Jack of all trades, master of none (depends on who am I talking to). Just graduated Masters a few years ago, previously worked in financial industry. My aspiration is to be an entrepreneur myself, tried a few things before, hard time finding a team. <comment><USER2> So here is the really good news: whatever happens you've learned from direct experience the sort of potentially disastrous naive [in the technical sense] mistakes founders and early hires can make at a time when coming away with nothing will certainly suck if it happens but won't be absolutely devastating. [1]

Now to me, if I were one of the founders, the most critical question on my mind would [hopefully] not be, how much value have I put into the company in the past six months versus how much you have put in. The critical question on my mind [hopefully] would be how much value you bring to the company in the future. Maybe it's 10% - in which case I would consider looking for someone else. What I would want [hopefully] is someone with the potential to exponentially increase the value of the company and therefore who is worth a founder's share. The idea is that a new company is born the day you come onboard.

Yeah it's a little crazy, but a startup is about big risks and big rewards, not little ones. 10% is fine for a lifestyle business with a proven business model and where the founders bring irreplaceable assets [big capital or licensed access to a restricted market]. But lets face it, though most people probably cannot grow and run a company, there are a substantial number who can unless you're Wolfram Research.

Anyway, I don't if that's advice good bad or indifferent, but good luck.

[1] If you walk away with nothing financial from this deal, it's still pretty much identical to the most likely outcome had you been granted equity six months ago. Startups usually fail.

</comment><comment><USER3> Yea... this is something you should have talked about on day -1. You can really mess up relationships by not getting the expectations out there and then making sure everyone lives up to them.

I would have a conversation with ownership and see if they want to give you any stock. I would couch it by saying. I'm really glad you let me learn from you, but I think its time for me to either get a job or get some visibility to one here.

I won't start making demands... doesn't sound like you set the expectations in the beginning and that's on you. Don't get mad at them for accepting your "help" paid or not. They might value your contribution very differently than you.

<comment><AUTHOR> Yes. I actually lost my job the same day, I asked if my friend needed any help.

So there was no expectation set on the 1st day. The first and 2nd month or so - was still determining our product-market fit. The 3rd month was more aligning to clients.

However, its clear the value I set for the team behind the 3 month acceleration process. And that now, if they lose my contribution, the whole startup would be set back. (granted thats my perspective)

<comment><USER3> Not trying to argue with you. I'm only pointing out that if they felt they "needed" you they would have clarified that by now. They may think they are "helping" you out by giving you some real world experience.

My point is you should have a talk with them and find out what's in their head, before you go all "I think I deserve..." There is no better time then now if the project is at a critical junction.

Simply ask what expectations you should have from them employment/equity-wise. How do they see me folding you into the firm. Don't let them put it off and get an answer, within a reasonable time.

Don't make it combative. Find out what they are thinking... digest it... tell them what you are thinking... let them digest... and come to an agreement... or not

</comment></comment></comment><comment><USER4> 10% is good if you are getting salary. If you aren't, you are a founder -- it should be more equitable, but not necessarily equal. If you get salary, perhaps you and next 2-4 employees should be splitting the 10%.

One thing to do is to make a contingent bonus for the pay you aren't getting. Let's say you think 6 months is worth 50k. Then, they sign a contract where they pay you a 50k (or more) bonus if the company (1) makes cumulative revenue of xx million or (2) is acquired (3) raises a round over zz million.

</comment><comment><USER5> Can you lay out a new case for them? If you've already agreed to Option B, then I would say it's going to be difficult to do anything other than assess which option is more ideal for you personally. Otherwise I would add an addendum to Option B, which is that the company pays you back for all your unpaid time (whatever rate is agreeable) should it become profitable or get funded.

<comment><AUTHOR> We will have the docs set up in the next 2-3 weeks.

Agreement was we do opposing research and share those readings based on common equity startup practices.

Obviously, its all different case-by-case.

What equity (or extra) compensation should I request for at this point?

A thought keep passing my head is: If I take a job at a mature startup, I be an employee as well. Here, I am also an employee (co-founder level) but no pay. Status is not important at the end, but it just cannot escape my head about it.</comment></comment>


Rosetta Stone to be first VC-backed IPO in six months - <AUTHOR> http://www.washingtonpost.com/wp-dyn/content/article/2009/04/01/AR2009040103976.html?wprss=rss_business

<comment><USER2> Good for them. I really don't see this as a sign that investor confidence is increasing though. Rosetta Stone is probably the most recognized names in computerized language instruction, and I am sure it is profitable. The company is also around 17 years old.

So I really don't see investing in Rosetta Stone to be a big risk. I have no idea how the stock is going to do, but I don't see any significant risk that the company will go bankrupt or lose the majority of its value in a year. They already have a successful business model.

</comment><comment><USER3> "According to the company's recent filing with the SEC, Rosetta plans to grow its business with new types of Web-based language instruction services."

Hopefully a good mobile application for Blackberry/android/iphone is a part of that. I used the desktop app for a while and felt it was a pretty good way to casually pick up a language (when paired with a dictionary and some grammar/theory books), but gave it up. I have a 40min commute each way 5 days a week, and would gladly use a mobile app if they had one.

</comment><comment><USER4> Hopefully this is a decent indicator of increased investor confidence.</comment>


Readability Advantages of C over C++ - <AUTHOR> http://coliveira.net/software/readability-advantages-of-c-over-c/

<comment><USER2> _Maybe the results of a function call may not be completely understood by the programmer, but from the syntactical point of view it is easy to figure out what is going on in the program.

And, to put it clearly, the problem is not that the function or class is doing something we don't know. The problem is mostly in trying to figure out what is happening in a given line of code. In C is very easy to figure out what is being called (up to macros): just read the manual for the functions being used and you will have a good idea of what is being executed._

After sorting through this pile of caveats, what point remains?

 _In C++, on the other hand, a large number of things can be happening in a single line: an overloaded operator, a type conversion, a template instantiation, an overridden function in one of a dozen of classes, a constructor called in some part of the hierarchy, in some namespace…_

It isn't that hard to figure things out in C++. An operator is an operator is an operator; there are a fixed list of symbols that can be used as operators. An operator may be defined by the language, or it may be user-defined. Template instantiations are visible. (I don't recall whether you need <> when a template has default parameters, but in that case it just acts like a regular class anyway.) Constructors are just functions that get called when objects are created. Granted, you can create a confusing situation by using multiple inheritance, but multiple inheritance is one of C++'s nuclear options, like macros in C. (I suspect the author would blame C++ for having multiple nuclear options instead of just one.)

Namespaces are very nice for organizing code, and almost every language has some equivalent mechanism. I think the burden is on the author to argue that everyone else is wrong about this.

I'll give him type conversions. Those can be tricky and unexpected, and it's backwards that you have to declare your constructors "explicit" to prevent them from being used in type conversions. It should be the other way around; you should have to declare constructors "implicit" in the rare cases where you want to enable conversion. However, once you're paying attention (and I agree you shouldn't have to), it isn't difficult to figure out when type conversion is happening, simply because you'll see that an argument of a certain type is being passed to a function that cannot take that type. If it compiles, then a type conversion is being invoked. Where people get really confused is when they're _trying_ to take advantage of type conversion, but the conversion they think is happening isn't actually happening. Personally, I've rarely messed with it, so I don't care.

 _You have to be smart enough to figure out what is going on_

I can't tell you how much it hurts my head to read C or how many times I've thought I just wouldn't be smart enough to be a C programmer. It's a different kind of thinking. I'd much rather read a few hundred lines of C++ full of tricky constructs than a few thousand lines of C full of buffer allocations and deallocations and return value checks. My brain overflows and I can't keep track of the high-level shape of the code. Trying to figure out how C code works when I don't already know its purpose is very hard for me. To each his own, I guess.

</comment><comment><USER3> > It is not a surprise that large scale projects such as the Linux kernel use > C without any problem.

I'm sorry, but a post that lacks intellectual honesty when discussing a rather complex topic such as this one just shouldn't make it to the HN front page. If you cannot bring yourself to at least admit in passing that increased expressiveness of a language can be beneficial in some situations, then I'm not even sure what to tell you. Your post is not weakened by admitting this, but I feel like the perception is that you must take a hardline approach.

As I've said before, these sorts of blog posts skate by simply because they tell HN what it wants to hear without actually contributing anything new to the discussion. Thus, it is bikeshedding, and, ergo, not 'highly interesting' (per pg's guideline). Additionally, this topic comes up repeatedly, and I'm not certain why it needs constant discussion.

<comment><USER4> I understand your point on increasing expressiveness, but how far do you need to go into post-incrementing C before you decide you'd better use a language made with the specific purpose of supporting such expressiveness rather than bolting it on top of C.

<comment><USER5> Unfortunately there are still many problem domains where you absolutely require the low-level control of memory and execution time that C and C++ provide. In most of those domains the extra expressiveness of C++ is a big win, despite its many warts.

Could you, with hindsight, design a better low-level language than C++ for these tasks? Yes. Is such a language available today? No. People write things like Photoshop and Cubase and Maya in C++ for a reason.

<comment><USER6> Isn't D exactly what you're looking for here? That is, roughly equivalent to C++ but with a coherent design?

I head Go also lets you manage memory manually if you want to.

<comment><USER7> D somewhat lacks stability. The language is still maturing and there was, for a long time, a major split in which standard library was... standard (and even now, that question isn't really clear). There's also the issue of tools - there are only two D compilers I know of, and neither of them is that great (and GDC is buggy, IME). It's also got several warts of its own.

When D matures a little more, maybe. At least C++ has a stable standard lib.

That's why I'm holding off on using it, and (with the exception of the standard lib) probably why most people are holding back.

</comment></comment></comment></comment></comment><comment><USER8> A "fun" exercise in C++ is to take a line of code that makes extensive use of advanced features, like templates, smart pointers, etc. and step through a -O0 compile with gdb. I was shocked, in some cases, about how many different functions were called for what looks like a simple expression.

This can lead to some interesting errors. For example, writing

void foo(const std::string s)

by mistake, instead of

void foo(const std::string &s)

won't result in a compiler error, but will result in an unusually large, and unexpected overhead in calling foo.

On the other hand, STL is great (less the error messages). I sorely miss it when programming in C.

<comment> loup-vaillant > _I sorely miss [the STL] when programming in C_.

Well, C++ got at least one thing right: deciding to support parametric polymorphism (or "genericity"). Templates are quite ugly, but at least they do the job.

</comment></comment><comment><USER9> It seems like the thesis is that C++ is a more complicated language, and therefore the code produced in it is more complicated and harder to comprehend. This line of reasoning is specious.

</comment><comment><USER10> _For example, operators can be overloaded, so that many math operations, and even punctuation such as "," can be overloaded by programmers._

',' is an operator too, not just punctuation.

<http://en.wikipedia.org/wiki/Comma_operator>

</comment><comment><USER11> This article sounds like a lesser version of a Linus rant I read once and even he used the strawman argument of "in C you can always see what's going on". Does nobody in C use function pointers?

I say horses for courses and if you use operator overloading and templates to make your C++ code overly cute then it's not the fault of the language.

<comment><USER12> C++ can be quite readable, but C can't be particularly magical. If I were Linus and I spent my days reviewing patches from all sorts of folks to a very large codebase, I'd be inclined to prefer a language that can't do anything unless you ask for it.

</comment></comment><comment><USER13> Readability depends on the writer, and if someone is trying to duplicate the functionality of C++ in C I expect they're liable to do a worse job than using C++ directly. void* pointers are one example of why.

</comment><comment><USER14> The usual complaint about C++ is the misleading compiler errors when one uses the STL. I disagree there are other readability issues. Encapsulation and polymorphism exist precisely because you don't _want_ to know what's underneath. It goes without saying that overusing operator overloading is bad design, not just a readability issue.</comment>