Solid advice all around. Most techies are scared of selling because they don't understand exactly what "sales" is. You're going to be awesome at sales precisely because you're not a stereotypical salesman.
Sales is getting out there, listening to customers' problems and then helping troubleshoot those problems. Sound like something an engineer might be good at? The "get money" thing is actually the easiest part. It comes naturally, almost as an afterthought, if the customer recognizes that you can genuinely solve a problem for him.
Ugh, who gives two weeks notice to someone that's getting fired? At every company I've worked at, you don't even to return to your desk once they drop the hammer on you.
This whole post reads like "How Not to Use AWS" instruction guide.
If you're running anything important on a single EC2 instance, you're doing it wrong. If you're logging in and manually configuring an EC2 instance, you're also doing it wrong.
Puppet and Chef are great tools, but my first entry into AWS management was a little more attainable without having to learn anything new.
I simply set up the instance to automatically download the current codebase from our 'production' repo on every boot, automatically install requirements, run database migrations, etc. Then freeze that AMI as the production AMI.
If you migrate your databases off of the instance to RDS, don't use EBS, and manage user uploads and static assets to go straight to S3, then what you end up with a very easily load balanceable configuration.
To set up load balancing, just spin up two of those instances, attach them to an elastic load balancer, attach the load balancer to your elastic IP, then you ought to be more redundant and management free. (Note, this doesn't fix your security issues, though you could very easily bake a nightly apt-get run for security updates into that image).
After that, you want to look into Fabric (or language-specific alternatives if they exist) to allow for remote management of your machines for things like bouncing web services, pulling new code deploys, etc.
If you want to sidestep all this management altogether, I'd strongly suggest looking into something like dotcloud - http://dotcloud.com/ - which effectively does all this for you.
I would begin with a figuring out a more secure, desired configuration before trying to automate it. (Especially given, IMHO, the very steep learning curve for Chef & Puppet)
That may be true from a scalability and maintenance perspective. I don't see how those criticisms relate to security. Automatically-maintained hosts are no less subject to exploit...
Great points. Thanks! There's more than one right answer and I certainly don't have them all. My blog post was just a reflection on what I've seen be most successful over the years.
Granted, it could just be my lack of LinkedIn savviness, but it's never been a source of actual business for me (I'm the author of this blog post). The only people who actually seem to use LinkedIn are recruiters who sloppily blast off emails on keyword matches.
But I continue to use it because it allows me to keep track of what my contacts are doing, which gives me an excuse to reconnect with them: "Hey Bob, how are you liking that new job?" It also is another source of credibility when people Google my name if they're contemplating hiring me.
I've gotten one or two leads through Linkedin, though from contacts who knew me fairly well (well enough to vouch for my skills), and who had my email address as well. So the fact they used LinkedIn to make the connection was just for convenience.
That said, what I like about Linkedin is it widens your "social surface area" - my referrals have come from unexpected places (a university professor, a classmate, a guy I met at a hackathon, etc), and Linkedin is a good service for maintaining those type of contacts.
I'm not so good at maintaing contact with old connections (any tips? I read Never Eat Alone but as an introvert, I find it hard to get motivated to put it into practice). I think one thing the platform we're building should do, though, is encourage and support freelance devs to build their professional networks.
LinkedIn is a pretty insignificant part of the article. I mentioned using it as a proxy to gauge the size of your professional network, and to find local interest groups. Overall, LinkedIn hasn't really helped my business all that much, other than increasing my web presence for credibility searches.
I'm rather surprised that you felt that there wasn't much content. I spent around seven hours writing and editing the post and it draws on several years of in-the-trenches experience.
The article was well written. Obviously not everything someone would need to know to start freelancing is written in this article, but it does present some very valuable information.
I'm the author of the blog. Using the model that I wrote about, you "downshift" from a full-time job that has you on the front line, doing billable work to someplace where you're supporting internal business operations. This frees of you of conflict of interest problems and allows you the bandwidth to build up a side business, helping many of the same people you met previously in your career. The only difference is that it's in smaller chunks and time-shifted to evenings and weekends.
The TG, Pylons, and Zope guys all joined forces under the Pyramid banner a couple of years ago. There are still people developing in each of those three projects (and I think it's largely still maintained), but the definite trend is to Pyramid itself.
