Updating classic workplace sabotage techniques - <AUTHOR> http://www.antipope.org/charlie/blog-static/2016/05/updating-a-classic.html <comment><USER2> I'm a career changer from actuary to software developer. The most shocking part of the career change was open office arrangements.

Both careers are technical and require both concentration and collaboration. Actuaries tend to have their own cubicles (offices for mid-level and higher).

Software developers require much more concentration. So I just assumed that the virtually all software developers would have their own offices because a solo cubicle seemed inadequate for most developer jobs. And of course, who would be dumb enough to use open office for developers? ... well, I got a little surprise.

Everyone tries to undo the damage of a bad floor design with expensive headphones, but it's just not adequate.

<comment><USER3> [http://www.cs.virginia.edu/~robins/YouAndYourResearch.html](http://www.cs.virginia.edu/~robins/YouAndYourResearch.html)

 _Another trait, it took me a while to notice. I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don 't know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important. Now I cannot prove the cause and effect sequence because you might say, ``The closed door is symbolic of a closed mind.'' I don't know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing - not much, but enough that they miss fame._ \-- Richard Hamming

<comment><USER4> It's slightly amusing that everyone seem to miss the huge difference between:

        A. Individual office with open door
        B. Open plan office

I'd imagine the ideal would be individual offices with no doors:

This would create a good enough sense of intimacy and would be obvious to people that when they pass the space of you non-existing door they are entering _your space_ so they should have _a reason to do it and you acceptance._ And of course, having an actual _separate_ ceiling atop your office is important - the visual part matters, we need the feeling of "private cave" even if we agree to share it most of the time. And open space above only brings anxiety and makes you feel that you are in an open savannah and a predator can jump at you from behind the bushes anytime.

But of course, we live in a _plentiful_ age, _obsessed with efficiency_ (oh, the bitter irony of the contradiction...), so all that _wasted space_ and _extra paid on rent_ because open-office spaces are probably cheaper is a no- no...

<comment><USER5> _It 's slightly amusing that everyone seem to miss the huge difference between: (A) Individual office with open door (B) Open plan office_

Exactly. And Hamming didn't work in an open plan office at Bell Labs. The fact that he writes about open vs. closed doors implies that they had offices with doors.

 _" I'd imagine the ideal would be individual offices with no doors"_

Doors are very useful to have, even if they remain open most of the time:

\- Closing your door allows you to have a meeting with a couple of people in your office without disturbing your neighbors.

\- If you manage people, you'll need to be able to have private conversations with them (e.g., performance reviews).

\- Sometimes, you really need to concentrate on a difficult problem without interruptions.

\- You'll occasionally want to be able to have private, personal phone conversations, e.g., with your doctor.

<comment><USER4> > Doors are very useful to have

Then I'd use them as some kind of status token, to gamify things a bit. Mangers would have offices with doors by necessity, for private conversations with employees etc. And for the rest, if you are a lead developer, or tech lead or senior developer, than you get a door added to your office. Otherwise the hinges stay, but no door... like a hint of "when you'll get better, you'll get that door" :)

<comment><USER6> An "incentivise the workforce through privacy deprivation", eh? I'd probably take it a step further - open plan toilets. Some employees spend far too long on the John. You can't stop them from going, that would be gross and impractical. But you can use social engineering to help them remember they are there to _work_ and to do so _collaboratively_.

I can't tell you how much time I've lost to the porcelain throne! (I never measured it) but I do know that I want to get ahead, and when I get to do a crap in a cubicle with a door, I'll have _made it_!

P.S. This is why wifi and laptops are so great. A lot of thinking time can be had on the dunny. To really get your creative juices flowing, encourage your employees to think about direction on the bog. You could get your next Gmail there. Think of it as 10% time, without need to allocate the 10%. Your employees will thank you!

<comment><USER7> Or just kill two birds with one stone and swap all of their chairs for toilets!

<comment><USER6> The CEO could be given a squatty potty instead of an executive chair. It's doable.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> 1) Promote based on tenure. If they found your company first, they're a priori more dedicated and therefore better qualified to lead.

2) Promote into/within people management roles based on their skill as an individual contributor. E.g. the better the programmer, the better they will be at managing programmers.

3) Create a set of company values vague enough to be meaningless. Enforce them selectively and only when convenient.

4) In the name of inclusiveness, expand meeting invitations to anyone who could possibly be affected by anything talked about. Refer to them as stakeholders. Be sure to include anyone whose job is unrelated but may be interested or have an opinion.

5) All goals should be subjective. The subjective meaning of the goal should change based on timing, external factors, mood, or self-confidence. If you aren't happy, someone (else) is doing something wrong and you should immediately switch directions. This is especially important in hiring.

6) In all meetings (see 4), require consensus.

7) Set individual performance metrics based on effort. Strong indicators:

\- Individual sends emails late at night

\- You see individual in the office late at night/early in the morning

\- Individual speaks frequently in meetings

\- Individual always seems so busy

8) Hire based on pedigree, especially from names you know. If they did not attend the Tier 1 school (Stanford), they're probably not an A player.

Recruit from companies with entirely different problems from your own. For example, if you're a small startup, target executives at Google so they can make you into Google. If you're a large company, acquihire small startups to inject agility and hunger.

<comment><USER9> Great list.

Some general commentary: companies don't get this way because people are stupid. They get this way because people hyper-optimize for their own self- interests. Everything on this list is a way to show off, suck up, or CYA, all of which occurs because people want to stay employed and get promoted, and they implicitly optimize for more immediate, local rewards like positive social feedback from the colleagues they see on a daily basis.

Abstract and macro-level concepts are difficult to grasp and people have soft, differing opinions on them. However, people who work with you daily will come to "know" that you're a super hard worker if you're sending out emails at 4am. Including the company's Controller in a database schema design meeting not only gives you a chance to demonstrate your know-how to someone else in the organization, but also wins points for being careful, considerate, and cautious.

When promotion time comes, the less-visible heads-down coder who's been working hard and churning out bugfixes gets a lot less credit than his more boisterous, gregarious counterpart, who's been more focused on grooming personal biases in his favor than actually plugging in commits.

In theory a good corporate leader is supposed to make sure this kind of stuff _doesn 't_ happen, but they're only human, so really 99% of people operate this way.

What it translates to is that if you want to be a successful employee, remember ABC: Always Be Campaigning. Your primary job duty is popularity.

<comment><USER10> That is why focusing on the performance of the team is probably a better idea.

</comment></comment></comment><comment><USER11> A lot of these read more like workplace complaints and poor management processes. The point of the original was how an individual already on the system could perform small acts of sabotage.

My list would be: 1) overestimate small tasks 2) Corollary to #1, underestimate large tasks 3) Find reasons to take the overestimated tasks and perform them slowly 4) Encourage your colleagues to take the larger tasks 5) Encourage bike shedding. Frequently evaluate your code standards. 6) If you are in the position to do so, enforce a terrible naming standard. 7) Write slow tests 8) Write useless tests 9) If you notice a coverage gap, try to introduce a subtle bug

As a manager: 1) Discourage specialization in favor of "flexibility" 2) Assign tasks to those with the least domain knowledge, within reason 3) Avoid letting more than a single developer work on a particular system/increase the "bus factor" 4) If you are able, under promise and under deliver 5) When brought new ideas or are asked to use new tools, be very encouraging but say you need approval. Never ask for approval.

<comment><USER12> The upvote button wasn't enough for me. Thank you for extending the ideas of that work place sabotage concept for modern tech work, like Stross implied he would. I'm not sure what to really learn from this sabotage idea, but your comment pointed out many of the obvious flaws in how things are done currently.

</comment></comment><comment><USER13> Am I the only one here who doesn't understand posts like these? Anyone who's had a job or read a Dilbert comic once or twice can come up with lists like these.

The difficult part is doing all of it right.*

Look, I appreciate the history here, but nothing in the article ties back to actual planned sabotage. Do companies actually do this? Are top managers paid by competitors to break the companies they run? I mean, nearly all items on this list require C-level executive powers to effectively implement.

