On Hiring: How Not to Annoy Developers - <AUTHOR> http://fredwu.me/post/16510145575/on-hiring-how-not-to-annoy-developers <comment><USER3> _I am in favour of having candidates to do one or two coding tests (on their own, not during the interview) that will demonstrate their technical abilities without spending too much time or be under interview pressure. If a question is going to take a candidate more than a couple of hours to do, it is too much._

I agree with this, I am a vocal advocate of getting rid of the whiteboard. These tests reflect the skills far more than a whiteboard in an interview. That being said, you should only ask developers that are in the final round of hiring to do this, if it is a filter to even get in the door for an interview then you are going to filter out a lot of good candidates. Developers are smart, more importantly most of them are good at simple math. They know hiring is a numbers game and are not going to waste time on a project, that does not even guarantee an interview. I am not a big fan of asking people to do stuff for free, because it is akin to saying here do some work, because we don't know how to spot good talent. It's not the message you want to be impressing on developers. As such, if they are in the final rounds, you have at least some rapport built with them, and can explain why it is important that they perform the task, and they get the confirmation that they are within sight of the goal, before they are asked to expend the extra energy.

<comment><USER4> Well doing it on a white board in the same room as the interviewer allows you to see how some one approaches a problem - which is more important than the quondam task of coding.

<comment><USER5> Except, most people asking white board questions are asking for code.

> allows you to see how some one approaches a problem

I've never jumped to a whiteboard. Rather, I've researched the problem. If they really wanted to see how you'd approach a problem, they'd give you the problem before the interview, and then when you come in, ask you to explain it, allowing you to use the whiteboard.

<comment><USER6> > I've never jumped to a whiteboard.

I've also never had to reverse a BST in place outside of an interview setting.

I personally like technical questions in interviews. I've had some good experiences with them, but that may be because I have always been a good "test-taker". I feel like I understand what tests (and interviewers) are looking for and can tailor my response accordingly.

For an interview, I've learned that the question isn't "come up with the best solution". The question is really "demonstrate how you approach this problem". I've learned to vocally explain that I'm starting with a naive approach. Then I explain how I'm considering the constraints for optimization. I state out loud any patterns or similarities between the optimizations I am trying to make and ones I've made in the past. (ie, "To make this O(logn), we need to find ways to eliminate half the data set each iteration. Is this similar to a BST at all?"). I pursue paths I know might not be correct, and backtrack when I see the fault in the idea. The key is to narrate for the interviewer.

Maybe I've had good interviewers, but 7 of the last 8 interviews I've had resulted in job or internship offers and I felt the interviewer was able to get an accurate picture of my abilities.

</comment></comment></comment></comment><comment><USER6> I recently interviewed with a startup. They had all 6 engineers interview me one by one. Each interview had a whiteboard/tech question component. At no point in time was I restricted to a language or expected to use an API. The questions measured an understanding of algorithms (data structures and big-O notation), an understanding of operating systems (concurrency, memory allocation, etc.) and object oriented programming.

There was even a gross bithack, which I really struggled with. After a half hour the interviewer was laughing, saying "I love this problem because everyone just goes bananas with it". It wasn't to make me look stupid, it was to see how I approached a problem that was apparently unsolvable.

With each question I was free to ask any questions, whether it was a clarification on pthreads or a question about problem constraints. I did not feel like my "off the cuff" knowledge of programming was being tested, but rather my experience and understanding of programming.

My only complaint with the interview was that it was long (11am - 7pm with a lunch break). That was mostly due to the fact they wanted me to meet with the entire team one at a time, as well as the fact that I was only in town for the day.

</comment><comment><USER7> Last fall, I had an interview where they asked me to reverse a linked-list in python and to filter out every unique items of a list. I failed because I did not remember the API by heart and they tried to impress me with a python one- liner that would do the job for me. Not so sure if the interview was for me or for them... Complete waste of time.

<comment><USER8> They wouldn't allow you to substitute your own implementation? That's rather odd. I'd be more interested in whether you knew how to traverse a linked list than I would be in any knowledge of the Python API.

<comment><USER9> I don't think reversing a link-list and removing unique items requires any special Python knowledge. No magical API needs to be used, just the basics.

A white board interview shouldn't exclude naive implementations. After the naive implementation has been done it's reasonable to ask for less naive approaches.

Also the continual whining about white board interviews is tiresome. It's a fact of life that exists in almost any tech interview you do. Practice, get your friends to bust your balls before the fact, write itoa on a white board or detect a loop in a singly linked list and move on with your life.

At some point if you're going to get paid you need to demonstrate your ability, reality says the potential employer decides what type of proof is required.

</comment></comment></comment><comment><USER10> I've never understood the whole emphasize on testing technical skills during the interview phase. In most countries it's either easy to fire someone, or you have legal probation period.

One month of employment should be enough to find out if someone has the practical skills they've expressed in the interview, and catch the 1% that can bullshit their way through.

Of course that 1% becomes a lot bigger number if the interviewer doesn't know what they are talking about. But that's not a problem you can solve with tests.

<comment><USER11> Some people are good at talking about coding (or pen testing, or sysadmining, or architecture, or...) but when you put them in front of a blank black screen with a cursor they're incapable of making forward progress.

It's five figures cheaper to ask everyone to FizzBuzz than it is to fire someone even after a week, and God help you if they're in a protected class.

<comment><USER12> Sadly, I've been that person. I read pg essays, blogs about programming and watched various videos about programming for about 3 years before finally deciding to leave my relatively comfortable small-business as an EFL cram- school partner and start actually coding stuff. People have been absolutely amazed by how little I know compared to how much I sound like I know.

Fizzbuzz wouldn't have filtered me out of getting my first (and current) real software job, but any sort of Google/MS-style interview would have. It may not be the wisest thing to admit to on the internet, but I'm basically in the opposite boat of your general target on HN: I'm fine with selling, but limited (non-EFL) skills to sell!

That, along with seeing numerous senior iOS dev applicants struggle both with Fizzbuzz and with Macs in general, has convinced me that it's more than worth it to test candidates without code portfolios.

</comment></comment></comment><comment><USER13> Having never experienced it, can someone tell me what the point of having the applicant code on a whiteboard instead of on a computer is (Maybe with screen- sharing so the interviewer doesn't have to be looking over the applicant's shoulder)?

<comment><USER14> It really depends what you are testing for, but using a whiteboard lets you get away from the details of things like syntax errors and language particulars and let's you focus on solving a problem at a much higher level of abstraction. Basically it comes down to, do you want to see if the person can write good Ruby code (use a computer) or to you want to see if a person can come up with clever abstract algorithms to solve hard problems (use a whiteboard).

<comment><USER15> But I come up with all my clever abstract algorithms in the shower - <USER2> while I am thinking of something else. I don't think being "clever" on demand is the mark of a good developer. I would prefer they look at some of my available open source code - that gives a much better reflection of my abilities.

</comment></comment></comment><comment><USER16> "The technical questions should focus on the logic behind a candidate's solutions, not what functions or libraries a candidate may or may not remember from the API documentation."

Finally someone said it. I'm an Asp.Net dev by trade, yet I don't even use or know 80% of the available functionality. Yet, interviewers are very adamant on you knowing this.

What it seems is that they don't understand that a lot of solutions can be solved purely with logic, not by some specific function, library, etc provided by the framework. I don't need to know the full scope of Asp.Net because I'm able to hack up a quick and logically sound solution. The thought process from A to B to C is vastly important compared to the API. In layman's speaking, Batman's brain is much more useful than his utility belt.

And let say you do need those items to complete a task, Google is always there to help. I sometimes wish that they would test out your Googling skills instead of asking you a framework question.

</comment><comment><USER17> "pair programming is an excellent way for both parties to get a sense of what it is like to work together." So true and if you can convince a developer to do this, power to you. We are an early stage startup and we are two for two with this method and have carved out a strong team.

I would argue that high salary requirements can be negotiated if you can frame a strong vision. Developers are not investment bankers and often are not doing this for the money alone. Often, good developers are looking for a place where their voice has as much weight as anyone else and where they can grow with company. We wouldn't have it any other way.

</comment><comment><USER18> Hi Fred. I would love to hear about examples of small companies that got it right. Have any stood out? What hiring techniques would make you happy?

<comment><AUTHOR> Hi Richard,

To me personally, not requiring on-the-spot coding tests would make me happy. Compare the following two scenarios:

Company A: During the interview, I was asked to write a short ruby method to solve a problem on the whiteboard. I didn't really do well because I couldn't remember some APIs. Though in the end I still got the job, so I don't really know how effective the whiteboard coding test was.

Company B: During the interview, I was asked to explain the _coding logic_ to solving a problem in Backbone JS on the whiteboard. I was much more comfortable with that, as I didn't have to remember exact APIs or methods to use. During this process, the interviewers got a good sense of my technical ability not just in Backbone JS, but also in JavaScript and MVC in general.

<comment><USER19> Are both fundamentally not the same thing? I understand that company A may have made you a bit uncomfortable, but perhaps their intent was the same as company B's? That is, to see how you logic out a problem. You did say that you got the job in the end, so clearly the point wasn't to see if you knew some APIs by memory as a make-or-break situation.

There's also some benefits that can be gained by company A's method ostensibly over company B's. You get to see their response to the discomfort of not remembering an API. You get to understand their problem solving abilities, not in terms of code, but in terms of interpersonal relationships. In a recent article I read, someone had suggested offering a code prompt and then challenging the applicant to find the bug on completion (even if there wasn't one), simply to see _how they respond when faced with that challenge_.

Naturally it may not be perfect, it's just hard to really quantify which one is "better" if they're arriving at the same end -- a presumably competent engineer being hired. Are companies not interested in hiring people with both interpersonal skills and technical ability, after all?

<comment><AUTHOR> Fair point. :) However, I would argue that in company A's scenario, the discomfort I got from not remembering the APIs would never happen in real world situations where API documentation and Google/StackOverflow are readily available.

Ideally, if one does really well in whiteboard situations then great. But similar to how some engineers give terrible public talks, we can't discount the ones that do get nervous in those situations.

</comment></comment></comment></comment><comment><USER20> Since going on the job market in November, I've been exercising an experimental policy: Interview with basically anyone (basic constraints apply - has to actually be a job I can do, a language I can speak, etc). It's been enlightening, especially because I'm at best a middling engineer (not a 'rockstar').

Virtually every company I've interviewed with has had tremendously awful HR, committing dozens of enormous mistakes that would have led me to abandon any interest in working for them (if not for my above-stated rule). I've learned a lot of interesting things from this experiment, but I think the biggest two are these:

A lot of companies screw up hiring from the HR side, but in general, the ones who mess up more than once tend to mess up a lot.

And in general, the ones with big money and big HR departments seem to be _worse_ at interviewing and hiring than the tiny scrappy ones that can't even afford an HR department.

Just to give a few illustrative examples from the maybe 50 or so companies I've dealt with so far:

One big local developer scheduled a day-long interview that spanned lunch (starting around 11:30am and ending at 5pm), and knew that I had to drive an hour+ in traffic to get there. There was no lunch scheduled, they had me sit in a room and interview all day, even after I pointed out how little sense this made to the hiring director while I was on-site. They did not reimburse me for parking at their facility. This on-site was after a long series of successful phone screens. After the on-site, they told me personally that they would contact me with an offer, and then proceeded to completely ignore me for 2 months before a person I had never met before finally responded with something cryptic about an internal reorganization.

Another up-and-coming developer repeatedly made basic scheduling mistakes that made it near impossible to actually interview with them. Their hiring manager failed to e-mail me to notify me that a director would be calling in the early morning and also failed to tell me who he was, so when I got an unsolicited call from a stranger in the middle of a night's sleep, I asked if I could return his call, and he said 'no, I'm too busy'. This pattern was reinforced when they scheduled my on-site interview to begin 45 minutes after my flight landed (in a city where it took over an hour of cab travel just to reach their office). They compounded this by having me wait an hour and a half in the lobby before actually starting the interview, and having me interviewed by employees who clearly had not even been told my name.

The technical director of one well-funded studio contacted me out of the blue to ask if I was on the market and solicit my resume. After providing it, he sent me their 'engineering pre-screen', a series of around 10 moderately complex engineering and math problems that took me around 8 hours to complete (and probably would have taken someone more skilled at least 4 hours). A week after I submitted the completed screen, the technical director responded with a long diatribe about how my solutions to simple algorithmic problems should have used specific SIMD instruction sets or optimized for corner cases that were not specified, and commented that my lack of certain domain-specific skills made me an unsuitable candidate for a job he had told me nothing about.

In general, it feels like the average company hiring developers doesn't have a clue how to do it. It fills me with terror to think of how many potentially awesome candidates are falling at the wayside due to simple mistakes, and the idea that those great candidates end up at mediocre companies only because of HR mistakes is a rough one. Worse still, it's extremely rare for a company's HR department to solicit feedback on the hiring process - even companies that make me offers tend not to ask how it went. It seems likely that they do not make any effort to improve.

</comment><comment><USER21> Whenever I hear about how horrible some company does something, I always think "Opportunity!" Just not sucking at something puts your scrappy little company ahead of your more impressive competitors.

</comment><comment><AUTHOR> In case anyone is interested, I've written another piece on how to attract technical co-founders:

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


5 NYC startups that you should know (and how they can help you) - <AUTHOR> http://5in5nyc.com/2012/04/30/5in5nyc-episode-02-favorly-huntsy-insidedigs-kopoint-and-muckrack/

<comment><AUTHOR> 5in5NYC is a new, positive outlet for NYC startups. We feature 5 startups each week, and give them a chance to share what they're building, answer questions, and interact with each other.

The theme that emerged during this episode was that each of these startups provide help. Favorly helps you find people who want to help out with your projects. Huntsy helps you stay organized when finding a job. InsideDigs helps you find your next apartment (and help others by listing your own). KoPoint helps you make sense of the news by provide a real, human-focused discussion around it. MuckRack helps you connect with journalists in a real way so when you have news to share you're not just another press release.

Every startup seeks to 'solve a problem' but it's fantastic to see so many NYC startups being built from the founder's desire to make things better.</comment>


One woman can't have a baby in nine months (2007) - <AUTHOR> http://gigamonkeys.wordpress.com/2007/05/10/baby-in-nine-months/ <comment><USER2> You're not debugging hard problems all the way through the whole project. The cool, hard bugs happen maybe two thirds of the way to the ship date.

Now, imagine puffing up your development staff by a conservative factor of two. Assuming perfect skill transfer you're going to shave maybe six weeks off the schedule? In practice, no way. Your 'expert' devs are going to be swamped for a week or two while the new guys are coming up to speed.

This begs the question: What's magic about nine months? I've worked on projects that have practically killed their teams and hit their ship dates, and the result was ALWAYS that the product sucked pretty bad, and the team wound up doing another 3-4 month "fix" cycle that (a) dramatically improved the product, and (b) didn't matter, because the damage had been done and the product was toast. Then there was team burnout and churn. All very bad damage.

If you are trying to compress ship time by adding engineers you're already making mistakes that will probably kill your product. The right thing to do is to slip, and slip significantly.

I know: "We have to hit Christmas!" \-- or whatever classic date your industry needs. But shipping a crap product in November is usually FAR worse than shipping a good product three months later.

<comment><USER3> Everywhere I have worked as a developer, hitting the date was far, far more important to the "folks upstairs" than quality. As mabbo mentioned, it could be inter-project dependencies. What if your software project is a driver for your company's electronic device, and they're ramping up for production in a month? You can't just say "Hey, the software team shouldn't be date-driven. Just keep 5 million finished units in a warehouse until the driver is really ready!"

It could be needing to ship in time for Christmas. You mock it, but the difference in terms of sales between hitting and missing Christmas can be the end of a small shop. Same goes for hitting trade shows. You can't just call up CES and tell them you need another week and could they please move their conference date.

It could be that your contract states that something will be delivered on DATE_A, and then something else on DATE_B. Dates are easy to describe and put in contracts. Quality goals are a lot harder to articulate and translate into terms of a contract. You'll see rough quality goals in some contracts, but you'll see dates in them all.

Saying, "We'll ship when it's good enough" often means you're never shipping. Go find products whose ship date was "when it's done" and look how late they were. When you aim for a date, and everyone is taking it seriously, you might just be able to ship something on that date, and "something" is usually good enough.

<comment><USER4> > Go find products whose ship date was "when it's done" and look how late they > were.

Many of the best Nintendo games were delivered under this rule (as in yes, they actually shipped), and went on to be incredibly successful.

You're right overall, of course, and we can't all be Nintendo. But for some markets quality really is important, and in those situations you can't shortchange. You have to decide based on what your own unique situation in the marketplace is.

</comment></comment></comment><comment><USER5> The author also misses a key point is that in pregnancy there are no shared resources -- each pregnancy is independent. In debugging hard problems this is often NOT the case.

For example, if you put 100 teams to find a particular issue that is causing crashes in the field you suddenly have your field team getting requests at random times asking similar questions, although each may have a distinct twist. At some point in time a percentage of the team suspects the networking stack -- the networking team starts getting questions staggered over time. Their time now gets spent looking at this. And then if you have to run some type of stress or in a specific customer environment -- that gets sequentialized, unless you buy new hardware.

And lets say all 100 teams find a fix, but they are all in different places in code. Now you have to figure out which is the right fix, which may not be a complete sequential process, but it's not embarrassingly parallel.

On the flip side, if you only want one fix, it's easy to shelve the rest (you could pull one of the other fixes back in if the select fix is found to regress something else). But if you only want one baby, and multiple couples have one, it's a bit trickier to figure out what to do.

<comment><USER6> The good news is that pregnancy is almost an embarrassingly parallel problem. This gets reflected in polygynous societies and the occasional episode of Sliders.

