Hacker News new | comments | show | ask | jobs | submit | BrentOzar's comments login

If they're launching now in major cities, I'm guessing drone deliveries aren't coming anytime soon. (Or this is insurance against the drone plan not working.)


We are the drones.


I don't think the drone plan was ever a serious short term consideration for 99.999% of Amazon's business


> I don't think the drone plan was ever a serious short term consideration for 99.999% of Amazon's business

Right, but where would it be a serious short term consideration? Where's that .001%? If it's not in dense urban areas like Seattle and Chicago, I'm not sure where it would work, and those are the very areas where they're launching Flex.


> Right, but where would it be a serious short term consideration?

Public relations.


The drone thing is a ways off; this is akin to Uber hiring drivers while working on driverless cars. The sad thing is the majority of jobs I hear about in the exciting new sharing economy are drivers and delivery people -- unskilled jobs that skilled engineers are furiously working on eliminating.


Those delivery drones aren't happening unless there is a huge improvement in battery technology and there are a number of companies and labs working very hard on that problem, some for decades.


> How does it handle VAT MOSS on digital goods in the EU?

They don't. See: https://filesprout.com/support/what-do-i-need.html

"If after talking with a professional you are responsible for paying sales tax for your items, you'll have to add this into your pricing manually."


Pretty sure that won't work. You need to add the VAT in the buyer's region, not the seller's. This is of course a nightmare to manage. See: http://euvataction.org/key-facts/#key_regulations

If that link is to be believed, you also need to submit your taxes on a quarterly basis, not a yearly basis as filesprout mentions as well as keep track of and store your customers data for 10 years.

Also, on your link they say: >Do you take a % of my sales? No way jose :) That's your money.

Whereas the main page says: >No contracts or monthly fees, leave at anytime. We take 5% you keep 95%. Fair enough?

Which too me qualifies as taking a % of sales, 5 to be precise.

And my final complaint: grey text on a white background...


Yeah, actually, if you're going to be a third party selling user generated content directly (and paying those users) over the internet, what are your responsibilities as the distributor? Can you really just say "Ask your accountant, not our problem..."? Seems like that's the best one can do as a startup though. Incorporate elsewhere?


> Incorporate elsewhere?

Doesn't matter, to a degree, the rules apply to anyone selling to Europeans regardless of where they are based. How and if non-compliance will be prosecuted is a more complicated matter.


>> How and if non-compliance will be prosecuted is a more complicated matter.

Indeed. As far as I can tell, it's only been tested in a limited sense when there are relatively clear violations, such as drug markets, blatant piracy, or gambling. But extend that a bit further, and you get into the sort of murky territory where you're forced to blacklist entire countries because they have crazy people running them.


IF someone provides the service with the VAT support i think it could actually work quite well for a lot of small vendors.


We also provide the service to help you with the EU VAT (and Norwegian VAT) and we also provides payment by SMS (mobile phone) for a lot of countries and a lot more.



Gumroad is: http://blog.gumroad.com/post/110080508463/vat


leanpub does it for books


"Error establishing a database connection"

Maybe you should rethink that rule when it comes to your sysadmins and database admins.


It's also important to let your admins fail, and let the people and systems improve based on what you learn from the failure.

Being completely risk averse creates an environment where it's very difficult to improve, for fear that your good change will happen to cause a problem and you'll get blamed for it.


That's not what the article is about - the article explicitly talks about when you know the employee's approach won't work and you'll have to do their work over, let them fail anyway without telling them in advance.

That's not being risk averse. That's bad management. A manager's role is also that of a mentor, helping your employees leapfrog over obstacles you've encountered in the past. (Don't get me wrong, there's a wrong way to do it - micromanagement.)


Part of mentoring is letting the mentored fail and working through the after-action and identifying the learning opportunities.

Controlling for how big or how expensive that failure is are both necessary components of the task; don't let them fail in a way that's going to torpedo the company.

But only being told how to do something makes a person a good follower and does nothing for their innovative or problem-solving skills. That's also bad management.

A successful professional needs a back catalog of failures and misses to understand why to do something.


When I was a professor mentoring students, my approach could vary depending on the student and situation. If a student felt strongly about doing something a certain way, I might say "I would be surprised if this worked (because of XYZ), but prove me wrong!" There have been occasions where I was wrong, and many others where they failed but learned along the way. If it is a more time-critical or important project, then I will probably provide more guidance depending on the context ("give this a try first, and check back when you have results; if you're not happy, we can try your way"). This approach has carried over to industry well for me.


Yes, exactly. Mentorship is about guidance, not hand-holding. It is about asking questions the inexperienced employee may not have thought of on their own, but also letting them find the optimal solution on their own.

