U.S. Hacker Linked to Fake Macron Documents, Says Cybersecurity Firm - <AUTHOR> https://www.wsj.com/articles/u-s-hacker-linked-to-fake-macron-documents-says-cybersecurity-firm-1494929136 <comment><USER2> Two things happened in the French election. First, someone created a forged document, purporting to show that Macron had a secret offshore bank account, and published it on 4chan. (The forgery was poorly done, and was recognized immediately). Second, someone hacked the Macron campaign's computers and published all their emails. (Possibly with fake emails mixed in, though I haven't heard of any specific emails from that dump being fake).

This article claims that the first of these, the forged document, was done by Weev (aka Andrew Auernheimer). However, the second of these - the email data dump - has not been attributed to Weev and was likely done by someone else.

<comment><USER3> Isn't weev supposed to be at least somewhat technically competent? The first leaked document seems to have been produced by someone with very little knowledge of image manipulation, or what actually happens under the hood of technology, given how trivial it was to prove that it was fake.

<comment><USER4> Weev is a high functioning polydrug abusing sociopath dedicated to short term pleasure. Don't confuse yourself.

<comment><USER5> Agreed. He has little to no actual skill, which made his conviction somewhat of a joke as well.

</comment></comment></comment></comment><comment><USER6> tl;dr: It's weev.

It will be interesting to see how, if at all, this changes the widely-held APT28 attribution hypothesis.

<comment><USER7> Two different incidents:

\- State sponsored email hacking

\- A kid on 4chan faked a document

<comment><USER8> Is the kid executing this purported forgery from his parents' basement?

