HN user

medinism

32 karma

grouptalent-manuel-medina

Posts3
Comments36
View on HN

Is anyone at all surprised their tech-stack is php? is it because of legacy or is it because any sensible person moving petabytes of data would use? or does it even matter

I agree. you can get around the skeleton crew issue by asking everyone to be at hand, nearby in case shit hits the fan. no biggie if all take turns manning the update.

SEEKING FREELANCER -San Francisco/New York/Boston remote ok as long as it is within the US

Project: HTML5 consumer app for Flash-sale site. Needs to be able to render in a number of devices, phone, PC and tablet.

Project is posted on GroupTalent: a hacker-centric marketplace for high-end development and design freelance projects. more info at manny@grouptalent.com, or sign up to get access to projects.

Good point. the way I was thinking about it was more like this 1- you provide an overall estimate on where you think you could come in at. you do this to give all clarity on how you are thinking about the problem, anchors your estimate and the functionality you are about to build, and allows the owner to get a sense of price 2- only commit to a week or 2 at the time. this allows the client to tweak things, see quick progress, and add or subtract features as you make progress. Or even stop, test features on customers - and pause.

thoughts?

I agree giving the project owner the appearance of certainty will make him feel safe and comfortable - however it is not good for them. The longer and more complicated the project the more likely your estimate will be wrong. So giving the customer a sense of overall effort is good - misleading them by telling them you know how much the overall project will cost is bad.

Below a few nuggets from what we have observed at GroupTalent: 1- Hire a freelancer based on work performed not on CV. Not only we do this by allowing our teams or single devs creating portfolios (which is privileged information displayed only to interested employers) but also by asking them to show us the code or design they are most proud of. 2- Have them come up with an overall plan for the project but commit to only the first sprint. Creating the overall plan for any project will allow you to see how the dev thinks about solving the problem while paying only for the first sprint will limit your risk and allows you to see a bit of his work at the time. 3- Limit the sprints to 1 week at most - and make sure at least a feature is developed in the sprint. Short sprints will help you a- prevent cost overruns, b- cap your risk of working with a bad apple and c- allow you to see features developed early on. 4- Try to manage the whole thing through github. Great programmers hate to add additional layers of estimation, communication, tracking, etc. yet you as a project owner need insight into the work. Make sure you agree to some schedule of commits with the dev so that you get to see progress along the way.

Feel free to ping us at grouptalent.com if any additional questions. otherwise - happy building!

starting your day in a creative mindset does frame your day in a different way. Not sure this is panacea, but optimizing for production rather than consumption seems like the right framework. dying to try it!

I disagree. Investment is a two way street. Angels benefit from deal flow as well so making themselves unavailable does seem odd. If they want to invest in early stage ventures but don't have the time there are plenty of other vehicles to put their money in without being bothered

Github is my resume 14 years ago

I feel some of this discussion misses the point. To date the best predictor of the future is the past. And the best way to measure the past is by reviewing work done - not a self-declared history of yourself. If Github does not get you there, then creating some kind of show and tell for anyone to review is necessary. The other stuff you would assumed you can get out of a CV, ie cultural fit, etc you can only assess by meeting the person and working with him/her for a while. At the end of day Github is the best catch all for "show your work" for programmers

I am especially fond of the make money from your customer advice - under boot-strapping. Sure there are biz that will make $ in the long term from having large volumes of something, but for the rest of us, charge early!

Agreed with this comments. but I am not sure what is that worth. is not like people spend a lot of time on any of those networks, ie not monetizable, and amount of utility they provide vs. FB is diminishing

This article stroke a cord with me. I actually agree that half the battle is showing up - or be at a place where the people you want to meet show up. One of the issues we are discussing at our current startup is about moving to the valley. All our customers, users, and funding will most likely come from there, so - what are we doing in Seattle again?

Agreed. The article was shallow and unimaginative. I was hoping for some nugget around what makes clever people not realize they are wasting their time at your company and move somewhere where their contributions really matter. but no dice!

Sleep for sure is good and important, but in a pinch good 20 minutes of cardio will send enough fresh blood to your brain to energize you for the rest of the day and you can still hit the sack hard at the end of it.

Is there a way to sign in with you Dribble credentials. It seems to me that Dribble is the most active community of designers and you would want to tap into that.

I would seem to me that if anything is going to change now is the time. Performance reviews are becoming more evaluative (is that a word?) of both upside and downside of not taking a particular action. Also, as competition within a company heats up, internal folks will look for outside talent to help their projects shine more. The argument you made could have been made for facebook, groupon, and a number of other startups/concepts that have been tried before and failed but "for some reason" are working now

Agreed. Loyalty is a useless metric when you hire talent. For sure you want someone smart with a positive attitude but you will have to get used to smart people wanting to move on.

Thank you mturmon. that was super insightful. so if read this correctly (and the theorem) is ok to stop as long as the stopping is not dependent on any other variable (like results of the experiments or time). correct?

I can relate to this post. Specially around Slow and Argumentative. These are cloaks in which faux-smart people hide under. I had experience with a developer who would not want to lift a finger until he absolutely knew that the feature he was about to build was assured unquestionable success. So we would gather some data to figure out users predisposition to use the feature, and still nothing. in the end he would not experiment and we fired him