> 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.
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.
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?
>> 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.
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.)
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.
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 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?
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.
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.
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.
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.
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.
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.
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.