In all honesty, it feels to me like this article is more about how happy Stross is about his career change than anything else. That's a perfectly good topic, but can we turn this around? What's good, actionable, advice for (aspiring) managers, founders and employees? What's the oppposite of active sabotage? And can we encourage active, constructive anti-sabotage without becoming a creepy cult?

*) HN used to have lots of submissions about how to run companies right. Is it just me, or have those disappeared somewhat?

<comment><USER14> > HN used to have lots of submissions about how to run companies right. Is it > just me, or have those disappeared somewhat?

I interpreted this as being one of them.

<comment><USER15> How? He provides no tips or guidelines for what _to do_ , only some snark about what _not to do_.

<comment><USER16> "Do Not Enter" street signs are useful.

</comment></comment></comment></comment><comment><USER17> My problem with posts like this is that it's a vehicle for bashing the currently accepted practices.

Here are a few of my favourites in no particular order:

* Stand ups are bad - Let's be frank, I'm belting out code so quickly that staying on the same page as everyone else is just not worth the time anyway (at the speed I'm going it'll be done tomorrow anyway).

* Pair programming is bad - when was the last time _I_ caused a bug, right? Or for that matter hit a problem I couldn't solve, and wasted time having to research the solution. Never, right? Right...ohhhh look at the cute picture of my niece on Facebook.

* Open plan offices are bad - I'm super important to the company, the company would break if I went away. I'm so much of a star that I should have the best office. Not to mention, I need somewhere to put all my trophies.

* Meetings - don't get me started on meetings. BAN THEM ALL. There must be a better way to communicate? Email? Ummm, yeah Email, wait, no, I'll come back to email. I know, lets just have someone decide on the direction we're going to go and write it on a stone tablet, that'll save some meetings (I'll get started on the tablet right after I finish here). I mean lets think about it, why do we need to coordinate anything? I'm the rockstar and if you just leave me to belt out the code it'll all come together...what do you mean other parts of the business need to do things to get ready?

* Emails - I get too many of them. For stupid things too. Ops alerts, customers asking questions, internal announcements, travel itineraries. Being included on email chain discussions about direction? Who needs that. What do you mean you made a decision without consulting me? Now we have to start over with the direction _I_ want to go in.

And I'm out of time. Off I go to my lean, agile, open plan job.

<comment><USER18> >Stand ups are bad - Let's be frank, I'm belting out code so quickly that staying on the same page as everyone else is just not worth the time anyway (at the speed I'm going it'll be done tomorrow anyway).

Could you elaborate on this? I find standups most useful when we're working on small widgets of feature work precisely because we move so fast. Standups keep the business side in sync with the code we're putting out (e.g. features x, y ready to release, expecting z next week). It gives them a tighter feedback loop in case they need to manage expectations or coordinate with other groups.

If we're working on meatier chunks that take longer then we back off to a pull model. When someone wants to know they ask, but daily standups aren't very helpful when updates sound like "Working on <huge_feature> for the forseeable future"

<comment><USER17> Yep agreed. I was finding arbitrary reasons to rag on stand ups to illustrate a point. You could absolutely write it the way you just said it and be even better.

</comment></comment></comment><comment><USER19> 1) Make people clock in. A local aerospace company used to make people clock in, which is bad enough, but they had to clock in at 8:42 because $BUREAUCRACY.

2) Have a small room for tea breaks. Split the workforce into two groups. Schedule one to end at the same time as the next one starts. (Teabreak for group A ends at 10:00 am; teabreak for group B starts at 10:00am;) This causes disruption and disgruntlement between people trying to wash up their cups and people trying to make their tea.

3) Allow some people to have cigarette breaks. Do not allow anyone else to have anything similar.

4) Occasionally drop in to the small room during teabreaks and have an important conversation, then allow that group an extra 5 minutes for their break but make sure the next teabreak group does not have that extra 5 minutes.

5) Observe what side of the desk people prefer to have their telephone. Tell them it's the wrong side, and that they must have it on the other side. Switch it for them. A surprising number of people don't just walk out here. The ones that stay? YOU HAVE BROKEN THEM AND VICTORY IS SURELY YOURS. CONTINUE TO CRUSH THEIR SPIRIT UNDER YOUR BOOTHEEL.

6) Tell someone that you're going to give them a payrise if they meet some vague but easily achievable criteria. Then, when they've achieved that, tell them that you hadn't promised the pay rise, and that their 360 feedback is disappointing this month. Especially because they keep moaning about the generous pay.

There's probably plenty of good material in "Processed World" [https://en.wikipedia.org/wiki/Processed_World_(magazine)](https://en.wikipedia.org/wiki/Processed_World_\(magazine\))

