News for hackers. Stuff that matters.

xcbnxcbxmcb

Re:Ask HN: Save developer time by automating setup? on Monday July 22, 2013 @11:21PM (#6088043)
I'm new to Vagrant and Chef but a quick walk through the docs and your idea of container + config management sounds extremely powerful! Chef even has recipes to setup applications and combining that with a PaaS/IaaS should automate all machines.
Re:Ask HN: Save developer time by automating setup? on Monday July 22, 2013 @09:32PM (#6087645)
Thanks for the great list of tools to explore. I had already tried out Heroku, Nitrous and VirtualBox but new to everything else on that list. I'm trying those out now and have also signed up on StackMachine... most of the tools solve only a part of the problem but I guess I need to figure out the combination to use.

Ask HN: Save developer time by automating setup?

As a (self-claimed) advanced developer with 8 years experience (big company, start-up and freelance), I waste a lot of time when I am starting new web projects - researching and installing all necessary run-times & frameworks, creating a new project and then configuring it to work with the DB, mailer etc. All this saps up a lot of time and energy that I feel is better spent actually...

( Read More... | 11 comments | 13 points | on HN )
Re:Ask HN: What is necessary for a launch? on Friday July 19, 2013 @01:32AM (#6068483)
You should maximize the "wow" moment your product delivers. Since you say it is heavy on "server integration", I guess you would need to focus on monitoring & server capacity and of course, features that directly address your users' problems instead of fringe, nice-to-have add-ons. Everything else (analytics, payments, non-core features) can be left out or done in a way that minimizes effort (Stripe + Google Analytics should take up very little of your time)

Your users are not all the people who visit your site because of the "launch" but those for whom you can solve "the problem" well. I will definitely go back to a product that solves my problem, even if it has a lot of bugs. As proof, I've used buggy UML tools, code editors, video/audio editing software for years because they're very good in at least one aspect I value.

A lower-risk approach: Suppose you list out the benefits of a "launch" (example: growth from 0 to 10K users, investor interest, attract/keep talent) and then separate out the components of a launch (example: Techcrunch release, beta mailing list, investor reach-out). You may be able to de-risk by going after individual components and only building whatever is necessary for each individual component. For example you can attack the mailing list first without worrying about scale to handle traffic that a press release would bring.

Re:Ask HN: how strong is your focus when you are coding? on Saturday May 18, 2013 @06:36AM (#5728460)
I'm almost 29 and I've written a lot of code over my life-time. Having spit out copious amounts of code for over 10 years now, I don't think productivity in a larger sense declines with age. Physically or in terms of life priorities, writing code all-night long is not so much fun anymore, but any reduction in energy is made up by a higher efficiency due to experience. At least, that's the way things have been so far!

I definitely have productivity swings (and I make myself feel better by saying they're akin to moood-swings and out of my control!) Productivity is highest for me when I'm in a highly structured environment. I've churned out insane amounts of code when

a) I knew exactly what needed to be done and b) Had a sharp timeline to complete it

#a happens externally sometimes, when requirements are crystal-clear. For example, when you build stuff on http://community.topcoder.com/tc Otherwise, my approach is to spend as much time as needed in order to clarify requirements. I simply do not bother to code unless I'm sure about the end-goal.

#b can be seen in hackathons, or when a team / startup has committed to a demo-day (it can also be artificially imposed by managers)

When both #a and #b are externally satisfied, I can code all day long without problems. Things like headphones (to prevent interruptions) are useful but not necessary unless the environment is extremely distracting.

When #b is satisfied but not #a, I try to reduce the uncertainty around requirements - otherwise jumping in to code and then having to throw it away can be killing. At some point, the RoI in trying to achieve more certainty will get negative, at which point I start coding with whatever I have.

When you have #a but not #b, it is very easy to procrastinate. Of late I'm inspired by www.structuredprocrastination.com (brilliant, short read) to still maintain productivity.

Finally, having neither #a nor #b is the worst. Being in startup mode for the last few years I've seen how difficult that is. I'm making my own version of productivity pr0n, inspired from Marc Andreessen's blog post http://pmarchive.com/guide_to_personal_productivity.html The most effective thing for me is to plan a day ahead and then actually log what happened in the day. Just the act of measurement goes a long way in lifting mood and productivity.