For example, if they are designing a backup solution for the first time, asking them "what will the system do if the backup media is full?" is good. Telling them what it should do when full is bad. By asking the question, you're basically teaching them that there should be a contingency in case of failure. From there, a discussion on possible solutions can take place, where the mentor once again guides the employee to figure out the pros and cons of each approach.

That said, I'd never knowingly let people fail. Even without that, any good professional will have plenty of failures anyway. If they don't, they are playing it too safe and aren't learning some important lessons, and it might be time to assign them more challenging projects.


That's a fantastic comment and example. Know your answer. Ask the question. I also highly respect Pixar's model - encourage collaboration and feedback between peers. I'm managing a team at the moment. We are a democratic group. I mostly ask Questions to steer toward success. The team (mostly women) are empowered to own, experiment, share and collaborate. It's been a fantastic experience. Interestingly, when we started, there was a lot of sass about gender superiority - but that's gone away since I expressed several times that we are all people, no other attitude will be tolerated.


> Even without that, any good professional will have plenty of failures anyway.

That's the main thing to me. Why waste people's time on known dead ends when you can fail on things that matter, together?

It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself. It also assumes you can predict every problem they'll encounter well enough to precisely ration out additional obstacles.


>>That's the main thing to me. Why waste people's time on known dead ends when you can fail on things that matter, together?

People learn differently from experience than they do from being told something.

>>It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself.

That's the thing though: people rarely make the same mistakes as you did. They tend to make different mistakes, and fail differently, with different results and consequences. By serving the solution to them on a silver platter, you're robbing them of very valuable learning opportunities.

A mentor's job is to use their experience to guide the employee and help them figure out how to avoid mistakes. And if they do make a mistake, then the mentor is there to help them recover. The recovery is followed by by what I call "lesson time", which is a judgment-free session where we discuss why the incident or failure happened and come up with actionable steps to prevent it from happening again.

If you find yourself in situations where you absolutely have to tell someone how to do something because failure would be fatal, at that point you should do that thing yourself, and have the employee watch you do it and take notes. That's another type of mentorship that a lot of people are not comfortable with, but it can be extremely valuable.


> It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself

This wasn't assumed in the premise, though the mentored may for sure have some experiences that the mentor did.

Learning and internalization happen after we synthesize stories and narratives into lessons that we can deeply connect with.

If a junior teammate comes to me with a solution and I say "I tried it that way once and it didn't work because xyz," that teammate will change their execution and, from my experience, not really internalize the xyz. This means they'll come back to me in the future with the same problem and we'll go through that again, because they didn't learn.

The critical action in both success and failure is reflection. Discovering the lessons through discussion is the way for us both to learn, and to ensure the experience is meaningful and sticks.


Let them fail: Second best case is that they fail, learn something, and are either open to suggestions or have better ideas the next time around. Either way, you have to re-do the project. Best case, they succeed, and you learn something.

Second worse case is that they fail, don't learn anything; lather, rinse, repeat. The worst case? They produce a semi-functional failure and you have a shambling horror of a monstrosity to support until you finally give up and resign.

Don't let them fail: Second best case: You mentor them into a failure, but they learn something and you learn something. That's sort of good, right? The best case is that you mentor them into a success, they learn stuff and you have a functional project.