</comment></comment></comment><comment><USER9> Non-paywalled link: [http://facebook.com/l.php?u=https://www.wsj.com/articles/u-s...](http://facebook.com/l.php?u=https://www.wsj.com/articles/u-s- hacker-linked-to-fake-macron-documents-says-cybersecurity-firm-1494929136)

<comment><USER10> Or Outline, for people without Facebook [https://outline.com/zBTYT5](https://outline.com/zBTYT5)

<comment><USER11> AFAIK, l.php does not require a Facebook account.

<comment><USER12> it still requires to give away privacy and go to facebook.com

<comment><USER13> That's cute, people thinking we still have privacy online. ISPs will be selling your browsing history soon enough.

<comment><USER12> You may have no online privacy, then too bad for you.

If you refer to the recent cancellation of a US law before it came into effect that would have reverted ISP selling customer data. Well you got it backwards. Anyways I'm not from the US and you'll be shocked to learn that I'm part of my own federated ISP[1] and that each subscriber has a say and is aware of what the ISP does, and privacy protection is a priority even when it is a governmental or police probe.

[1]: [https://www.ffdn.org/](https://www.ffdn.org/)

</comment></comment></comment></comment></comment></comment><comment><USER14> Keep this in mind when you read "Chinese" or "Russian" hacker and immediately assume it's state sponsored...

<comment><USER15> Interesting to see people downvote you, just a week ago the top comment here on HackerNews (on Macron winning), mentioned how there was "Russian metadata" in the hack [1].

Just goes to show you how people will believe what benefits them and downvote what's inconvenient.

[1] [https://news.ycombinator.com/item?id=14286630](https://news.ycombinator.com/item?id=14286630)

<comment><USER16> Put away the persecution fantasies, he's being downvoted because he's wrong. There were two separate incidents here: weev is behind the phony finance documents, _not_ the account hacks, which are still believed to be Russian in origin.

<comment><USER17> He is not wrong in general, though. Russia and China do have kids doing it for the lulz, as well as criminal groups.

So if you have clues on the country of origin of an attack, you still need additional evidence (such as methods used and choice of target) to be reasonably sure of state sponsorship.

<comment><USER18> Provided the Macron campaign had a competent chief security officer (coming straight from the industry) and was paranoid about security, and given the scale of the leak, it seems unlikely that it was the job of skiddies doing it for the lulz.

<comment><USER12> Macron campaign had a competent chief security officer ? Seems unlikely.

-edit- well then downvote me instead of providing a name and explanation that this guy was competent, macronleak was depicted as poor security practices and probably low level attacks[1]. Let's not forget that they got breached at least once beforehand during the campaign and the trend micro report[2] explained what to do to protect against these attacks which obviously was not applied (assuming the leak has not been orchestrated).

[1] [https://www.nextinpact.com/news/104217-edito-macronleaks- ou-...](https://www.nextinpact.com/news/104217-edito-macronleaks-ou-eloge- dune-meilleure-securite-et-chiffrement-echanges.htm) [2] [https://documents.trendmicro.com/assets/wp/wp-two-years- of-p...](https://documents.trendmicro.com/assets/wp/wp-two-years-of-pawn- storm.pdf)

</comment></comment></comment></comment></comment></comment><comment><USER19> I was reading some of the leaked emails. They are awful. Purchasing "legal highs" off the dark web. Cocaine. All sorts of horrendous stuff.

I think the En Marche! leak has many similar properties to the DNC leaks. Once many very incriminating emails were leaked, many "invested" parties jumped on the opportunity to inject fakes to discredit the whole.

If I was Podesta or Macron, and a bunch of private emails were leaked to show corruption, pedophilia, illegal drug use, etc., what would be my first port of call? Discredit the authenticity with fakes.</comment>


Steve Bannon Wants Facebook and Google Regulated Like Utilities - <AUTHOR> https://theintercept.com/2017/07/27/steve-bannon-wants-facebook-and-google-regulated-like-utilities/ <comment><USER2> Well shit I agree. I want to see all the instant gratification producing counters (likes/views/upvotes/retweets) regulated.

It modifies people's behaviour and has the proven capacity to train them like circus animals to jump.</comment>


A 2 month app experiment how Ratings/Reviews impact Visibility and Conversion - <AUTHOR> https://heyimakeapps.com/blog/the-effect-of-improving-app-ratings-what-happened-next <comment><AUTHOR> I created this experiment with the hypothesis; by encouraging people who love using the app to submit a rating (and review), it'll increase its likelihood of displaying higher in search results, and lead to more organic exposure & downloads on the App Store & Play Store.

After encouraging results over a 2-6 month period, I figured it'd be a missed opportunity to not share these tips & results, as the system I created required minimal dev overhead to get up and running.

I'd love to hear if people have had success with a system similar to this for their apps, big or small.</comment>


Mystery humans spiced up ancients' rampant sex lives - <AUTHOR> http://www.nature.com/news/mystery-humans-spiced-up-ancients-rampant-sex-lives-1.14196

<comment><USER2> Man, that's one hell of a clickbait title.</comment>


What I wish I knew when I became CTO - <AUTHOR> https://medium.com/sketchdeck-developer-blog/what-i-wish-i-knew-when-i-became-cto-fdc934b790e3 <comment><USER2> > I've found it a real struggle to get our team to adopt writing tests.

If you're struggling to judge the engineering culture of a company that you're considering joining, consider this indicative of a poor one. It isn't definitive, but it's something you should ask about and probe further. Ask to see their CI dashboard and PR comments over the last few days. When they talk about Agile, ask what _engineering_ techniques (not process!) they leverage. These things will tell you if you're joining a GM or a Toyota; a company that sees quality and efficiency as opposing forces, or one that sees them as inseparable.

When it comes to tests, there are two types of people: those who know how to write tests, and those who think they're inefficient. If I had to guess what happened here, I'd say: the company had a lack of people who knew how to write effective tests combined with a lack of mentoring.

That's why you ask to see recent PR comments and find out if they do pair programming. Because these two things are decisive factors in a good engineering culture.

<comment><USER3> PR comments I agree with, but after believing in unit tests for years I'm drifting slowly into the "waste of time" camp.

I'm convinced that unit tests don't usually find bugs. IMO, most bugs are edge cases that were an oversight in the design. If the dev didn't handle the case in code they're not going to know to test for it. Fuzzing is a much better approach.

At my current position I have the opportunity to work with two large code- bases, built by different teams in different offices. One of the projects has ~70% code coverage, the other doesn't have a single test. Exposure to both of these systems really bent my opinion on unit tests and it has not recovered.

The project with high code coverage is basically shit and has so many bugs that we regularly cull anything marked less than "medium" severity as "not worth fixing". This project was written by a team that loves "patterns", so you can find all sorts of gems like Aspect Based Programming, CQRS, N-tier, etc. well mixed into a featureless grey Java EE goo. We get so many bug reports that its someones job to go through them.

The other project with no tests is a dream to work on. Not a single file over a few hundreds lines, everything linted and well documented. Almost no methods that don't fit on the screen, no recursion. No bullshit "layering" or "patterns". I can't remember the last time we had a bug report, since our monitoring picks up any exception client and server side. Every bug I've worked on was identified by our monitoring and fixed before anyone noticed.

Whats the difference between teams that developed these vastly different applications?? I've worked with both teams for a while, and honestly, the engineers that wrote no tests are of far higher caliber. Use Linux at home, programming since they can remember, hacking assembler on the weekends and 3D printing random useless objects they could easily buy. The other team went to school to program, and they do it because it pays the bills. Most of the bad programmers know what they're doing is wrong, but they do it anyways so they can pad their resume with more crap and tell the boss how great they are for adding machine learning to the help screen that nobody has ever opened.

If your developers are great then tests would hardly fail and be fairly useless, and if they're terrible tests don't save you. Maybe there's some middle ground if you have a mixed team or a bunch of mediocre devs??

<comment><USER4> Let's break this down.

> I'm convinced that unit tests don't usually find bugs.

They don't, they test whether or not the API contract the developer had in mind is still valid or not.

> IMO, most bugs are edge cases that were an oversight in the design. If the > dev didn't handle the case in code they're not going to know to test for it.

You don't write test to find bugs (in 98% of cases), but you can write tests for bugs found.

> Fuzzing is a much better approach.

If you're writing an I/O intense thing, such as a JSON parser, then yes. For 80% which is CRUD, probably not.

> The project with high code coverage is basically shit and has so many bugs > that we regularly cull anything marked less than "medium" severity as "not > worth fixing". This project was written by a team that loves "patterns", so > you can find all sorts of gems like Aspect Based Programming, CQRS, N-tier, > etc. well mixed into a featureless grey Java EE goo. We get so many bug > reports that its someones job to go through them.

You are blaming tests for bad design choices. With the patterns raised unit tests only get you so far, integration tests are what help you prevent bad deployments.

> The other project with no tests is a dream to work on. Not a single file > over a few hundreds lines, everything linted and well documented. Almost no > methods that don't fit on the screen, no recursion. No bullshit "layering" > or "patterns". I can't remember the last time we had a bug report, since our > monitoring picks up any exception client and server side. Every bug I've > worked on was identified by our monitoring and fixed before anyone noticed.

So how many exceptions were raised due to bad deploys? Core review only gets you so far.

> If your developers are great then tests would hardly fail and be fairly > useless, and if they're terrible tests don't save you.

Failing tests don't have to do with devs being "great" or not. Developers must have the capability of quickly testing the system without manual work, in order to be more effective and ship new features faster. If the tests are one- sided (only unit tests, only integration tests), then this will get you only so far, but it still get's you that far.

Don't abandon good development practices only because you saw a terrible Java EE application.

<comment><USER5> > Developers must have the capability of quickly testing the system without > manual work

Running unit tests is hardly quick. Especially if you have to compile them. End-to-end are even worse, in this regard.

> They don't, they test whether or not the API contract the developer had in > mind is still valid or not.

If you're always breaking the API, then that's a sign that the API is too complex and poorly designed. The API _should_ be the closest thing you have to being set in stone. Linus Torvalds has many rants on breaking the Linux kernel's API (which, also, has no real unit tests).

It's also really easy to tell if you're breaking the API. Are you touching that API code path at this time? Then yes, you're probably breaking the API. Unless there was a preexisting bug that you are fixing (in which case, the unit test failed) then you are, by _definition_ , breaking the API, assuming your API truly is doing one logical, self-contained thing at a time as any good API should.

edit: As an aside, I'd like to point out that POSIX C/C11/jQuery/etc. are littered with deprecated API calls, such as sprintf(). This is almost always the correct thing to do. Deprecate broken interfaces and create new interfaces that fix the issues. Attempting to fix broken APIs by introducing optional "modes" or parameters to an interface, or altering the response is certain to cause bugs in the consumer of the interface.

> Don't abandon good development practices

Unit tests are a tool. There are cases where they make sense, where they are trivial to implement and benefit you greatly at the same time. Then there are cases where implementing a unit test will take an entire day with marginal benefit and the code will be entirely rewritten next year anyway (literally _all_ web development everywhere). It doesn't make sense to spend man-months and man-years writing and _maintaining_ unit tests when the app will get tossed out and rewritten in LatestFad Framework almost as soon as you write the test.

<comment><USER6> > implementing a unit test will take an entire day with marginal benefit

The benefit should be realizing that if you need an entire day to implement an unit test you're doing something very very wrong.

</comment></comment></comment></comment></comment><comment><USER7> > I've found it a real struggle to get our team to adopt writing tests.

I find this hard to believe. Do others CTOs / team leads find this to be the case?

I've been a CTO of two small startups with 3-7 developers. We've had resistance to tests at some points (myself included). We've solved it fairly simply. All pull requests (PRs) require tests. PRs are rejected immediately without tests. If a PR doesn't have tests and it is critical to get in, we open a new ticket to track adding tests. It isn't fool proof, but it does result in a high degree of test coverage.

And once developers understand how and where to write tests, they usually see the benefit quickly and want to write more tests.

<comment><USER8> I'm not a CTO but I do lead the dev team at our agency (was previously 16 devs, but we've slimmed down to 7 currently). I want to preface this by saying that at an agency, your biggest enemy is always time; sales teams have to sell projects for the absolute minimum in order to get a contract, so you can't waste time on non-essentials for most projects.

That said, the biggest resistance I have found is "this feature is due in three days, I need two and a half to finish, and then we have another half to review and find bugs." In the end, the biggest issue is that we have time to test on the spot or write tests, but not both. You can scrape by with just manual testing, but I don't think anyone would ever rely on automated tests 100%.

Our larger projects are test-backed, and our largest even reaches 90% coverage, but the only reasons we wrote tests for those was because we knew we would be working on them for 2-3 years and it was worth the time in that case. I wish this wasn't the case, but I've found it's always the argument against automated tests in my corner of the market

<comment><USER9> I always find code coverage such a useless metric: if you have two independent ifs next to each other and one test goes in one if and another test in the other you have 100% coverage. Congratulations. But you've never tested what happens when you go in both

<comment><USER8> I agree that it is a useless statistic, especially when comparing unit vs integration vs functional vs smoke testing. There are different types of tests and just because you are reaching 90% of your code does not mean you are thoroughly testing it.

The only reason I brought it up was to show that we don't skip test writing entirely and the projects where we do write them, it isn't like we just wrote a test to check that "Project Name" is returned on the homepage and called it a day.

</comment></comment></comment></comment><comment><USER10> So hiring is pretty hard but I kinda disagree with most of the points there..

* only hire when desperate

Strong talent is so hard to get you should probably always be hiring. If you're hiring too many people your bar is probably too low.

* only hire to keep up with growth

You need to be at least a little preemptive. The hiring process itself can take months, plus the time to train even good new hires is at least a few months, AND you need your most sr. engineers to help interview so that is time they aren't writing features when you're trying to hit that critical milestone.

* Don't hire someone to do something you've not yet figured out

This is probably also a mistake as software engineering has become pretty specialized. Specialized Frontend, Devops, or Data engineers can bang out solutions even a strong generalist would take ten times longer to even approximate (and most likely anything they build will be throw-away). There is huge low hanging fruit in engineering productivity /business value to getting at least a decent 80% solution for most of these areas that it's worth hiring at least one strong specialist to help Shepard development.

<comment><USER11> > Don't hire someone to do something you've not yet figured out

I think this is not an indictment of hiring for something you do not know how to do, so much as it is of hiring someone before you have a defined job for them to do.

When you're hiring an engineer, presumably you'll be placing them onto a team that is responsible for some well-defined part of the stack. So you should know what skills you're looking for when you're interviewing. This should make interviewing easier; if you know what capabilities you need a new hire to have, then you know exactly what to test for in new candidates.

(This is yet another reason why generic whiteboard interviews make no sense. They're optimizing for solving problems that could be wholly unrelated to the problems your company faces on a daily basis. I'm surprised more companies do not give interviews that focus more specifically on their relevant problem domains.)

If you don't know what the new hire is going to do when he or she starts work, then you have no idea what skills to measure in the interview, and end up settling for the "least common denominator" of whiteboard coding ability.

<comment><USER12> The Whiteboard is nothing more than a hazing ritual testing marathon runners on their 100-yard dash. As CTO I opted to go for two-pronged:

1) give them a take-home project in an area relating to the position they want to weed out the unqualified.

2) bring them on site and speak with them in persona along with other members of the team they will be joining.

3) Its fairly easy to tell whos a whos an impostor if you are knowledgeable yourself, but a group of engineers can identify a faker fairly quickly.

4) Always consult your team about the new hire and don't make it unilaterally or their failures will reflect on you. Even their success won't make up for it if they turn out to be a nutjob and you vouched for them.

</comment></comment></comment><comment><USER13> Enjoyed reading this article, all valid points. However, the one thing that stood out to me in this area was how light I was in effective principles of management and leadership. As a CTO of an organization of more than a handful of people you eventually "get things done" largely via other people rather than being hands on yourself. Had to read a lot of Harvard Business Review to gain the skills and confidence for that. Just like programming, there are indeed tangible skills to learn. It's not just common sense and you're not just born with it.

<comment><USER14> It's funny how, as you progress through a career and gain responsibility, those HBR articles go from seeming like a bunch of Markov chain corporate- speak to being on-target for that exact problem you had last month with the leadership team.

<comment><USER15> Are you sure they really have any more meaning, or are you just ascribing them meaning that exists more in your "evaluation context" than in the text itself?

Compare: the way meditation is usually taught. There is something "there" to communicate, but meditation teachers mostly fail to communicate it. To use an old phrase, they are "pointing at the moon"—but, to stretch the analogy a bit, they're doing this pointing _indoors_ , where the sight-picture you get by following the tangent of their finger does not, in fact, contain a visible moon. You have to _imagine_ taking the thing they're doing (pointing), and reframe it in a context where there _is_ a hypothetical moon to see. Whether that helps you find the moon is more about what you know about the sky and fingers and angles, than it is about how well the meditation teacher can point. And this is _why_ the teachers end up failing to communicate: they did not, themselves, figure out how to "reach enlightenment" by absorbing a verbalized lesson, but rather by pondering a gestalt mess of ideas that have little in the way of words associated—so they can't just turn that gestalt mess back into words.

So: are HBR writers pointing at a visible moon, or are their words Markov- chain-speak because they're trying to backwards-chain the gestalt mess of their own _mostly wordless_ understanding into a verbal lesson?

<comment><USER16> What is up with the disrespect I constantly hear for wordless understanding? Not everything is best communicated verbally. There's a reason traditional education is often described as a series of falsehoods.

<comment><USER15> There's nothing wrong with wordless understanding per se; the thing that's "wrong" is thinking that you _have_ words (i.e. a teaching) that can effectively, _repeatably_ communicate a concept, when you actually just have a wordless understanding.

The problem of meditation teaching is false positives: people experience enlightenment while pondering some koan, so they think that that koan actually _helped_ , and pass it on. It's superstition. Anything could have helped. Something that truly helps, should help _more people_ than average, _more often_ than chance—and if you've got that, you've got words.

<comment><USER16> False dichotomy. Understandings aren't completely wordless or wordable. They fall along a scale.

> Anything could have helped.

If something helped a person, and they want to pass it along, even if it's difficult to communicate in a tangible fashion, I'm not going to stand in their way.

<comment><USER15> Sure, but If I want to _learn_ a difficult-to-communicate lesson, I would hope that the people who have a wordless understanding would keep their communicating to themselves—unless-and-until they come up with some coherent words to match their thoughts, that they can be sure can be used to reconstruct those thoughts without their brain there to help.

People don't yet know what they don't know, until they know it—so it can't be the _learner 's_ task to preemptively avoid vacuous lessons. That responsibility has to fall to the teacher.

<comment><USER16> Sometimes what sounds like nonsense hints at a higher truth.