<comment><USER20> [http://www.processedworld.com/Issues/issue29/i29down.html](http://www.processedworld.com/Issues/issue29/i29down.html)

Thanks for that link.

</comment></comment><comment><USER21> I declare false advertising.

Q: "How can we sabotage stuff?"

A: "Here's a bunch of stuff I think is messed up. Leave your own complaints in the comments."

I am disappoint. No creative sabotage ideas here, only observations of stuff already going on that we think is "wrong." Now granted, when looking for tips on how to fuck shit up, you can look at actual fucked-up shit and get ideas. But I guess I was hoping for something more creative. And yeah not the supposedly hilarious hahajoke that "Golly things are so messed up we can't even tell if they're inept or saboteurs," and not more complaints about "If only the world listened to my brilliant ideas about how to do things the 'right' way (my way)." If I had a dollar for every asshole with an opinion...

<comment><USER22> It's because to admit to themselves that someone would want to sabotage a technology company would be to admit something much more troubling.

There's no reason, in their healthy minds, why someone would want to sabotage their IT company.

For me, the real interesting question is why would someone want to sabotage my workplace.

</comment></comment><comment><USER23> A corollary to #3:

It is also the job of Human Resources to ensure that the company scores as highly as possible in the local business journal's annual edition of the Best Places to Work. Here's a link to an "anonymous" survey with a unique ID embedded in the URL. We strongly encourage you to fill it out.

</comment><comment><USER24> >"Programmers don't need root/admin access to their development environments. Marketing, however, need to be able to manage the CRM and should have global admin permissions across the network."

This!

Air gap developer workstations, have a formal procedure including a detailed approval form which must include a justification and must be reviewed and signed off by C-level for moving information/software between the outside network and the inside network.

<comment><USER20> Include clauses on the contract that forbid you from installing any kind of software on work machines, and at the same time provision work machines with a clean Windows 8 install. Not even Notepad++, it's notepad.exe for C# or violating the contract.

</comment></comment><comment><USER25> You don't need to sabotage competing tech companies. They sabotage themselves just fine.

\- Byzantine hiring practices. Create engineering teams that are 95% new college grads. They're the only ones who'll suffer your BS, while having no experience to call upon in challenging decisions.

</comment><comment><USER26> Pile on every cargo cult "quality assurance" technique until everybody keeps getting glowing performance reviews about how they helped implement the neat SWOT matrix that pointed to the need for better performance reviews whose consequence will make clear the path to even better SWOT matrices that will discover that more extensive performance reviews would result in...

<comment><USER16> I call this work about work.

</comment></comment><comment><USER27> Researching leaked/de-classified governmental documents can be incredibly interesting, especially if its from a 3 letter agency. Tons of practical techniques can be gleaned from studying the content or citations, which is easily translatable from warfare/diplomacy to layman personal/professional interactions.

A basic analysis of a selection of the NSA/GCQH leaks showed a significant number of citations to various marketing textbooks and public research papers.

</comment><comment><USER28> If someone was actively subverting an office it would rapidly kill a company.

Maybe this is the point, but to me all the comments and even article itself read more like a commertary on common issues than an subversive insider attack.

<comment><USER29> I think the key is, small acts of sabotage that could never be considered sabotage, so there isn't any chance of getting caught. Using a hammer that is to small or adding another technology to an already complex technology stack would never be considered sabotage. They likely wouldn't even be considered incompetence, especially in the latter case if the person who added another database/programming language/web toolkit/etc managed to achieve something with in in a short period of time.

Instead that person is a hero, and the costs associated with the decision are initially small and don't show up until that person is long gone.

Repeated a few times the small hits to productivity/quality/etc will result significant lost ground. This is probably even more important long term in the technology industry than it is to a war effort. The sides would have to be close to evenly matched and the war would have to go on a long time for all the little bits of sabotage to add up.

<comment><USER30> > latter case if the person who added another database/programming > language/web toolkit/etc managed to achieve something with in in a short > period of time.

This one bothers me. It's brought up all the time. And I completely agree that adding a new tool or feature adds risk and technical debt. But if there's no other way to do it... I work in a corporate VBA shop. 90 percent of our work in the last year was in VBA. But next year is looking like python, R and JS. How? Requirements changed. We got handed some projects in machine learning and we delivered, crudely but still. While in the technical sense we 'could' have coded it all in VBA it's not practical in the slightest to do so.

<comment><USER29> I don't think that is an argument against having a handful of technologies in any given stack. I think its more an argument against having a lot of similar technologies. For example, I wouldn't dream of trying to write a device driver in anything other than C, but I wouldn't try writing a web back-end in C either. OTOH, I promptly ripped out ~100 lines of perl one of our developers insisted on dropping into a bash script a month before he left. Turned out the bash equivalent was actually more concise and didn't require yet another dependency on top of the 4 major programming languages (not including bash) already contained in the project.

</comment></comment></comment></comment><comment><USER31> My favorite by far:

"Teams are better than individuals and everyone has to be aware of the valuable contributions of employees in other roles. So let's team every programmer with a sales person—preferably working the phones at the same desk—and stack-rank them on the basis of each pair's combined quarterly contribution to the corporate bottom line."

That is gooood.

I would quit, yet be so traumatized that my productivity would still suffer, even at my next job. A double win for the enemy.

</comment><comment><USER32> Heros that invoke long days to save the company from a crisis are well rewarded. The rewards are increased by a factor of two if the hero sleeps under their desk in an old, moldy sleeping bag. The rewards are tripled if the hero created the crisis him or herself.

Edit: typo

</comment><comment><USER33> >> we can go a step further and institute hot desking—we will establish an average developer's workstation requirements and provide it for everyone at every desk.

Oh, dont' we all wish. In practice, unfortunately, what's calculated is the average office worker's workstation requirements. Then the developer gets that, too, like everyone else.

<comment><USER20> 8GB of RAM ought to be enough for everybody.

Even if you need two instances of Visual Studio on a VM.

<comment><USER33> I was mostly thinking of monitor arrangements and how hotdesking messes with that.

For instance, in my old workplace at Small Company™ I had two 24-inch monitors. In my current (but only for another two days) workplace at Big Corp™ we're only allowed a single 19-inch monitor. Try running two instances of VS on _that_. I have to constantly Alt-tab between browser and IDE, or stack windows side-by-side, which is not optimal. Obviously, because we're not allowed to keep anything on our desks, we can't bring our own monitor from home. So.

>> 8GB of RAM ought to be enough for everybody.

And even that is not a given. Frex, in the last two years at Big Corp™ I had to run a lot of machine learning algorithms - those were for my MSc course, sponsored by my employer so it was OK to run during office hours. Now, my work laptop has 12 GBs of RAM and it's noticeably faster than my home laptop, with 8 GBs and a similar processor.

And the fact that my office laptop has 12 GBs is a happy accident. Normally you only get 4 GBs, 8 if you ask nicely. So I was going to ask for 8, but let's just say I got lucky and the person who managed my request for the new laptop didn't know much about RAM and suggested the 12-GB stick spontaneously (and obviously I didn't turn it down).

But that's just a silly way to handle this sort of thing. Big Corp™ can afford to give devs much more if it wants to. It just doesn't value them as highly as other staff, who get the goodies _they_ value highly.

</comment></comment></comment><comment><USER34> It's also a little irritating that a couple of commenters focus on minority/diversity hiring as a way to commit sabotage.

In my experience, people who might be called "minority" or "diversity" hires tend to kick ass, possibly because they have put up with so much cognitive bias about how they supposedly don't belong.

</comment><comment><USER35> Maybe this one is too obvious, but:

11) Ping ping tables and other noisy shit.

<comment><USER36> tabletop football is mandatory for hipness.

<comment><USER35> oh my god

</comment></comment></comment><comment><USER37> Disallow email export. Delete all email older than 90 days.

<comment><USER38> FRCP?

</comment></comment><comment><USER34> I'm disappointed that this list seems to be made with the intent of describing current practices, rather than how you can actually disrupt the workplace as a saboteur.

The idea of promoting incompetent people still works. That's a gem.

For the small hammer/big hammer, simply choose technologies that are less suited and make them work. Sorry, our CRM is also our mapreduce framework. Make security an afterthought, and the world will do your sabotage for you.

<comment><USER9> Surprisingly many get away with only rudimentary security controls. I have a client that absolutely _refuses_ to upgrade off Rails 2.3, even to the drop-in Rails LTS releases. Their "web director" keeps insisting that no one would want to infiltrate and that there's no damage can be caused by a compromise of Rails anyway.

The frightening incompetence of that guy is maddening. Incidentally, I don't think he was put in place to sabotage the company. Just a case of well-meaning nepotism.

</comment></comment><comment><USER39> I think the "sabotage" techniques suggested by the author actually benefit companies whose main product is built by intellectual labor. Companies care a great deal about controlling workers: to get them in line, to squeeze labor from them, to weed out motivated folks whose interests don't align with profit, to shut down rabble-rousers, etc. Since the dawn of work, workers have resisted working, and Agile, etc. are just the new strategies management use to control this new group of creative workers.

I wish the author had addressed worker sabotage too. More on that here: [http://thenewinquiry.com/essays/manual- override/](http://thenewinquiry.com/essays/manual-override/)

</comment><comment><USER40> Pick vendors that ship patches to their enterprise software as a 705 megabyte SQL file that must be run and files that must be manually placed on the machine.

You might think I joking, but I'm not.

<comment><USER20> That's child's play. Here's a much worse true story.

\- Spend a couple months researching existing solutions for a complex product \- Pick the "perfect" one \- Ask for a quote \- Recoil in horror at the price (about 1 weeks pay for that decision maker, in a 100+ people company) \- Steal the damn JS library from their demo page \- Use it on the product \- ... \- Profit? Once they can sell this turd

</comment></comment><comment><USER41> I went through the second list and got a perfect 10 for one of my previous positions and an 8 for most of the others. This is as realistic as Dilbert.

</comment><comment><USER42> Give everybody in the company local admin rights. This will give all staff the ability to experiment and learn more about technology. Since everyone now has local admin and they can now manage their own computers, you can fire the IT staff who previously managed these workstations.

<comment><USER36> This sounds like it will result in a better environment that there is in many places. I have seen places with a strict "don't install anything policies" far to often. (I have even seen terms that techincally forbade executables in the home dir. For programmers.) Don't use anything you like. Or want. Or could use to work more productive. Use the outdated debian version of the shitty software that the benevolent admin choose for you. And good forbid you BYOD. Or want to the admin to install anything else. Fist of all, the admin knows best, second it's not in the debian repos.

Given you have backups and ensure they can't fiddle with the authentication system: Go for it. It's like BYOD but with provided hardware.

<comment><USER42> We give our people who have reasonable need Local Admin.

Giving local admin to the non-technical staff who want to download 'free' software (not FLOSS, free as in beer) because they think (at best) that they are saving the company money, but instead infest their computer malware. Most people are totally disinterested in their computing environment, let alone managing it. We standardise on certain packages because there is utility in having common programs from support, training, and administration points of view, but ultimately if there is a good reason to get/use something else, we will do that.

Furthermore, any user with a local admin access can use a Kerberos 'Golden Ticket' leverage attack to gain full domain access across the entire realm.

Are you seriously telling me that you want the teller at your bank to have local admin access to his workstation?

How about the person at the IRS/CRA/HMRC/<you government tax office> that you just called?

Local admin has its place, and certainly the first test is that will the person endanger their system by running dubious programs. The next question is if that person does infect their system, can they clean up the mess themselves?

We went from a situation where we had local admin across our estate where we had at least one virus problem a week to one where I can not remember the last time we had one. Finally, can you really trust a Windows workstation after it has had an infection?

</comment></comment></comment><comment><USER43> Is my job being taken down by the cia? So many meetings and rules! This list is epic I would expect mike judge to write t for Silicon Valley. As for its usefulness in the real world the opposite of each rule should be shown to all management as what to do.

</comment><comment><USER44> Fortunately, someone already wrote the corresponding guide for software developers: [https://github.com/Droogans/unmaintainable- code](https://github.com/Droogans/unmaintainable-code)

</comment><comment><USER10> I wonder if there are companies who pick CEOs randomly from new MBA graduates, and pay them an extremely high salary with no stock options or other incentives. Or pick CEOs randomly from resumes submitted and trains them to be professional CEOs.

</comment><comment><USER45> As a sysadmin, I have long thought that the most effective workplace sabotage I could do would be not to question anything I was told to do. A huge chunk of my job is suggesting when things are in fact a bad idea.

</comment><comment><USER46> I'm weirded out by not seeing Intel mentioned here, as being the inventor of cubicles, hotdesking, and failure to be in mobile business while having the best phab tech out there.

</comment><comment><USER47> See also [https://en.wikipedia.org/wiki/Bureau_of_Sabotage](https://en.wikipedia.org/wiki/Bureau_of_Sabotage)

</comment><comment><USER48> It's scary how many of these policies my company follows...

</comment><comment><USER49> I'd rather have a closed door and office and a company wide IRC server.

</comment><comment><USER50> 1) Everything which doesn't have a rule should have a rule.

It applies to the kitchen policy, to the bathroom policy ("Keep the toilets clean"), to the password policy. Initiate a company discussion to get feedback, the exclude the black sheep.

2) Spread rumours about how the dept/company/sector is cutting jobs. It is very important that employees feel they're in surplus so they'll work more. Keep them upset about things, so they'll focus on that instead of programming.

3) Promote women. Don't help men to succeed or learn things.</comment>


Why the Navy Misses the Old F-14 Tomcat, Despite All of the Problems - <AUTHOR> https://nationalinterest.org/blog/buzz/why-navy-misses-old-f-14-tomcat-despite-all-problems-30367 <comment><USER2> As a former F-18 pilot, I don't think v2 of the Tomcat is what we need. Unmanned missile trucks are the future. The Joint Strike Turd should be the last manned fighter. The services are bankrupting the country with the current crop of do-it-all aircraft. Other countries are on a better track adding the latest tech to older airframes and accepting their expendability. Carriers themselves should be phased out for smaller more expendable ships that can launch and recover the missile trucks.

<comment><USER3> > The services are bankrupting the country

Superficially, it feels like the crux of the problem is that "supporting the troops" has been subverted to mean not questioning civilian-driven military policy. This has given them carte-blanche lest anyone be accused of not supporting our boys.

(It's possible to be against a war (and the policies and politicians that set that course) while still honoring/supporting soldiers and their family.)

<comment><USER4> Military policy isn't civilian driven. The Pentagon drives the policy, as well as the weapons decisions. The surprise is when the civilians actually do exert some control--such as in preventing the USAF from scrapping the A-10, fighting the USAF on cancelling the the JSTARs recap, or when they force extra Littoral Combat Ships on the navy against their will :)

<comment><USER5> > Military policy isn't civilian driven

Except when a congressman from Ohio decides that they need more tanks so that he can keep his voters employed [1], despite the army saying they have plenty and don't know what to do with them. They have literally thousands of tanks sitting in storage in the desert, and they're rolling tanks straight off the production line into storage.

[1] [https://en.wikipedia.org/wiki/Lima_Army_Tank_Plant](https://en.wikipedia.org/wiki/Lima_Army_Tank_Plant)

<comment><USER6> I followed the link and came down to 2010s where I couldn't understand the following sentence:

 _The army did not convince Congress that it did not need more tanks in 2011, so in 2013, Congress funded an additional tanks to be built at a cost of ~$270M._

Usually, the military provides requirement and the civilian administration provides the funds. How can the Congress order the Army to make more tanks when they don't need it? I am not an American, so probably I am missing the entire context here.

<comment><USER7> One of the troubles is that congress can't trust the army to admit the truth. Congress must guess.

You see, the army is controlled by the president. The president may be from a different political party or even be following his own personal agenda. The army must strictly obey orders according to the chain of command, and the president is at the top.

If the president dislikes tanks, he can order the army to place tanks into storage and claim that the tanks are not wanted. Congress is left wondering if the people in the army are stating their true expert opinions or just following orders.

Here is a real case that leaked out:

[https://www.military.com/dodbuzz/2015/01/16/general- praising...](https://www.military.com/dodbuzz/2015/01/16/general-praising- the-a-10-to-lawmakers-is-treason) [https://www.military.com/daily- news/2015/01/26/generals-a10-...](https://www.military.com/daily- news/2015/01/26/generals-a10-treason-comment-sparks-concern-protected- speech.html)

So yes, the military being ordered to lie to congress is a real thing.

<comment><USER8> What? No. In case anyone wants an update on this case from 2015, that general was fired. He was not implementing some sort of secret presidential policy with his remarks.

The A10 is an example of Congress imposing civilian priorities on the military. Despite its declining military utility, it's a popular plane, so Congress won't let the military sunset it. It has nothing to do with the president ordering the military to lie to Congress.

You're not even legally correct... while the president is the commander in chief, Congress has oversight of military spending under Article I, Section 8. An order to lie to Congress about spending would be an illegal order, and military personnel are not compelled to follow illegal orders.

<comment><USER7> He was fired, though that isn't proof he got in trouble for what he was doing or that he wasn't ordered to do that. He did things in a ham-handed way and it leaked, causing a PR disaster.

The F22 looks to be a similar case. Here we don't have a crude effort getting leaked, but that doesn't mean the situation was any more legitimate. It very much seems that Obama was pushing to kill the F22 and the military marched to his orders.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I'm not sure that a replacement F-14 is thinking big enough here. David Wise's post in War is Boring, "The U.S. Navy's Big Mistake — Building Tons of Supercarriers" ([https://medium.com/war-is-boring/the-u-s-navy-s-big- mistake-...](https://medium.com/war-is-boring/the-u-s-navy-s-big-mistake- building-tons-of-supercarriers-79cb42029b8)) puts forth a strong argument as to why the U.S. Navy needs a paradigm shift from carrier groups to increased funding for drones and submarines. Carriers are an extremely costly asset that are also vulnerable to cruise missiles (and those missiles are getting much more advanced).

<comment><USER10> When your usual target for a beat down is a third world country that has no real way to defend themselves against your attacks, strategy matters very little as does the ability to simply deploy your weapons quickly and easily.

<comment><USER11> That sort of thinking dismisses the real threats.

We have a maginot line floating at sea.

<comment><USER12> >That sort of thinking dismisses the real threats.

Does the USA really have any threats that aren't just the USA being on the offense?

<comment> King-Aaron China.

It would be a folly to dismiss it.

<comment><USER13> China is massively invested in the US. It's hard to imagine any war scenario being worth the cost.

<comment><USER4> And its decoupling now. See: Trade War.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I am constantly amazed that Iran manages to keep some of their F-14s airworthy decades after the US stopped supplying spare parts and knowledge.

Seems to me that they have worked out how to manufacture certain parts themselves, or are getting them on the black market somehow.

For all the F-14s many faults, at least it proved to be a serviceable aircraft that proved itself in an actual dogfight situation. Our own RAAF is slated to receive F-35s soon, but I recall last year during an airshow to display their capabilities to the local crowds, the aircraft could not return to their home base to land and had to be diverted to an alternate due to... light rain.

Fair enough the aircraft were not certified for flight into inclement weather yet, but it strikes me (pun intended) that the new generation of aircraft are far more sensitive to issues like these than the older generation aircraft that could be flown while held together with sticky tape and chewing gum.

<comment><USER15> There was an airshow recently in Toronto and all aircraft (including F35) stopped flying because of a light rain. I guess it's a common precaution measure on airshows.

<comment><USER14> I understand about not flying a display routine in inclement weather, fog or low cloud (I am a former pilot).

In this case, then F-35 squadron had done the flyover at the actual airshow in clear weather and were returning to their temporary airbase several hundred miles away. They could not land back there due to the light rain over the base and had to be diverted to a dry base elsewhere.

</comment></comment></comment><comment><USER4> Top Gun notwithstanding, the F-14 was one of the biggest pieces of garbage the Navy ever fielded. Incredibly heavy, horrible E-M characteristics, expensive, crappy swing wing (a wing design that was in-vogue in the 60s but has now been discredited). Interestingly the Navy wanted to keep buying more and more of these until the Fighter Mafia foisted the F-16 on the air force, and the Navy reluctantly took a variant of the F-16 and blew it up in size and renamed it the F-18 (the F-18 variant was actually the losing contender to be the F-16). If it wasn't for the Fighter Mafia, the Navy would still be buying pieces of crap like the F-14.

Interesting that nowhere in this article are the capabilities of the F-35 STOVL variant discussed, a weapon that the Navy is paying $100M+ for. That they are skipping that discussion and jumping into why they need NGAD is just disgusting.

Oh well, the Pentagon is just a giant building that buys weapons. Always looking for the next piece of kit to blow cash on.

And just while I'm on this tirade...there are almost no use cases where you need an airplane that goes faster than Mach 2. At that speed you are outside the envelope where you can fire a missile. If you are trying to design a fighter aircraft as an interceptor, you are doing it wrong...

<comment><USER2> STOVL is the marines, and the shiniest of the Joint Strike Turds. And I think Boyd and the Fighter Mafia were actually wrong. For BVR air-to-air, I would have rather had an F-14/F-15 with phased-array radar and AMRAAM, than an F-16/18\. Although the F22 clubs them all like baby seals. The Vietnam lesson was only good until missiles improved. Now the war is between missiles and radar more than planes. And a fast missile truck is better than a slow missile truck. Mach 2+ would be nice after you've shot your load and are running away.

</comment></comment><comment><USER16> FYI, Canada was _very_ close to getting f-14s. (Canada made an offer on the F-14s sold to Iran.) Had that happened, no doubt Canada would still be flying them today.

The 14 had range and speed, but using those abilities was very difficult. Midair refueling is headache on a carrier. The faster and further the 14s had to go, the more tanker aircraft had to be launched. They were great for fleet defense, sticking close to home, but were ill suited for escorting bombers on long ground attack missions. So as cold war battles on the high seas were replaced by pocket ground wars, the 14 lacked purpose.

The 14s weapon system, the phoenix, would not be acceptable today. It was meant for downing incoming waves of bombers over open ocean, where the enemy is clearly identifiable. It wouldn't work well in a mixed environment such as over Syria. So the 14 would need a new missile/radar to compliment its speed/range.

<comment><USER17> > The faster and further the 14s had to go, the more tanker aircraft had to be > launched.

Speaking of crazy refueling, does anything beat the Vulcan raid during the Falklands war? 13(!) tankers supporting one bomber going from Ascension to Port Stanley and back. Not only tankers refueling the bomber, but tankers refueling tankers etc.

Here's a documentary about the raid: [https://www.youtube.com/watch?v=PBJ99bIhAVk](https://www.youtube.com/watch?v=PBJ99bIhAVk)

All this massive effort, and in the end one single bomb out of 12(24?) managed to actually hit the runway.

<comment><USER17> Correction to myself, 11 tankers and 21 bombs.

</comment></comment></comment><comment><USER18> Good article on this subject from Naval Institute Proceedings.[1] Non-carrier surface combatants with missiles can be more useful than carriers against an enemy that can fight back. There are just too many long-range weapons an advanced enemy can shoot at a carrier - cruise missiles, anti-ship missiles, ballistic missiles, long range torpedoes. Some of those will get through. China, of course, has been investing heavily in land-based anti-ship missiles. Those arrive from almost straight up at re-entry speeds, too fast to shoot down.

[1] [https://www.usni.org/magazines/proceedings/2018-09/use- carri...](https://www.usni.org/magazines/proceedings/2018-09/use-carriers- differently-high-end-fight)

</comment><comment><USER19> The article misses an important point - the brand. There was never an aircraft before or after F14 that did so much for the Navy in terms of branding as Tomcat did. Every kid in 1980s wanted to fly one.

<comment><USER20> In the 1980s, i wanted to fly an F-4 Phantom. I suppose i was retro before that was cool.

<comment> King-Aaron I still have a real soft-spot for the Phantom, as a kid growing up the RAAF used them (along with the F-111's). I remember seeing one pass overhead pretty low while we were out on the boat fishing, and immediately made me want to go down an air force career.

Then I went blind and decided if I couldn't fly a jet, then meh, I'd do something different.

</comment></comment></comment><comment><USER21> It sounds like what the Navy misses isn't so much the F-14 as the AIM-54 Phoenix ([https://en.wikipedia.org/wiki/AIM-54_Phoenix](https://en.wikipedia.org/wiki/AIM-54_Phoenix)), the long-range air-to-air missile paired with the F-14 that let the Tomcat knock down airborne threats much further out than the F-18 can.

<comment><USER14> Pity the Phoenix was never tested under actual battle conditions. Even the shoot down of the Sukhois (which inspired the opening scene of Top Gun) was done with the older AIM-9 Sidewinders.

Interesting proposition, but I don't know how effective BVR air to air missiles would have been?

<comment><USER13> Isn't the problem that one rarely operates under RoE where BVR missiles would be permitted? Particularly in these days of mostly-counterterrorism, hitting the wrong target is worse than not hitting at all.

</comment></comment></comment><comment><USER22> The F-14 wasn't a multi role plane though right?

I thought that was one of the issues, and would still be an issue today wouldn't it?

<comment><USER23> It was single-role for the first half of its life due to Navy policy. From 1992 onwards it was modified for multi-role, see 'Bombcat'.

</comment></comment><comment><USER24> Because people like being able to hum "Danger Zone" while they are flying

<comment><USER25> Lanaaaaaaaa!

</comment></comment><comment><USER26> The entire air force and navy are sitting ducks and totally obsolete in the face of a somewhat modern cheap drone air force and antiship missles, to say nothing of naval and submersible drones.

<comment><USER27> As long it is not submersible CIWS can shred pretty much anything to pieces: [https://en.wikipedia.org/wiki/Close- in_weapon_system](https://en.wikipedia.org/wiki/Close-in_weapon_system)

<comment><USER28> Those drones will swarm in with volumes. CIWS may be effective taking out dozens of them but what if the came in hundreds or thousands?

> the best unclassified study we have suggests that if eight small drones > attack an Aegis-equipped destroyer - which has various AA missiles as well > as Phalanx - it would get about five of them. However, this is crucially > dependent on the exact speed, size and stealthiness of the drones involved > > [https://calhoun.nps.edu/handle/10945/28669](https://calhoun.nps.edu/handle/10945/28669)

CIWS need to find a way to scale. Maybe a grid?

</comment></comment></comment><comment><USER29> I'm so confused, we already spent how many billions on the F-22 and there is no carrier capable version that outperforms the F-18? How on earth did that happen?

<comment><USER30> The F-22 is an air superiority fighter that was always intended for exclusive use by the Air Force. There was never a plan to have a carrier based version of the F-22.

Perhaps you mean the F-35? There are two carrier based variants - the F-35B and F-35C. The B is a STOVL and the C is designed for takeoff and landing on carriers. Both variants are still in testing, and I believe the C is closer to operational than the B at this point.

</comment></comment><comment><USER31> My first job out of college was as a software developer on the F-14D project, and the AIM missiles.

It was probably the most interesting job I ever had.

We programmed in CMS-2 and AN/UYK assembly language

<comment><USER25> Wow, that's cool.

Assuming you are allowed to, could you share some more info?

How did you program AIM missiles for following heat signatures, was it a case of reading bits from the IR sensor?

Did missiles logic have exceptions e.g. FuelRanOutException, IRSensorUnresponsive?

</comment></comment><comment><USER32> Well DUH.

Two words: TOP GUN.</comment>


Introducing Strongbox, a Tool for Anonymous Document-Sharing - <AUTHOR> http://www.newyorker.com/online/blogs/closeread/2013/05/introducing-strongbox-anonymous-document-sharing-tool.html

<comment><USER2> I am really sorry to criticize but:

My eyes are not good and I find that infographic impossible to read.

Something about the red rectangles and the contrast and alignment makes it impossible for me to focus on the text.

Would it be better just to have a Visio-esque flowchart with directed arrows ?

<comment><AUTHOR> New Yorker generally don't have any experience with creating infographics, so this is probably part of the reason why it is so bad. I transcribed it for you:

1\. Access the Tor network

2\. Upload and submit your files or messages. You'll receive a randomly generated code name.

3\. The files are encrypted using P.G.P. (sic) and transmitted to a server separate from the rest of the Condé Nast network.

4\. _New Yorker_ editors check the dedicated Strongbox server for enw material, using a laptop with a V.P.N. connection.

5\. _New Yorker_ editors download the encrypted files to a thumb drive.

6\. A second laptop, not connected to the Internet, is booted up from a live CD and erased each time it is powered on.

7\. A second thumb drive, containing P.G.P. decryption keys, is connected to the laptop.

8\. _New Yorker_ editors plug the first thumb drive into the unconnected laptop, download and decrypt the documents.

9\. _New Yorker_ editors will be able to send you a response. This message will only be visible if you return to Strongbox and use your code name.

<comment><USER3> I would assume PGP is correct as written: <http://en.wikipedia.org/wiki/Pretty_Good_Privacy>

(Not to be confused with GPG, which is an open source implementation of the same protocol).

<comment><AUTHOR> I was just referring to the classic New Yorker style of putting all the periods in the acronym. :)

Shame there wasn't an excuse to use a diaeresis.

<comment> jack-r-abbit Interesting that they didn't feel the need to write "C.D." though. I guess that one has been around long enough that it no longer is viewed as an acronym?

</comment></comment></comment></comment></comment><comment><USER4> It's pretty goofy.</comment>


The only GitHub repo with a reserved name - <AUTHOR> https://github.com/bmaland?utf8=%E2%9C%93&tab=repositories&q=.&type=&language= <comment><USER2> I don't see it...

<comment><USER3> The name is "."</comment></comment>


Here's why NYC got 212 area code and San Francisco got 415 - <AUTHOR> http://us1.campaign-archive.com/?u=2889002ad89d45ca21f50ba46&id=e6329273cf

<comment><USER3> Their illustration of a rotary dial phone has * and # on it!

They also don't realize that 411 and 911 were originally 114 and 119 and were changed when long distance direct dialing was introduced and 1 became the code to introduce it.

</comment><comment><USER4> Only recently (relatively) has Nevada gone from a state-wide code of 702 to 702 and 775.

Additionally - by the last paragraph, why then would San Jose have a 408 - <USER2> by their facts only states with a single area code for the state had 0 as the second digit?</comment>


Are Tech Companies Overvalued? Top Investors Think So - <AUTHOR> http://techcrunch.com/2014/05/15/tech-company-valuations/

<comment><USER2> Examples: WhatsApp...~$19B, very little revenue.

Snapchat (almost bought by FB) for $3B, zero revenue.

</comment><comment><USER3> Well duh.... 40x revenue for airbnb...</comment>


Onsets and Frames: Dual-Objective Piano Transcription - <AUTHOR> https://arxiv.org/abs/1710.11153 <comment><AUTHOR> Co-authored by Doug Eck, who was also featured in this excellent recent YC podcast

[https://blog.ycombinator.com/making-music-and-art-through- ma...](https://blog.ycombinator.com/making-music-and-art-through-machine- learning-doug-eck-of-magenta/)</comment>


Entry-Level Startup Jobs Are Now Mostly Dead Ends in the Boondocks - <AUTHOR> https://backchannel.com/those-entry-level-startup-jobs-they-re-now-mostly-dead-ends-in-the-boondocks-af3b4066f5dd?gi=c797a91ba23#.ipwqgrpop <comment><USER2> This article is a little hand-wavey. Customer support is definitely underappreciated in terms of its value. Support is the primary connection to your product's relationship with customers and a source of research as well as ambassadors for your brand.

On the other hand, the idea that employees doing one aspect of a company's work could count on being promoted to another area requiring different skills is not particularly common in most industries, pre-internet. Most people who regard doing support as an "in" need to either independently enhance their skills or choose to work at a much smaller company.

One of the sad things that this article exposes is that so many support people choose their careers with the same attitude this article criticises; that support isn't valuable or rewarding to them. Maybe this is akin to people going into teaching, which paradoxically tends to be a major with lower scores and grades than average. People go into a job where they help people not because it's exciting but because they think it's an easier path to working in tech than coding. Great support people committed to what they do can sometimes succeed and grow into more senior roles, and that path should be more rewarded.

<comment><USER3> Years ago there was an article or case study about a company who had rehomed their support under Sales to some success. I always thought that was a good way to balance things, where customer problems don't have to wend their way through IT/Ops to some meeting where pushback against sales may or may not occur.

<comment><USER4> When I worked in enterprise support, a significant part of my work was dealing with misrepresentations made by sales reps, so I can see where moving the costs of those problems back to Sales would be a productive way to create a disincentive to causing the problems in the first place, which is more efficient than having someone else cleaning up behind Sales.

</comment></comment></comment><comment><USER5> So Nashville with a population of darn near 2 million is "the Boondocks?" Am I missing that part of this that had something about a job in someplace that could even remotely be considered Boondocky?

<comment><USER6> You see, San Francisco is where the Internet _is_. You might think it's a globally interconnected network of computers, but in fact it's really all in one place, and so the further away from it you are, the less you can channel its power into disrupting markets.

<comment><USER7> Let's hope that this Silicon Valley chauvinism accidentally builds new SVs in places around the country, who can pick up once this one crashes.

<comment><USER3> SV stole the industry from Boston, and I think we can assume that if SV wanted to support remote organizational models that they would have done so more readily than they have. Best of the best, after all.

</comment></comment></comment></comment><comment><USER8> Well, outsourcing to Nashville is better than having entire work outsourced to India.

Though I must admit that having lived in Mumbai, Upstate New York and New York City, the cost of living is low argument is bullshit. It is just sugar coating the fact that your work/job profile is not important enough for the company to merit the benefits that living in a metropolis brings.

35K$ per year is a really very low salary, especially for SF, grad students earn more.

Also

""" It doesn't make any fucking sense to live in one of the most expensive areas in the country and work in nonprofit development," one told me."""

I think she meant cost-center, there is nothing related to non-profit in usual sense in that article.

</comment><comment><USER9> I know people who work in enterprise customer support, on expensive software applications, that are far more complex tickets than just refunds and bug reports. They make good money.

Another guy I knew moved from support into being a "sales engineer", which is basically helping to sell software to the more technically minded, demo it properly, assist with integrations, etc. That's also well-paying.

Bottom-line is, if you come out of college with an English degree and want to work in tech, you need to get your foot in the door somehow, and support is an option.

<comment><USER10> I guess it's akin to wanting to join the video game industry and getting your foot in the door through QA play testing.

<comment><USER11> Well, that's one alternative to learning to code, and taking on more hours for less pay than your peers. But at least you're making games, right?

<comment><USER12> Just finish play-testing that level than rerun the PM's comments about that new level design!

</comment></comment></comment></comment><comment><USER13> Why are ten year old billion dollar companies with back offices in other states still called startups?

<comment><USER14> Often they're even publicly traded billion dollar companies.

I'd like to propose the phrase "new-economy company" to replace startup.

<comment><USER15> Or "post-startup" or "previous startup" or "startup alum" (like YC alum)

<comment><USER16> or 'started' not sure if I'm joking

<comment><USER17> Brilliant.

</comment></comment></comment></comment></comment><comment><USER18> I hate that customer support in start ups is considered nothing more than a leg up into a "real" job. It may not be the best paid job in the organisation, but it's crucial and certainly shouldn't be paid at such a fraction of other jobs that "promotion" to another department is the only viable option.

<comment><USER19> Yup. Every startup bio story and advice hypes up how much you have to have good communication with customers.

It must be all those MBAs that flock to these companies that don't read up on HN.

</comment></comment><comment><USER20> I'm a part of Eventbrite's engineering team in Nashville. I'm really bummed about this article. I think it's a shame that Lyft told a whole department "leave SF or lose your job". I agree it's problematic for a company to segregate customer support in a satellite office. Neither of those are how Eventbrite handled their expansion to Nashville.

We're growing like crazy here across the business- engineering, finance, HR, support, sales... Yesterday we had a hot chicken lunch [0] to celebrate two new engineering hires. Tomorrow we'll christen some temporary office space to accomodate our newly-added sales team. Within a year, we'll be moved into a new space more than triple the size of our current office. Trust me, that's not because we're tripling the size of our support team.

Within engineering, my coworkers in Nashville come from a number of different backgrounds, Many of them are experienced devs. Others are career changers via coding bootcamps. Most relevant to the article, some have come from our customer support team. People tend to stay at Eventbrite for a long time [1]. There may not be as clearly defined a career path as you'd find at a more established company, but you're not stuck doing the same thing forever.

[0] It's a Nashville thing. If you haven't had it here, you're missing out. :-)

[1] Although you see the real tenure in the original SF office, in Nashville no one in engineering has quit yet (if you don't count the guy who left for Y Combinator, then came back afterwards).

</comment><comment><USER21> >Another customer service worker I'd talked to from a big software company decided that if she wanted to stick around the Bay Area, it was time to teach herself to code.

Just curious. Is that going to help her get a job in Silicon Valley while competing with grads from top schools for the same jobs?

<comment><USER22> > Is that going to help her get a job in Silicon Valley while competing with > grads from top schools for the same jobs?

Yes, but not with a well-known company as their first gig.

</comment></comment><comment><USER14> I'd gladly take a paycut to move to a place where the cost of living was 1/4 as much. I might be unique.

<comment><USER23> Have a little chat with your buddies who grew up in the plains states. They will politely tell you you're full of shit.

Alternatively, go try it. You could take a paycut to go live in bumblefuck any time. Why not today? I think you'll discover pretty quickly that the grass isn't that green over there. They are low rent because there is either nothing to do, or because they're dangerous.

<comment><USER24> > nothing to do

Yeah, you don't know anything about Nashville.

<comment><USER25> I think of the major cities in the country, "nothing to do" fits _San Jose 's_ downtown better than most. And I say that as an SJ native. South First Fridays[0] are about the only time there is a palpable presence in downtown.

[0] [http://www.southfirstfridays.com/](http://www.southfirstfridays.com/)

</comment></comment></comment></comment><comment><USER26> Support needs to move out of the Bay Area. Honestly, there's just no way to live here on the salaries support professionals make.

These are just the facts. If I had my way we'd have a lot more affordable housing and renter-friendly policies here, but we don't and that's not going to change any time soon. So let's get real and know that putting support in low cost of living areas is the right thing to do.

</comment><comment><USER27> 3 reasons that, in early stages, startups have customer service at their HQs (IMO), and why it makes (financial) sense to move them to lower cost areas when a startup reaches a certain size:

(1) at the early stage basically everyone is part of customer support in that they are addressing/solving a slew of new/unanticipated problems together in real time and therefore its beneficial/valuable to have everyone in the same place. they also (usually) don't know how to run a customer service organization and are learning how it goes on the fly, esp. for the new product.

Later, the product matures and the majority of customer issues and their solutions are known and the process for addressing them can be (mostly) crystallized into a pre-determined set of responses, meaning that the customer service team can be separated from the rest of the organization. This is usually identified (or forced) by a more experienced customer service manager trained at a larger organization.

(2) at an early stage, costs associated with customer service are still relatively low vs. other investments (ie. product development, customer acquisition, technical hiring) so it seems relatively cheap to grow (you can hire 3-4 CS people for the price of one eng. in SF)

Later, as the organization grows, customer service can quickly balloon into a massive, expensive organization that grows in a more linear relationship with business/customer growth vs. product or dev teams, which (ideally) can be more leveraged.

(3) at the early stage, they are focused more on growth than profitability, so they aren't looking to optimize for lowering customer support costs and are more focused on the speed at which they are solving customer problems, aka. resolving impediments to growth.

Later, when it comes time to pay the piper (which is what appears to be happening with many, many on-demand startups..), customer service is a very easy place to try and cut costs, esp. when up until this point they had been run very inefficiently.

conclusion:

Once a company realizes that their support teams don't need to be at the HQ anymore, that the teams are inefficient and (oh shit!) they want to (try and) be profitable, it makes a lot of sense to move the customer service team to a lower cost location, or outsource it entirely. there's a reason most large, mature corporations do it.

</comment><comment><USER6> Oh man, having to live somewhere the commutes aren't an hour long (or more) and you can afford a house, how terrible...

</comment><comment><USER28> It's a bit unreasonable to join a tech company as something other than a technical person or a manager, and expect to quickly be promoted to a top-tier position. No career path works that way.

</comment><comment><USER29> Emotions aside, this makes perfect sense.

Working in a commodity job means less opportunity. It's the same reason not every company has Uber's valuation. Pay is (roughly) correlated to value.

</comment><comment><USER30> >"'How do we make this cost less?' Every support case can cost up to $30 for them. You cost them a lot of money and don't bring in a lot of revenue." Still, "They can't run the company without you."

What's the actual average cost of a support request? $30 seems like it would eat up annual profits of a lot of services fairly quickly.

<comment><USER31> That's the cost of a support incident handled by a live person. If you use self-service options like the knowledge base or Google then the cost is essentially zero.

This is why many companies make it hard to call them.

<comment><USER30> And is that the same across mediums...i.e. are email, chat and phone all $30 on average?

</comment></comment></comment><comment><USER32> Dumb article....customer svc is a low man on totem pole job. There is a huge demand for coders so learn how to code and make a very good living or fight all ur fellow reps for that one or two PM openings. That's how it goes in the tech world and in general. Everywhere.

</comment><comment><USER33> "Those are soft skills, and associated with women, they're not super valued."

Why are they associated with women? Where does that stem from?

</comment><comment><USER34> What is the business reason that Lyft is moving their customer service jobs here? Wages are not low here. Perhaps it is lack of state income tax? HMMMM

<comment><USER35> Oh, I think the fact that TN's median income is about 70% that of CA and Nashville's is about 60% that of SF might have had _something_ to do with it, along with commercial lease rates being 20% those of SF office space. Meanwhile, the rest of the company is still commuting to the Mission.

</comment></comment><comment><USER36> That article reads identical to the first few chapers of The Circle by Dave Eggers.

</comment><comment><USER37> remote teams, not remote people</comment>


Ask HN: The most important thing you learned in 2013? - <AUTHOR>

Let's keep it short and simple - one sentence replies.<p>Happy New Years! <comment><USER2> 1) Right and Wrong are just perspectives

2) True happiness is in doing what you really enjoy and being in control of yourself all the time

3) There are always more unfortunate around you

4) World is full of irrational behavior; but good part is you got choices

5) One-thing-at-a-time is a myth; you can do what you believe you can

6) No matter how bad it looks, convincing most of the people is mere wastage of time; they hear what they want to hear

7) Reading is an unpleasant process for majority and so is easy explanation

8) Working hard is fine only when you're learning

9) Business is all about minimizing the risks - contradictory to the general belief

10) The universe doesn't give a flying fuck about you. So go out there and live the life the way you dream of.

<comment><USER3> First thing to learn in 2014: Remember to read the subtext under the Ask HN entries. :)

<comment><USER2> Thanks; I did miss it totally. Will watch carefully next time before commenting.

<comment><USER3> That's okay, they are all worthy, and it's much better than 10 separate replies. :)

</comment></comment></comment></comment><comment><USER4> When we get older we generally don't get wiser we simply get more habitual and become more of what we already were in the first place. If you have strong intellectual/creative habits early on in life (even if you ask lots of stupid questions and flunk out of school) it can serve as a self regulating mechanism later in life. What I mean by this is if you (for lack of a better way to phrase it) start becoming a fucking zombie with a rote 'job' who plops down in front of the TV box and the like every day after work, eventually you will feel like something is missing from your existence due to your earlier childhood habits of curiosity etc. If those earlier habits were strong enough your won't be able to help yourself in finding a better path as it becomes a compulsion. Unfortunately its been my experience that most people are the inverse of this. Ask a question that requires more than 2 brain cells and they change the topic or miss the point....simply out of bad habits. Our habits have a tenancy to lock us into a path, so have good habits early on and never be afraid to yank yourself out of bad ones even if it hurts and makes you feel awkward.

Of course I already intuitively knew all this as it is just common sense and very remedial but the above was a crystallized theme for moi this year.

</comment><comment><USER5> 1\. With purpose comes passion. With passion comes Enthusiasm. So We need to set a purpose for the whole year. My passion for 2013 was to train atleast 1000 students on technology.

I ended up training 1315 Students and 40 Teachers in Java, Android and other latest technology. My purpose of 2014 is to create lasting impact through my work. (author a book, fitness, Instructor for online course)

Here is my blogpost of my learnings and events in 2013: [http://santhoshthepro.in/snapshot-2013-a-year-of- giving](http://santhoshthepro.in/snapshot-2013-a-year-of-giving)

</comment><comment><USER6> I learned that events (conferences) are a good place to find leads for the kind of business I'm in.

Also, I discovered "Complexity Economics"[1] this year, and that has changed my world-view in many ways and has given me a _lot_ of ideas and inspiration.

[1]: [http://en.wikipedia.org/wiki/Complexity_economics](http://en.wikipedia.org/wiki/Complexity_economics)

</comment><comment><USER7> That my government is doing just about everything a tinfoil crazy could come up with. I live in a true surveillance state.

</comment><comment><USER8> Constraint is no less important than freedom.</comment>


Code For America Open for Applications - <AUTHOR> http://codeforamerica.org/2010/06/01/we-are-now-officially-recruiting-fellows/ <comment><USER2> This is very _interesting_ , but (as a developer) doesn't seem _appealing_.

Apparently you live in San Francisco for a year, working on projects for another American city. You visit the city for a month to meet people and figure out what it is that you're actually doing, and then you go back to SF in some kind of mentoring camp with other Fellows, and implement the idea.

I have a bad feeling about the requirements management problem. It's known to be much better to be working onsite with your users, because communication between users and developers is critical. How is this addressed?

Another big sticking point is the salary. $35k, and I'll be living in San Francisco? It seems like a good web developer -- the kind you are trying to recruit, right? -- would be paid a LOT more, even at a startup (where they might have more impact, too). So it just doesn't feel right.

<comment><USER3> Getting paid 35k/yr to get abused by some asshole on the city council? Nobody in their right mind would even consider this.

I guarantee nobody on their advisory board would sign up for this shit. If you want to live in poverty there are lots of other things you could build on your own that would have a much bigger impact.

A much better solution would be to run a job placement service so people actually get paid. I don't see how them adding another layer of bureaucracy is going to help anything.

<comment><USER4> > _Nobody in their right mind would even consider this._

I am.

I figure, either you can be part of the problem, or part of the solution. It's so easy to just sit back and complain about the way things are all the time, but it's much more interesting to actually try to change them.

'Sides, it would be a good introduction to dealing with municipal governments, and that could be useful.

<comment><USER5> _I figure, either you can be part of the problem, or part of the solution._

False dichotomy.

 _It's so easy to just sit back and complain about the way things are all the time, but it's much more interesting to actually try to change them._

It may be more _interesting_ to try, but it may not be any more productive.

More specifically, the most significant problems I might sit back and complain about are ones that can't be solved with software[1], let alone custom software.

The notion of targetting municipal government is suspect to me, as it reeks of the enterprise software model. I may be misinterpretting what they're trying to do, but, if not, it will be threatened by the same dangers, which means that 7 months isn't nearly enough.

[1] ..or any technology by itself. I occasionally complain that programmers have a tendency to believe that all (technical) problems can be solved in software, but this goes well beyond that.

<comment><USER4> Again, the point isn't to attempt to solve a non-software problem using software, it's to get a guided introduction to dealing with municipal governments.

<comment><USER5> I guess I missed where that point is outlined, though I admit to not reading all the backstory.

The title of the project obviously can't be taken literally, but I expect I'm not the only technical person who would expect the point has something to do with code.

</comment></comment></comment></comment></comment></comment><comment><USER6> Cities should just pay reasonable salaries to a couple developers and build apps themselves.

"Each team returns to Bay Area headquarters and then has seven months to develop their application for their city."

Nevermind the potential issues from giving development seven months without having heard requirements. My question is, why just one application? Cities are huge machines. I have enough trouble navigating around a single councilwoman's website - let alone the DMV's. How is one application supposed to service an entire city in a meaningful way?

Before reading the details of this program, I imagined it would be something like this:

 _CFA puts you up in the city you'll be helping. Lodging, food, transportation, etc.

Instead of visiting the city you're helping, you visit SF headquarters - for a couple weeks, to go over your vision for development.

After identifying the applications that would be most beneficial to the city's residents, you build them. The applications start small – you iterate as you get feedback from citizens._

The benefit of this approach over CFA's is that you don't end up with one monolithic application that is difficult to add functionality to. Instead, you have a few examples of efficiency throughout the city. Enough examples, hopefully, that other departments will be inspired to invest in their own department's application.

<comment><USER7> Why even visit SF? Just setup a irc channel for all the devs and a weekly conf call to deal with announcements and attaboys.

</comment></comment><comment><USER8> Where I work we do a lot of software development for cities ranging from websites to applications. Most cities/departments are really reluctant to bring in any new systems. regardless how much they help. So I don't see how they would be able to do so much with what will more then likely be a bunch of new developers.

They also have to go out for bids on everything..

<comment><USER9> This seems like it's trying to build public services based off of the data in the cities' systems. On top of that, I think it's more of a non-profit so I'm assuming (and perhaps incorrectly) that they'd be more welcome as a partner.

My thought is this is to spread some of the openness that cities like SF and NYC (albeit at a much smaller level) have started.

</comment></comment><comment><USER10> Seems like they're trying to do the CFA project more like a "startup" style:

\- SF -> checked

\- Small team -> checked

\- 2.0 -> checked

\- Web (?) -> checked

\- Ramen wage -> checked

\- Tight deadline -> checked

\- Unknown requirements -> checked

Plus health benefit and travel tickets. Minus bureaucracy (probably).

I don't think it's a bad idea. If you were to work there and be successful in 1-2 projects, you would get the following benefits:

\- Connection with government agencies

\- Experience delivering govt/municipal public solution (portfolio)

\- Having stayed at SF for a while (maybe stationed yourself there)

\- Probably connection to the startup scenes there (if they go to meetups)

You can join a startup afterward and get a bigger paycheck. Of course all of these are probably more suitable for fresh-grad looking for an opportunity in Silicon Valley.

</comment><comment><USER11> This is a pretty amazing opportunity for anyone that wants to help fix cities. $35k stipend + travel + health and a chance at writing code that has meaning and helps fix a real problem. Will be interesting to see the kind of things that get built (and if the bureaucracy is beaten!)

More info on the program here: <http://codeforamerica.org/become-a-fellow/></comment>


How I built Sinklog.com – combine your log outputs into a single stream - <AUTHOR> http://benwilber.github.io/nginx/syslog-ng/logs/stream/syslog/http/websocket/lua/2016/01/31/how-I-built-sinklog.com.html <comment><USER2> Deleting submissions and reposting is against HN rules. (reposting itself, within limits, is ok)

</comment><comment><USER3> Yep, saw this the other two times you posted it.</comment>