The second worst case is that you beat them into submission and get a functional project, but they resent you for not letting them do things their way; they haven't learned anything. The worst case is that you mentor them into a failure, catch all the blame for it, and they're now mentoring you. (And yes, I'm explicitly assuming that you are ten times as skilled and experienced as they are; this is a very bad thing.)

Now, it may just be my experience, but the best cases on either side are entirely theoretical. I've only personally experienced variations on the worst cases. But, I've also worked in government contracting (that may be redundant). There are a lot of hard-headed, not-especially-competent junior devs out there.

The bottom line is that you should just do it yourself---it'll generally save you a lot of grief.


This exactly.

I'd love to find some way to deal with the politics of the case where you end up with the shambling semi functional monstrosity.

Watching someone who is clearly out of their depth trying like hell to save face while time slips past and the software doesn't improve is very frustrating.


There's a difference between being adverse to failing at some task and not wanting your venture to crash.

For vital infrastructure, it's more important that those "failures" be more in the way of the dba or sa needing to look up how to make something work properly, than actually fry the server instance and wipe your data.


> Do you not get bail money back when your presence in court is concluded?

If you post the full bail yourself, yes, but he said he'd paid a bail bond. If you can't post the full bail yourself (say, it's $30k) then you go to a bail bondsman and they pay the full bail for you - in exchange for a fee, usually 10% of your bail. That fee is non-refundable.

Then if you skip out while you're on bail, they come find you and drag you back to court to get their money back.


I like it because it got me down from several cards (debit, credit card A, credit card B, business card, business debit card) to two (debit card, Coin). The debit card is my backup to Coin.


I formerly did the same, but it became insufficient.

There are at least 4 cards that I need working at all times: (1) Debit card, as you mentioned, to be able to withdraw cash in a pinch, (2) Chase Sapphire Preferred - card with no FX fee, (3) Corporate Amex for charges I don't want to take on personally, (4) Starwood (SPG) card to amass a non-negligible amount of points on hotel stays. And maybe a 5th on which I'm trying to spend a large amount on quickly (for example - I might be planning to put $1500 on a random card with a big signup bonus, and it might be critical for me to get points I need for an upcoming reservation)

I of course have all of these loaded into my Coin, but each has failed enough times (forcing me to use the debit) that I started carrying the others as backup. Then I found myself carrying 5 cards....plus the Coin. And if Coin is targeted to users like me (who carry multiple credit cards, optimizing for different uses)....then what's the point?


Uber was the wrong example to use for this hypothesis - taxi companies in the US never really had driver employees to begin with.


> I would say why not improve the CLR support that has been there since SQL 2005?

Because it won't cause new license sales, whereas integrating R might.


If I was going to pick a relational database system, I'm not sure these would be the criteria I'd use:

CSV support - if you do that much CSV extract/transform/load (or indeed, any kind of ETL work), use an ETL tool. SQL Server comes with SQL Server Integration Services for that kind of thing.

Ergonomics of dropping and creating tables and stored procedures - the author's example is probably the toughest way I can think of to drop a table. It's easier to check sys.all_objects (which will catch anything - functions, views, procs, etc).

Operating system choice - well, in 2015, if you're going to mention that, you should be thinking cloud services anyway. They're both available in the cloud - and at which point, who cares what OS it runs on?

Goes on and on. I'm a SQL Server guy, and if I was going to make a list of how to choose a relational database platform, here's what I'd probably list:

* Up-front cost (license, maintenance)

* Ease of finding staff, and their costs

* Ease of finding tooling, and its cost

* Ease of finding scalable patterns (proven ways to grow it)

I don't think either platform is a loser on those counts - it's hard to go wrong with either one.


I mean you have a point on the OS, being in the cloud is a definite bonus. However caring what OS it's running on comes down to something he was brief about in his article. For me, I can manage an Linux server no issue with just a bash prompt, I can't honestly say the same about a Windows Server. Other people might argue Apache and running that on a Windows server is kind of pointless? I don't know, just spit-balling that one.

Obviously Windows would be IIS, which means overall the OS choice is a nice one. The fact that you can choose which one to host with, which means you get something comfortable.


> For me, I can manage an Linux server no issue with just a bash prompt, I can't honestly say the same about a Windows Server.

Have you seen Windows Core and PowerShell? An increasing number of admins are doing just that - it's how we work at Stack Overflow, for example.


I've used PowerShell quite a bit actually, even wrote a few script a couple years ago to work with Active Directory. I still can't see myself managing a server from there. I know configurations and everything are possible through it, like the registry and such. However config files are just so much more friendly to me. Which is probably why I would pick Linux on that. Permissions are also a little bit more basic and harder to screw up in Linux IMO.


It's try-able. But tell me how to setup and configure IIS ARR as a reverse proxy without using the GUI.

SQL Server is probably the best case, since the UI is a wrapper around TSQL and they expose the scripts at any point.

Then there's fun stuff. Like Invoke-WebRequest going super slow because it has a terribly implemented progress bar. That's right: out of the box, you can't download files with the shipped downloader, because it shows progress (like curl) and increases transfer times by a couple orders of magnitude. Come on.


Oh, do you work for SO Brent?


> Oh, do you work for SO Brent?

I just do SQL Server consulting for 'em from time to time. They're ridiculously sharp guys, so they don't need me much anymore.


Fully agree! This article is based on merits that I would hardly consider if making a choice between any relational engine. It is even more disturbing that the author claims to be a data analyst. CSV support.......R U serious? Who in the right mind would spend hundreds of thousands of $$$ for SQL Server Enterprise Edition licences and regret it because PostreSQL can do it better for free? I'm using both and they're both great but not for or in spite of the reasons outlined here. Author needs to educate herself/himself better before publishing this nonsense.


> CSV support - if you do that much CSV extract/transform/load (or indeed, any kind of ETL work), use an ETL tool.

Why? CSVs are portable and much easier to deal with (when exported correctly, which PostgreSQL does and MS SQL does NOT).


Yes. I have seen more than few 100k+ employees companies using CSV for data transfer between their internal systems.

They were usually processed using Oracle external tables though.


Can you drop a recommendation for your favorite startup-friendly ETL tool?


Pentaho if you have no or little money or SSIS (comes with SQL Server licence)


SSIS is the most frustrating, worthwhile bundled app I've seen. It's gotten significantly better but for what is essentially a giant XML writer they sure do like to hide all the options and configurations. I love the API though, so handy.


I don't think so. I used it since it was DTS, not SSIS and whilst Informatica is better at all things ETL, SSIS is great for what it can do out of the box. Besides, if it can't, you can always do it via custom C#or VB extension.

Just finished a multi-terabyte data warehouse project where all data is loaded using SSIS and ControlM and it works great! The dev process was also easy and trouble-free.


I can't tell if I know you now...

Anyways, yes, it's very powerful and an excellent tool but I always have to describe it as awfulsome. SSISDB has made great improvements to the setup and promotion of objects which previously could be a pretty big headache (especially when you're not the one deploying etc). Functions for the various tasks/settings can be hidden and it can take a while to convince newcomers that the options are available, you just have to...poke around a bit. It comes with a substantial amount of controls.

The metadata/conversion of data can be frustrating but automation greater improves this with a quick controlling framework and the sys tables, it also makes moving data across hundreds of tables a breeze. It is very fast and very stable and I'm glad it's getting improvements and having focused development.


I tried Pentaho, but our ETL tasks are being written by engineers (at least right now), and it seemed much clunkier than just writing ruby scripts. Is it worth it in the long run?


If you just need to move data from A 2 B than no. If your transformations are complex and will grow overtime than yes, the time and learning curve are justified IMO.


Met one of my two co-founders during a project. In a room full of argumentative type-A personalities, she was the only one building bridges and moving the project forward. That really stood out for me as a huge asset in any team.

The other co-founder and I met in a hallway at a database conference, then tried our first startup a few months later. It failed - but it was so much fun failing with him that I figured we should keep trying on other projects because at least failing wouldn't feel bad.


As a small business owner who's done a few successful casting calls, the problem with this article comes down to their first answer:

> Yes, you have quantity, but what about quality? How much time will you spend sorting the wheat from the chaff? How much application spam will you have to review and dispose of? And of the relevant ones, how many under- and over-qualified candidates do you need to sift through because they lacked the vital piece of information that is a salary range?

It's easy: filter the incoming candidates based on who you want to hire. Send your favorite candidates a simple email saying what you want to pay for that position, and ask if they're still interested. Interview the ones that are. (This way, you're not posting the salary number to the public, but you're still filtering candidates quickly and respecting their time.)

If none of your favorite candidates are interested at your targeted price, there's your answer. Either lower your standards and take one of the other applicants, or ask all of your favorite candidates what number it would take to get them interested. (No interviewing - you don't have the right to take up their time until you can come up with the money - you're just asking for the salary number they would need to even step into an interview.) When the numbers come back, that's what it would take to hire your favorite candidates.


This only works if the candidates still apply. A lot of the time I choose not to apply for roles without posted salaries, because there's a good chance I'm either over- or under-qualified for the role. Applying to a job takes time and effort to do properly (and it's worth doing properly).

As other people have said, you can post a range rather than a single number, and that number doesn't have to be 100% ironclad - if a range is 5-10% out for me, I'd probably still apply and try to negotiate - but I'm not going to waste my time applying for jobs only to find out they're offering £50k if I want £100k.

Check out the jobs posted here: http://oxfordknight.co.uk/jobs/

They all have salary ranges, many are quite broad, but it communicates quite clearly the level that both parties should be thinking about when entering into negotiations. So much more useful.


This is the opposite of how a lot of hiring managers I know think.

The tactic they use (how can anyone think this is a good idea...) is to hope by the end of the interview process the candidate will be so attached to the position (or invested at this point! see: throwing good money after bad, or the sunk cost fallacy) to refuse! Or maybe they'll just ask for 5k more, or something.


I have to disagree with this. If you don't do your market research ahead of time and reserve enough space in the budget to close a deal with the person you want, you are wasting the time of everyone who could close such a deal elsewhere.

They are not wasting your time. You are wasting theirs. The candidate cannot reasonably determine how well your company is able to monetize their skills ahead of time. It's the employer's job to figure that out, and offer a reasonable fraction thereof to the employee. The employer should know that the position will be profitable, otherwise advertising it as permanent would be a misrepresentation. If you don't know how technical professionals will make you money (or cut your costs), and to what extent, you have no business hiring them.

That's why whenever a company starts to discuss salary before their goals for the unfilled position and my qualifications, I back away.


I would respect a company significantly more if this is how the negotiations started. It addresses their need to determine if their range is on par with the market rate, and it allows both parties to minimize wasted time if they aren't.

Sadly I rarely see this happen in practice. It would be nice to see studies about how this affects the average cost to recruit a new employee.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact