Throwaway Code - <AUTHOR> https://blog.bencope.land/throwaway-code/ <comment><USER2> Having seen too many times how throwaway code and proof of concepts went into production I try to always write decent code. You don't need all the bells and whistles but just give things decent names, put repeated stuff into functions, avoid memory leaks, define constants and so on.

It also reduces cognitive overhead. A lot of people seem to spend a Lot of energy thinking about whether a project needs proper coding or not.

<comment><USER3> Most people underestimate the value of refactoring existing code. Even a prototype provides a good base to start the refactoring. Of course it will help if the programming language helps with easy refactoring. In my projects, I expect to refactor the code at least 3 or 4 times before it reaches a state I am comfortable with.

IMHO, this is far better than _starting from scratch_. Both code and SQL are meant to refactored. Don't over-engineer from the beginning adding usecases we know nothing about.

<comment><USER4> Refactoring production code can be _very_ difficult. You often end up constrained by the existing code's public APIs, cross-API data structures, remote systems running the old code, etc. It's worth putting at least a little bit of thought into maintainability, even in the prototype stage.

<comment><USER5> Especially if it's a project with multiple people working on it. Refactoring will cause major merge problems for everyone doing anything else on those files. And if your team does best practices with code reviews and testing, then refactoring a chunk of code becomes a big project.

</comment></comment></comment></comment><comment><USER6> > make sure the people using throwaway code understand that even though it > kind of looks like it works, it cannot be maintained and must be rewritten

I couldn't agree more with this. Not that long ago I inherited a project which on the surface looked shiny and nice. I was however aware that it was a mess underneath. Mind you, I was completely unprepared for the utter crap that awaited me. In all fairness it is the worst thing I have ever seen by light years. It took me two almost 2 weeks to find where a bug was coming from (it was written in a way which no debugger could trace it back, no logs, everything was surprised). After fixing it eventually, I decided to scrap it and build the whole thing from scratch. At the end it took me just over a month (Saturdays and Sundays included) and another 2 weeks from another developer to get a replacement project from an empty file. And here are the two painful truths about the whole endeavour: it took us collectively under two months to build, document, test, and run it in production. A grand total of around 20-30k lines of code. It took the people before us 3 and a half years to make their version which was anti patterns, top to bottom and in those 3 years the company invested around half a million Euros in salaries alone. If argue that this is the most painful thought. Not even the fact that this has been my first weekend this year in which I'm actually relaxing and not working. So my word of advice-if you end up in a similar situation, scrap everything, do it from scratch. Take a piece of paper, write down the business logic, draw a diagram of the structure of your application around it, pick the most appropriate stack and go for it. Avoid shiny new toys, profile everything and remember that sometimes it's better to let an application crash in order to find it's weaknesses.

<comment><USER7> Counter argument [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)

<comment><USER8> " Things You Should Never Do: They decided to rewrite the code from scratch." This is a great general rule.

The rule is situation dependant and some people can break it and succeed: the parent comment was very clearly one of those situations.

The actual risk is that the majority of us think we can break the rule, when it turns out we can't. But a minority of people/situations can successfully do a complete rewrite, success defined as where the gains abundantly outweigh the pains.

<comment><USER9> My rule is be skeptical of anyone proposing a rewrite who doesn't fully understand the existing system, to such depth that they would feel comfortable refactoring it. Which means anytime someone says "we want to rewrite it because refactoring it is too hard" I tend to not believe them.

There are times when rewrites are less total work, but they're hardly ever "easier" when you account for the cognitive load of making sure the requirements of the rewrite are being accurately captured. Maybe there's an exception if you know the requirements have been drastically simplified, but I doubt that's practically useful.

</comment></comment></comment></comment><comment><USER10> A colleague told me an anecdote tangentially related.

He was working on a service and managed to hack together some code that barely worked. His manager came around and a conversation like this unfolded.

Manager: How is your project going?

Engineer: Pretty well, I got something working.

Manager: Excellent! We have a meeting with a VP tomorrow and we want you to do a demo.

The lesson learned was to be careful and under optimistic about how you communicate to leadership.

<comment><USER11> I've seen X-Language shops write PoCs in different languages only to end up with those PoCs in production and a kludge layer between the PoC code and the normal X-language layer.

I've seen people nail down the complete UI first only to spend umpteen sprint demos afterwards explaining why a "fully functional" UI can't be put into production yet to angry management. No matter how hard you try, you can't explain an iceberg to a management staff that wants the project to start earning money already.

> The lesson learned was to be careful and under optimistic about how you > communicate to leadership.

Yes. Some people have to learn this the hard way. I would add, don't try and be sneaky either (ie: using different languages, etc.).

<comment><USER12> The worst part about demo code like that is you have to code review every single line to make sure that the entire UI is using real data now and not some placeholders embedded in a function or the UI. We had someone go way down that rabbit hole once and I had to tell the manager that we don't and can't know how long it will take to ship this, because the entire thing is a fiction.

</comment></comment></comment><comment><USER13> I find throwaway code to be freeing and fun. I don't have to worry so much about making the perfect abstraction, or some DRYness optimizations. I've also had my share of throwing making it into production.

The secret is keeping it simple. Simple code can always be optimized later. It can always be optimized if it's simple. Besides, the junior developers need something to bust their chops on anyway right?

Often times when someone takes over the project I've already listed in the library and in comments what can and should be improved.

</comment><comment><USER14> I use a different framework for throwaway code. For example, my current prod application I work on uses Apache Storm and Kafka Streams, my throwaway code is written with Eclipse Vert.x.

I tend to use bottom up approach when I start by writing small bits and pieces of utility functions, tools, etc. and I build a larger proof of concept based on that.

Typically, the top level of the application is pretty dirty and changes constantly while I spend time to get the bottom of it correct right from the start.

I use the top level of the application as a kind of test framework for the bottom parts.

Then when the time is right, I throw away the top of the application and build the new one using some of the tools I have already developed.

I would love to do my throwaway code in Clojure but writing it in the same language as my production application lets me gain more knowledge, faster, and already have some stuff ready when I get to write the main part.

</comment><comment><USER15> I think there are 2 cases in real world scenario:

1) either you have the habit, energy and time to systematically rewrite your code properly through iteration;

2) or you are so good that your average throwaway code is considered not that bad.

Because mostly either we are going through well known paths which leads to case 2) or we're exploring new things and being "skilled & experienced developers" we manage to have the right habits, energy and time to build things iteratively ending up in case 1).

If in the end we still have trashy code, then we need to ask ourselves if we are lacking any of the following: skills, energy, time or good habits (or a proper context, but that's a whole other universe of problems).

</comment><comment><USER16> All of your code will be thrown away.

</comment><comment><USER17> If the code is any good, it _will_ be rewritten. Or it's perfect. Bad code however, no one want to touch it.

</comment><comment><USER18> If your "throwaway" code works fine in production for years without any active maintenance and the only down side is that it needs a rewrite five years later, was it really that bad? Or is it the exact thing tech debt refers to - borrowing future time to work on what's important? If I had to make a point it would be that there's no line between code that needs to be replaced right now and code that is perfect and lasts for decades - it's a spectrum and circumstances influence your tolerance.

<comment><USER12> The flip side of this is people who get sunk cost fallacy around that throwaway code. Rewriting a piece of code that's been in use for two, three years doesn't invalidate its existence. It wasn't necessarily a mistake for it to be written that way. It _is_ a mistake to keep on using it, though.

I think maybe it's similar to the way we misuse the term "crutch". If you have a broken leg use the damn crutches. When your leg heals and you sell the crutches, don't castigate yourself or anyone else about how useless crutches are. You used them. Past tense. That's done now, and you're moving on.

</comment></comment><comment><USER19> I like to have a folder called playground within my projects, where I build related prototypes and try out new ideas. Whenever something seems to work well, I do some sort of cherry-picking to keep the things I got right within the prototype and rewrite everything else.

This helps me to validate ideas while keeping the main project in good shape. It is not as extreme as choosing a different language for the prototypes, but for me, it worked well so far.

</comment><comment><USER20> That might work for video games, but in a web company I've seen so many throwaway bash, perl or python scripts wrapped in an `system(*command)` that are unmaintainable and sometimes cause RCE or injections bugs.

I feel that this advice only fixes the symptoms and not the underlying root cause. This is a culture issue, not a technical issue.

</comment><comment><USER5> I haven't written a prototype in forever. I don't find them effective. And they typically take _way_ longer than you expect at the outset.

Do some wire charts or graphics and present those. It's far more boring to do than writing a prototype, and learning design tools is cumbersome, but they allow you to demo things better to executives, redraw stuff on the fly in meetings, copy and paste to a document or slideshow, share with external parties, and people don't get hung up on minutae that come with presenting a prototype. Stakeholders far prefer seeing a well thought out document or slideshow than a dinky fake app.

Once you get signoff on the design and flow, then jump straight into the real code, skip the whole prototype step.

I'd rather be coding, but sometimes it's just not the most efficient use of my time.

<comment><USER21> Do you use any specific tooling to help with this?

<comment><USER5> My primary tools are actually Photoshop and PowerPoint. Lame I know, but they have served me well over the years.

Actually, hadn't thought much about it before, but being proficient at these two tools might be just as valuable to me as coding skills.

<comment><USER22> Krita's become mature over the years.

</comment></comment></comment></comment><comment><USER12> There was an interview posted here last week about tech debt, and the speaker mentioned that if you compartmentalize throwaway code properly it can be kind of liberating. I don't know that I've seen that in the wild, but it sounded plausible. Instead, he claimed, the only important part of that code - at all - were the interfaces. So save your design that part well and for the rest, save your energy.

I have seen flavors of the latter work out, especially when you combine the idea of riskiest thing first (also last week) with reversible decisions and only decide today on things that have to be decided now. For things that are easy to change, make an arbitrary selection and keep moving. For everything else, play for time and hope that new information will improve those decisions.

</comment><comment><USER23> A related idea: use not just a different language, but a completely different toolset.

At my last job, I prototyped half of the serious overhaul of a mid-sized product (backend and UI) in a bunch of ObservableHQ notebooks. It was all a pile of hacky JS, hastly-written over the course of a week, but it let me explore and showcase all the new product ideas and serve as a reference for my co-workers (and something to demo to the management), and at the same time there was no way it would ever end up in production. After all, it was all just a bunch of private notebooks on a third-party SaaS, and the presentation was explicitly following the notebook/document model instead of an application model. And, of course, our real backend wasn't written in JavaScript.

</comment><comment><USER24> It's not a black/white thing, really. My code tends to be somewhat repetitive and terse while exploring new ideas.

Once I know where I'm going I'll gradually refactor and spell things out to the level I'm aiming for, which is different depending on context.

Polishing code that should never go anywhere is a waste of life, and once you've spent all that effort it's more difficult to keep an open mind about the design.

</comment><comment><USER25> I write every line of code as if it were going out the door.

But that's actually a fairly good idea (use a different language).

</comment><comment><USER26> I have the opposite problem - a lot of the code I think carefully about, factor correctly and ensure is thoroughly unit-tested spends about six months circling the plug-hole of tech demos and PoC before being sent to the bit- sewer and forgotten.

</comment><comment><USER27> Similar to the infamous: "temporary" workarounds...</comment>


Berlin Is Becoming a Sponge City [video] - <AUTHOR> https://www.youtube.com/watch?v=uWjGGvY65jk <comment><USER2> These kinds of techniques are often claimed to be effective against flash floods, which makes sense since they slow down water transfer to rivers. Does anyone know any studies about how effective it could be against seriously heavy precipitation of the scale of Harvey or South Asia floods right now? In other words, how well does the approach scale?

<comment><USER3> Civil engineering has pretty well quantified the rate at which water is absorbed by certain soils, accounting for groundcover, trees, pavement, local detainment, etc. Berlin's sponge mission is baiscially distributed detainment, working to offset hardscaping (driveways and roofing). In other words, it's a well known and very predictable science, but we (we being US land development industry) has not cared. HOWEVER rain at the scale of Harvey cannot practically be planned for beyond "don't build on land that's lower than average"

<comment><USER4> Well, that's partly true. A lot of the flooding is due to the fact that the entirety of Texas doesn't care about hydrology, and all that water is ending up downstream, in Houston.

There'd still be flooding, and it would still be bad, but a certain degree of flooding was avoidable.

<comment><USER5> The other thought, I imagine, is that they felt the probability was low that they would see a flood of this scale even within their lifetime; that ended up being a poor bet. Even so, flood insurance is also cheaper when the perceived likelihood of a flood is low.

<comment><USER6> Since cities usually survive much more than one human lifetime, this is not good reasoning.

<comment><USER5> People build houses, cities don't.

<comment><USER6> As you almost certainly know, the city controls permissions for every building.

A city that gives planning permission for a development that is probably going to be destroyed with loss of life in the next hundred years is not serving people well.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> My first thought is that it might be hard to prevent decay and leaks into the structures supporting these spongy surfaces. 80cm of water logged soil above a parking garage, for example.

<comment><USER8> Planting grass on top of parking garages isn't that unusual or new in Germany (though usually done for aesthetic reasons), so I assume this is a solved problem.

Sufficiently deep buildings and parking garages might also encounter ground water, so adding soil on top might not even add new problems to the engineering side.

Similarly, the rooftop plants are shown on rooftop designs that would already have to deal with stagnating water

<comment><USER9> Municipalities can (and commonly do) grant a reduction of fees for reducing sealed soil, so it's not only aesthetic reasons. [https://de.wikipedia.org/wiki/Niederschlagswassergeb%C3%BChr](https://de.wikipedia.org/wiki/Niederschlagswassergeb%C3%BChr)

</comment></comment></comment><comment><USER10> funny just watched this yesterday night. Was really surprised by it. When you live in Berlin it's not something you see that yet. But of course Berlin is a more green city than something of the size of New York just by being smaller.

</comment><comment><USER11> The video only shows relatively small buildings - would that system work with high rise towers?

<comment><USER12> High towers have got the same land footprint, so yeah, it would work

<comment><USER11> Land footprint, yes, but they do have higher volume to surface ratios and that should play some role in heat absorption and dissipation I think.

</comment></comment></comment><comment><USER13> What happens to the plants during the summer if there is too little rain? Do they also install watering systems? That would be expensive to maintain.

<comment><USER14> This is Berlin! Too little rain? I don't think so.

</comment></comment><comment><USER15> [https://news.ycombinator.com/item?id=15128428](https://news.ycombinator.com/item?id=15128428)

</comment><comment> the-dude Interesting, but no new ideas. These rain water management ideas are being implemented for a couple of years now in The Netherlands when developing new real estate.

<comment><USER16> And The Netherlands probably got the idea from China: [https://www.theguardian.com/sustainable- business/2015/oct/01...](https://www.theguardian.com/sustainable- business/2015/oct/01/china-sponge-cities-los-angeles-water-urban-design- drought-floods-urbanisation-rooftop-gardens)

<comment><USER17> Hopefully they steal good ideas from all over the place. The video mentions swales, which is a mainstay of permaculture, which has been tried out in various ways all over the world since the 70s.</comment></comment></comment>


Rodney Brooks - <AUTHOR> https://www.technologyreview.com/s/614124/rodney-brooks/ <comment><USER2> Rod Brooks was on my thesis committee. His work was inspirational, but the subsumption architecture was badly flawed and ultimately proved to be a dead end. It's simply not true that "the world is its own best model" because wherever you are you can only see a small part of the world. It works great if all you want to do is avoid obstacles, but if you want to do anything complex and goal-directed, a robot really does have to be able to remember things. The reason he was so influential is because the dominant paradigm at the time, the so-called sense-plan-act model, was just as much of a dead end, and on top of that, produced really boring demos so it was doubly doomed. The right answer is to combine the two approaches with a layer of "glue" that connects them together in a so-called "three-layer" architecture [1]. That's actually the way that autonomous robots work today (AFAIK -- I've been out of the business for a very long time now).

[1] [http://www.flownet.com/gat/papers/tla.pdf](http://www.flownet.com/gat/papers/tla.pdf)

<comment><USER3> I wonder under which paradigm the modern robots of iRobot (the Roomba company, where Brooks works today) are developed. Them being three-layer would be a pretty good indictment of pure-subsumption as an architecture.

<comment><USER4> > iRobot (the Roomba company, where Brooks works today)

That was two companies ago, AFAIK

Edit: And, indeed, TFA says as much.

<comment><USER2> TFA?

<comment><USER4> The Fine Article

</comment></comment></comment></comment></comment><comment><USER5> I quite appreciated Rodney's paper from 1985 titled "A Robust Layered Control System for a Mobile Robot" [1]. I'm sometimes wondering if mobile robotics would look much different without this paper or if we would arrive to something similar anyway.

I even asked Rodney Brooks whether the results of this paper were applied on some robot platform as a follow up research and received a very interesting reply [2]. I agree that I might have worded it poorly but it's still one of my favourite tweets.

[1] [https://apps.dtic.mil/dtic/tr/fulltext/u2/a160833.pdf](https://apps.dtic.mil/dtic/tr/fulltext/u2/a160833.pdf) [2] [https://twitter.com/WeeklyRobotics/status/105775034299205222...](https://twitter.com/WeeklyRobotics/status/1057750342992052224)

</comment><comment><USER6> Great guy. Here's an anecdote from that time. He spent a few months on sabbatical at our lab ( [https://ai.vub.ac.be/](https://ai.vub.ac.be/) ) in those days. We were preparing robots for a NATO Advanced Study Institute ( [https://www.springer.com/gp/book/9783642796319](https://www.springer.com/gp/book/9783642796319) ), and I was struggling writing the serial driver for a custom embedded computer for this as the system kept crashing (due to a bug in the dram controller). Anyways, Rod Brooks, offered to help me with the coding. It wasn't needed as the code was not the problem, but I don't know many professors that could and would be prepared to dive in that deep.

P.S. I posted this comment in reply to a Brooks reference a few days back, but might be more on topic here.

</comment><comment><USER7> A useful search term the article didn't mention: [https://en.wikipedia.org/wiki/Subsumption_architecture](https://en.wikipedia.org/wiki/Subsumption_architecture)

Before you get into that, it's delightful to start with the Braitenberg "Vehicles" book: [https://en.wikipedia.org/wiki/Braitenberg_vehicle](https://en.wikipedia.org/wiki/Braitenberg_vehicle)

</comment><comment><USER8> I love how he's constantly dubious about autonomous robots news on twitter. Yesterday he criticized the Berkeley delivery [https://twitter.com/rodneyabrooks/status/1165736688141787136...](https://twitter.com/rodneyabrooks/status/1165736688141787136?s=20) for not being autonomous and their short distances. He's also very skeptical about self-driving cars in general.

</comment><comment><USER9> Allen sounds remarkably like a new version of Grey Walter's Machina speculatrix: [https://sites.google.com/view/machinaspeculatrix/home](https://sites.google.com/view/machinaspeculatrix/home)</comment>


New Chinese chip for hybrid AI thousands times more efficient than GPU - <AUTHOR> https://syncedreview.com/2019/07/31/nature-cover-story-chinese-teams-tianjic-chip-bridges-machine-learning-and-neuroscience-in-pursuit-of-agi/ <comment><AUTHOR> The research team designed a self-driving bicycle experiment to evaluate the chip's capability for integrating multimodal information and making prompt decisions. Equipped with the Tianjic chip and IMU sensor and a camera the bicycle was tasked with performing functions such as real-time object detection, tracking, voice-command recognition, riding over a speed bump, obstacle avoidance, balance control and decision making.

The research team developed a variety of neural networks (CNN, CANN, SNN and MLP networks) to enable each task. The models were pretrained and programmed onto the Tianjic chip, which can process the models in parallel and enable seamless on-chip communication across different models.

Video of the unmanned bike: [https://youtu.be/VjSs6KCLTC0](https://youtu.be/VjSs6KCLTC0)

</comment><comment><AUTHOR> Some critics from ZDNet:

There is very little information about how the two types of networks, neural and neuromorphic, are trained, which is an important issue for either one separately, and even more important when they're combined. Pei and colleagues write, in the "Methods" section of the paper, that they trained the deep learning part in the normal way, and that for the neuromorphic part, they relied on a method introduced last year by some of the researchers, called "Spatio-temporal backpropagation," a version of the backpropogation approach common in deep learning.

There are also some missing details about the chip's fabrication. For example, the part is said to have "reconfigurable" circuits, but how the circuits are to be reconfigured is never specified. It could be so-called "field- programmable gate array," or FPGA, technology or something else. Code for the project is not provided by the authors as it often is for such research; the authors offer to provide the code "on reasonable request."

More important is the fact the chip may have a hard time stacking up to a lot of competing chips out there, says analyst Gwennap. The specs seem underwhelming, in his view. "Tianjic's reported 1.28 TOPS/watt [trillions of operations per watt, a common measure of performance] is similar to today's GPUs," he notes, referring to graphics processing unit chips made by Nvidia and Advanced Micro Devices. However, the performance is "well behind more advanced architectures" of newer chips, he notes.

Gwennap's colleague, Mike Demler, concurs. He notes some inaccuracies in the paper, such as the contention that spiking neurons require "extra high- precision memory" circuits for some functions. Demler's review of a neuromorphic chip by chip giant Intel, called "Loihi," shows that such is not the case. A chip developed by startup Brainchip, Inc., also proves the claim false, he says. Moreover, since the Loihi chip has already shown that conventional neural networks, such as a convolutional neural network, or CNN, can be implemented as a spiking neuron, there's no need for the kind of "unified" chip that the Tsinghua authors claim.

</comment><comment><USER2> "The 28-nm chip consists of 156 FCores, containing approximately 40,000 neurons and 10 million synapses"

I am dying to know where they are harvesting these from?

(yes, there is a pun hiding in the sentence above)</comment>


UniPCemu x86 (8086/8088/80186/80286/80386/80486) Emulator - <AUTHOR> https://bitbucket.org/superfury/unipcemu/wiki/Home <comment><AUTHOR> The more graphical explainer page:

[https://superfury.itch.io/unipcemu](https://superfury.itch.io/unipcemu)

>"The UniPCemu (Universal PC emulator) emulator, originally made to play games on the PSP, now built for Android, Windows and PSP! Play your old classic PC games on Android! It's a cycle-accurate x86 emulator (previously called x86emu). It's a 8086(IBM PC) up to Pentium (Compaq Deskpro 386/Compaq Deskpro 386 with PS/2 mouse(adds PS/2 mouse to the Compaq Deskpro 386 chipset, optional BIOS ROM replacement(loading it instead) and seperate CMOS settings like the other architectures) emulator(with various, configurable hardware), with up to 80386 timings (80486 and Pentium using 80386 timings or 1 cycle for newer/unknown timings, both having no floating point unit)).

It can run many IBM PC XT games, and also various 286-Pentium* games."

Disclaimer: I don't want to play games on it, I think it might be useful for OS engineering -- but that's just me...</comment>


Android Income Report - <AUTHOR> http://droid-blog.net/2012/05/13/android-income-report-12-may-12/

<comment><USER2> I'm a successful app developer and I can't help but feel that this kind of approach is not the right way to go about.

App-stores are "hit based", at that level of revenue you should be thinking, "how do I make this go up an order of magnitude", not "how do I optimize my ads to squeeze a little more revenue out". Just taking a look at some of the reviews your apps have... you should be improving quality before optimizing revenue.

<comment><USER3> One of the reviews:

"Update: Facebook Ad is covering up my ship! I want old version back"

Yea, that certainly makes me question his focus :S

</comment></comment><comment><USER4> One pet peeve I've got with Android and Google Play is that my country is still not supported in Google Checkout, so I can't register for a merchant account.

This means that I cannot sell apps, so the 3 options I have would be to:

1) go with an ad-supported model

2) enable in-app payments with a third-party provider, such as PayPal, but this is tricky because it goes against the guidelines of Google Play

3) publish the app on my own website, with payments through PayPal, being the only sane solution for me in case I don't want an ad-supported model

I'm extremely disappointed that Google, after 4 years of Android being on the market, is still not allowing my country. And I wouldn't have a problem selling iOS apps in iTunes. Not only that, but there have been numerous reports of extremely poor customer service for Google Checkout, so even if you're blessed to live in an approved country, you can still get fucked.

And then people wonder why the ad-supported model is preferred for Android.

<comment><USER3> Are you sure you cannot sell stuff even without merchant support? Here in my country (Brazil) the merchant account is also not supported, but they give me the option to use an AdSense account instead to receive money.

It's far from ideal, and makes me have to jump through additional hoops just to sell apps. But it's allowed.

</comment></comment><comment><USER5> I'm extremely disappointed that you'd choose to try an obnoxious, intrusive SDK like SellARing. Not only are you exposing your users to it while you app is installed, but they leave their SDK installed on the user's device after they've deleted your application and left it a one-star review for doing something so disrespectful. I imagine there is also a large number of users that are just not savvy enough to uninstall this SDK after-the-fact, so you've effectively hosed them.

I appreciate the need for app developers to make money off their work, but this is not the way to do it.

EDIT: I misread their product description - this SDK doesn't survive an uninstall of the offending application. I was assuming they'd use a permission like "install applications" to drop another application. At least on this count, you don't have to worry.

<comment><USER6> > they leave their SDK installed on the user's device after they've deleted > your application

How does this work? I come from the iOS universe and statements like this scare me out of ever installing anything from the Play Store. Is installing an app not clearly reversible? I can't find anything useful for "uninstall sellaring" or "remove sellaring" either.

Is there a golden rule to keeping Android 4 clean?

<comment><USER7> > they leave their SDK installed on the user's device after they've deleted > your application

I have worked on an Android app extensively. I am pretty sure that's not possible.

<comment><USER5> You're right - I misread the product description (updated parent post).

I was assuming they'd be doing something tricky like asking for INSTALL_PACKAGES ([http://developer.android.com/reference/android/Manifest.perm...](http://developer.android.com/reference/android/Manifest.permission.html#INSTALL_PACKAGES)) and dropping something on the device. Thankfully they don't do that.

As someone who has hacked on Android before (ie: <http://unrevoked.com>), I wouldn't be surprised if there were ways to silently install packages, or even just tricking the user into allowing an install of a further package.

Quick googling leads to this: [http://jon.oberheide.org/blog/2010/06/28/a-peek-inside- the-g...](http://jon.oberheide.org/blog/2010/06/28/a-peek-inside-the- gtalkservice-connection/)

<comment><USER8> Android apps can't have that permission, only the Market gets that permission.

No offense, but you're spreading some pretty false FUD. Unrevoked uses multiple exploits and requires a lot of user interaction _and_ a computer to initiate the process.

Further that last link basically describes how Play remote installs applications and is all under the assumption that someone has somehow MITM the SSL connection, something I'm presuming is not at all easily done. (Further it's going on two years old, I wouldn't be shocked if Google is now signing their INSTALL_ASSET messages, Play has changed a LOT in the last two years).

Apps are sandboxed overall similarly in iOS, WinRT, Android, WP7. Uninstalling them, uninstalls them. It even removes all data attached assuming the dev doesn't manually put data on the SD card instead of using the API to store data on the SD card.

<comment><USER9> FYI, it is possible for unprivileged apps to invoke the INSTALL_ASSET functionality themselves. One such example described here:

[http://blog.duosecurity.com/2011/05/when-angry-birds- attack-...](http://blog.duosecurity.com/2011/05/when-angry-birds-attack- android-edition/)

Another variation of that attack is still unpatched, allowing any app to invoke INSTALL_ASSET. Certainly that's not intended functionality and is a bug that will be (eventually) patched, but I wouldn't classify it as FUD.

<comment><USER6> That is indeed a little scary. Thanks!

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> One thing I'm always curious about when I see revenue from mobile applications is: does advertising on a mobile device really work? I'm hesitant to sell anything unless I'd be confident selling it with my name attached to the label and I'm not sure mobile ads are something I'd consider valuable.

The two primary issues are that 1) mobile devices slow down / severely discourage any online form entry and 2) the age old question of "how many clicks are misclicks".

1) is the killer for me. It's rare for me to actively click on an ad and even if I'm drawn to an ad whether I'm on laptop/desktop or a mobile device makes quite a large difference on the ultimate decision.

I guess you could argue that it's up to the advertiser to ensure their ad money is well spent but unless you're just spreading awareness (or possibly other applications?) I'd personally not feel happy selling mobile ads.

Thanks for sharing your numbers though! This sort of openness is something I quite enjoy seeing. Best of luck hitting your $2k goal next month and I hope the $4k goal is reached soon after :)

<comment><USER11> You are right to wonder. Mobile ads largely do not work. I tired admob as a publisher and a as an advertiser, results are poor. As a publisher I saw ad revenue on the order of $5 for 1000 active monthly users. As an advertiser I sunk in a few 100 bucks and saw I think one purchase of my apps that I advertise. Mobile ads are destroying value. I have once met a person at a conference who said he was making money in mobile ads. Turns out he knew peopple at abig companies willing to spend money on brand advertising. I still run the admob ads In my app, and I see that most ads are brand ads, and ads from companies willing to buy their way into minds e.g. Google or Microsoft.

<comment><USER12> It leads one to wonder if the mobile ad payment argument is simply a problem with Google. That is, Google's strength is in advertising, and it works for Google due to their size and reach, but that capability may not expand to their app developers. Certainly, some are making the argument that there's more money to be made by pushing your app through a traditional retailer than a traditional advertiser. (Erm, that last word may be a poor choice there... I just can't think of a better one.) e.g.: [http://www.engadget.com/2012/03/31/flurrys-analytics- apple-a...](http://www.engadget.com/2012/03/31/flurrys-analytics-apple-app- store-amazon-appstore-android-google-play/)

</comment></comment></comment><comment><USER13> It kind of blows my mind that any developer would willingly integrate something like Sellaring. It sounds like the kind of ad network no sane person would ever want anything to do with, and if an app I used integrated it, I would uninstall that app on the spot. I'm not shocked it had such a negative impact; I wonder if he spent any time considering how his users would feel about it?

<comment><USER14> Exactly this. If a form of advertising would actively annoy me if it was on my phone, I do not put it in my apps. Most users understand the need for ads in applications. They're willing to have a 50px banner because they're pretty easily ignored. Most users are not tolerant of apps reaching outside their scope and pushing ads, like this Sellaring and whatever the other one was that put ads in the notifications (AirPush maybe?).

<comment><USER15> To inspect the addons used by apps there is a brilliant app called "Addons Detector" which you can find out about the analytics, advertising, developer tools, social gaming, push notifications etc libraries used by the apps installed on your Android.

I was really interested when I first ran it! I have no connection to app, just a happy user.

</comment></comment></comment><comment><USER16> Bit confused here. You had 1.3m Madvertise requests and 100k Madvertise impressions. Where did the 1.2m requests go (I'm assuming 600k went to AdMob. How about the other 600k)?

<comment><USER14> Probably just unfilled. Before filling my remaining requests with House Ads, it was not unusual to only have a 50-75% fill rate on Admob. Maybe Madvertise is different (I've never used them) but it could be that no advert is served.

</comment></comment><comment><USER17> 3D invaders is really fun. You should be selling an ad-free version for 99 cents. (Maybe you are already? I didn't see anything indicating that, however.)

<comment><AUTHOR> I'm glad you like it. There's no ad free version available at the moment though.

</comment></comment><comment><USER18> These methods will not work for long, and it's not a basis for a business. The adverts are extremely intrusive and irritating for users.

</comment><comment><AUTHOR> Thank all you guys for the great discussion!</comment>


R.J. Lipton - A proof that P is not equal to NP  - <AUTHOR> https://rjlipton.wordpress.com/2010/08/08/a-proof-that-p-is-not-equal-to-np/

<comment><USER2> Reading Lipton's description of this paper I think I understand how normal people feel when they listen to geeks talk about technology.

</comment><comment><USER3> The paper is rather complicated, you can see it here <http://www.hpl.hp.com/personal/Vinay_Deolalikar/#s.p>. on the author's site.

it would be nice to believe this is solved, but my gut instinct is that it will not be vetted.

</comment><comment><USER4> This was also good the last three times today it appeared on HN. :)

<comment><USER5> In all fairness, this is an article by someone who knows his stuff saying maybe. There's so many crackpots going after P ≠ NP that we need to hear from those people saying this time is different. The news to this article isn't that a claimed proof exists, but that R. J. Lipton is saying it seems plausible.

<comment><AUTHOR> Yeah - I updated the post title to make that a bit more clear.

</comment></comment></comment><comment><USER6> [jokingly] Would be interesting to know, what Does Perelman think about the proof? At least it is not from math community, so probably it is ok to take the million...</comment>


Optimum Monopoly Strategy Based on Payback Period/ROI - <AUTHOR> http://www.amnesta.net/other/monopoly/

<comment><USER2> I always remember the time abstractbill decided to teach me a harsh lesson - He was probably 9, me about 7.

Him: "Hey! You can start with _all_ the money, and I'll start with _all_ the property" Me: "Woah good deal! I've got tons of money now!"

An hour or so later I'd lost obviously.

</comment><comment><USER3> For more super-intense Monopoly analysis, check out this math prof's page: [http://www.public.iastate.edu/~hentzel/monopoly/homepage.htm...](http://www.public.iastate.edu/~hentzel/monopoly/homepage.html)

This guy was doing computer analysis of Monopoly like 25 years ago.

</comment><comment><USER4> This is off topic, but if you are teaching (or learning) OO, designing an object model for Monopoly is a great project.</comment>


Good Design Is Thorough Down to the Last Detail - <AUTHOR> http://theindustry.cc/2014/09/10/good-design-thorough-last-detail/

<comment><USER2> I always enjoy a well-formulated counterposition to not sweating the details and favoring shipping quickly. I've found the trick with these delightful "details" is that users are often unaware of their appreciation for them. That is, these are things that are "felt and not seen". They are unaware the experience is better with them but would feel the degradation if they were removed.</comment>


Ten Rules for Negotiating a Job Offer - <AUTHOR> https://medium.freecodecamp.com/ten-rules-for-negotiating-a-job-offer-ee17cccbdab6 <comment><USER2> I wonder if the "game" operates somewhat differently for junior people, versus developers with 10 to 15+ years experience?

When I was fresh out of school, at the tail end of the dot-com boom, negotiation seemed very much central. Employers (and the third-party recruiters working for them) always wanted me to throw out the first number, or wanted to know what I was making at my last job. Then once I was at the new company for awhile, people would gossip... and I'd always discover that I'd low-balled myself. So I would leave, using the apparent market rate as my baseline in the next search. And I simply stopped disclosing what I was making at the previous job.

I learned that the difference between a $70k candidate and a $90k candidate is basically just that the latter declares himself to be a $90k candidate.

However, once I crossed over the $120k line (at least in my local market) it seemed that things plateaued and changed a bit. It's not as easy to just "declare" that you're a $180k candidate rather than a $140k candidate. At that level, you often start to find that you're interviewing for managerial positions rather an individual contributor technical role.

At this stage of my career, I pretty much tell the recruiter my target (which happens to be about 5-10% more than my current salary), and then I'm not even wasting my time interviewing with companies that won't go that high.

Ten or fifteen years ago, I was apparently selling myself short. Today, I don't talk about salary IRL, because I'm making significantly higher than what I hear through gossip or see on Glassdoor.

Is this common for other experienced devs out there? Or am I selling myself short, and probably should be making $750k for a non-managerial job outside of the Bay Area by now? (haha)

<comment><USER3> > And I simply stopped disclosing what I was making at the previous job.

What's a good way of phrasing this to come off as non-combative? I always feel awkward saying something like "I'm not comfortable telling you that information".

<comment><USER4> It's not awkward, and it's totally your prerogative for telling a recruiter for that. If they say "well I won't work with you if you won't disclose that info", then I'd say "thanks for your time, good luck in your search." Nowadays there's always a dozen other recruiters who'd be willing to have a phone call with a developer who's actively looking. Obviously, YMMV.

As a rule, I don't tell third-parties (recruiters, etc) my current or former compensation. I ask what range the company is aiming for, and whether I'm interested or not. I think compensation is something to be discussed only between the candidate and the company.

Anecdotal story: I once was lowballed without my knowledge going into an interview set up by a third-party recruiter, contracted out by the company. They were very excited to get me in - turns out the recruiter gave the company a number that was 25% less my current salary. The company wouldn't be able to meet anywhere near my actual current salary, but the recruiter wanted to get a butt in the seat by any means.

From now on, I keep that info private until I choose to disclose it.

</comment></comment></comment><comment><USER5> I've negotiated hundreds or maybe thousands of salaries.

The goal should be to find a salary that is appropriate for the employees skills and experience level. Neither too high nor too low.

You do not want anyone to "win" the negotiation.

The idea is to find a salary that will ensure that the employee feels that they are being appropriately paid during their employment, and will not be browsing jobs because they feel they are under market rate. You want to employer to feel that they have someone who is being paid at a level that reflects the employees skills and experience and is broadly consistent with other employees at a similar level.

Negotiating isn't a battle. It's a process of trying to find if there is common ground.

If the employee and the employer do not find satisfactory common ground then the negotiation should end gracefully - both parties move on.

It's important to work out at the very beginning of the employment process if jobseeker and employee are in the same ballpark on salary - it's silly and wasteful of everyones resources to get to the end of a process only to find out the parties expectations do not synch.

<comment><USER6> "Negotiating isn't a battle"

of course it is. you make this sound like there is no asymmetry, that it boils down to two equal parties sitting down to chat over tea. that's not the case. this is a completely asymmetrical process, where the firm really has most of the power. they are essentially uneffected, no matter the outcome of the negotation.

"it's silly and wasteful of everyones resources to get to the end of a process only to find out the parties expectations do not synch"

again, you are implicitly promulgating the fiction that this amounts to two equal parties trying to find a meeting point. it just isn't. i see how tech companies go about recruiting. it's an assembly line. their recruiting process is a well-oiled machine, an assembly line -- and i'm the widget on their conveyer belt. if i attempt to get a salary that i think i deserve, and fail, they won't lose any sleep. their well-oiled machine will continue to hum.

software engineers are a commodity to the firms we interview at. you patronize us by suggesting otherwise.

<comment><USER5> The only sort of negotiation worth "winning" is one in which there is no ongoing relationship at the conclusion of the negotiation, i.e. certain types of purchases/sales such as for example a house or a car.

If there is an ongoing relationship and one party "won" the negotiation then the price is resentment and likely "evening up" by the "loser" at some point in the future.

In many cases it is worth conceding some value to the other party even if the other party has no leverage just because you (as the "winner") want the other party to feel that they did not "lose" the negotiation. For example say a potential employee asks for an extra $10K. The employer might know that the new employee will take the job even if the $10K request is refused. But just to ensure the new employee saves face and feels like they were valued and listened to and did not "lose", then a wise employer might give them $1K or $2K or some other concession instead such as a guaranteed review in 3 months.

<comment><USER7> I totally agree with you, under a lot of circumstances. Many job-hunters/HR reps treat the interview process as a one-time deal. Therefore, it is my responsibility to prove my worth. When I negotiate a higher salary, it's not because I want the extra money (though it is a factor), it's because I want to prove to them I am worth at least that much to them (hopefully more).

At the end of the day, unless I'm a terrible employee, the employer still profits off of me and still "wins." There might some some opportunity cost here and there (they could have hired person B for $X less!), so from there on out it is my job to prove that I am worth the $Y salary that I worked so hard to negotiate. I don't want them to think about the "what ifs" of not hiring me, I want them to see the value I put on the table.

For me, personally, I always try to do my best work, no matter how much I am being paid (my latest contract job was $15/hour and was definitely way below my pay grade, but I put my best foot forward regardless).

Since I know that many other people will only perform to the rate at which they think they should perform at that pay level, that puts me at an advantage. I can negotiate a higher salary and prove that I will always over- deliver, thereby proving my worth.

I get a nicer salary, they get an exceptional employee, win-win.

Of course, if I end up not performing up to the price I put on myself, then the company is not getting what they are paying for, and I'll probably find my name on the list of lay-offs when it comes to that. Rightfully so, too.

</comment></comment></comment></comment><comment><USER8> Quite a lot similar posts recently. The more these points are repeated over and over again, the less relevant they are. That same advice you can find in articles from 50 years ago. As more people are pretending to be excited about the job no matter what and not motivated by money just to appear more attractive it lowers the performance scores everywhere and it just doesn't work anymore.

The most productive negotiations should be straight talk about the numbers and terms. You shouldn't just hope the other party is stupid and will agree to less than fair terms. When somebody brings up a number ask or explain where it comes from and how does it compare to other numbers. Ask if their offer is fair, something that they would take in your shoes, so that if they say yes and later on it turns out that was not the case, you can raise the issue with a good reason. If the other party starts to get forgetful, dodge questions or lie - fine, you can treat them as a hostile party, but it makes no sense to start off with deception and advantage play against your team. Especially in startups. Big companies have moved on from this more or less anyway.

</comment><comment><USER9> Generally speaking there are two kinds of negotiation situations.

One is a one-time negotiation, for example, buying a new or used car. All you care about is getting the best price. You don't really care if you're eating into the dealer's margins.

Second is a negotiation that is part of a long term relationship. Here you want to exit the negotiation with both sides feeling good about it. You don't want to jeopardize the relationship for the negotiation. You don't want to screw the other side over.

A job offer should be a type II situation. If any of the parties approaches it like a type I then they probably shouldn't be working together. The employee should get an idea of what they'll be happy with and the company should pay the employee what they'll be happy with. If the employee is approaching this with the idea of taking advantage of the company then it basically turns into a type I situation and the company should walk away. If a company is approaching the future employee as a type I negotiation the employee should walk away.

I was really excited in a previous job where I figured out what I thought I was worth based on my current comp and some research and when I asked for that I got an offer that was somewhat higher. That told me the company cared about making me happy more than they cared about the (negligible) extra $$$'s. That was all the negotiation. Both sides were happy and I was very enthusiastic on my first day. Now in a type I negotiation I would have been able to squeeze them for more money but this is not a type I negotiation.

Another situation where a fairly successful small web company offered me less than I was making at the time. When I tried to get some concessions in other areas like extra vacation time or more time working from home I was flat out refused. Their CTO interviewed and liked me, the team liked me, they got the CFO to tell me how they couldn't afford to pay more. They were really surprised when I declined their offer. From my perspective they were treating me as if they were trying to buy my car and that told me that's the way they would keep treating me if I came to work for them.

The way I see it if you've done everything right up to this point and if both sides are interested the offer is pretty much a mere formality. Not a starting point for bazar style bargaining.

<comment><USER10> > If the employee is approaching this with the idea of taking advantage of the > company

You should be aware that this is not possible... A company will never hire you for a salary it cannot pay, because they know very well their numbers. On the other hand, it is very easy for workers to be screwed because they don't know how much the company is willing to pay for that position. The only way to get to know how much the company can offer is to ask for a salary that is way higher than the first offer.

</comment></comment><comment><USER11> To add to point #3, (information is power), I would advise any candidate to do research into approx. salary ranges for the type of positions they've applied to and the geographical area in which they are located.

The author does lament the general trend of "pay secrecy" in part 2 [2] of his previous article on how he landed a job at Airbnb[1] but it's worthwhile to point out here. Almost any offer/salary does not exist in a vacuum but within the context of the current salary ranges (i.e. the market) for similar positions and also different positions.

Look at it this way: If I tell you that apples are 2 Simoleons (§) per lb, is that a good price? There's hardly any way to know, given that I quoted it in a fictional currency.

But if you know that oranges are 10§/lb, bananas are 5§/lb and that you can get a job at the grocery store selling them making 20§/hour, that gives some context to not only the prices of apples, but also the relative value of different produce and the ability to afford it. This is the essence of a market economy, which the job economy is an instance of.

Sites like Glassdoor and other efforts to share salary information[3] (even if they may be subject to reporting bias) are a good way to give you more information about the relative value of any offer, which will be another tool in your kit for negotiation. Read as much as you can, as in my experience it will be well worth your time.

1\. [http://haseebq.com/farewell-app-academy-hello-airbnb- part-i/](http://haseebq.com/farewell-app-academy-hello-airbnb-part-i/)

2\. [http://haseebq.com/farewell-app-academy-hello-airbnb-part- ii...](http://haseebq.com/farewell-app-academy-hello-airbnb-part-ii/)

3\. [https://blog.step.com/2016/06/16/more-salaries-twitter- linke...](https://blog.step.com/2016/06/16/more-salaries-twitter-linkedin/)

<comment><USER12> "information is power" <\-- amen to this. It's also important to gather another type of information, and that's information about yourself. You've got to be able to prove (detailed instances, dates even) how you've added value in the past (which hopefully means you can again). You need leverage for these negotiations and that involves knowing what you're worth and what the market thinks you're worth (not always the same).

</comment></comment><comment><USER13> Given my technical background (SWE), I have found only one useful tip for salary negotiations during a job offer: get atleast two offers and play the companies against each other. I've found nothing else to be effective.

<comment><USER14> Basically: have a real card to play that they think you might play. Companies will empathise to the end of the earth with you about anything, however you have to have that card.

</comment></comment><comment><USER15> This is a really good article and I would highly recommend it. In case other HN'ers are wondering, its complimentary to patio11's posts on salary negotiation. I especially agree with the point made at the end that it really helps if you try to understand the employer's perspective as well. Remember that the best outcome should be a win-win situation in which both the company and the future employee are happy with the outcome.

I really disliked to work in places where the job was very good but the pay was definitely not the best. The best way to fix this is to negotiate a good pay at the start: that way you can fully focus on the exciting work.

<comment><USER16> Yes, as in a sale, if both parties walk away happy it was a good sale. I feel there is way too much "screw the companies" attitude here.

</comment></comment><comment><USER17> I don't know why, but I get really frustrated at the negative sentiment around and apologetics for negotiation.

>I'm the first to admit that negotiation is stupid. It's a practice that inherently benefits those who are good at it, and is an absurd axis on which to reward people. But it's a reality of our economic system.

When incentives are opposed (like me wanting good wages, and companies wanting to pay me at little as possible, all else being equal), negotiation seems like the _only_ way to decide how to reach an agreement. Of course it inherently benefits people who are good at it! Those benefits are the things they are negotiating!

Instead of calling it an absurd axis to use to reach mutually agreeable terms, why can't we accept that negotiation is how reach those terms?

<comment><USER18> I see where you're coming from, and I think there are things negotiation does well.

Negotiation allows a company to offer more (or less) than a standard wage when a candidate genuinely offers more or less value for the same position. Economically, that seems like a good thing, and I consider that the principal virtue of negotiation.

But the downside is that negotiation enables candidates who are better at negotiating to command stronger offers (because they're more charismatic, or courageous, or just better studied in the practice of negotiating). That's clearly arbitrary. Negotiating skill is an axis that's mostly orthogonal to the value a candidate brings to a company. Here the public sector's system of having fixed, publicly known wages for positions is a good one. Candidates who are good at negotiating make just as much as candidates who are bad at it.

The question then boils down to how much of the variation in negotiated offers can be attributed to variation value as opposed to variation in negotiating skills.

I suspect it's weighted toward the latter. But if you think it's mostly toward the former, then I think it's sensible to claim that negotiation is mostly a good thing.

<comment><USER17> >The question then boils down to how much of the variation in negotiated offers can be attributed to variation value as opposed to variation in negotiating skills.

I think this covers most of it, but it all feels like it's only one side of the supply-demand equation. All else equal, the value to the company doesn't change whether you are one of 100 people with your skill set or one of a gazillion. But the wages certainly will. I think that's totally fair thing, and we can't get it with your model of just value to the company and negotiating skill.

</comment></comment></comment><comment><USER19> I stalled in comp and title for about 2 years due to an acquisition. While I was definitely maximizing my compensation, it was a miserable experience. Perhaps I lack the mental fortitude to not skip in to complacency, but for those two years there was no difference between an excellent job done and a mediocre one. After about 12 months of erring on the side of excellent, I just gave up. I did the minimum required and got paid handsomely for it. I eventually left and took a pay cut.

It may have been extenuating circumstances but I do wonder if I would have been happier with less compensation and more room to grow.

That being said, the burden of preventing overcompensation lies on the hiring manager. The candidate should push for as much as possible and the hiring manager should make a judgement call about whether the employee will have room to grow.

<comment><USER15> Taking a cut in salary in lieu of room to grow or anything else should be decided very very carefully. You must really understand that you actually do have an opportunity to grow; at the very least, you should know that its risky and have evaluated the risk as one worth taking.

<comment><USER19> Very true. In this case, it was actually an increase in salary but a loss of liquid stock compensation in favor of illiquid stock options.

Overall cashflow, it was a pay cut. Median/Mode outcome, probably still a pay cut. With extremely high variance, I believe the Mean outcome is probably a break even.

As far as not having room to grow, I can probably sum that up in a single word: Yahoo!

</comment></comment></comment><comment><USER20> There is an implicit assumption in this entire article:

That if you can't come to an agreeable negotiation of salary, you can walk away from offer N because there will be an offer N+1.

Maybe in The Valley or Manhattan or Austin, but in many other places, there is no "N+1". You don't have that implicit position of power with Company N that Company N+1 will give you what you're asking for. Or you don't have time to find N+1 before N-1 becomes untenable (or non-existent).

And yes, I'm talking about developer jobs.

</comment><comment><USER21> This whole thing seems so overwhelming. I understand negotiation is a skill that you can learn, but like anything else, it takes a _lot_ of practice to get really good.

In a way, negotiation is the polar opposite skill as computer programming. As a programmer, what you do is anything _but_ negotiation. You don't negotiate with PHP to get you code running the way you want it to. You tell it exactly what you want it to do, then PHP does exactly that.

<comment><USER22> You only say that because you're good at programming. I remember folks in the computer lab trying to negotiate with _god_ for their code to run...

<comment><USER23> Depending on the language or tooling I sometimes still do (is undef gt or lt 0?).

</comment></comment></comment><comment><USER24> FYI, This looks like a republish of his original blog post[1] that was discussed previously[2].

[1] [http://haseebq.com/my-ten-rules-for-negotiating-a-job- offer/](http://haseebq.com/my-ten-rules-for-negotiating-a-job-offer/)

[2] [https://news.ycombinator.com/item?id=12086876](https://news.ycombinator.com/item?id=12086876)

</comment><comment><USER25> Don't suppose anyone could link patio11's posts, could they? I've seen them referenced twice now, and would love to check them out :-)

<comment><USER26> Probably these

[http://www.kalzumeus.com/2012/01/23/salary- negotiation/](http://www.kalzumeus.com/2012/01/23/salary-negotiation/)

[http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a- pro...](http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

</comment></comment><comment><USER26> I enjoyed reading this post, as well as I did patio11's a few years ago, but I feel that a lot of the advice applies mostly to highly in-demand workers (read: software people). At least, so has been my limited experience.

<comment><USER27> Well obviously it only applies to software people.

That's why it was posted to HACKER news. :P

</comment></comment><comment><USER28> This guy is a legend!!

[http://haseebq.com/farewell-app-academy-hello-airbnb- part-i/](http://haseebq.com/farewell-app-academy-hello-airbnb-part-i/)

</comment><comment> shawn-butler "Exploding" job offers used to target people on their 1st or 2nd jobs with little or no experience in how the hiring process works is borderline unethical.

<comment><USER29> A job offer is a business deal. The earlier on you learn how to do business, the better it is for your career.

<comment> shawn-butler So are used car deals. That's why we have lemon laws.

Getting a good deal by fraud harms everyone involved.

</comment></comment></comment><comment><USER30> A couple of interesting talks (and article about one of them) about open source and employment contracts:

[https://lwn.net/Articles/688451/](https://lwn.net/Articles/688451/) [https://www.youtube.com/watch?v=H-m2ozX9zO0](https://www.youtube.com/watch?v=H-m2ozX9zO0) [http://meetings-archive.debian.net/pub/debian- meetings/2016/...](http://meetings-archive.debian.net/pub/debian- meetings/2016/debconf16/Free_Software_Companies_and_You.webm)

</comment><comment><USER31> > A job is just a deal. It is a deal between you and a company to exchange > labor for money (and other things you value).

This came naturally when I became a contractor. Rather than having a salary based on market rates, I was offering the services of my own company that has N value in a B2B deal. It does sound like an abstract point, but it completely changed the conversation at the table.

</comment><comment><USER32> This ruleset leads him to special sort of companies that "hunt stars at any cost". If you're so precious AND have speech skill, maybe that's for you. But maybe get less-tech, speech-oriented job then?

Most employees are just workers, not stars, and at least among my management environment there is a simple rule: skip negotiators. If he can't tell what he wants, we do not call again. If he said X, we do not negotiate _that_. Negotiation is about skill and whether he will work here or not, which position and/or responsibilities he will take. Not about salary. It is stupid to constraint employee's living and needs, no matter if these are first- or second-class needs. It is also stupid to not know how much you need.

<comment><USER33> I'm really curious what sort of company you work for (industry, small/medium/large, and country).

</comment></comment><comment><USER34> Enjoyed this read. The part that really stuck out to me was the exploding offers section.

IBM performed interviews at my college weeks (or more) before anyone else was even hiring. After doing the interview process and getting an offer, they wanted an answer within 2 days. Obviously I told them that this wasn't going to work, and they basically said it was too bad. A few months later, I got a call asking if I was still available (wasn't at this point). Be prepared to walk away in a negative situation like that, it says a lot about the company.

<comment><USER35> Agreed, exploding job offers is a great term for this.

</comment></comment><comment><USER36> Well reasoned post that I agree with many points. I had said in a previous thread and would add here, never forget you are the one in control and never be desperate.

</comment><comment><USER37> So when you're doing an initial phone interview and they say

"So what is your current salary, and what are you looking for ?"

What are you supposed to say ? Just stay quiet ? Mutter something about not being able to tell them ?

I'm all for negotiation, but it seems that every situation I find myself in, doesn't really lend itself to the described pattern.

<comment><USER38> My line is always "salary is something I'd discuss in a face-to-face interview".

If they push just apologise and say you're not comfortable discussing your salary over the phone.

<comment><USER37> Thanks. That seems a fairly reasonable way of addressing it.

</comment></comment></comment><comment><USER39> Am I missing out if I don't try and negotiate higher salaries or raises? I usually feel like what I'm being offered is fair but then again I wonder if I'm being cheated out of money. Like they are offering something low expecting me to request something higher.

<comment><USER15> You should really read patio11's article on it, but the short of it is that, yes, you should always ask for more. The simple reason being that they won't rescind your offer but might give you more, since they planned a salary range for that position.

<comment><USER40> Especially if you ask for a _little_ more. I had friend once who asked for _a lot_ more and they rescinded the offer; because they (probably rightly) figured the two wouldn't have a long relationship together if it's starting like this.

</comment></comment></comment><comment><USER41> The intro to this article is great. One of the reasons to avoid negotiating is because it's scary. All of us are smart people and can read tips on the Internet but it's hard to follow them it. Having someone in your social circle guide and coach you helps.

</comment><comment><USER42> I'm a big fan of Haseeb's writing. Looking forward to part two.

</comment><comment><USER43> Great tips and tricks because I suck at negotiating (trying to change that) and am currently looking for a new job which I have to get pretty hasty (since I'm moving for other reasons).

</comment><comment><USER44> Rule #11: Disregard rules 1 through 10 if you're a woman, because negotiating your job offer will hurt your career trajectory. Even HBR agrees: [https://hbr.org/2016/04/women-who-dont-negotiate-their- salar...](https://hbr.org/2016/04/women-who-dont-negotiate-their-salaries- might-have-a-good-reason)

<comment><USER43> Except what you are saying it total BS and you didn't even bother to read either the article you linked to NOR the study. A comment such as yours doesn't really belong.

That is given that that study is the exact fact, but it is indeed mostly a study based on polls which I would say is not exactly hard evidence.

</comment></comment><comment><USER45> Thanks for sharing. How to negotiate a salary hike during appraisal ?

<comment><USER46> Companies usually have some sort of "rules" that make getting meaningful raises (more than say 3%) "impossible" to keep employees from negotiating meaningful raises. I'm done with that phase of my career but when I worked as an employee, I found it was just easier to move on to another company when my salary fell too far behind my market value.</comment></comment>


The real CrowdSelling Platform Launched - <AUTHOR> https://www.intubus.com/

<comment><USER2> Old friend of mine launched [https://sellfy.com/](https://sellfy.com/) a couple of years ago, wonder how he's doing now.

<comment><AUTHOR> Gumroad last year raised about $8M. How's Sellfy?

<comment><USER2> I have no idea.. ;) I guess I'll have to ask him.

</comment></comment></comment><comment><USER3> e-junkie has been doing this for ages. But considering the service is free at the moment, it might gain some traction.

<comment><USER4> the site mentions a 5% commission fee on any sale - which is higher than comparable sites like Etsy (3.5%).

<comment><AUTHOR> Etsy does not solve the distribution problem. Embed the Intubus widget on your blog and your content will be appears on thousands of websites.</comment></comment></comment>


Language Server Protocol - <AUTHOR> https://github.com/Microsoft/language-server-protocol <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=11988446](https://news.ycombinator.com/item?id=11988446)

</comment><comment><USER3> I'm on the fence about this, standardization let's people pool resources to provide common functionality, but it also ossifies the interface so that doing anything _not_ supported by the interface becomes harder than before.

The first thing that pops into my head is that for languages with interprocedural type inference, I really want my IDE to show me what types it has inferred, but this is outside the spec and not even applicable to all languages.

<comment><USER4> With this,a new language can have an IDE integration done easily which can cover say 95% features. Some language specific feature may be obviously left out but getting a minimum viable integration to any supported IDE is a good thing.May be when this protocol evolves,it can give extension to the protocols to cover the other 5% features(or may be it is already there)

<comment><USER3> Heh. We'll see. Writing the glue code is not what makes writing language analysis hard. This is clearly a move to make the lives of IDE writers easier, rather than those who would be writing the analysis code.

<comment><USER5> But it'd make your analysis code work for multiple IDEs and editors instead of having to learn about each's peculiarities. One less thing to worry about is always good.

</comment></comment></comment></comment><comment><USER6> We're considering moving the new Rust language service over to this protocol, or possibly, having it as a default protocol while supporting other protocols.

Since I've been learning it recently, maybe some points to help understand it:

It's _just_ the protocol piece. Currently, VSCode will stand up the language server and communicate using the protocol over stdin/stdout. Nothing to say they couldn't support http servers in the future, but currently it seems lower level that that.

They do support hovers, which you can use for seemingly anything. We currently are using them for type information and showing API docs.

I'm hoping this takes on with other editors, as once they support it, then they'll get the stronger language support the servers provide, which can do hovers, on-the-fly error checking, code navigation, and more. It's not perfect, but as a baseline set of features, it's a pretty good starting set.

</comment><comment><USER7> This is great! Abstracting away static code analysis is very helpful for people like us building browser based dev tools.

I am the developer of HiveMind (crudzilla.com), I have been dragging my feet about plunging into static code analysis so this type of solution is definitely intriguing.

</comment><comment><USER8> Well, us emacs users will finally get some decent autocomplete. So that's nice, I suppose.

This actually sounds an awful lot like what Grok was trying to do. Any relation in the development?

<comment><USER9> See Kythe (Google OSS): [http://kythe.io/](http://kythe.io/)

<comment><USER8> Heh. Neat.

</comment></comment></comment><comment><USER10> I only glanced through the document, but I didn't see anything which could verify that the "Tool" and the "Language Server" are both referring to the same content. Is there a mechanism for handling this kind of synchronization drift?

<comment><USER11> See TextDocumentSyncKind and TextDocumentItem.

</comment></comment><comment><USER12> Does anyone know what tool was used to create that diagram?

<comment><USER13> I very much doubt it was used in this case, but [https://www.websequencediagrams.com/](https://www.websequencediagrams.com/) is great if you want to do Message Sequence Charts.

</comment></comment><comment><USER14> What happens when I don't have internet access? Do I install a second piece of software on by box?

<comment><USER15> The "server" in "language server" does not mean "server you access over the network" but "other process (on your machine) your editor talks to". (This is just the spec for a protocol.)

<comment><USER14> Can it be on across the internet? So, Apple can or cannot set up an internet service for Swift? If I think I have a better version can I point my editor towards that? If I program in a couple of languages, do I need to get ahold of servers to install?

<comment><USER16> > Can it be on across the internet?

In theory, yes the protocol can be used across the internet, but that would raise plenty of issues (security being a huge one). This is designed so that any program, like an IDE, can get code analysis and more without having to build special handling for each of them.

> So, Apple can or cannot set up an internet service for Swift?

Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.

> If I think I have a better version can I point my editor towards that?

Yes. You simply stop the currently running language server and start the one you want to use instead.

> If I program in a couple of languages, do I need to get ahold of servers to > install?

Yes. Each language would, in theory, provide its own server to do analysis. Of course, your favorite IDE would likely be more than happy to start the server for you if it's not running yet (as it's just a small process that runs in the background).

If you want to see how this works in practice just grab Visual Studio Code and start editing a Typescript file. This is already in use there.

<comment><USER14> > In theory, yes the protocol can be used across the internet, but that would > raise plenty of issues (security being a huge one). This is designed so that > any program, like an IDE, can get code analysis and more without having to > build special handling for each of them.

I'm pretty sure I would be ok at part of teaching a class.

> Again, in theory they could. But why would they do that? Just run the server > locally and get all the information there.

I was getting at that from the student-level. I'm pretty sure some metrics on edge problems in a remote learning class might help with the material revisions.</comment></comment></comment></comment></comment>


Ask HN: Cognitive behaviour therapy, tried and tested resources - <AUTHOR> I'm coming out of an extended spell of mental fog, and I would like to investigate self-administered cognitive behaviour therapy as part of my recovery and treatment. My local health service is running at capacity and so I'm looking at doing this myself, at least initially, in a responsible fashion.
I have a budget for ebooks and online courses. I would be grateful for advice or feedback on what is and is not worth investing time and money in. What works or worked for you or someone you know?
Thank you in advance. <comment><USER2> I have had amazing results with David burns books. As a matter of fact his cbt exercises in 'feeling good' have helped me so much that I've turned them into a software for my own personal use. This way I'm able to do his exercises on the phone / laptop very easily. My bdc score dropped from 20 to 5 in 3 months just doing that.

If you've read his books I'd be happy to share the link to my website (but it won't make a lot of sense if you haven't read his book though).

<comment><USER3> Turning the exercise into software sounds like a great idea. Do you mind sharing your website? I have gone through the book and it might be beneficial

<comment><USER2> Sure thing. It's at

[https://www.feelhappy.win](https://www.feelhappy.win)

Unfortunately since I made it for personal use there isn't a lot of documentation. But most of it would be easy to use if you're read the book

<comment><USER4> Hi.. :-)

Can't seem to get in, sent an email to your support address, got a "No mailbox" response.

<comment><USER2> edit: i tried it and everything seems to be working for me. you have to register first to load the app (just use any throwaway gmail). let me know the exact issue if you're still having probs.

ohh i guess it's having issues.. this wasnt supposed to be released but I'll have a look :)

also yeah no support or mailbox but if you have questions just shoot me an email (hn profile)

</comment></comment></comment></comment></comment><comment><USER5> The Australian website "mood gym" has an evidence base and is sometimes recommended by English NHS therapists. [https://moodgym.com.au/](https://moodgym.com.au/)

The book "Mind over mood" is also recommended by English NHS therapists: [https://www.amazon.co.uk/Mind-Over-Mood-Second- Changing/dp/1...](https://www.amazon.co.uk/Mind-Over-Mood-Second- Changing/dp/1462520421/)

The NHS has a page of apps. I don't have much experience with these, but the page does tell you how they assess apps: [https://www.nhs.uk/apps- library/category/mental-health/](https://www.nhs.uk/apps- library/category/mental-health/)

Good luck!

</comment><comment><USER6> David Burns' books are very good. Make sure to do the exercise as you go along to get the full effect. Also if your local health service is full, there are online options available, which can help complement the self work. This article is a good overview of the topic: [https://www.caredash.com/articles/what-is-online-therapy- and...](https://www.caredash.com/articles/what-is-online-therapy-and-is-it- right-for-you)

</comment><comment><USER7> I had a hard time being convinced by the usual 2/3-pagers that tell you CBT will change your life and then going straight to "just close your eyes and breathe and focus on your nose". It irks me to be told what to do and not why. If your brain works like mine then this suggestion might be useful, otherwise probably not so much.

I found a used version of Mindfulness and Psychotherapy[1], which is designed as an introduction and contextualization of mindfulness, aimed at therapists. Because of that, it gives more details and helped me see behind the curtain, which is what a lot of therapists don't think about sharing.

An example of that: early on, there is a discussion between the usage of "client" versus "patient" to refer to the people therapists will help (which would be you), and their choice of using "patient" \- as it means "one who bears suffering" -, instead of client - which means "one who puts themselves under the protection of a patron -, holds the implication the therapists are there to alleviate suffering.

[1] [https://www.amazon.com/Mindfulness-Psychotherapy-Second- Chri...](https://www.amazon.com/Mindfulness-Psychotherapy-Second-Christopher- Germer-ebook/dp/B00DG1H8WS)

</comment><comment><USER8> Russel Brand's book and video course were great for me - wasn't particularly what I needed but really opened my eyes to some of the cognitive distortions I have.

John Kim's books I also found useful.

</comment><comment><USER9> [random advice from the internet]

Ask your therapist for recommendations. It's the sort of thing that can be handled telephonically. Under clinical protocols, it probably adds a contact note to your chart which will enable follow up or bring a different practitioner up to speed (possibly, if they actually read your chart). In short there are not likely to be any downsides to asking...and in a time of stress, softballs from someone doing well is likely to be a bright spot in the midst of your therapist's grim regularity. Good luck.

</comment><comment><USER10> If you're interested in philosophy, Stoicism might help. A lot of CBT is based off of stoic principles. In fact the book, "How to Think Like a Roman Emperor" goes through that history and teaches you some really useful CBT techniques.</comment>