[http://m.nautil.us/issue/40/learning/teaching-me-softly- rp](http://m.nautil.us/issue/40/learning/teaching-me-softly-rp)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I have quit jobs because we kept bad hires too long and then didn't fight to keep good hires from walking away. I think grooming and retaining talent is just as important as providing technical leadership. You need to be strong in both areas.

<comment><USER18> I've seen exactly this in a local well-regarded startup. Incompetent hires with problematic behaviors thriving and being protected, and competent hires being unprotected, not cared about, and almost pushed out.

They would hire almost anyone, and then not take active action in maintaining a healthy staff. Needless to say, it's not going very well over there, regardless of the CTO being quite technically proficient.

<comment><USER19> Incompetent PMs can be an issue too, between inaccurate/incomplete feature planning and shoving their responsibilities onto unwitting developers. I'd argue that a great PM is worth as much as the much-vaunted 10x developers, if not worth much more.

</comment></comment></comment><comment><USER20> What always stands out about startup reflections like these is how utterly undefined, freeform, and rapidly evolving the roles can be.

The old fire hose saying is true, but it's not just that you're drinking from a fire hose, it's that you often don't know what's coming out of the hose next. One minute deep technical decisions, the next minute helping to establish hiring philosophy, and cashflow and growth always on a background thread.

After a few years of this I think my experience is not uncommon. If you exit and through whatever circumstance (success or failure), come back inside an F500 company, you realize that trial by fire has force fed you a vast amount of new skills without even realizing it.

On one hand, the realization is really empowering, the realization you feel comfortable taking on various high impact tasks without much thought that you could have never jumped right into before. On the other hand, it can feel limiting, because F500 companies tend not to encourage even the most talented technical people to cross roles and help define company wide hiring practices.

It's an invaluable education, but I don't know if MBA is quite the correct ananlogy, not sure what a better comparison is.

</comment><comment><USER21> Much of this is summed up to be:

CTO positions are much more about technology vision (e.g. choosing frameworks/technologies that can last + serve your needs today and tomorrow) and hiring/retaining talent. Everything else is gravy.

<comment><USER22> Is the choosing frameworks and technologies really a thing that CTOs do? That seems like more of a tech lead/architect job to choose the right tool for the job. I could see the cto pushing back on those choices from time to time if something is being drastically over engineered but declaring what technology is being used seems like a job far below a cto.

<comment><USER23> In a word, no. But in startup-land, where the total number of people on the engineering team is, say, less than 10, chances are good that the CTO will also play a lead engineer and/or architect sort of role, in which case they will play a part in designing the architecture, selecting frameworks, and so forth.

CTO of, say, US Foods? No, of course not.

<comment><USER24> Why call the role a CTO then? If the role is closer to a tech lead or architect, just call them an architect.

This has always confused me in start up land. There will be a full c suite in a company of 10 people, despite that those c suite folks day to day would look nothing like a corporate position.

Just call it what it is instead of inflating titles.

<comment><USER25> What do you call the person running the company of 10 people? I guess "team lead" would be a non inflated title, or just "manager"? It would be pretty strange to have to explain that title to anyone outside of the company though

<comment><USER22> "founder"?

</comment></comment></comment></comment></comment></comment><comment><USER26> > Don't hire someone to do something you've not yet figured out

Hum. I would say the reverse. Bring people that are smarter and know more than you.

<comment><USER27> If you don't know how to do something yourself, you wont even be able to identify someone who is better than you in that field.

I've seen people who don't know how to market their product go out and try to hire a marketing guy. You might luck out and get someone perfect for you, but I've never seen it.

Usually they just end up wasting a lot of money and learning some hard lessons.

<comment><USER28> So how do you hire effectively as a CEO? There are too many areas for you to be knowledgeable, yet you need to be able to hire top talent across a variety of areas.

<comment><USER29> The method I've found is to ask people I respect a lot, "Who is the best X that you know?" Then call/email them, saying, "I'm the CEO of Y, and I'm trying to find out what a good X looks like. So and so said you're the best she knows. Can I have 30 minutes of your time?"

Do 5 of these, and you'll have a good idea of what someone good looks like. (And those 5 may give you some candidates)

This is very difficult though because things like "organizes the team to hit quota every quarter" can come in many different manners.

</comment></comment></comment></comment><comment><USER30> "Only hire when you feel you're completely desperate for the role". Maybe for a tiny, extremely lean startup. But for anyone else if you wait until you are desperate you will end up hiring the first person that you think might do the job. That doesn't sound like the right way to go to me. But maybe "desperate" is relative.

<comment><USER31> Although I'm not a founder, the rule I espoused in the early days (<20 people) was to not hire for a role unless 50% of a person's time was collectively being spent on that role across the company. This was a great way to be disciplined in determining what was actually a bottleneck for our growth.

</comment></comment><comment><USER32> > _...it's a blessing that my predilection for hipster technologies has not > caused any serious problems._

It's entirely possible that this was the primary source of his problems with hiring, firing, testing, and a lot more.

The technology you choose determines which technologists you attract. And it's not a superficial thing, it actually says everything about the CTO's own technical skill, judgement, and experience.

<comment><USER33> I was thinking that most of the problems he notes are the result of that litany of tech. How much of that was really necessary or appropriate?

</comment></comment><comment><USER34> As time goes on, the CTO becomes a pretty flexible position, somewhat analogous to that of a COO. This article was useful for me to figure out the kind of options I had as a CTO, in terms of specializing, as the company got progressively bigger: [https://www.linkedin.com/pulse/five-flavors-being-cto- matt-t...](https://www.linkedin.com/pulse/five-flavors-being-cto-matt-tucker/)

Early on, like OP discovered, you pretty much have to do it all, but you slowly remove yourself away from a lot of those tasks as you find better people to replace you in those areas.

</comment><comment><USER35> I like reading posts like this one. May be they serve as a form of therapy for me that I'm not in this alone. There are others in a similar boat, fighting the good fight, making similar mistakes, and having the same realizations.

Very well; now, I can go back to work with my head up high. :)

</comment><comment><USER36> > "I appreciate now that technologies have a surprisingly short lifespan"

This fact alone makes me so glad that I stuck with older tech that has withstood the test of time for our own SaaS. I _know_ that we have users from bleeding edge tech companies sign up for our service, then run away when they glean the 'ancient' tech that it runs on - but then again, I think we have outlasted many other new tech frameworks/languages that have rocketed on high, then fizzled out into obscurity in that same time.

<comment> wu-ikkyu What was the stack?

<comment><USER36> Front end is basically Bootstrap + jQuery (o_O) Back end is Ruby, but built using Padrino, based on the Sinatra framework instead of Rails. Not exactly 'old' tech there, but not nearly as cool or fast moving as Rails, Go, Rust etc.

</comment></comment></comment><comment><USER37> > hence why cloud providers can offer $100,000 initial credit

Is this a thing? How can my company get $100,000 of AWS on credit?

<comment><USER38> That kind of offer is generally only available to startups that are in an accelerator program

</comment></comment><comment><USER39> > Don't hire someone to do something you've not yet figured out (some > exceptional candidates can bring new capabilities to companies, but often > the most reliable route is for some "founder magic" to re-assemble the > company until it can perform the new thing)

I'm curious what this "founder magic" bit means. Is this advice largely because of the difficulty of trying to find a qualified expert to bring new capabilities to your company when you personally aren't familiar with that area? E.g., it's hard to not get the wool pulled over your eyes by someone who talks well but can't deliver?

<comment><USER40> Unless you are hiring someone for a VP type role, your new hire likely isn't going to step in and know exactly what they should be doing everyday to achieve the goals you have laid out for them.

So you have to try it all out yourself first and figure out what makes someone in this role successful, what makes them not successful, and how to create a process or blueprint that your new hire can follow to success.

<comment><USER41> Specifically: in a company of five, don't hire a customer service person if you haven't done customer support yourself at least a bit. Don't hire a database person if you yourself (or somebody internal) hasn't already tried [and presumably failed].

Experience and Failure are important guide-posts to help you look for the right person to fill that role. Where are they better than you? Then you have to mentor them so they get to be better than themselves so they can make your next hire(s).

</comment></comment></comment><comment><USER42> Yo, why are you doing BI queries on MySQL?

<comment><USER43> I'm no fan of MySQL either, but probably because they were already using MySQL and they had some Business questions they wanted answered Intelligently without setting up a bunch of new infrastructure. Sometimes at a startup you just need to get things done, and fix it later when (if) it becomes a pain point.

<comment><USER44> Definitely the kind of thing you use a dedicated replica for

<comment><USER45> Really not a replica. That is a fine shim for early days but it means you are severely limited to what you can do with reporting based on the data structure prod has. A better pattern is prodDB->Kafka/kinesis streams to a reporting DB like redshift/snowflake/big query. That way you can shape the data however you need, and it lets data teams avoid bogging down engineering.

<comment><USER44> That's putting the cart miles ahead of the horse at small-medium organizations. SQL scales a long way. It's not a shim - it's the best way to do business until the technology is a limit for you. Modern RDMS can go a long way.

Scale enough to have people dedicated to building and maintaining data lakes is a late stage problem. Who's going to go build and maintain that reshaping of data?

<comment><USER45> I guess I really value data, especially for early stage companies trying to understand users and find fit. I don't think the DB needs to be a dedicated analyticsDB, MySQL and especially Postgres work great for analytics. My issue is with read replicas. In most cases it doesn't make sense to force the prod DB to have an analytics friendly schema for the replica to use. Making all those views and interesting in them as important business questions come up shouldn't require a production DB migration.

That said I'm helping an early stage company and an AWS read replica plus Metabase is meeting most of our needs fine for today. We'll probably start pushing events to bigquery soon so we can make some metrics that would otherwise take crazy joins and sub queries.

<comment><USER46> Most early stage companies will be writing queries directly against OLTP tables - which is why a read-only replica of your master DB is the safest/fastest option.

</comment></comment></comment></comment></comment></comment></comment><comment><USER47> >Of the list, AngularJS and MySQL have been the only ones to give us scaling problems. Our monolithic AngularJS code-bundle has got too big and the initial download takes quite a while and the application is a bit too slow. MySQL (in RDS) crashes and restarts due to growing BI query complexity and it's been hard to fix this.

Maybe they should try TiDB([https://github.com/pingcap/tidb](https://github.com/pingcap/tidb)). It is a MySQL drop-in replacement that scales.

</comment><comment><USER48> It's funny you mention that you had difficulty having your team write tests. At my company, the CTO has difficulty writing tests and the team has consistently written adequate test coverage.

I fixed this in a new project by starting with jest [1] and failing the CI if the test coverage wasn't at 100%.

[1] : [https://facebook.github.io/jest/](https://facebook.github.io/jest/)

<comment><USER46> > failing the CI if the test coverage wasn't at 100%.

This is horrible advice and should never be followed.

<comment><USER48> Why? It's not hard to do if you start a fresh project.

<comment><USER49> Just because you have coverage doesn't necessarily mean that you have written good tests.

That being said, we do something similar where we require 80% coverage.

<comment><USER50> The difference between 80% coverage and 100% coverage is overrated. 80% is more than sufficient, i'd even go ahead and say 70% is better.

100% goes into "change detecting test" territory. There's also the time aspect: going from 0-70 is not hard, 70-100 is extremely time consuming, and often not worth the effort.

Monitoring is a way more efficient tool at catching issues.

<comment><USER49> While I agree with 70% is about the sweet spot, it really depends on the tools you're using.

We've found that with using Jest and just doing snapshots you can get to 70% without actually testing any of your others methods, hence the 80% coverage requirement.

</comment></comment></comment></comment></comment></comment><comment><USER51> > You accept long-term "technical debt" with the adoption of any technology.

how long have they been using perl5 over at craiglist?

</comment><comment><USER52> Re: getting your team more interested in testing. This is not an easy thing to get momentum on if people aren't used to it. Yes to getting the test time down (and keeping it down)

Also, try defining (maybe in collaboration with the team) the tests you want people to write rather than leaving it up to them or (hopefully not) expecting 100% coverage. I wrote this on my thoughts a while back [https://getcorrello.com/blog/2015/11/20/how-much- automated-t...](https://getcorrello.com/blog/2015/11/20/how-much-automated- testing-is-enough-automated-testing/) We had some success with increasing testing using that and code review so others could check tests were being written. Still not total buy in to be honest but a big move in the right direction :)

One surprising thing was that after years of thinking I was encouraging my team to write tests, the main feedback on why they didn't was that the didn't have time. Making it an explicit part of the process and importantly defining what tests didn't need to be maintained forever really helped.

</comment><comment><USER53> I just write the gherkin in comments, interleaved with the test code. No messing with regexes

</comment><comment><USER54> Why are so many self-appointed startup CTOs so anxious to share startup advice?

</comment><comment><USER55> I recently interviewed with these guys. Was not impressed.

</comment><comment><USER56> Great article!

</comment><comment><USER57> If your engineers don't write tests you hired the wrong people. Testing is vital. Make a rule: Every change needs to be tested (you can even set up a pre-commit hook for this. If a class has no test, one has to be written. If tests can not be written easily for a class, it has to be refactored.

<comment><USER58> > _If tests can not be written easily for a class, it has to be refactored._

How do you make sure that the refactored class does the same thing as the old one? Rewriting old code that you don't have test coverage for is way riskier than whatever small change you were going to make to it.

I write a lot of code without tests because a lot of legacy codebases aren't set up to be testable, _but they work_ , and it's important to the business that we're able to deliver small bug fixes and incremental improvements on the existing code while we write whatever replacement system we want to write. As I work on them they'll slowly get more testable, but if you're abandoning working code because it has no tests, you're usually making the wrong decision. (Which the author recognizes.)

<comment><USER59> > How do you make sure that the refactored class does the same thing as the > old one?

This. This is the problem. The answer, with tests.

<comment><USER58> What properties do you write tests for, though? Presumably you're touching the code because there's something wrong with it. How do you know _how much_ of it is wrong? How do you know that all callers are actually thinking the current behavior is wrong, instead of one caller misbehaving and another caller expecting it (possibly because someone noticed and worked around it, and now that workaround is going to break)?

Tests are simply the implementation of knowing what the code is expected to do. If you don't have any basis for that expectation, writing tests is meaningless - either you test the current behavior of the code, which doesn't help you change anything, or you test your imagined behavior of the code, which doesn't help you validate anything.

<comment><USER59> I agree, and commend how well you've noted the problems when code is written without tests. Such a codebase becomes mentally exhausting and expensive to probe into; much more expensive than the original time saved by ignoring testing practices altogether. Sure, a huge amount of legacy software may not have tests, let alone comments. Then yes, it's like where do you even begin and have any confidence in what youre testing for. But ignoring proper testing practices in new, modern codebases, especially in a business where the single product or service offering is software, is extremely risky and irresponsible. This is a little ranty because why are devs justifying not writings tests in 2018!

</comment></comment></comment></comment></comment><comment><USER60> > I appreciate now that technologies have a surprisingly short lifespan

That's pretty much only true in the Javascript ecosystem. Every other areas of the technological stack usually see lifetimes in the decades.

> Stepping aside from pure technical decisions, the life-blood of being a CTO > is people management

Not really, no. That's the job of a CTO at a start up, not at a larger company. I'm not sure the author of the article has actually learned the right lessons from his experience.

At the end of the day, CTO of a start up is not really a CTO role in my opinion. It's a technical co founder. You just happened to be the most senior person of the team at a point in time and you inherited a few leadership responsibilities in the process.

I've seen a lot of start ups fail because they fail to recognize that fact and didn't realize that after a few years, they needed a different CTO than the co founder, someone who understands that role at scale and the many tasks it implies that are not necessarily relevant to the early years of the company.</comment>


Show HN: a multiProcess scheduler in Python - <AUTHOR> I was recently involved in a job change, and for that I have been doing a lot of programming interviews (white board questions). One common question on those interviews were: "how to implement a scheduler?" follow up by "how to make it multi-processing?". I have to confess that I only had a clue on how to do that.
After the interview period, I started searching for a solution for that, and could not find one. To be more specific, the std python implementation for a scheduler says "No multi-threading is implied; you are supposed to hack that yourself, or use a single instance per application."
So that's what I did, I hacked my own implementation of a multi-process scheduler in python:
https://github.com/thalesfc/Multprocess-Scheduler
What do you guys think? How to improve it? <comment><USER2> clickable -> [https://github.com/thalesfc/Multprocess- Scheduler](https://github.com/thalesfc/Multprocess-Scheduler)

<comment><AUTHOR> thanks</comment></comment>


The Implicit Social Graph - Whats its value? - <AUTHOR> http://cheolhominale.posterous.com/the-implicit-social-graph-whats-its-value#

<comment><USER2> I think the "location" implicit social graph is just one of many. It might be the easiest to grok, but it doesn't strike me as the most useful.

I like Fred's example of people with similar music taste on last.fm. I like the idea of being connected with people who will attend the same event as me, or an event I wish I was at, or whose netflix ratings correlate highly with mine.

I would imagine that eventually, the _explicit_ side of things will more be addressing the privacy issue you mention. But really, I want my graphs to be generated for me with the least work possible.

Instead of a social dating site, what about an implicit social graph approach: show me people in this coffee shop who are open to being approached for a brief chat. Show me people in this city who are willing to grab a beer with a stranger in town for the night who have similar interests.

Lots and lots of interesting stuff will become possible as we start to master all the information and implicit connections available out there even today.

<comment><AUTHOR> i agree that use case for graphs around interests are possibly a better use. If you look at Yobongo (YC), I think is exactly what you're talking about in showing you people near you that want to chat or go out within your city.</comment></comment>


Ask HN: How do you navigate being assigned to uninteresting projects? - <AUTHOR> I work as a sort of scientific programmer and am  well paid for what I do. However, when I joined the (medium size) firm, I was assigned to a project that is somewhat interesting but ultimately unrelated to what I'm both good at or interested in. I figured that I should learn these new skills and it would get more interesting over time, but it's mostly led to a lack of interest in work and envy of my coworkers who are in groups that work on "sexy" projects.
I asked about transferring, but I got the impression it would "reset" me experience-wise, and didn't seem guaranteed to give me interesting work. On the flip side, I have a great boss who I am reluctant to leave because that's pretty rare.
I'm sure this is a common feeling. Is this just a case of "the grass is always greener" or should I consider finding something new? How do you navigate these kinds of questions for yourself? <comment><USER2> I face a similar dilemma too. A good work environment is hard to come by and I relate with your reluctance to lose it. I guess you just have to weigh what comes higher on your priority list- mentally satisfying projects or nice boss.

P.S.- wouldn't hurt to consider what will look better on your resume :)</comment>


Ask HN: Fireball in the sky - <AUTHOR>

On Friday evening (11/21) I was walking home (in NJ) at around 8 PM and I saw a fireball streak across the sky.  It's hard to describe the size of the ball but let's say it looked to be about the size of an airplane, but moved very quickly and left a yellow streak in its path.  It was a pretty spectacular once in a lifetime type of sight...but it left me scratching my head and asking myself what the hell was that?
I searched for a news story about what happened Saturday evening and this is the closest thing I found (an incident from a different day, same week): http://www.montanasnewsstation.com/Global/story.asp?S=9390870&nav=LpDZ
And here is a YouTue video about the meteor from the above story: http://www.youtube.com/watch?v=e_2aX-784sw
The fireball I saw was about a fifth of the diameter, much less bright, and its trajectory was much more horizontal- it looked like it wouldn't hit the earth for a while if it kept on its path.
My best guess after a little research on the web is that I saw part of the Leonid meteor shower.
Anyone else see anything similar in the past 7 or so days? <comment><USER2> I've seen these things in the sky over Stockport about 6 times now, they're never falling, always travelling as a plane would. On new years eve four of us saw one going along as usual but then split into 3 and go in different directions. Whatever these things are they seem to have a flight path over our house as we've only been there 6 months and seen them 6 times! I've seen mereorites falling before and they're definately not those and I live near Manchester airport and know for a fact they're nothing to do with planes. They are definately big balls of fire travelling through the sky. Weird!!!!!

</comment><comment><USER3> I saw something just like this from Orlando, Florida (I live in Alberta but was there for a trade show) on Tuesday, the same day as the police cam.

The one I saw didn't make as huge a flash at the end, but it was still the most incredible thing I've ever seen in the sky. I was with a friend (who didn't see it) and told him that I just saw something that absolutely had to be fireworks (even though it was going horizontal and not like any other fireworks I'd ever seen) because it was so bright and amazing, and we weren't far from Disney World. But turns out it was a meteor...

<comment><AUTHOR> Yes, that reminds me a lot of what I saw. Something like fireworks but horizontal and a single large (relative to fireworks) streak.

</comment></comment><comment><USER4> I'd bet heavily that it was a meteor of some kind. The different compositions will produce different colors and they can enter the atmosphere at many different angles. But there may not have been a report because you may have been the only one to see it! They happen so quickly and you have to be looking up at just the right moment.

I once saw one (fiery streak then short burst of flaming goodness) sitting on the Hudson shore in Hoboken looking across at the NYC skyline. I'll never forget that, especially with revelers nearby jamming to Latin music.

</comment><comment><USER5> Didn't see your fireball, but your description sounds a lot like the streak of the space shuttle in its reentry before landing that I saw a few times from Texas in the 1990s -- went from horizon to horizon rather quickly, like a glowing jet contrail in the night sky.

</comment><comment><USER6> i see dead people</comment>


Firefox Test Pilot is flying off into the sunset on January 22nd, 2019 - <AUTHOR> https://medium.com/firefox-test-pilot/adios-amigo-51bec2a00072 <comment><AUTHOR> Note: I've used the first sentence of the article for the submission, since "Adios, Amigo" doesn't tell anything useful.</comment>


The Perils of Being Suddenly Rich - <AUTHOR> http://www.nytimes.com/2007/04/21/technology/21hayden.html <comment><USER2> I'm sorry, but I just can't help but not feel bad for these people. If you set yourself up for a fall like that, you get what's coming to you.

I think my "perils" would be a bit more reasonable, like paying off my school loans, helping my parents out, and basic things like that. If I ever irrationally waste money as he did (and borrowed money, no less), I hope that the same outcome befalls me.

Another point is that he wasn't "suddenly rich" anyways. He was buying things with money borrowed against the company. I would think that a wise man would at least wait until the money is definitely there before buying multiple homes and throwing away money in various ways.

</comment><comment><USER3> The perils of being a moron with your money.

</comment><comment><USER4> This excerpt from the book "Burn Rate" (about the early days of the first internet bubble) is interesting wrt this guy Hayden and his first venture:

<http://www.wired.com/wired/archive/6.06/es_burnrate_pr.html>

Not particularly flattering.

<comment><USER5> The fact that he married into the Maxwell family shows he's more of a lame gold digger than an inspirational or sympathetic figure.

</comment></comment><comment><USER6> I suspect it's an urban legend, but I heard that the day Priceline IPO'd one of the execs went down to the car dealership and bought a Porsche, and then crashed into a tree going 100mph and died on the way to the marina to buy a boat.

<comment><USER4> The basic story actually happened in the 80s (see the second paragraph): <http://en.wikipedia.org/wiki/Eagle_Computer>

</comment></comment><comment><USER7> This guy is sort of a sympathetic figure, I guess -- more than the NYT headline would suggest. It's a cautionary tale should any of us do well.</comment>


Apple has peaked — for real, this time - <AUTHOR> http://qz.com/22490/five-reasons-apple-has-peaked-for-real-this-time/

<comment><USER2> Ugh the site blows on mobile. It loaded an article about a Greek journalist instead. Why can't people be happy with a regular website.

<comment><USER3> It blows on desktop as well.

</comment></comment><comment><USER4> As far as cheap, sensationalist headlines designed by trolls to grab traffic, this one isn't even very good.

The five reasons given are all pretty flimsy.

Do you seriously think that's _it_ for Apple, that the iPad was their swan song?

This is like declaring Pixar "peaked" after Toy Story 2.

</comment><comment><USER5> Same old story as it is read on the linked site - opinions galore (like mine here of course). Article was not really my cup of joe as nearly all the arguments were speculative to say the least.</comment>


Steinhaus Longimeter - <AUTHOR> http://cstaecker.fairfield.edu/~cstaecker/machines/longimeter.html <comment><USER2> He groans with disappointment in the video that the longimeter and the map measurer don't give the same result, but we don't find out which was right. When he measures the curve he drew, the longimeter gives 28.9 mm but the map measurer (a.k.a. opisometer, a hand-held instrument for measuring curves on paper) says 34.5 mm; that's a 16% difference, so pretty big.

To do a real test, you could print out a curve with a mathematically calculated length, say a sine curve, then measure with both methods (and other methods like placing a string on top) to find out what works best in practice.

<comment><USER3> Hm. That 16% difference reminds me of the 60% point Miles Mathis makes in his infamous 'pi'='4' [single quotes INTENTIONAL.] paper (which ISN'T what people think. Numerous people tried to debunk it and I would absolutely LOVE to see a proper debunking of it, but each 'debunker' actually only skimmed his writing, or only read one of his papers on it instead of all of them, and constructed bad counter arguments as a consequence.)

[http://milesmathis.com/pi.html](http://milesmathis.com/pi.html) [http://milesmathis.com/pi2.html](http://milesmathis.com/pi2.html) [http://milesmathis.com/pi3.html](http://milesmathis.com/pi3.html) [https://sagacityssentinel.wordpress.com/](https://sagacityssentinel.wordpress.com/) (the debunk reply there is from 2011 and doesn't factor in the fact that Mathis indeed didn't realized the rather obvious link to the Hilbert/Taxicab metric until 2012, see the pi2.html page there.)

<comment><USER4> The short version has a simple but fundamental error in the use of limits, and so as long as the author claims that this contains the essence of his argument, there seems little point in wading through the full work, especially as it is written in an extremely discursive manner, to put it charitably.

</comment></comment></comment><comment><USER5> The interesting part is the explanation on how it works and on the accuracy you can expect:

[https://books.google.it/books?id=sFzCAgAAQBAJ&pg=PA121#v=one...](https://books.google.it/books?id=sFzCAgAAQBAJ&pg=PA121#v=onepage&q&f=false)

</comment><comment><USER6> This is a great youtube channel as well! I liked this review on a planar planimeter and how it ties in to Green's Theorem.

[https://www.youtube.com/watch?v=jMvEOmpy8Kw](https://www.youtube.com/watch?v=jMvEOmpy8Kw)

<comment><USER7> Wow it really is great. Plan to share with everyone I know who would find this interesting. Already watched a few of them and they are all just as enjoyable. Hope he gets a bunch more subs and keeps making videos.

</comment></comment><comment><USER8> Presumably this is the length of some discretisation of the curve, perhaps one of millimeter-long line segments. (The exact length is uncomputable!) Really cool though!

<comment><USER9> It also has the corner cases of curves that exactly align with the overlay and hence never cross any lines.

<comment><USER10> For increased accuracy, one can displace the overlay slightly and measure again, and take the average of multiple measurements.

</comment></comment></comment><comment><USER11> See [https://en.wikipedia.org/wiki/Crofton_formula](https://en.wikipedia.org/wiki/Crofton_formula)

Also see page 41 of _Differential Geometry of Curves and Surfaces_ by Manfredo Do Carmo

</comment><comment><USER12> Also interesting is [https://en.wikipedia.org/wiki/Opisometer](https://en.wikipedia.org/wiki/Opisometer)

<comment><USER13> That one is easy to understand. hettps://en.wikipedia.org/wiki/Planimeter is more interesting: trace the perimeter to measure an _area_.

</comment></comment><comment><USER14> How is this better than using a string? (Actual piece of string, not text).

</comment><comment><USER15> This is brilliant.</comment>


Show HN: Fully automated domain transfers from GoDaddy to Badger - <AUTHOR> http://blog.badger.com/2012/06/25/linked-accounts-automated-transfers/

<comment><AUTHOR> First 25 people who signup using this URL get their first domain transfer free:

<https://www.badger.com/#account/create/hackernews></comment>


Why Google's $400 Pixel 3a convinced me to never again buy a $1000 smartphone - <AUTHOR> https://www.businessinsider.com/pixel-3a-from-pixel-2-2019-5 <comment><USER2> My issue remains privacy. I can't help but feel that every swipe and key I type into an Android will be added to some profile on me.

<comment><USER3> Actually one of the best things about Android is that you can drop all the Google apps. Don't use the default Google keyboard but install your own. Don't want to see ads in YouTube? Get YT Vanced. No ads in apps ever? DNS66. Want the Play Store apps without Google? Yalp.

<comment><USER4> That doesn't change the fact that you need google play services for most of the phone to work. It can be done, but it's a huge pain in the ass.

</comment></comment></comment><comment><USER5> Heaphone jack is a great bonus in my book, but then again I am described as a neckbeard by some of my non-imaginary friends.

<comment><USER6> I won't buy a phone without a headphone jack.

<comment><USER7> Or at least without USB-C: at least then I can use the same headphones on my laptop, iPad Pro, and phone.

<comment><USER5> Audio over USB (or charging port) is nice when you don't want to use your headphones while charging your phone

</comment></comment></comment></comment><comment><USER8> My Nexus 6P died in the fall of 2018 and I had to upgrade so I got the Pixel 3. If i knew they were going to make a $400 Pixel 3a I would have waited. Really pissed about this release cycle and I feel like I wasted money I didn't want to spend.

<comment><USER9> So you would have gone over 6 months with no phone?

<comment><USER8> sorry when i say "died" i mean the battery life was under 2 hours without needing to be charged again

<comment><USER10> Does the 6P have a replaceable battery?

</comment></comment></comment></comment><comment><USER11> after being an iphone user for years i switched to Android when apple released iphone 7. up to iphone 6s the innovation was worth upgrading but since then 'flagship' devices have been adding just gimmicks while charging 4 digit amounts. I got my OnePlus 5T for 499 and two years later it works like it did on its first day. Unlike iphones that would slow down after exactly 1 year when a new iphone was released. right now 400-500 dollar phones do everything a phone is supposed to do and lack nothing compared to flagships. you can tell most people agree with this judging by weak sales of new releases. customers are holding on to their phones for 2-3 years and rightfully so. smartphone frenzy is over and looks like 'few hundred dollars' is the new budget people think its worth.

<comment><USER12> I'm tired of even $400-500 every 2 years, for seemingly the same thing over and over. I'm going to do battery replacements as long as the device survives. (I'm 2 battery replacements into my Nexus 6P).

<comment><USER13> Are the newer batteries doing any better... mine literally caught fire (small explosion) at the service location when they took it apart. Been on a Pixel 2 XL since, man I miss a headphone jack, can't even find the damned adapter and the two I bought on Amazon don't work (compatible my ass).

The 6P was a great phone (charging/battery issues aside). Glad to see Google returning to the mid-range.

</comment></comment></comment><comment><USER14> Hopefully the 4a comes with ip67 or ip68 certification; it's really the only missing feature from the 3a that gives me pause. I don't want to have to worry if I walk outside and it is raining, or my phone slips off the bathroom sink edge and ends up under a stream of water.

<comment><USER15> Agreed. This Pixel 3a could be my next phone if not for the lack of IP67 or IP68.

</comment></comment><comment><USER16> I've had various iPhones and Androids over the years, most recently iPhone 6s+, 7+ and XR. I just yesterday bought a Oneplus 6T and am very happy with it. I've had the Xr for a few months now and it's been my least favorite iPhone. For me, it's a little heavy compared to even the older pluses. And the display isn't all that much chop for a premium phone. I'm glad it's a work phone, because I don't think I would ever have forked out over $1200 AUD for it. As much as I appreciate the privacy angle of the Apple ecosystem, it turns out that I've really missed just being able to install what I want on my phone. It's been liberating being able to customize what I want to not what Apple allows you to. Also, with Oneplus phones, you really do get 'flagship' quality phones without having to fork out the money.

<comment><USER17> To be fair, if you've only had the phone for a single day it's a little too early to tell how well it's going to pay off :)

</comment></comment><comment><USER18> I use Xiaomi Mi Max 3 I got for $230. $400 is still 50%+ overpriced.

<comment><USER19> I have the MI A2 (~$230). It's spec'd very similarly to the Pixel 3a and has stock Android. It's been available for almost a year now.

<comment><USER20> Cool. I had thought all of Xiaomi's phones came with MIUI. I didn't know they sold this Android One Device as well.

</comment></comment></comment><comment><USER21> What's the encryption story with Pixel 3a? I know when I lock my old iPhone 6 that not even the Federal Government can get into it. Can the same be said for the Pixel?

<comment><USER22> The Pixel 2+ have an equivalent to the iPhone's Secure Enclave: [https://www.blog.google/products/pixel/titan-m-makes- pixel-3...](https://www.blog.google/products/pixel/titan-m-makes-pixel-3-our- most-secure-phone-yet/)

But honestly, the government will either shoulder-surf your PIN code or make you unlock it with your finger, or just snatch the phone from you while its unlocked.

They bought an exploit to unlock the San Bernardino phone, but they only really needed to do that because the owner was dead and Apple stopped their routine cooperation.

If the federal government is in your threat model, this is the wrong place to be protecting.

<comment><USER23> >make you unlock it with your finger

[https://www.zdnet.com/article/police-cant-force-us- citizens-...](https://www.zdnet.com/article/police-cant-force-us-citizens-to- unlock-their-phone-by-face-or-finger/)

Another ruling:

[https://www.forbes.com/sites/thomasbrewster/2019/05/10/the-u...](https://www.forbes.com/sites/thomasbrewster/2019/05/10/the- us-government-cant-force-you-to-unlock-your-phone-with-your-fingerprint- another-judge-rules/#7ae3b0e24445)

<comment><USER24> This is not at all settled law, so it is not safe to assume the government can't force you to provide biometric decryption data.

[https://reason.com/2019/01/15/search-warrants-and- compelled-...](https://reason.com/2019/01/15/search-warrants-and-compelled- biometric/)

[https://observer.com/2019/05/police-force-unlock-phones- nj-s...](https://observer.com/2019/05/police-force-unlock-phones-nj-supreme- court/)

</comment></comment></comment></comment><comment><USER25> My son wanted a Pixel to replace his iPhone but wouldn't buy one because like Apple it didn't have a headphone jack to enable him to use it in his car for music. He bought a Huawei instead.

I am not yet ready to replace my iPhoneSE but I'll be going Android as well - and if Google will provide a headphone jack they are in the running, but ONLY if they provide a headphone jack.

<comment><USER26> From what I saw, the 3a has a headphone jack.

<comment><USER25> Yes - that is what interested me.

</comment></comment></comment><comment><USER27> I'd like a new post a year from now, telling us how the phone overall has aged. And another after 18 months.

<comment><USER28> Another big one is resale value. I can be sure that my iPhone depreciates at give or take AUD$200/year and there will be people that would buy it.

With something like this the resale value tends to tank pretty quickly and becomes difficult to sell.

<comment><USER29> Why does this even matter? Resale value is just interesting if you don't plan to use a product to its fullest and maybe till its death.

Choosing phones by looking at how much you can make of it a year from now is part of the problem this world faces.

<comment><USER28> Initial investment being offset by resale price is a better reflection of overall cost which would make someone make a more informed decision.

But, erm, this is more about recycling.

Device reuse (and a market for second hand electronics) is actually something beneficial to the world, not something harmful. It affects repair economics.

For what it's worth I imagine this device's EOL would be less than an iPhones too, where there is still a market (and software updates) for the five year old iPhone 6.

</comment></comment></comment></comment><comment><USER30> Slightly off-topic: I have an iPhone 6 that I believe cost me $299 in 2015. Whenever it dies I'm going to continue with Apple but I guess it will be the first time I don't buy a current model. I just can't justify the cost of a $899+ device for my use-case.

<comment><USER31> The iPhone 6 retailed for a minimum of $649. Your comparing subsidized to unsubsidized prices. Its not a fair comparison, the difference was just paid monthly as part of your cellphone contract.

<comment><USER30> You're right. Thanks for the correction.

</comment></comment></comment><comment><USER32> Look, I just want a Moto G4 with a better camera, that's it. I'm not going to pay $400.

</comment><comment><USER33> I swore off the Pixel lines when Google gave up on the flagship-beating Nexus. Seriously, try explaining to your parents that they'll be getting a worse camera than what was in the Nexus 5X if they want to stay at the $400AUD mark. Hopefully now I can point to the 3a as an option, although it's $650AUD here.

</comment><comment><USER34> You still wasted 200 american pesetas lmfao</comment>