"Build a scalable service on top of something open source, rather than T&M services."
37Signals/Basecamp are an interesting example of this. Rather than building a business around supporting Ruby on Rails, they've built products on top of the framework they created. It's certainly an outlier and I can't think of many other examples like them who both built a popular tool, but then just used it as a tool instead of trying to monetize it directly.
DHH wrote: "External, expected rewards diminish the intrinsic motivation of the fundraising open-source contributor. It risks transporting a community of peers into a transactional terminal. And that buyer-seller frame detracts from the magic that is peer-collaborators.
It also holds the threat of corrupting the community at large. We plant the seeds of discontent by selective monetary rewards."
I've certainly seen this recently in some open-source communities. The peer-to-peer camaraderie transitions to a dictator-to-underlings relationship and people start defecting. It's sad to see, but happens when an open-source company isn't vigilant in nurturing the community that got them where they are.
Kudos to those companies that are able to pull off maintaining a strong community while still staying focused. It's a rare thing to be able to do well and behind the scenes there's a lot of work that goes into that kind of nurturing.
A lot of great new features in this release - very excited to see the tool become more and more powerful.
I only came across Ansible this summer, but it really blew my mind. I've been doing systems contracting for a few years now and Ansible is the most valuable tool I've come across for systems management so far. Now, rather than have to use (and train my clients on) multiple tools, I can have them just learn one solid tool that can handle orchestration, deployment, configuration management, server inventory, etc. I can now do a systems project in days when before the same project would take weeks. Expect to hear a lot more about Ansible in the future.
Ansible isn't awesome because of a feature-list. It's awesome because it saves me time and gives me a lot of power for very little investment. Whether you're setting up a single server or 10,000 nodes, you can use this tool to give you a ton of leverage without having to spend weeks learning complex tools.
That's why I've been focusing on it so much in the last few months.
Your book looks fantastic - seriously considering getting a copy right now.
I've just started learning Ansible, and I'm interested in using it for slightly more complex setups than the typical "deploy my Django app to my VPS" scenario - e.g. EC2, load balancing, RabbitMQ/Celery and shared configuration between servers.
Can you recommend any other comprehensive tutorials that are a bit more high-level than the docs? I'm also interested in replacing our use of Fabric with Ansible - there doesn't seem to be a lot of documentation around running one-off tasks though...
I'm a big advocate of Kathy Sierra's "minimum badass user" strategy. Basically, try to write as little about yourself and write what will be most useful to improve someone else's abilities. I'm not amazing at this (yet), but it's my main goal.
Identifying too closely with being a "writer" or "coder" or whatever can be detrimental to doing more meaningful work. That's because it's all about you. But really, it should be all about your users and how you are making their lives better.
The more you can focus on "What will help my reader be awesome?" instead of "What will I write?", the better your writing will be.
Nobody cares about how awesome I am (and they shouldn't!), but everyone cares about becoming more awesome themselves. Resist the temptation to focus on yourself and shift that focus to them and you'll automatically be better than 99% of writers out there.
If you spend a week learning something remarkable and then show others how to do it in only an hour, it's a huge win for them. By focusing on learning and then sharing what you learned in a succinct way, you are accelerating the progress of others. That, more than anything else, will make you a great writer. The metric should be how much more powerful your readers are after reading your writing.
(Naturally, I'm talking about a specific type of writing here, not fiction or historical writing, etc.)
What matters is that the topic about which a person is writing is something about which they feel passionate - for example the process of writing in the original article...and in your post...and in this post. So, while I agree that anyone who cares about how awesome I am will be sorely disappointed, my goal is to say something interesting and entertaining - not necessarily entertaining in the sense of amusement but in the sense of engaging the reader's mind.
I suppose that the Pythonic Mr. Anchovy has no more likelihood of going from a chartered accountant to writer in one go than he does of becoming a lion tamer. But that seems a wanting-to-be-a-writer-strawman.
I read somewhere that there's no such thing as a person who is passionate about writing who doesn't write, and I am too lazy to google it.
The strong sense of wanting to be a writer is wanting to be a better writer, and that means practicing the craft and throwing manuscripts over the transom and the internet is a great place for doing that, e.g. HN provides an excellent opportunity to obtain feedback about one's writing, and not just from internet trolls, but from "really fucking smart people."®
As I look at my office bookshelf--which runs from tech stuff to random stuff bought downtown and not taken home, I question "about which they feel passionate". It is certainly reasonable to say that Hennessy and Patterson have a consuming interest in hardware design, but do they feel passionate about it? Would Wright Morris or Anthony Burgess have used "feel passionate" as a reason for writing those volumes of autobiography?
I can confirm this works in my own experience of trial-and-error interviewing over 2000 applicants and hiring over 200 for my clients and myself (since ~2006).
Nearly 100% of the applicants were remote, so I think that helped me from falling into traps of poor "traditional" hiring practices.
The point of hiring these remote folks was to help accelerate whatever team I was on. It can be a great way to scale your existing team very quickly if you know how to do it.
For example, I took over an iPhone app dev team and it was taking them 4 months to produce an app. These apps were all very similar in functionality, but the developers were spending a ton of time slicing images, testing, and other tasks that remote workers could easily do. So I hired some remote staff (via oDesk) to do most of that supporting work and we got the app production time down consistently to 1 month. That was a huge ROI for the business since the total cost for all remote staff was the same as for 1 additional on-site engineer.
There's nothing magic about hiring well, but I've watched others try to hire remote staff and the vast majority of them try once, fail, and give up on it.
They will approach the hiring process in a traditional way (personally interview them to watch how they handle puzzles, etc). It's a grueling process and then they still get really poor hires and conclude that "outsourcing doesn't work".
It's most helpful to think of the process as panning for gold. (Naturally, I'm not saying that some people are more valuable than others innately, just that you're looking for those who are most valuable at performing your given tasks.)
So, to find gold, you must filter, filter, filter. That's the exact process for finding applicants that are high performers. Most of your applicants will be pretty terrible at the job you're hiring for, so the filtering process is critical for success.
- filter out the very worst applicants with a small easy question
- filter out the remaining applicants:
- pick a real-life production task you've recently completed
- ensure that the task is *exactly* what they'd be doing in the job
- have them perform the task
- compare their task results to your task results
- hire more than you need of the top performers
- filter out (gently fire) the ones that aren't as good
- repeat as needed until you have gold
When I see others attempt this, the most common problem is that they essentially go down to the river and just grab whatever pebbles they see in their first handful and hope there's gold in it (hire without filtering). Or they go down and carefully pick the prettiest pebbles hoping they will be gold (wrong filter / puzzle interviewing). But the only way to really find gold is to seriously invest in a filtering process that will yield actual gold. That means filtering based on their ability to do the actual tasks they'll be doing on the job.
The great thing about hiring remote folks is that I care 0% how they get the task done. I don't care if they've automated it, or have their mom do it for them, or whatever. If they provide the results I need, I'm happy, period.
There are plenty of other smaller caveats and gotchas to watch out for, but I'll try to cover those in a blog post sometime.
If you're a startup and want to go faster, try this out by off-loading some of the grunt work from your staff. It can be a big competitive advantage if you can do it right.
> - filter out (gently fire) the ones that aren't as good
God I would hate this. I'd rather be told that my work sucks, and shown examples of better work, so that I could actually improve and not just wonder if I was let go for some arbitrary reason. If I disagree with you BFD, life goes on, but I'd at least like to know if it was related to my output or not.
"Gently" just means that you are sensitive to the feelings of the person you aren't going to continue sending work to. That doesn't mean you can't tell them why. I often do tell them why - it really depends on how they took feedback earlier in the contract. If they are defensive and don't take feedback well, then I generally don't give them final feedback since they've made it clear they don't like it. However, if they've taken feedback well during the contract, then I give them final feedback that will help them improve and win future contracts.
The feedback I give is also gentle. Well, I guess everything is done gently. These are all good human beings your dealing with, so why not be gentle? Gentleness doesn't mean you aren't honest with them. It just means that you are considerate of their feelings when working with them.
In practice, it usually means that I start sending more and more work to the better workers until there is little work left for the worker that doesn't perform as well.
I guess you could think of it like a load balancer distributing work. If there is a worker that is less responsive or sending poorer results than the rest, then you start sending less and less work to them. Ultimately, you run out of work for them since it's all going to the higher performers.
At that point, there's no point in continuing the contract with the lower performer. So, then I will let them know and end the contract and give them the best review and feedback I can while still being honest about their performance.
It's worth noting again that these are short-term part-time contracts, so this already fits within the contractor's expectations. They don't expect this job to last forever and they're generally not too heartbroken if a contract ends. They are often working on multiple contacts simultaneously, so mine is just one of several contracts.
Ultimately all contracts end, even for the best workers. The nice thing about hiring temporary contractors is that their expectations are already set that this is a temporary engagement.
OP was clearly talking about hiring people on odesk where different rules apply.
On odesk you hire people for projects of limited time.
He didn't mean that you don't pay the people you've hired if they do the work they promised - that will get you kicked out of odesk really quickly.
What he does mean by "gentle fire" is "don't hire them again for more work".
And that's how it's supposed to work: odesk freelancers have no right to expect being hired by you for second job if they didn't perform to your satisfaction on their first job, for which they were paid the amount they agreed to be paid (just to make this clear).
"filter out (gently fire) the ones that aren't as good." If the employee finds out you "hire more than you need of the top performers", you end up with a potential court case.
If I found this out about a former employer, I would have pursued them to the end of hell.
Isn't this what the up-or-out policy at major consulting firms and investment banks is all about? I mean, it's not identical, but it's a similar idea. I assume that if sure that if firms like McKinsey are hiring/firing like this, it's not illegal.
Remember that these aren't employees, but are temporary part-time contractors. It's not really "firing", but just ending the contract earlier for some than for others. All the contracts end ultimately, I just keep the best performers much longer than the lesser performers.
IANAL, and I'm just taking a stab in the dark here... But might it have to do with the work contract not being made in good faith?
That is in my basic understanding of contracts it is assumed as part of the contract that there is good will between both parties to fulfill what is set out in the contract. Practices such as these would indicate that the company has no actual intention of hiring the employee and is using the hire as an additional filter.
I suppose if the contract stipulated that there was a trial period or some such it might be a way to wiggle out of it. From a quick google search it seems you can either sue for Fraud (they advertised a permanent position and that wasn't the case, or they didn't make it explicit that the position was temporary) or Breach of Contract if they didn't specify that you were in a trial period.
Would love to hear from someone with better grasp of the situation.
In the US, generally people are employed at will (http://en.wikipedia.org/wiki/At-will_employment) which means an employee can be dismissed by an employer for pretty much any reason and an employee can leave their job for any reason, without any notice.
There's some exceptions (for example, discrimination) but you're free to take a job in bad faith too.
A job being at-will doesn't affect whether you can offer a job in bad faith. "At will" says you have the right to fire me for any reason. "Bad faith" means you shouldn't offer me the job in the first place unless you mean it. They affect two different actions.
Let's make an extreme example: I interview Anderson, Beth, and Charlee. I like Anderson and Beth, but Beth is a better fit for the team. Charlee is terrible.
Meanwhile, All three are interviewing with my competition. So... I give jobs to Anderson and Beth. I offer Anderson a very good salary just to make sure he doesn't go to the competition. They hire Charlee, and that's a win for me. Now I fire Anderson.
I suggest that if this was my plan all along, I wronged Anderson when I offered him a job in bad faith. I may not have wronged him when I used the "at will" provision to fire him, but I wronged him when I fraudulently offered him a job that I had zero intention of letting him earn the right to keep.
I can't provide any specific laws, but the general objection is that they were hired in bad faith. If I hire 15 people with the intention of firing 5 of them (and don't tell them that), that's a dick move. I misrepresented their opportunity at my company.
It depends what you tell them. If you said, "I'm hiring you" and you expected to fire 5, that's a horrible move. But if you told them, "We have a contract for you now, and might have more work later." Now the fact that you're intending to give 10 of them full time jobs is a very nice move!
The difference is not just semantics either. If they have other work already, the odds that they accept your first contract will depend on what you told them at the start.
This can work if there is a large enough pool of quality applicants that are either currently unemployed or are already contractors. If they are contractors, they may not be seeking full time employment (they like the mobility of contracting). But if you want to recruit someone who has a full time job, lots of luck convincing them to leave a good position (or any steady position) for a 6-month contract that "may" turn into a full time job.
This is how I was hired at my current job though. I was laid off for a few months, and a contract to hire position opened up. I took it, because it was better than not working -- but I would have never considered it if I was working at the time (they ended making me a permanent offer after 3 weeks, instead of 6 months, and I really like the place, so it ended up working out).
I've used a very similar method for myself in hiring remote workers, although my ratios are more extreme. In some cases we tested over 200 people and selected one person for the job.
Have not used math questions at this stage as it seems a bit too obtuse and not to-the-point. Better to ask an actual coding question if you are hiring a coder. However I have had success in hiring people that have been involved in maths olympiads or also in coding competitions.
Second, you should completely ignore Continuous Deployment until you have sane systems.
I do contract systems work for a living and have seen hundreds of live production systems. Nearly every system I see is in some kind of serious peril:
- no backups
- if backups, no docs on how to restore
- no monitoring (or very little)
- production passwords in the wild (former employees, etc)
- no configuration management
- no path to scale
- no path to replace defunkt servers
- etc... (I could go on for hours)
Often when I'm talking with a potential client, they are SUPER interested in Continuous Deployment (or whatever the hotness is at the time), but they start to yawn when I start talking about getting their core systems in order.
Your systems are the foundation of your application and your business. You wouldn't build your office building on top of an active volcano or below sea level on the coast, yet many businesses happily do this for their systems.
You know all those constant news stories about massive outages, security breaches, crippled sites, etc? I'd bet 99% of them are due to them failing at the fundamentals of sane systems. Having seen behind the curtains of so many companies, I'm honestly surprised there isn't more massive systems failure in the news.
This is a critical problem in the tech world. Does it affect you? A few of you will have amazing solid secure systems, but the vast majority of folks reading this won't.
If you're using a PaaS like Heroku or Parse, then you have most of the systems worries taken care of for you. You can breath a bit easier.
But if you are managing physical or virtual servers and aren't even using configuration management (puppet/chef/salt/ansible/etc), then your systems are probably in a very precarious situation. You might not think so, since everything just happens to be working at the moment, but you are essentially coding without using version control.
You would probably think that a developer that used email for his code version control is an idiot. You would be right. But consider that emailing code around for version control is actually better than what most companies do for their systems. Most companies set up their servers manually. They often don't even have any docs or even shell scripts.
At one client, it took them 2 weeks (!!!) to bring up a new server. The engineers thought it would take only 4 hours. Those engineers nearly killed that company.
Do you want to be a 10X or 100X systems engineer? Then use configuration management! After we put that client's systems in Puppet, we could bring up a new server in under 5 minutes. Yep, that's 4000X faster.
IMO, the example you're using in your blog should be simplified even more. I've never heard of Passenger before and it's not something I've needed.
But I have needed to ensure that a file exists in a particular folder on the server. An example of ensuring that would be more universal. Then you can explain that this vs a shell script is better because it's error prone/difficult to run the shell script twice, etc.
But I did get a lot of value out of this article because now I know that Ansible exists. Thanks
Ansible is pretty decent but new release seem to break backwards compatibility quite a lot so be prepared for playbooks not working on newer versions should you need to reuse them at a later stage.
Of course virtualenv gets around this quite nicely.
Completely agree with Matt. You should get your house in order before aspiring to do automation or continuous deployment. I worked with one client who was trying to check off a list by trying to implement a continuous deployment on a system that he was planning to retire in a year. Bottom line is if you have system problems, fix them first, lay a good foundation and then move on to automation efforts and continuous deployment.