[http://sliders.wikia.com/wiki/Love_Gods](http://sliders.wikia.com/wiki/Love_Gods)

</comment></comment><comment><USER7> Two thoughts:

* you only get to combine probabilities that way if the individual trials are independent. Debugging does not usually work that way - if I'm looking for the same bug as you, I'm likely to try many of the same things. Unless, of course, your development team is using a stochastic debugging process, in which case you've got... other problems.

* I read the analogy as more about the challenges of inherently-serial processes (must complete A and B before C) and the individualized nature of software creation. For a counterexample, note that other "building" processes are parallelizable and standardized; it takes quite a long time to turn bauxite, sand, and rubber into a car, but the intermediate steps are not specific to the final product.

</comment><comment><USER8> There's a problem with his argument he doesn't really address. The baby analogy isn't perfect because having a baby is a physical process with a set success rate. So the math checks out, but debugging isn't a physical process. Debugging is problem solving.

When debugging there is likely to be a lot of overlap in the ideas and methods the individual debuggers use in order to find the bugs. Obviously, the debuggers can communicate with each other about what doesn't work so there are gains there. But in terms of thought processes, there will exist this overlap. It is only in the places where there is no overlap that an extra debugger is useful. And as more debuggers are added, the odds that any additional debugger will provide independent thought is diminished.

His model is too simple because it does not account for this overlap.

<comment><USER9> Id go further. The best debuggers don't look for the bug; they look to prove what Can't be the problem, reducing the search space geometrically. With parallel debugging efforts, many of the debuggers will be pointlessly crawling through code and tests that have already been discounted.

In my experience hard bugs don't get solved until a skilled debugger is found to look for them. Up til then little or nothing gets done. And skilled debuggers are small in number, and their efforts are necessarily serialized.

<comment><USER10> I believe you are missing the point he is trying to make. With parallel debugging a lot of the time will be spent looking through code that has already been checked (more women can't have a single baby in less than nine months). The only thing that changes is the expected amount of time it will take to find the bug (with more women there is a higher chance of having _a_ baby in nine months).

Even if you do have the best debuggers, they can still miss the bug. By throwing more debuggers at the problem, there is a higher chance the bug will be found in a given time frame.

</comment></comment></comment><comment><USER9> Carry a baby, not conceive a baby. OP (deliberately) misinterpreted the meme for comic effect.

</comment><comment><USER11> Apple does this, I think. I wouldn't be surprised if Amazon did (in their quest to reduce everything to replaceable cogs).

You create three teams, and get them to work on basically the same problem. Apple will often give them slightly different scope (port OSX to the iPhone, add functionality to the iPod OS, see which project can ship first / deliver the best product).

Problem solving is more or less lognormal. You can squash a trivial bug in minutes or weeks, depending on whether or not you spot the cause of it. This can actually save man hours - as you don't have someone staring at stack dumps for weeks without making any progress whatsoever - you just tell them on the second day that a co-worker found the error, and ask if they can think of any other things that might be wrong (now that they've got the provisional fix).

I can see a lot of comments worrying about the efficiency of this - what if two people solve the problem at the same time? What if the quick fix isn't a good? Well, that's a good problem to have - one engineer / team didn't really fix it, and one did - you've just saved yourself from the risk of missing the root cause!

Yes, there might be a few painful meetings, especially when two different approaches have been shown to work. If patching the iPod OS and porting OSX both seem to work, it's going to cause an ugly political showdown. But it would be more political if neither team had written a line of code, and were simply duelling with Powerpoint (Keynote?) presentations to back up the viability of their approach.

</comment><comment><USER12> The argument he makes about increasing your chances of having one successful project by funding lots of projects is similar to the VC idea of investing in many companies in the hope that one pays off.

While interesting Mythical Man Month's use of the metaphor always seemed to me to be saying that the non-parallelizable tasks take up the majority of the development time. Which is a different argument

<comment><USER13> Yeah, but one thing that often gets overlooked when talking about 'non- parallelizable tasks' is that most tasks aren't actually non-parallelizable, rather that they are weakly parallelizable (less than linear speed-up), or they have a large time constant (the 'train-up' time of adding additional resources). If you can identify this and recognize your current position, it can still be possible to accelerate your timelines by adding more people in some cases.

<comment><USER14> Can we say courting is the equivalent of the 'train-up' period for having a baby?

<comment><USER9> Definitely THAT can be parallelized. Just play the field!

<comment><USER15> But make sure that you have proper isolation between the subtasks.

</comment></comment></comment></comment></comment><comment><USER16> The best part of the analogy is that most of the work is post birth. That is maintenance and care of the baby, just like with software ;)

<comment><USER17> Exactly. If your software is only going to be used more than once, then any notion of "finished" is illusory and often toxic.

</comment></comment><comment><USER18> The article's conclusion seems to be that even if debugging/software development can't be parallelized perfectly (which is true because debugging requires a buildup of mental context about a codebase), since the amount of time required is a random variable, doing the entire task redundantly in parallel will necessarily reduce the expected value of the minimum amount of time required. For instance, if you throw $n$ developers with equal knowledge of a codebase independently at a problem whose time-to-solve is exponentially distributed with rate $\lambda$, then they'll solve it at a rate of $n \lambda$. Of course, this is almost always less efficient than letting them work on their own problems!

However, if you apply a similar analogy to _reliability_ instead of time, having people work on the same task with what would appear at first to be redundant effort can increase reliability phenomenally. In a way, we see this in organizations that demarcate developers and test engineers - you're throwing bodies at a problem, creating a rivalry of two groups that challenge each other by attacking a problem from different angles, and in doing so you have a different distribution over the error/bug rate than you would otherwise.

An interesting read on this point is [http://www.fastcompany.com/28121/they- write-right-stuff](http://www.fastcompany.com/28121/they-write-right-stuff) about the team that does (did :( ) software engineering for the space shuttle. Things like rigorous separation into development and testing sub- organizations... duplication of coding effort insofar as every line of code isn't just code-reviewed, but requires double-entry in a specification as well, and review of that specification... constant "process-ization" of debugging insights so the entire team doesn't make the mistake again. It's the exact opposite of "agile," but it makes sense if reliability is what you want to model and optimize.

<comment><USER4> > It's the exact opposite of "agile," but it makes sense if reliability is > what you want to model and optimize.

One of the more interesting aspects about that classic story was that the software developers, despite having deadlines of their own and having to adapt to ever-changing hardware on the Space Shuttle, almost never ended up in "crunch mode".

</comment></comment><comment><USER19> The author takes the analogy beyond the logical conclusion.

The saying is simply meant to say "there are things that you can't make happen faster than one person can do them".

There are corollaries that we used at Microsoft. "And you can't assign the baby to a man" and "She can't have it all on her own."

Taking the analogy farther than one should... Conception is typically a two person activity. But assuming you have a Fertile woman, you can take that 15% that they talk about and up it significantly by trying with 3 different men a day, every day of the month.

So you can "have the baby in 10 months" with enough planning and since you only need each guy for about 5 minutes, you only added 450 Minutes (about 8 man hours) to the process. Less if you stick to 20 days conception can happen.

Bringing that back to Startups/Products: Let's say you have a startup and you are going to build a Server Farm to support it. It used to be you had to order the servers and Dell would take a month to ship them. You can't speed that up. It is a fixed part of the timeline.

Let's say you want to build a new Electric car, the government testing for crash and safety takes a fixed amount of time you can't speed that up.

The analogy is not just about can you speed something up by putting more people on it, it is meant as a lesson that some processes are beyond your control.

It is also used as a "build vs. buy" argument. "Apple just released a Feature that we don't have" "Oh, no How long will it take us to build?" "9 months" "That's too long we need this out by end of quarter". How do you do that? You buy someone with that feature and you integrate for 45 days. Just like if your rich uncle announces he has a week to live, and each Grand Nephew (I think that is the kid of your Niece or Nephew) will inherit an equal split of his Billion Dollars, so you need a baby tomorrow. You can't try to get your girlfriend pregnant, that won't work in a week. Your only option is to buy or steal a baby.

</comment><comment><USER20> One difference between pregnancies and debugging is that the success probabilities of pregnancies are more or less independent -- couple A's failure to conceive doesn't cause us to believe that couple B will be any more or less likely to succeed -- whereas bug-finding times are _not_ independent, because all of your developers are searching for the same bug. If developer A fails to find the bug in a week, then, assuming she is competent, the bug is likely very subtle and so developer B will likely _also_ fail to find it.

This doesn't invalidate the argument entirely; adding developer B is clearly no _worse_ than just using developer A (assuming B doesn't disrupt A's work and also that we don't care about the cost of an extra developer), and, to whatever degree B and A are using different strategies (giving them some partial independence), it will somewhat reduce the tail probability that the bug takes a long time to find. But the lack of independence, relative to the pregnancy example, means that the gains probably won't be as dramatic as this post assumes.

<comment><USER21> As an aside, there are many differences between pregnancy and debugging.

<comment><USER9> Yeah, debugging and pregnancy are both difficult. But one involves long sleepless hours, takes way too long with everybody looking over your shoulder and giving advice, ruins your health and relationships. And the other one is debugging.

</comment></comment></comment><comment><USER22> Well, there are many things to disagree on. Many where already listed. These I haven't found yet:

1\. I real baby doesn't always take 9 months. The same goes for software. Even if you get over the first few hurdles it is still a guessing game how long it takes. In fact Chinese people even say it takes 10 months for the baby to come out.

2\. While the idea proposed by the author, that you can let teams work in parallel to increase predictability of the results, might have many flaws, I actually believe it pays out to think like that, because there are individuals and teams who work way, way better than the average coder/team. If you let 3 teams tackle the same problem at the same time one of them might yield a much better result than the others, and in that case will probably do it even faster. And the next time you can just let the single best team work on a problem and make a better profit margin.

</comment><comment><USER23> > Unfortunately, I haven't been able to find anywhere where he explains what > he means by "the sequential nature of debugging"

It's clear to me that what Brooks is referring to is the sequential process of:

1\. Let's try to use this functional. 2\. Whoops, a bug. 3\. Okay, I've fixed the bug. 4\. Now the process blows up further along, or only in certain cases. 5\. Repeat until marketing insists on shipping.

</comment><comment><USER24> Chapter 26 of Ross Anderson's Security Engineering covers the probability distribution involved in finding bugs, and its impact on software vulnerabilities:

[http://www.cl.cam.ac.uk/~rja14/book.html](http://www.cl.cam.ac.uk/~rja14/book.html)

</comment><comment><USER25> My friend had baby in seven months (both are fine now)....

</comment><comment><USER26> The author is taking this analogy far too literally. What else can you really say?

<comment><USER27> And he missed the fact that it's roughly 9.5 months even when everything goes swimmingly (40 to 41 weeks). In some oriental countries like Japan, they talk about 10 months pregnancies not 9 like in the West, where we count since the first missing menstruation.

<comment><USER14> I think the whole thing works out well. You can't speed up the sequential bits by throwing people at it, but you _can_ increase the chance of _finding_ elusive sequential bits (so long as people are already familiar - it can take longer for strangers to have a baby than a married couple! [citation needed]).

And I think your comment balances it out nicely with: and it's already going to take longer than quoted anyway!

</comment></comment></comment><comment><USER28> > is it actually the case that one woman can have a baby in nine months?

Yes, it is.

If your blog post's title is obviously false, you're doing yourself a disservice.

</comment><comment><USER29> tl;dr: Adding more people to a late project makes it later.

<comment><USER30> That's actually not what the post is about at all.</comment></comment>


Git Exercises - <AUTHOR> https://gitexercises.fracz.com/ <comment><USER2> This is actually pretty well done, but I can't help but feel like the number of articles and documents trying to explain or teach git is a sign that the tool just has usability problems.

Maybe I'm misremembering, but I don't remember people having so much trouble with svn. With rcs and cvs, sure, and it was mainly stuff with breaking locks, moving files, and other BS that were part of the bad design. With svn I remember the problems being: setting up the daemon (https vs svnserve+ssh), fixing a wedged Berkeley DB when that was still a thing, and getting hook scripts working right cross-platform. With git, the common problem seems to be: "what command am I even supposed to use here?" and "I broke it somehow and I don't know how to fix it." If the number of articles about it ever seemed to go down I might say, "Oh, it's just growing pains for new users," but they still seem to be out there constantly. Why is everybody still having trouble learning to use git?

Note to the zealots: This isn't to say git is bad, anymore than vi/vim is bad for having it's own arcane interface that users have complained about and struggled with for decades. Lots of terrific software carries burdens like a terrible interface, or an onerous configuration, or a lack of documentation. That doesn't mean we can't be critical.

<comment><USER3> I think this is a commonly recognized issue—for instance, here is some research explicitly addressing the problem: [https://spderosso.github.io/onward13.pdf](https://spderosso.github.io/onward13.pdf) ("What's Wrong with Git? A Conceptual Design Analysis")

What makes the issue most clear to me is just looking at the language used in various git commands, and asking how related it is to the abstract task I'm actually trying to accomplish. More often than not, the choice of words makes sense in connection with the _implementation_ of various git operations, but has no relation to the task you're attempting to accomplish.

I believe that situation is a consequence of the UI being centered around several data structures at the heart of git's operation. So, if you learn, first, that those data structures exist at all, how they're used, and how the various commands relate to them—then you can start becoming proficient at git, and the language used in the commands makes a kind of sense even from a design perspective.

IMO, the main thing missing is a way of seeing git's core data structures updated in real-time as you perform various operations on them. Instead we mostly rely on manually kept mental models of them—and on making backups before trying new things ;) I think this project I'm working on could potentially work really well for giving a real-time visualization of git's data structures: [http://symbolflux.com/projects/avd](http://symbolflux.com/projects/avd) (not that I can imagine any realistic route for incorporating it with the git codebase, though...—but in principle.)

<comment><USER2> That's an interesting paper.

> More often than not, the choice of words makes sense in connection with the > implementation of various git operations, but has no relation to the task > you're attempting to accomplish.

This seems like an _extremely_ common problem in computing. I support several applications and a lot of the fields and functions in those applications seem to be placed arbitrarily until you know that those fields live in the same table or those functions are a part of the same module or class. Users find the organization very confusing because the model of what they need when doesn't match how it's organized in the system. The user shouldn't need to know about those sorts of implementation details because that knowledge isn't their problem. The program interface should follow a natural workflow, not force the user's workflow to match the implementation.

> IMO, the main thing missing is a way of seeing git's core data structures > updated in real-time as you perform various operations on them.

I think that would be a great help for troubleshooting those really obscure or weird situations, but I don't think that's information that your average git user should feel like they need to know to get work done.

<comment><USER3> > This seems like an extremely common problem in computing.

I agree—I see it all over the place. It's what you get for a UI by default, if you don't take any extra measures to seek an effective design: you just expose program internals.

I think the situation with git is slightly different from that all too common, naive pattern, though. The best comparison I can make is to graphics APIs like OpenGL (or even better, Vulcan), which are there in large as a means of giving access to graphics hardware, very low-level and a horrible impedance mismatch for actually describing moving images. However, they are necessary because the variety of things people might want to do with a graphics card is so vast, that 'nicer' abstractions will always also be restrictions on capabilities. So, you get OpenGL/Vulcan and rather than using it directly to build applications, it's the basis for building other graphics libraries which actually have good usability. (But also like git, there are many cases where people just need to use the low-level APIs directly, despite poor usability.)

Git seems to be addressing a similar issue in that any abstraction over the internal core data structures ends up limiting the vast spectrum of potential use cases, so it makes the compromise of providing (relatively) un-abstracted access to the program's core data structures, which maximizes use-cases covered, and sacrifices usability. But, the generality it provides leaves open the possibility of building higher-level abstractions on top of it... I know a bunch of these exist in various forms, CLI and GUI, and for me anyway, none that I'm aware of cover everything I need to do with git—but I believe such an application could be built and the community would stabilize on using it for 90% of cases instead.

As far as visualization of its data structures goes, I see it fitting in as training wheels essentially: it would be an effective way of teaching people how the program works by allowing them to see the direct impact of particular git commands on the git data structures. Eventually you stop using it, except for troubleshooting really weird/obscure situations, as you mention. (More generally, I could see open source projects offering a flag so that their core data structures are visualized or not as a means of more effectively/enjoyably teaching new developers how data moves around in the app at a high level.)

<comment><USER4> >> But, the generality it provides leaves open the possibility of building higher-level abstractions on top of it [...] I know a bunch of these exist in various forms, CLI and GUI, and for me anyway, none that I'm aware of cover everything I need to do with git—but I believe such an application could be built and the community would stabilize on using it for 90% of cases instead.

The beauty of being able to use an abstraction on top of git is that it doesn't _need_ to cover everything you do. You can use a GUI or a couple simple aliases or scripts for daily driving and then move to the CLI for surgery; a good GUI will have a CLI pane or a button to open a CLI in the right directory.

Even for simply committing, it's nice to have the GUI visualization as an easy sanity check that you haven't accidentally added tons of files, or as an easy way to browse your changes before committing.

Stabilizing on git itself is good enough, there's no need for everyone to use the same abstraction on top of it. The only reason there's so much focus on the CLI is because it's the default, and because power users keep convincing newbies that you're not cool if you don't use it.

</comment></comment></comment></comment></comment><comment><USER5> Site is evidently crumbling under load... getting some 50x responses from the load balancer. (edit: seems ok now?)

<comment><USER6> Now getting TLS error!

</comment></comment><comment><USER7> +1 for well-written FAQs</comment>


Ask HN: What's one book or article I should read before starting a company? - <AUTHOR> Classic story for HN I assume. I'm a developer with an idea for a SaaS trying to figure out what's in store for me if I pursue it. My question in a nutshell: What are the current best practices around product development and growing a SaaS startup? <comment><USER2> Neal Stephenson's template business plan (lifted from the cryptonomicon): [http://avsport.org/microcomm/admin/busplan.pdf](http://avsport.org/microcomm/admin/busplan.pdf)

Still a fun read and should inject a dose of realism in your own plans.

</comment><comment><USER3> Startup playbook covers all the basics, but not in detail: [https://playbook.samaltman.com/](https://playbook.samaltman.com/)

Product development is straightforward. Build something a few people love, not something a lot of people kinda like. Landing sites, sign ups, questionnaires, focus groups.. all that is meaningless. The litmus test is how much money they throw at you. The early adopters often have already hacked together a solution that is ugly and unstable, and if you can build something better, they'll happily give you money. Launch your solution early, take note of criticism, and quickly fix it.

</comment><comment><USER4> [random internet remarks]

Reading a book is easier than finding customers. Without customers, all the books in the world won't matter. Reading books is useful in school. It's useful before interviews. It's not a substitute for facing face to face rejection. Reference: _Before the startup_ [http://www.paulgraham.com/before.html](http://www.paulgraham.com/before.html)

</comment><comment> alok-g Read nothing. Fill Guy Kawasaki's 10-slide pitch desk.

Find my full comment on this here:

[https://www.linkedin.com/feed/update/urn:li:activity:6521948...](https://www.linkedin.com/feed/update/urn:li:activity:6521948130508890112?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6521948130508890112%2C6521999922173173761%29)

</comment><comment><USER5> Well, I think a book to motivate you and get you out there, making something the quickest, is RE:WORK. It was written by the Ruby on Rails creator and his co founder at Basecamp. It's pretty different than most books and most ideas are 1-2 pages long and I found that it got me motivated to build faster than any other book.</comment>


Ask HN: Why did you choose a particular "flavor" of Linux? - <AUTHOR> I'm thinking about jumping ship from OS X, and buying a machine to run a "true" distribution of Linux. I'm wondering what are some of the pros-cons of particular Linux "flavors." <comment><USER2> I use Arch Linux because I get to choose exactly what is running on my system. Arch also has the most active community as well, IMHO. If there's ever any doubt how to do something, the Arch Wiki will show you how to do it, often 5 different ways.

One of the biggest pluses of Arch is the Arch User Repository. If a package for something doesn't exist, someone will put it in the AUR for you. Whenever some software is released for a specific Linux distro, I assume Arch gets it too and I'm almost always right. I like Mint Linux's UI a lot (that's Mint Linux's main selling point) so I installed it on Arch with one command. Steam only worked with Ubuntu when it was released for Linux... except I installed it on Arch with one command the next day. Spotify is tricky to get for Linux unless you use a Debian based distro... or Arch, in which case it's in the AUR ready to be installed with one command.

[https://wiki.archlinux.org/index.php/Arch_compared_to_other_...](https://wiki.archlinux.org/index.php/Arch_compared_to_other_distributions)

</comment><comment><USER3> I use both Mint and Ubuntu, on two separate computers.

Ubuntu is great except for the Unity crap. In theory, you can run Ubuntu without Unity but I gave up trying to remove it after the first 5 hours of work. If you are getting into Linux, its important to know that if the first few sets of instructions you find on forums do not work, you will need to be an expert to solve the problem. Normally forum instructions work great, just be aware that 90% of the time is not 100%.

Mint is great. Period. It does exactly what I want - to act like a 'standard windows' linux user interface without any crazy UI experiments getting in the way. I cannot recommend it highly enough.

<comment><USER4> It should also be noted that Mint is built on top of Ubuntu (and Ubuntu is built upon Debian). And from my experience, things in general that work on Debian or Ubuntu also work on Mint.

So if you're torn between the 3, pick Mint because it works out the box.

</comment></comment><comment><USER5> If you're choosing a distro for use on a workstation (desktop/laptop), just use Ubuntu. It has had miles more elbow grease put into it to make using it on a workstation nice than any other distro available.

If you're choosing a distro for use on a server, popular choices are Debian, CentOS, Red Hat, and Ubuntu Server. Which one is right for you will depend mostly on your priorities:

* Debian: 100% Free Software and nothing but

* Ubuntu: Debian plus some small-but-nice tweaks

* Red Hat: compatibility with Big Enterprise Software, for people who don't mind paying for their software

* CentOS: compatibility with Big Enterprise Software, for people who do

</comment><comment><USER6> I switched from Ubuntu to Mint a few years ago while Canonical was rolling out Unity, because I found (and still find) the idea of a unified interface for PC, phone, tablet, and whatever the hell else, to be utterly absurd. Metro and Unity are in the same boat, as far as I'm concerned.

For those here using Ubuntu, has it gotten any better? Note that I did try Unity when it was first coming out and I hated it, so if you loved it then and are recommending it based on that I probably won't agree. I want to know, has it _changed_ for the better?

<comment><USER7> It is snappier, the launcher/finder works relatively well but can take some times if you have too many lens. I quite like the keyboard shortcuts to glue a window in a corner, or to change workspace. That's about it. It does not get too much in the way. Nothing earth shattering and nothing too awful.

</comment></comment><comment><USER8> At the moment I am using mint-kde on my workstation and I stick to the long support versions because I don't really like to reinstall my system each 9 months (yep I know I can save all there is in my home and the list of installed packages, but I lose all the /etc configuration file and I have a lot of configuration files on it). Of linux mint I love the fact is well supported, there is a community around it almost comparable to that of ubuntu (and you usually can solve problem of mint also looking at solutions based on debian and ubuntu) and all DEs work perfectly if you want to constantly switch.

On servers I usually just run ubuntu lts or debian stable based on the requirements

A question: why you speak about buying a new machine to run linux? If you have a macbook it is perfect for linux, I am waiting to have enough money to buy one with the explicit purpose to run linux on it

<comment><AUTHOR> Oh yea, that's true. I could just install Linux on my mac.

I hesitated on saying that is because I may have a period where I have two computers to help with the transition.

</comment></comment><comment><USER9> I don't know how familiar you are with the Distros... as far as the major distros go (Debian/Ubuntu/Fedora/CentOS...), they all get the job done and the only difference you might stumble on in the beginning will be the different package management systems.

Anyway, i did not choose any flavour... i just happened to start out with Debian because a fried gave me the CD many years ago when a 700mb download was still a big thing. So i mastered Debian first and i still usually stick with Debian-based distros (such as Ubuntu, elementaryOS) if i have the choice. That being said i recommend Ubuntu for anyone that is getting into the Linux world, simply because the community and available resources are huge. If you run into any problems there is a 99% chance there is a easy to follow guide on how to fix it.

</comment><comment><USER10> I tried installing Arch on my laptop and couldn't get it to work, so I went with Ubuntu because it was easy. Haven't had any problems so far, except one: I simply cannot get good results plugging my laptop into projectors. Either I can't mirror screens at all, or if I can, I end up at a lowest-common- denominator resolution, usually less than 1024x768. It could really become a dealbreaker for me, because I need to give a lot of presentations in places with their own projectors (e.g. classrooms). Anybody know if there's a Linux distribution that can do whatever magic Windows and Apple do when plugged into a projector?

</comment><comment><USER11> Ubuntu, because it's the most popular desktop distribution right now. Software for the popular distributions tends to be more well distributed, tested, and supported.

I've run Linux as my desktop for 17 years and that's why I'm running Ubuntu. I hardly care at this point which distribution I run. They're mostly quite similar and almost all rely on exactly the same software for most of what they do.

<comment><USER12> +1 to Ubuntu. Meteor (officially) only supports Linux and OSX, so I run Ubuntu along Win7. Some time ago I tried Mint. Mint is basically last version of Ubuntu with windows inspired niceties (theme and drivers). I still prefer the main distro.

As a Windows user Linux environment hurts a bit. Windows have a GUI for almost everything, Linux not so, even if you can easily make stuff through Terminal (like installing software) that makes you think that Linux approach is not that bad. The problem is the huge learning curve (at least for an hobbyist as me). It's like driving a Ferrari at night without knowing how to use the lights. You feel the speed in the moments that you know what you are doing and can see the way but sometimes you have to completely stop because you are in the dark..

</comment></comment><comment><USER13> I use xubuntu because it's lightweight and runs fast on my weak laptop. I tried ubuntu before that but it became impossible to run anything else with it installed. Maybe I should have just changed the desktop environment but I thought why not go with xubuntu instead. I have been very happy with it. It's got everything that ubuntu does plus it uses fewer resources. Win win for me.

</comment><comment><USER14> As a complete linux noob I chose debian/ubuntu to dual boot on my laptop as a sort of introduction into the wonderful world of linux. So far I've been blown away with how easy it is to accomplish certain tasks and how awesome the command line is compared to windows. I think in the future my next laptop will just be a thinkpad with ubuntu on it.

</comment><comment><USER15> I chose Ubuntu because back in the day

\- it was the easiest to install

\- Had all (or most of) the packages I wanted

\- the deb packages beat out rpm hands down (back in dependency hell days, things are way better now)

\- when I had (or have even now) a problem, I could ALWAYS find a solution in the Ubuntu Communities.

I may have to tweak it on install, to get a decent UI, etc. But if that's the worst of it, it isn't all that bad.

<comment><AUTHOR> "...to get a decent UI..."

Do you mean that you can install something other than Unity?

<comment><USER15> Yeah, classic Gnome or some other one with a bit more functionality.

</comment></comment></comment><comment><USER16> I use Debian stable because I did not agree with Ubuntu's business plan at the time and since Ubuntu was Debian based it seemed like the easiest transition. The only downside is the 'old-ness'. I wanted to go with Jessie but the installer wouldn't work and I never bothered upgrading when I got stable installed.

</comment><comment><USER17> I am an heavy windows user and now currently migrating to Linux. I chose ubuntu to begin with because of its popularity which in turn guarantees less overhead (essential for the new OS)

</comment><comment><USER18> I'd say better get familiar with Linux first (go with Ubuntu it's the safest choice) and then see if there are any distros that fit your needs better. If you don't have time to spend on the OS, _light-weight_ distributions might not be well suited. Other than that, I'd say stick to what you choose and you'll be fine :-)

That said, at this point in time, I use too many OSX-related programs to go back to Linux (I was using Gentoo 2001-2005 as desktop).

<comment><USER19> I don't dislike Ubuntu, but I do think that Unity is enough of an odd duck as a UX that a recommendation of Ubuntu to a Linux newcomer ought to mention that it's not for everyone.

</comment></comment><comment><USER20> I use Fedora, because it has the best SELinux support of the desktop-oriented distros.

</comment><comment><USER21> i choose Fedora because Red Hat puts a lot of work into all aspects of the GNU/Linux ecosystem. I like Debian a lot (for philosophical reasons), but i prefer something a bit more opinionated for everyday desktop use.

</comment><comment><USER22> Arch. I like to keep things light.

<comment><USER23> Arch as well. I like to keep things simple (as in the Unix philosophy).</comment></comment>


Bribe developers to fix bugs - <AUTHOR> http://bribe.io/ We are creating Bribe.io for Startup Weekend. It is a service which allows users to pay developers to prioritize bugs that need fixing. We'd like to get feedback from users and developers who would use this new service. Please check out Bribe.io and fill out our survey. <comment><USER2> [http://dilbert.com/strips/comic/1995-11-13/](http://dilbert.com/strips/comic/1995-11-13/)

Wally: "i am going to write myself a new minvan this afternoon"

<comment><AUTHOR> We envision that many times the bugs will be fixed by someone who has not already been working on that Open Source project. We also do not expect any projects which are intentionally buggy to become popular enough to make a difference.

Bribe.io will also include work on enhancements to an existing Open Source project.

<comment><USER3> An open-source environment is really the only place this kind of motivation could work. As you say, if the project is intentionally buggy, it's unlikely to be used.

Love the idea!

</comment></comment></comment><comment><USER4> Some of my colleagues wrote a research paper about a system like this a few years back:

[http://researcher.watson.ibm.com/researcher/files/us- bacon/B...](http://researcher.watson.ibm.com/researcher/files/us- bacon/Bacon09MarketBased.pdf)

They proposed a new notion of "software correctness" as an equilibrium in which there is insufficient economic demand for any further bug fixes. Cool to see such a system being built!

</comment><comment><USER5> I was considering starting a kickstarter like site for this as well. Some projects have stalled development. It would be interesting to have a system where people can create a road plan for a particular stalled open source project, and donate to the development. Once a given target is reached, developers can bid on the project, compleat it, and get paid.

There are some projects, like DoubleCommander, which I would pay money to make it move faster, as it's the only viable TotalCommander clone for MAC. However, I can't afford to hire anyone to work on it by my self, and can't expect the primary developer to work on it for free any harder than he already is.

</comment><comment><USER6> Aka, extort users to pay for bug fixes :)

<comment><USER7> Yes, because requesting to be paid for doing work is a programmers ultimate sin..

<comment><USER8> Nothing wrong with it though it seems wrong to lead people into thinking something is free or letting them become depending on it.

</comment></comment></comment><comment><USER9> For a side project I wanted to experiment with a very similar idea.

Due to other commitments I was not able to give the project the love it deserved. Perhaps some of the code or concepts will be useful for you guys:

[https://github.com/codebounty/codebounty](https://github.com/codebounty/codebounty) codebounty.co

Let me know if I can help. @jon_perl

</comment><comment><USER10> This is different from [https://www.bountysource.com/](https://www.bountysource.com/) how?

<comment><USER11> Was just about to mention this site. I'd also be interested in knowing on what points it will differ from it, assuming the founders of bribe.io know about the already-available alternative.

<comment><AUTHOR> We have been looking at Bounty Source. We think jobs on Bribe.io will not be on that scale. Some of those projects are quite involved while Bribe.io may be smaller efforts, like updating a WordPress plugin to be responsive for mobile so it works with a mobile theme. It may just take an hour and earn the developer $100.

There may be some crossover with Bounty Source which could be good to provide multiple resources for users and developers.

<comment><USER11> I see. Thanks for the quick reply!

</comment></comment></comment></comment><comment><USER12> bribes, or bounties, or prizes, or whatever you want to call it work on the extrinsic motivations for people to act. In many cases, open source projects are a product of love, that is, intrinsic motivations. There's always a risk when introducing extrinsic motivations that they'll crowd out the intrinsic.

<comment><USER13> I see where you are coming from, but I find that for myself, I come to different conclusions.

I work on open source not just because I love my product, but due to an element of wanting to show off. It's kind of a badge of honor, a point of pride to have a project that people use and love.

Which is to say that, _without_ the motivation of others using my project, wanting to contribute to it, and even wanting to donate money to the project, my personal level of interest declines ("nobody is using this anyway.")

</comment></comment><comment><USER14> I like the idea. But bribe has a negative feel to it. Why not bounty?

<comment><USER10> Because that's already been done! [https://www.bountysource.com/](https://www.bountysource.com/)

</comment></comment><comment><USER15> This is amazing idea, but I'm wondering that how is transaction going to work? Will there be any amount of money that "staff" keep?

<comment><AUTHOR> The way we are going to handle the money is to take the payment when someone creates a job. The money will be held in an escrow account. Then developers can work on the job and submit their solution. Once the user accepts the work by the developer the money from the escrow account will be released to the developer. There will be a fee for the user while the developer gets the full amount pledged.

If there is a conflict we can step in to resolve it and make a decision. Since the money is in the escrow account it will not be possible for the user to just not pay and the developer cannot just take the money and run before they user accepts the solution.

<comment><USER16> Since you are taking money from the user, it is your incentive always to decide in their favor in order to get their repeat business.

</comment></comment></comment><comment><USER17> Nice idea. I think it's extra interesting since I remember reading a debate here on HN about "bribing" OSS developers.

<comment><AUTHOR> Got a link for that debate? The name is meant to get some attention while it is our intention to help users find developers who can help them make updates to the software they use but cannot update themselves.

And the developers getting paid to make these updates may be college undergrads or someone who has a day job but dedicates sometime to working on the jobs set up on Bribe.io. They can make some money helping others while also contributing to OSS which helps everyone.

</comment></comment><comment><USER18> Not just bugs, but adding features too!</comment>


13 Ways To Pull Off A Killer Demo Day Presentation - <AUTHOR> http://onstartups.com/tabid/3339/bid/48317/13-Ways-To-Pull-Of-A-Killer-Demo-Day-Presentation.aspx?source=Blog_Email_[13+Ways+To+Pull+Of+A]

<comment><USER2> Title guideline: "If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids.""

Click "Guidelines" at the bottom of the page.

</comment><comment><USER3> I really like the idea of planning some tweetable quotes ahead. Of course this is not necessary for all audiences - but in some settings it can create a lot of positive hype.

</comment><comment><USER4> Sound or Tweet bytes loved it. Really like Series Awesome!</comment>


Google Storage Now Available To Developers - <AUTHOR> http://code.google.com/apis/storage/docs/getting-started.html <comment><USER2> 5 years, 1 month and 28 days after S3 is publicly launched. It is just a reminder that the threat by incumbents to startups is hardly worth worrying about.

<comment><USER3> Amazon was hardly a startup 5 years ago. And we're talking about a service and a space that's difficult to replicate and get into. S3 had resources most startups won't have to get that 5-year lead.

<comment><USER4> Amazon wasn't the "startup" in his example. His point was the 5 year wait time for a "giant"* to get a product out the door...

* who, even worse for their case, already had the infrastructure, resources, engineers, etc. to get it done.

<comment><USER3> The point still stands; this isn't an example of why startups shouldn't fear giants/incumbents. Just because Google couldn't/chose not to get a product like Amazon S3 out the door to compete with Amazon, doesn't mean incumbents can't replicate and dominate a bootstrapped start-up's low-cost, innovative web app or mobile app.

The statement should say that startups with innovative, hard-to-reproduce products have nothing to fear; you'll either produce a product that they'll choose not to compete with/can't compete with (Twitter, Facebook) or get bought by them.

How many startups get killed because they can't compete with the big guys, though? Here's an example: <http://family.go.com/assets/bubbleshare/>

<comment><USER5> I'm trying to innovate in the same field that Bubbleshare was in. I only learned about them recently via reading old techcrunch posts. What killed them? Did they go through a prolonged period of difficulty?

<comment><USER6> Founder greed and bad timing.

<comment><USER5> Ah can you elaborate please? To me it looks like Bubbleshare was the best thing ever---till it suddenly shut down.

I find glowing reports about it from TechCrunch, then.... nothing, it just dies.

So what happened?

<comment><USER6> Disclaimer: I was not involved, but several people that were are friends. These friends did not inform my answer here, which is just my opinion based on many sources.

BubbleShare was a Toronto tech darling started by the always brilliant Albert Lai. They were WAY ahead of their time.

All I'm comfortable sharing here is that they received buyout Offer A, which Albert rejected in favour of doubling down for a better deal. Unfortunately fortune did not smile and BubbleShare ultimately accepted Offer B, which was significantly smaller than Offer A.

The site was sold to Kaboose, which is a Canadian family content company. As usually happens when startups are acquired, the key talent left (Albert started Kontagent) and innovation on the site halted.

I'm not an analyst, but these things usually distill down to "too early / too early / too late". I'm not sure that people were ever lining up to pay them money to use the service, and that might give you pause before going down the same road. Many products are cool but aren't solving a problem causing paying customers real pain.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> The pricing is far less interesting to me than the differences between GS and S3. In some significant ways, GS appears to be a much more technically sophisticated product. And there are some arguably less used functionality like BitTorrent which are removed from the picture.

The ACL scheme is significantly more flexible on GS. In fact, one of the two major problems I have with S3 is a non-issue on GS:

1\. All files on S3 are not world-readable when they are first uploaded. You cannot change the default permission for a file uploaded to a bucket. On GS you can set the default ACL on a bucket to world-readable.

2\. For me, the most incredible thing GS could do right now is add a callback API. I want it to notify my application when my bucket is updated, webhooks style.

With both 1 & 2 in place, you can build storage driven applications in the cloud that don't require constant polling. Man, that would sure be something.

</comment><comment><USER7> A compelling reason for our use case to switch from S3 is their support for lots of buckets coupled with CNAME support:

<http://code.google.com/apis/storage/docs/reference-uris.html>

Due to Amazon's limitation of 100 buckets per account and the coupling between bucket name and CNAME, hosting files for our clients and supporting custom CNAMEs has not been possible for us. If we were to move to Google Storage, it would be.

<comment><USER8> Another good reason for certain use cases is its support for resumable uploads:

[http://code.google.com/apis/storage/docs/developer- guide.htm...](http://code.google.com/apis/storage/docs/developer- guide.html#resumable)

Afaik S3 can't do that.

<comment><USER9> No, S3 (essentially) can as well:

[http://aws.typepad.com/aws/2010/11/amazon-s3-multipart- uploa...](http://aws.typepad.com/aws/2010/11/amazon-s3-multipart-upload.html)

<comment><USER10> Multipart uploads only sort-of address this. For one thing, the minimum "part" size is 5MB, so you can only resume at 5MB boundaries (or whatever part size you use). You also have to manage more state yourself.

</comment></comment></comment></comment><comment><USER11> It's really nice to see that boto (python AWS library) supports S3 and Google Storage side-by-side. Being able to pick and choose providers behind the same API is how the cloud should be.

<comment><USER12> It probably wouldn't have worked out that way if Google didnt clone S3's API.

<comment><USER13> To be fair to Google, most of the S3 REST API is pretty obvious. Even if you'd never seen S3, you'd likely come up with an API that was 80% similar.

<comment><USER14> not the openstack storage api..

<comment><USER13> What do you mean? I haven't looked into Openstack in great deal, but my impression of the storage API was that it was very similar to S3, aside from how it handles authentication.

</comment></comment></comment></comment></comment><comment><USER4> Can someone explain why I would choose this over S3, when S3's starting rate is 0.14 / GB and goes down from there?

</comment><comment><USER15> At Google's scale I would have guessed that they would have had no difficulty in matching and even beating Amazon's pricing. This is surprising. Why so?

<comment><USER16> Perhaps they're looking to grow the service slowly initially? If they announced pricing significantly lower than amazon's right at launch they'd get a flood of new traffic that could overload however much resources they provisioned for launch. By starting out with a slightly higher pricing model, they can test out the service with production customers, and slowly reduce prices to attract more business when they're confident they can handle the load.

</comment></comment><comment><AUTHOR> No more invites required to use, but at first glance it appears to be more expensive than S3.

<comment><USER17> Cost of storing data:

S3: $0.140 per GB (at the most expensive rate) vs. Google: $0.17 per GB (at their only listed rate)

The rest seems to be the same though.

<comment><USER18> Fascinating, so a 1TB sata drive is $70 [1] these days and that equates to about 7 cents per GB, if you made three copies to insure your backups had a 'good' copy that would be 21 cents/gB so its cheaper than using your own hard drives.

The whole 'we've decided to kill that product, you've got 30 days to get your stuff back' and the 'we lost a switch or something and we'll be back online day after tomorrow' kinds of things are still concerns of course.

I've always been impressed at the prices Amazon could charge for S3 and keep it a going concern. I'd love to see the breakout on that revenue but I'm sure that isn't going to happen any time soon.

[1] [http://www.newegg.com/Product/ProductList.aspx?Submit=ENE...](http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2010150014%20103530090%201035313496&name=1TB&nm_mc=KNC- GoogleAdwords&cm_mmc=KNC-GoogleAdwords-_-HardDrives-_-NA-_-NA)

<comment><USER19> Your comparison assumes that the average lifetime of a hard drive is 1 month. I sure hope that's not the case!

Also, don't forget bandwidth charges if e.g. some of your s3 access does not come from ec2.

<comment><USER18> Oh it gets much worse if you assume that you replace your hard drives every 3 years (their warranty period) which would add a $1.94/month depreciation cost.

You could add into the cost / GB of bandwidth to access the files, not as easy to factor into a TCO model in the personal use case.

<comment><USER18> The way I was accounting for it you have to replace the drive in 3 years, you have 3 drives. So you've got a cost of $210 that recurs every three years (purchasing the drives). If you distribute that cost across the 36 months that is a $5.83/month fixed cost (doesn't vary by storage usage because you have to replace the entire drive). Unlike Google which can amortize depreciation on a per-GB basis because they are spreading out the replacements amongst many thousands of drives, as an individual you're on the hook for your own drives regardless.

<comment><USER20> right, but the point being made was that the storage fee Google/S3 charge is not a one-time thing - it recurs monthly.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Download data: $0.15 to Americas, Europe, the Middle East, and Africa $0.30 to Asia-Pacific

So if a bunch of people from Japan decide to download from your app, you are screwed.

<comment><USER22> You're screwed if a bunch of people download from your app from anywhere, for sufficiently large values of 'bunch'.

<comment><USER23> Not if they paid you a sufficiently large sum of money for the privilege of downloading your app. :-)

<comment><USER22> Truth. My comment was quite negatively off-base, considering lots of downloads is what everybody strives for. I almost deleted it. Funny it got so many upvotes, should have been downvoted to oblivion.

</comment></comment></comment></comment><comment><USER24> A bucket in Latin America would be a killer feature. Doesn't Google already have a data center in São Paulo?

</comment><comment><USER25> I am a little confused about Google Storage Manager. Is this supposed to be a consumer facing product? AKA dropbox killer?

<comment><USER26> No, it's an Amazon S3 competitor.

<comment><USER25> Then what is the point of the frontend app?

<comment><USER27> S3 has a web based access application as well. It is nice if you need to just manipulate a few files, check that a backup actually did make it to S3, etc.

Dropbox isn't really a storage company (they're built on top of S3) their secret sauce is in the syncing.

</comment></comment></comment></comment><comment><USER28> Only 5 years, 1 month, and 28 days after Amazon made S3 available to developers.

</comment><comment><USER29> meh, in 3 years they'll probably just announce a new pricing structure where every reasonable use of this ends up with 1000%-2000% price hike (GAE user here, grumble grumble)

</comment><comment><USER30> Damn, I was hoping this was going to spur Amazon to cut prices.

</comment><comment><USER31> Anyone know how to copy an S3 bucket to Google Storage?

<comment><USER27> The quickest/cheapest thing would probably be to startup an ec2 instance, install the GSUtils [1] and then pull from S3 and push to GS.

1 - <http://code.google.com/apis/storage/docs/gsutil.html#install>

</comment></comment><comment><USER32> does anyone know if s3 is profitable?

<comment><USER33> Only the same people who know how many Kindles they've sold. Amazon is pretty tight-lipped about their financials, at least at a granular level.

</comment></comment><comment><USER34> i thought this was just an auxiliary service to other google services.. not really a competitor to s3?</comment>


C++: Using References Instead of Pointers - <AUTHOR> https://awesomekling.github.io/Serenity-C++-patterns-References-instead-of-Pointers/ <comment><USER2> Smart pointers are strangely absent from this comment, which is rather weird as handling raw pointers ceased to make sense and became a pungent code smell with the inception of C++11.</comment>


Tesla reviewing contractors, firing everyone not vouched for by an employee - <AUTHOR> https://electrek.co/2018/05/06/tesla-brutal-review-contractors-firing-vouching-employee/#disqus_thread <comment><USER2> Sounds shocking... but having worked as a contractor for a goodly portion of my career, I'd argue that something is seriously wrong if you can't get at least one employee to vouch for you.

Really, every place I've worked, you could say this happens every month; almost always I've needed an employee to sign off on my hours, either the person I report to or the person they report to. I always took that as a vote of confidence, personally.

(I mean, obviously, even if I get fired, I expect to get paid for hours worked, but point being, the guy just signed off on spending $15k-$20K, depending on the body shop cut, for a month of my work, I'd assume that would trigger at least a few minutes of "what did Luke do for me this month?" and a phone call letting me know not to come in Monday if the answer was "Not much".)

<comment><AUTHOR> > I'd argue that something is seriously wrong if you can't get at least one > employee to vouch for you.

The corollary to that is that if you get to the point where you need to check on the vouchsafety of all your contractors - en masse - something is seriously wrong with your company.

<comment><USER3> I think Elon was pretty clear that he considers the situation to be seriously wrong, hence the extreme approach. It's a refreshing attitude; this sort of problem is common in most large companies.

<comment><USER4> Yeah, a startup founder seeing a problem and having a clumsy, heavy handed, poorly thought out reaction is super refreshing. Hadn't been this refreshed since like, Friday.

<comment><USER5> you know he founded PayPal, right?

Which sold to eBay for $1.5b

His first company was acquired by Compaq for almost half a billion.

He's listed by Forbes as one of the top 25 most powerful people on earth.

Tesla is a 15 year old company.

I feel like "startup founder" should not the operating phrase here.

<comment><USER6> Not to diminish his achievements but...

> you know he founded PayPal, right?

Confinity (Levchin, Thiel, Nosek, no Musk) launched PayPal in late 1999. X.com (founded by Musk) merged with Confinity in March 2000. In no way can Musk be considered a "founder" of PayPal.

> His first company was acquired by Compaq for almost half a billion.

Zip2? $340M. Nowhere near half a billion and that was in 1999 at the height of the _ridiculous_ tech bubble.

The man's done a lot of stuff - there's no need to embellish them.

</comment></comment></comment></comment></comment></comment><comment><USER7> In the race for attention, is this article interesting because it's a new model for implementing and delegating work, or more the fact that a company has decided to rapidly cut down on contractors?

Because there's lots of companies that rapidly cut down on contractors, and I doubt they'd all have an article written about them at the top of Hacker News.

I'm neither here nor there about the company, but I note that it competes for a lot of my attention. I feel like if they decided to switch to all Macs, or abandoned Slack for IRC, I'd see a story about it here on Hacker News.

<comment><USER8> Exactly.

</comment></comment><comment><USER9> As a contractor myself, this sounds like a great idea. If there aren't multiple people at an organization that can vouch for you, there's a good chance you're dead weight - or at any rate, there are no checks in place to prevent you from becoming so.

<comment><USER10> My Dad liked to tell a story. The parts of the body were arguing about which was most important. The heart pumps the blood, the brain keeps everything working together, the lungs bring in air etc... Then the anus closed up!

Even if no one vouches for the butt hole in department C they can still be necessary. Something to keep in mind before making sweeping changes without regards to the details.

</comment></comment><comment><USER11> Meta: can you not link to the Disqus deeplink on the page?

        https://electrek.co/2018/0...ployee/#disqus_thread

</comment><comment><USER12> The bigger concern I have is that it encourages extreme nepotism — people vouch for people from their schools and prior jobs, and so risks introducing systemic bias against people from different backgrounds. Obviously gender and race are heavily represented in this kind of thing, but even basic stuff like west coast vs east university nonsense can start happening.

<comment><USER13> Your own reputation is put on the line by vouching for a contractor, according to the article. So if something bad happens down the line, your continued engagement with Tesla will be questioned too.

Nepotism and bribes are _going_ to happen, but I think there will be some fast lessons when Tesla axes employees for this behavior.

<comment><USER14> Which is exactly the situation when friends and former classmates get more advantage over someone you know for three months.

It makes it more clicky.

</comment></comment></comment><comment><USER15> He's probably talking about consultants. I'm sure Accenture, Deloitte, and McKinsey (among others) infections have run rampant in just about all departments. Consultants are great when they're great but almost unimaginably inept and expensive when they're not.

<comment><USER16> And the ones that are inept, are experts at sounding exactly the same or better than the ones that are great, making the difference difficult to understand without equal expertise.

</comment></comment><comment><USER17> Being a hard ass CEO isn't sexy, but it's what so many successful CEO's are.

> _Often, it is like a Russian nesting doll of contractor, subcontractor, sub- > subcontractor, etc. before you finally find someone doing actual work._

I'd also argue that these multi-level contractor setups are a major security concern. Ideally they should make it policy to have no more than one additional level between Tesla and the contractor performing the work.

Aggregate contracting will make assigning liability a difficult task and it's likely the person working for you is being underpaid as each layer takes their cut. Meanwhile you get 100% of the shit-storm from any media backlash about worker salary/conditions.

<comment><USER18> It really makes me wonder: Isn't using contractors super inefficient? Why do companies, when they could do it in house, use them?

<comment><USER19> > Why do companies, when they could do it in house, use them?

A few basic reasons:

* You can't do it in-house as well as a contractor who specializes in this field, or as well as this particular contractor. Very broadly speaking, the best people in field X want to work for themselves, do things their way, and keep the revenue from their work. They don't want to be several layers deep in management at your company, to have f-ng morons (i.e., anyone else) telling them how to do their job, and to be paid a salary for the breathtaking, save-the-day miracles they routinely output.

* It's not worth the investment: You would have to find and hire talent, ramp up, provide resources to them (equipment, training, etc.), be able to manage the talent in a field that isn't your expertise, and keep them busy and interested. Maybe you don't have enough scale in the things they do to support quality resources; maybe you just don't have enough work or enough interesting work for them.

* Every additional employee or capability is a distraction for the organization, including management. Keep focused on the things you do best and that are strategically important; you don't even have time for that. If you're small restaurant chain, IT isn't strategically important - it just has to be reliable and good enough. Outsource it and focus on world-beating food, service, and marketing.

* You don't want to pay benefits, taxes, or have the other responsibilities of being an employer. See: _Uber_.

* Sometimes it's just politics: I once worked in an outsourced capacity for a company where the IT manager simply didn't want to invest in a technology that would threaten their fiefdom, so somebody brought in a contractor. It was not a fun place to be.

</comment></comment></comment><comment><USER20> Is this meant to be shocking? When I was a consultant at a big European telecom company the department got a new manager who started by saying that there should be no multi-year consulting contracts - within a few months of hiring a consultant the position should be either inhoused or outsourced. I remember thinking "about f-ing time" even though my job would probably be one of the first on the chopping block. The financial incentives are so screwed up I can't believe consulting is still such a big business.

<comment><USER21> Without even factoring in work culture, the cost of a FT employee is really really high in a place like Australia where you basically can't fire people. Want a 6 month project done, makes more sense to pay for a consultant team than try spin up new employees. They come in for a set period, fixed deliverables and accountability, then they go. Effect multiplies when it's something like IT and the business is completely unrelated to IT.

</comment></comment><comment><USER22> Wish the US government would do the same thing!

<comment><USER23> You're being downvoted but my work with a state government frightened me. It was amazing how many contractors are building castles of crap and then protecting them so that they can make an exorbitant living off of the teat of the taxpayer - and I'm about as liberal as one gets - AND this was at the state level.

</comment></comment><comment><USER24> This is what happens when you don't fill out your TPS reports correctly.

Sarcasm aside it seems like Tesla has operational issues. This coupled with the story a few weeks back about somewhat "slapdash" power module assembly is a bit concerning.

Musk is a visionary... but few visionaries are excellent operations people.

</comment><comment><USER25> This is one of those things that's going to be painful in the short term and pay off in the long term, but given Tesla's precarious financial situation, who knows if they'll even have a long term.

It's possible that musk is just trying to cut their burn rate and is going to blame the inevitable decline in production after this on 'restructuring' or whatever.

</comment><comment><USER26> Having an employee vouch for you... does this not imply they don't even know where their money is going as a company and who is valuable and who is not? I agree, that having the line worker / employee using the part's blessing is important, but surely there are more holistic top-down ways of evaluating this?

<comment><USER27> > surely there are more holistic top-down ways of evaluating this?

Which would take months. This is about sending a message as much as it is about cutting costs (fast).

<comment><USER28> What's the real message. Employees prepared to be fired as soon as we reduce the outsourcing budget. Your jobs are not safe so if a better opportunity comes up, take it.

</comment></comment></comment><comment><USER29> Can we take the #disqus_thread off the link?

</comment><comment><USER30> Sometimes when employee learns how much given contractor make, they get very bitter. I wonder how it is going to play out in terms of vouching... edit: typo

</comment><comment><USER31> Tesla seems like a company where people would place a premium on being a direct employee, vs. another organization. I'd certainly feel more 'pride' in saying "I work for Tesla" than "I work for X" for almost all non-SpaceX or tiny-startup values of X, and that's probably generally held by people who would contract for Tesla.

<comment><USER32> _I 'd certainly feel more 'pride' in saying "I work for Tesla"_

Why? SpaceX, sure. But Tesla? Just because it gets more news coverage?

<comment><USER18> Tesla is cool. But as a contractor, effectively working for Tesla, I'd probably also call it that.

</comment></comment></comment><comment><USER33> I believe that in this particular case a contractor could be a company of couple hundred (or 1000s) people or so, producing a sub-part of a car. Car makers mostly just put the car together - they do not manufacture parts.

Which begs the question: can Tesla afford to fire contractors? R&D on complex parts takes years, even at Tesla ...

</comment><comment><USER34> I wonder if this is to protect ip. I know of one self-driving startup in which the founder recently had his wife get an internship with Tesla's self-driving team. I'm sure there is a big risk of ip theft or just learning other things that can give a competitive advantage.

</comment><comment><USER35> The article is unclear. Does contractor mean supplier, or is it an individual working at Tesla site?

</comment><comment><USER36> > Often, it is like a Russian nesting doll of contractor, subcontractor, sub- > subcontractor, etc. before you finally find someone doing actual work. This > means a lot of middle-managers adding cost but not doing anything obviously > useful.

who would not like to cut down mess like this?

</comment><comment><USER37> Is it possible this just Tesla "encouraging" contractors to switch to employees?

Contractors generally get paid significantly more than employees in the short term, and Tesla is on the line for getting to profitability.

<comment><USER38> Employees have a lot of expenses that contractors don't have. Payroll taxes, health insurance, other benefits, and generally there are more HR policies governing termination for an employee than a contractor, even in an at-will employment situation.

<comment><USER39> Yes, in the major tech companies very few people will elect to stay W2 contractors if given the chance to convert. Most would prefer full time positions.

</comment></comment></comment><comment><USER40> Don't contractors have managers that are supposed to, well, manage them?

<comment><USER41> Not that sort of singleton contractor - and technically having a company employee manage your day to day tasks will be take by the tax man as disguised employment - not a good idea.

<comment><USER38> Yes, there will generally be a person designated to tell you what they want done, but they can't manage where and how you do it.

</comment></comment></comment><comment><USER42> For a Russian it is nice to hear about a matryoshka from Musk. (sorry for useless comment)</comment>


More Than 80% of All Net Neutrality Comments Were Sent by Bots - <AUTHOR> https://motherboard.vice.com/en_us/article/43a5kg/80-percent-net-neutrality-comments-bots-astroturfing <comment><USER2> I couldn't ldnt log in to leave a comment, so I'll take one just so long as it's in favor of no fast lanes, free and open net.</comment>


Show HN: Vacancy. Interesting jobs for programmers - <AUTHOR> https://vacancy.io

<comment><USER2> Agree with allowing browsing before signing up. Looks great though. Well done and good luck!

<comment><AUTHOR> Will definitely consider changing this. Currently it's very early stage so all feedback is really useful. Currently working on gathering more jobs, implementing better search and making good recommendations depending on a programmers particular skills and interests. Thanks again for the feedback. Really appreciate it. : )

<comment><USER2> No problem. Good luck. I'm going to sign up at some point soon and will keep my eye on it.

</comment></comment></comment><comment><AUTHOR> Still very early stages. Feedback very welcome : )

<comment><USER3> How about the ability to browse? I'm tired of signing up to all these new sites only to find I'll never use them. I'd like to know what I'm getting first.

<comment><AUTHOR> Appreciate the feedback by the way. Thanks. : )

<comment><USER3> No problem. Thanks for the reply.</comment></comment></comment></comment>