Ask HN: We started our first software company, how can we improve our website? - <AUTHOR>

Dear HN, we are two seasoned software engineers, previously working on large enterprise applications in investment banking and Big Four companies, now trying to leave our corporate past and go on our own. We are the best in serious back-end Java and web development (we recently launched an online trading platform for physical gold), just built a website (www.codedose.com) and launched AdWords campaign along with spreading the word across our peers trying to attract some first customers.<p>What can we do to improve our website? Any hints are greatly welcome, we feel like it's just the beginning really. <comment><USER2> With a quick glance:

1\. There is a misspelled word in your subtitle.

2\. Avoid drug references, however whimsical. Dump the capsule graphic and the word "dose." The problem? Young people won't trust you, and old people will wonder what you do in your spare time.

3\. You need to summarize what you do with fewer words, so a casual visitor is almost instantly aware of your line of work.

4\. Overall, you need a copy editor to rewrite the textual content of your site. There are too many badly chosen sentences and phrases.

Well, you asked. :)

<comment><AUTHOR> Great, thanks lutusp! It seems we need a better copy :)

</comment></comment><comment><USER3> First, congrats on taking the plunge and much success to you. Overall it's a well done site, so these are only minor things:

Bring more attention to the services & certificates in the footer. Some graphic/logos from Sun for example.

Put Portfolio before Team in the nav. I know team should come first :P But Portfolio is what a new visitor is going to look for immediately (I did). You may have Portfolio pushed back because it isn't extensive yet, and if so, I can understand that.

In that same vein, add Portfolio to the graphical nav on the homepage for consistency.

(On English language) Was going to mention some spelling errors but I see they're being corrected.

<comment><AUTHOR> Thanks flexxaeon! Everything was put up in a rush really, we will definitely work more on our copy. I wonder whether you find the name "Codedose" somehow weird or just too quirky?

<comment><USER3> To be honest, yes. It looks weird and rolls off the tongue even weirder. (I naturally want to say 'coh-dose' and feel like I have to force that extra D in there)

</comment></comment></comment><comment><USER4> I could immediately tell from the copy that English isn't your first language. It wasn't wrong, but it didn't read like anything a good writer whose first language is English would write.

That's not a criticism of you. I don't speak Polish. But if you want to minimise the risk of people making snap judgements because of it, you could pay someone to rewrite your copy.

</comment><comment><AUTHOR> clickable: <http://www.codedose.com/></comment>


Sell Your Downloads with 100% Royalty - <AUTHOR> http://blog.intubus.com/post/155351189803/say-goodbye-to-a-trading-commission <comment><USER2> The landing page is bad - too minimal, unclear who it's aimed at, or what sort of products are referred to. The Feature text is too jargon-driven and reads like how an SEO firm would describe github.

However, the intro video is _pure gold_ and sold the service very effectively - it so happens I'm your target market, but I wouldn't have guessed that just from reading the text.</comment>


Felix Salmon explained why Tim Cook's sexuality wasn't common knowledge (2011) - mkr-hn http://blogs.reuters.com/felix-salmon/2011/08/25/dont-ignore-tim-cooks-sexuality/

<comment><AUTHOR> > _For a better and more heartfelt version of this post, read Joe Clark from > back in February: "When you tell us it's wrong to report on gay public > figures," he writes, "you are telling gays not to come out of the closet and > journalists not to report the truth."_

I think that even if you are straight, e.g under no real threat from revealing your sexual orientation, you should have a right to privacy. That's your fucking (no pun intented) matter, not of the press.

And being famous (e.g a top CEO) doesn't change that.

The line about respecting that is like saying to "journalists not to report the truth" is totally BS. Journalists shouldn't report on private issues, period.

They are supposed to report on NEWS, stuff about public matters, policy, uncover scandals (scandals that affect the life of people, e.g with regards to corruption etc, not "x is gay" or "y commited adultery" and such things).

That we accept this "gossip" and even support it with "the public has a right to know" distracts from the true role of the press.

</comment><comment><USER2> I disagree with the article. Tim Cook is not a gay role model but he should not be one: it's great that he is judged based on his performance, not on other factors. So let's celebrate that sexual orientation can stay as a private thing, detached from business and career. It's ok that people know he's gay, it's also ok that it's not brough up all the time.

</comment><comment><USER3> This isn't a spectacular article. I, for one, think the status quo in this case is kind of great: it's not reported on because it's not newsworthy.

Now, I know that isn't really true: in 2014 it's still somewhat remarkable, sadly, for him to be in that position. But things are looking up! I look forward to the day when a CEO's sexual preference is reported with the same fervor as his or her preference for chocolate ice cream vs. vanilla: not necessarily secret but irrelevant to performance and frankly not very interesting.

</comment><comment> mkr-hn I could have used some geeky gay role models growing up. This matters to me. Things are a lot better almost three years later, but we still have a long way to go.

The article linked at the bottom is also worth a read: [http://blog.fawny.org/2011/02/02/gaylives/](http://blog.fawny.org/2011/02/02/gaylives/)

<comment><USER4> I only needed one.

</comment></comment><comment><USER5> Wow, I didn't know this even now.

As much as we'd like to say these things aren't big deals because we're [sexuality|color|gender]blind, society is still struggling with the fact that old barriers are coming down. Ironically, open opposition isn't the only reactionary response; people also try to react by hushing it up.

</comment><comment><USER6> Tim Cook has as much right to a private life as anyone else, I think that his sexuality being too boring a topic to be worth commenting on is probably a good indicator.

<comment> mkr-hn edit: HN won't let me post any comments. I'm sick of being rate limited every time I get into an interesting and worthwhile conversation. This story has already been flagged off the front page (was #3). This is ridiculous. E-mail me or PM me on Reddit if you want to know why most of the replies here miss the point.

How everyone in Silicon Valley reacted to this tells me you still have a long way to go before you can justifiably call it an accepting environment.

\</comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>--

You wouldn't realize this, but it's very helpful to people who are closeted or questioning to have real-life examples of gay people they can relate to. I live in a very sports-centric region. I didn't feel safe until Michael Sam came out and I could see that friends and family reacted positively. People around here just plain didn't discuss it before, so people like me had to take a big risk to live an authentic life in the open.

Straight people don't realize how much they reference their sexuality. You probably do it all the time in ways that are subtle and invisible to you. It doesn't make you a bad person. It just means you don't realize how goofy this sounds:

> _I think that his sexuality being too boring a topic to be worth commenting > on is probably a good indicator._

<comment><USER7> Exactly. So many young people are terrified that if they come out that their whole life is going to be about being gay. Everybody will interact with you through the lense of the dominating fact that you are gay.

The message people get is that it's okay to be gay as long as you act reasonably straight or are funny enough to be on TV. Same message being sent to blacks. No problem as long as you act normal aka white.

</comment></comment><comment><USER8> I have huge respect for people who think about computing such as Peter Thiel and Alan Turing.

That they are gay is not relevant.

I am not saying this to support people 'coming out', although that is all well and good. I'm saying it because it is a fact that way too many people focus excessively on their 'lifestyle' as defining them as a person. It doesn't matter if you are a swinger, a gay, a transvestite, or straight. Outside of the "heat of the moment" for a person, your sexuality is not that interesting and probably should not define you as a person because that is a great way to waste your time in pursuit of pointless objectives like validation by society.

Sexuality is transitory, it does not last. It is not an accomplishment. I am as liberal as it gets when it comes to sex, but too many people waste time here.

<comment><USER9> I agree. Beyond being gay these people are human beings and have accomplished great things, and as such should be defined by their accomplishments rather than their sexual orientation. Until I read this article I didn't know Tim Cook was gay. and until I read your comment I didn't know Peter Thiel was gay. I know these men by their accomplishments, not their sexual orientation. Now that I know their sexual orientation, who cares? As someone pointed out it's as trivial as knowing the name of Tim Cook's dog, if he has one.

</comment></comment><comment><USER10> I find it appalling that these "journalists" take the liberty of discussing private matters in a very public setting. Sexuality, like health and other personal subjects, shouldn't neither be discussed nor be part of the judgement of a professional figure.

</comment><comment><USER11> The lack of interest shows just how boring Tim Cook really is. Now if Jobs was Gay, then Wow.

</comment><comment><USER12> I feel like Tim Cook's sexuality is trivia not news. Like knowing his dog's name or what he collects.</comment>


Why Everyone Will Totally Read This Column  - <AUTHOR> http://online.wsj.com/news/articles/SB10001424052702304579404579231772007379090 <comment><USER2> _Subheading that actually explains what the article is about:_

"A Gawker Editor Tells How He Picks 'Viral' Content Readers Can't Resist Sharing"</comment>


DB-19: Resurrecting an Obsolete Connector (2016) - <AUTHOR> http://www.bigmessowires.com/2016/06/04/db-19-resurrecting-an-obsolete-connector/ <comment><USER2> It's embarrassing that it's easier to get things made in China than in the US.

I had some 5/16" paper tape manufactured for use in antique Teletype machines. I tried several US paper tape manufacturers. One quoted me $10 a roll, but made a good roll. One sent me a roll with rough edges that jammed in the machine. Most were uninterested, even for a large order. The US companies were really hard to communicate with, too. Getting emails answered was tough. Phone calls usually went to voicemail. I finally had 1000 rolls made in Fujian, China for $1/roll. They worked fine. Much better customer communication, too.

Some of the decline in US manufacturing comes from this sort of thing.

<comment><USER3> I have been in physical product development and manufacturing for three decades. Doing business with US manufacturers has become more and more difficult over time. What you describe here is very true and only the tip of the iceberg. I have, for example, sent out 50 requests for quotes for machined components only to be utterly ignored by most of the shops I contacted. The same exercise with China results in an almost overwhelming number of quotes received almost instantly. They are open for business. Have been for a while. I, frankly, have no clue what game we are playing.

<comment><USER4> _> Doing business with US manufacturers has become more and more difficult over time._

Any thoughts on why?

<comment><USER5> In my experience, it's a combo of issues.

US manufactures were the first to automate, so many of them are with 1st/2nd generation gear that is designed for high throughput operation and not around setup time. These machines can take several hours to change what they make.

Also, manufactures have become jaded with new customers as they are constantly asking for them to move mountains for overseas pricing. Manufactures typically have a big enough collection of frequent customers that they can use bad first customer support as a means to filter out people who will go overseas anyways after they hear the quote the manufacturer spent a fair amount of time on. If a customer is willing to pass the gauntlet of trying to contact you, they are much less likely to disappear after you give them a quote.

<comment><USER6> I tried to get some waterjet cut parts about 5 years ago near Santa Barbara. The only shop I could find that could do it had no way to get the data into the 486 - yes you read right - other than hand replicating my file in his ancient CAD program.

My experience overseas is more like fire off an email with an attachment and have perfect parts a few weeks later.

I believe this is changing though. There are some awesome short run PCB assembly services in the states now for instance.

<comment><USER5> Now that the old equipment is at the end of its useful mechanical life people are switching.

In the manufacturing I'm involved with recently got rid of their last machine that used 8080 era processors and character only green CRTs.

</comment></comment></comment></comment></comment></comment><comment><USER7> Previous discussion: [https://news.ycombinator.com/item?id=11839690](https://news.ycombinator.com/item?id=11839690)

</comment><comment><USER8> There's a similar issue going on with the square DIN plug used for power connectors on the Commodore 128 and TED series (C16, Plus/4) computers. Someone found a place in China with old stock and has been buying them. One person is building new power supplies and machining their own connectors.

</comment><comment><USER9> Heh, I've had a similar project on my back burner for a long time having to do with reusable Keurig filters. There are a ton of them on the market, and they all have the same fundamental design flaw: they are _just_ a filter, without the surrounding housing with a small hole designed to hold pressure. So they all make weak coffee (and a huge mess). I would happily sink some money into the design and manufacture of a filter that actually worked. I think it could even be a money-maker, though I'm mainly interested in it for my own personal use. But I have no clue where to even begin looking for someone who could make such a thing. If anyone here has a clue I'd appreciate hearing about it.

<comment><USER10> This might be an idiot answer, but have you checked your local makerspace? Or contacted someone at a university?

Last year a few of my classmates did an "Aggie Challenge" where they designed something for a private party in exchange for some mentorship and a resume bullet.

We usually do small projects for professors/companies that need help with something simple (like a CAD model/Design).

<comment><USER9> No, I haven't. I doubt reusable coffee filters are "cool" enough to attract that kind of attention. I need to somehow reach the people who are already making them, and they are almost certainly in China somewhere.

</comment></comment></comment><comment><USER11> > For the moment at least, I have nearly the entire world's supply of DB-19 > connectors, stacked in my living room. I think I'm going to fill the bathtub > and swim in them.

And 2 years later, all the stock on Ebay is still from North America/Europe. I'm a bit surprised.

</comment><comment><USER12> Yes, this has been here before. Back then I replied that, when confronted with the same problem, I simply took a hacksaw to a DB-25 and had a working connector within a minute. Not as fancy, maybe, but just as functional...

<comment><USER13> Sure, that works for a one-off. Not exactly a good solution though when you are selling a new product. "So, plug the cable into the rough hack-sawed connector on the back of our jankey product".

<comment><USER14> I wonder if it'd come out nice if you water-jet them in bulk and then glue the halves together.

</comment></comment></comment><comment><USER15> So what's the follow up? Is OP still happy with their parts? Are they available for purchase at 1/10th the price on AliExpress now? Did they recoup their investment?

<comment><USER16> I don't find any DB-19 connectors on Aliexpress or Alibaba. eBay has them for either ~$20 or ~$5.

<comment><USER17> The author recommends buying them from here in the article (that being said, the article is from 2016) so YMMV: [http://www.iec-usa.com/cgi- bin/iec/DB19MS](http://www.iec-usa.com/cgi-bin/iec/DB19MS)

</comment></comment></comment><comment><USER18> Definitely has been on HN before. Cool read though, once again.

</comment><comment><USER19> Needs a [2016] tag

<comment><USER20> Updated, thanks!</comment></comment>


How to do a code review - <AUTHOR> https://google.github.io/eng-practices/review/reviewer/ <comment><USER4> Here's the part that resonated with me most:

      A particular type of complexity is over-engineering, where developers have made the code more generic than
      it needs to be, or added functionality that isn't presently needed by the system. Reviewers should be
      especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be
      solved now, not the problem that the developer speculates might need to be solved in the future. The future
      problem should be solved once it arrives and you can see its actual shape and requirements in the physical
      universe.

Note how Google does NOT say "make sure the code is properly architected". Instead they say "make sure the code is not over-engineered"! At top companies like Google, projects rarely fail because there isn't enough architecture. Instead projects end up costing 10x to 30x because of unnecessary complexity. Over-engineering is a trap that very good developers fall into all too often. I am glad to see Google has cautioned against this, because I can now point my fellow developers to this when they are about to fall into the same trap!

<comment><USER5> It sounds like walking a tight line between over engineering, and falling into technical debt. If you design code specifically solves the immediate need, that may need to be thrown away or extensively worked on / around when future needs come up. On the other hand, you can write code that solves future needs that never appear, and still fail to solve the actual needs that end up appearing.

For me, I would rather put a bit of additional effort up front gathering enough information about the direction of the project or usage of it to better formulate an attack plan so that it does actually become more future proof. But even that is subject to failure, so what do you do?

<comment><USER6> I think of it this way: How can I build this so that it only solves today's problems but doesn't make it overly difficult to solve tomorrow's problems?

Loose coupling, dependency injection, composition over inheritance, and similar techniques tend to be good answers to this question in my experience.

In contrast, over engineering attempts to solve tomorrow's problems before they arrive and, if they arrive differently than predicted, makes them harder to solve, because when you have to change something it's less clear which parts of the design were necessary to solve the original problem and which were only necessary for the future problem that was incorrectly predicted. Often times you might end up having to rethink the entire architecture rather than having the relatively simple problem of adjusting things to meet new requirements.

<comment><USER7> Very well said!

My own experience is that effort invested in removing restrictions and handling corner cases is generally well spent. It may not seem too onerous to have to remember that a particular function works only for nonempty inputs or when called after some other function, but in a large system where many operations have such restrictions, keeping track of them quickly overwhelms the capacity of human memory. Sooner or later someone is bound to forget, and it may even be the author of the code in question. I try to ask "what are people going to expect this code to do?" and then, if within reason, to make it do that (and failing that, to protect it with assertions). Alternatively, someone may be forced to make some other part of the system more complicated to work around the restriction, leading to excessive coupling.

I suppose this practice sometimes risks over-engineering, but I have found the risk to be worth taking. As you say, it makes the system easier to extend further.

<comment><USER6> Yeah absolutely. I think a big part of it is considering possible edge cases or failure scenarios and not necessarily solving them immediately but considering how your design might need to be changed in order to solve them. Many times I have found there's a solution that requires little or no more work than a naive implementation but is far more robust to future changes.

To use inheritance as an example - if there's a conceivable possibility that some future requirement might lead you to add the same functionality to other classes, you probably don't want to have to deal with a long and convoluted inheritance chain when you could compose some set of functionality onto one class as easily as many classes.

Or in the case of dependencies, wrapping some third party mail sending library in your own generic API is barely more work than using the third party library directly and will pay dividends if you change mail providers in the future.

One very specific example that I worked on recently: In most cases there are one of X, but in a handful of cases there are many of X. My initial inclination was to branch off and handle the many case as an exception, but then I realized that you could eliminate that corner case entirely if you handled everything as a collection of X, even if in most cases that collection only has one item in it.

<comment><USER8> That's a pattern I learned a long time ago. It's much more future-proof to treat items as an array, even if it seems over-engineering at first, because scope-creep dictates it's more likely you are going to handle more items in the future, not fewer. And dealing with one item vs. many can change your architecture pretty drastically.

</comment></comment></comment></comment></comment></comment><comment><USER9> This is great advice and isn't followed often enough, especially when reviewing code written by people new to an organization/team:

> If you see something nice in the CL, tell the developer, especially when > they addressed one of your comments in a great way. Code reviews often just > focus on mistakes, but they should offer encouragement and appreciation for > good practices, as well. It's sometimes even more valuable, in terms of > mentoring, to tell a developer what they did right than to tell them what > they did wrong.

I've seen cases where people got hundreds of comments (many of them minor, nitpicky) from more experienced developers and were discouraged by the sheer number of them. That most new developers naturally suffer from imposter syndrome is not helped at all by 100% critical code reviews.

<comment><USER10> Why is it that people feel so discouraged by loads of review, especially early on? I always had a good bit of imposter syndrome early on, but never considered quitting. I always assumed that you have a lot to learn, that it's expected you're going to suck at some level.

<comment> compiler-guy People have their own internal stories about how good they are, and all that feedback can be very painful.

It doesn't help that many comments are nitpicks and pedantry, made by people without much social empathy.

This is especially true when sending a patch for a high-level review of your proof of concept, and the next thing you know people are complaining about your formatting.

<comment><USER11> It can be hard to review badly formatted code. The reviewer has to put in effort to understand your change, but they have to put in more effort to parse the change if the formatting is bad.

"Why is this function's return value not being checked? Oh, turns out this person used a yoda conditional even though the rest of the code doesn't do that."

"Why is this block of code running even when the condition is false? Oh, turns out the else branch already ended and this part of the code is just indented wrong."

And so on. Even something as minor as `foo ()` vs `foo()` can stand out and act as a constant stream of mental speedbumps.

Claiming your change is high-level / only looking for feedback to the overall design doesn't change that. You're asking for a code review because you want the reviewer to read your code, but reading it is exactly the part that they're finding hard to do.

And it's not excusable, but the reviewer might be insulted that the reviewee is wasting their time and their feedback may be ruder / snappier as a result. After all, the reviewee could easily have put in the effort to run the auto- formatter, follow the existing code's style, etc.

<comment><USER12> The formatting & style could be automated via IDE configurations, so that when the code is submitted for review it is already clean. This will make reviewer to focus on the design/logic instead of formatting.

<comment> compiler-guy Autoformatters fix many things, but not all of these issues.

</comment></comment></comment></comment></comment></comment><comment><USER13> I'd add two things, from a decade of experience at Google:

Review code in this order: protocol buffers, unit tests, headers, implementation. It's common for a new employee to be an expert on C++ or Java or whatever languages but it's very uncommon to meet anyone who knows how to define a decent protocol message. The tests should give the reviewer a very clear idea of what's happening in the code (and this should be congruent with the description of the change), if not send back to author at this point. The headers should contain clear interfaces, types, and comments and should not contain anything that's not part of the API (when this is technically possible). Finally look in the CC file; at this point the reviewer should see things they were already expecting and no funny business.

Any claims about speed, efficiency, or performance whether in comments or during the review must have accompanying microbenchmarks or they should be deleted. Wrong ideas about software performance abound, and even correct beliefs become incorrect with time, in which case the microbenchmarks are critical to evaluating the continued value of the code.

When sending a changelist for review, always clear all automated warnings or errors before wasting the reviewers' time. Nobody wants to see code that doesn't build, breaks a bunch of tests, doesn't lint, etc.

<comment><USER14> > Any claims about speed, efficiency, or performance whether in comments or > during the review _must_ have accompanying microbenchmarks or they should be > deleted.

That's way too strict. If I want to suggest moving a statement that's inside a loop to the outside, I don't want to waste my time writing microbenchmarks showing that it improves performance.

If the suggestion is complicated or non-obvious, and it's in a really critical part of the code, then sure, write a benchmark. Outside of that though, it's rarely a good use of developer time.

<comment><USER15> I agree that "must" is too strict. If I replace linear search with binary search, or hashmap/hashset lookup I don't need to write a benchmark to prove it improves performance. There is math, logic, Big O analysis that allows to reason about performance and speed without microbenchmarks.

<comment><USER16> bt848 already said it, but you picked a really poor example. In many real world scenarios, a linear search beats a binary search due to a lack of overhead.

Along those lines, in C++, a vector very often performs better than a theoretically better data structure. I learned C++ fairly well from a very experienced guy in the company, and he said that you should always benchmark against a vector. I suspect if I was in his team and he were reviewing my code, he wouldn't let the code pass unless I had benchmarks that show whatever data set I picked is faster than a vector.

He wasn't against other data structures - he just wanted proof they would perform better. In quite a few cases, they didn't.

<comment><USER15> Yes, the size of the data matters, and linear search may be the right choice for many use cases and may outperform more advanced data structures. You learn it on the job as it is not a topic usually studied in universities. But I don't agree that we need to completely throw away theory, O complexity analysis where N - input size is the main variable. Microbenchmarks are hard to write correctly. Recreating the scenarios occurring in production is not always possible in the microbenchmark settings. You can write a microbenchmark that shows your code works great, but fails to perform in production because the input data is totally different. bt848 mentioned load test, which is not the same as microbenchmark. Load test that simulates production settings is a better tool to validate the optimizations.

<comment><USER16> >But I don't agree that we need to completely throw away theory, O complexity analysis where N - input size is the main variable.

No one here is agreeing with that.

</comment></comment></comment></comment></comment></comment><comment><USER17> Would help if they mention what a "CL" is somewhere before using it ubiquitously

<comment><USER18> It refers to "changelist". Google uses a Perforce-like VCS internally, and they kept the Perforce terminology: [https://www.perforce.com/perforce/doc.051/manuals/p4guide/07...](https://www.perforce.com/perforce/doc.051/manuals/p4guide/07_changelists.html)

<comment><USER19> aka "Pull Request" in Github parlance.

<comment><USER20> aka "Merge Request" in Gitlab vernacular (which makes more sense than "pull request" in my opinion).

<comment><USER21> aka "patch" for the Linux kernel development community

<comment><USER22> aka "diff" or "revision" at FB .)

<comment><USER23> aka "CR" or "Change Request" at Amazon

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> It's very interesting that so much of it is about the social aspects of engineering - a lot of it kind of reads like " _don 't be a jerk_". In CS engineering classes, where presumably we would learn to become great engineers, I don't recall learning about any of this, and instead I remember the emphasis being on technical knowledge and accomplishment. I'd probably have been a better engineer in my early career if I'd understood how much the ability to exchange clear, constructive, and nonthreatening critique with peers actually mattered. It's reminiscent of how training in technical fields such as architecture and medicine often put the emphasis on technique over the service aspects of the job such as client interactions and bedside manner.

<comment><USER6> Code review is a social activity and when you frame it as such it's not so surprising that a lot of the discussion of it involves these social aspects.

I definitely agree that my experience was the same w/ regards to an almost exclusive focus on the technical aspects of programming. I only had one CS project in my senior year that involved building something with another person and even in that case it was only one other person.

I don't think this problem is simple to solve or specific to programming. On the one hand, educators have to asses individuals so it makes sense that they'd want to isolate work to the individual. On the other hand, work after education is never (I hesitate to generalize but this seems like a safe generalization) an individual activity, and the rare dreaded group project in school is the norm afterwards.

I am not sure what the solution to this problem is. Even in a situation where you have version control and can look at each individuals contribution to the code itself, unless 100% of the discussion around that code happens in comments on a platform like github, it's still difficult to assess things like how much the input of one individual contributes to the output of another.

In addition to this, teaching effective approaches to technical problems is easy compared to teaching effective approaches to human interactions.

<comment><USER24> > I only had one CS project in my senior year that involved building something > with another person and even in that case it was only one other person.

I had many group projects in school, but they didn't set it up so that we'd review each other's code. We'd just break it up into modules, split the work accordingly, and each worked on a different part.

A more fundamental limitation of school projects is that they have by definition a limited lifespan, so that the notion of code debt, the importance of ensuring that code be readable by current and future colleagues, etc. are irrelevant - in all the projects I've done in school, even group ones, I was the only one reading my own code and it would never be run after class finished. In such a situation, "improve overall code health" makes no sense. You write only what you need to pass the class, which is usually some kind of demo feature.

Maybe making contributions to well-established open source projects should be encouraged as part of the curriculum, at least to experience the receiving end of it...

</comment></comment></comment><comment><USER25> >In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect.

This is a great rule of thumb

<comment><USER26> It's a nice rule of thumb for CLs (changelists) that provide a bug fix or refactoring. But I think it's a terribly useless rule of thumb when evaluating a CL that just implements a new feature.

Imagine some new features such as "support exporting to CSV" or "auto-generate avatars for new users". Implementing them will necessarily add more code, and more complexity, to the codebase. And adding more complexity makes the code harder to work with – in other words, harms "the overall code health of the system". Businesses develop new features because of the _improvements to the product_ they bring and the reputational or monetary gains that come from that, _in spite_ of the damage done to the codebase. The only way you could get a new-feature CL to pass by the standard you quoted (the standard of "improving the overall code health of the system being worked on") is to refactor existing messy code written by someone else, and that would not be sustainable.

Does anyone see a way to interpret the rule, or have a preferred variation of the rule, that makes it useful for evaluating new-feature CLs?

</comment></comment><comment><USER21> In the "What Is Not An Emergency?" section:

> It is the end of the day on a Friday and it would just be great to get this > CL in before the developer leaves for the weekend.

I laughed out loud because it reminded me of so many times I have seen it happen and then someone had to fix in the weekend.

Who shares the same experience?

<comment><USER27> Some places I've worked explicitly won't push/deploy/similar on Friday.

<comment><USER28> I worked at one (horrible) place where we explicitly _only_ deployed on Friday afternoon.

The logic was we have fewer users over the weekend, so if something goes wrong, fewer people will notice.

<comment><USER29> It depends on what company you are.

Some who administers some SAP thing for a huge supermarket chain tells me they do all of their upgrades on weekends because their users aren't at work.

Makes sense for them, but it would be a crazy thing to do the consumer-focused interweb company that I work for.

</comment></comment></comment></comment><comment><USER30> What is good design, what is good naming, over-engineering, etc, etc.. How on earth can a group of people agree on all those points? Look around here on HN, all those discussions.. Do we have consensus? No, and that is OK, but it's not in a team by code review.

There is only one way a group of people can have healty code reviews, that is when they like each other so much, or enough to accept what they not agree on. But man, if one or more dev's are not you're best friend, you have a problem there. Because it is not who has the best code or ideas, it's who fits best in the group, not?

But I totally agree code that comes into a code-base needs to be checked. And IMAO only by 1 developer, the LEAD who is responsible for the code-base. No democracy, no endless discussions, no 6 people spending 1 hour a day to do this.

Personally I prefer to do only gigs where there is a lead dev. I try to stay away from the popular self managing teams. I've seen enough horror, where a good developer had to leave the team because they were constantly frustrated, endless discussions about futilities, and in the end it all became personal.. Is it only me who sees this?

<comment><USER31> I agree with you. This "Agile" cancer that has infected the industry needs to die now. Someone here called it collectivized micromanagement and that's the best term I have heard for what's become of "Agile".

<comment><USER32> I don't think you should accept bastardizations of terms into your lexicon.

Yes, acknowledge when someone means "micromanaging" when they say "agile", and act accordingly. But don't redefine the word in your own head, otherwise how can you even speak?

Like, what word do you use now for the basic principle of agile development now that you've changed it to mean micromanagement in your head?

<comment><USER33> I'd say Agile development is about "agorisation" of the development process. "Agorisation" is the act of making a place (virtual or not) amenable to proposing, discussing, and setting up and in motion _categories_ that will enhance this development process in both qualitative and quantitative aspects, such that agents who collaborate into it can live through this process like a citizen through the city.

\</comment></comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----

category (n.)

1580s, in Aristotle's logic, "a highest notion," from Middle French catégorie, from Late Latin categoria, from Greek kategoria "accusation, prediction, category," verbal noun from kategorein "to speak against; to accuse, assert, predicate," from kata "down to" (or perhaps "against;" see cata-) + agoreuein "to harangue, to declaim (in the assembly)," from agora "public assembly" (from PIE root *ger- "to gather").

</comment><comment><USER34> Here's my workflow and it works very good to get everyone on the same level:

\- Each night, I go over all the commits of the day and do a code review \- Each morning at 9:00, we go over all the comments on the commints, with everyone, talk about it and make sure everyone understands.

This allows me to explain more advanced or new concepts that one developer uses to make sure everyone understands. It allows me to introduce improvements and explain why they are beneficial, and it allows me to signal when people don't follow the standards we impose; giving not only the person who did it wrong a refresher, but it makes sure everyone is reminded of the way we should write code, etc.

The feedback has been amazing and everyone loves it because it helps everyone grow and they feel like they are allowed to focus on quality; due to time pressures, coders tend to let standards slip when under pressure. When you focus on quality every day, it stays with them, because they know, if they don't deliver quality, it will be in the daily review. So far, this has not hurt production speed at all and quality has gone up a lot since we started doing this.

<comment><USER35> This is an interesting approach. How many engineer hours do you think you spend each day doing this? If you're reviewing CLs as a group, it seems like it could get very expensive very quickly, no?

<comment><USER34> They last anywhere from 15 minutes, to 90 minutes, depending on the topics and it replaces a lot of other meetings/sharing that normally takes place.

</comment></comment></comment><comment><USER36> > if a reviewer makes it very difficult for any change to go in, then > developers are disincentivized to make improvements in the future.

This is a problem I see far too often but it's rarely talked about. Too often, engineers misinterpret "quality" code for "their" code. Code review turns from "what should we be doing here?" Into "what would this reviewing engineer name this one unimportant variable here?"

There needs to be a happy medium between velocity and quality, and increasing velocity doesn't necessarily mean decreasing quality.

</comment><comment><USER37> I have never not seen code reviews end up being a massive social/cultural pain point for most people involved. Most people hate getting their code reviewed in depth. In situations where there isn't just one lead dev who is responsible for reviews, this leads to "Merge Request symbiosis", where two people uncritically approve each others requests so they don't have to deal with the third.

<comment><USER38> I agree, my role of thumb is to only review code if I was asked by the author to do so, and never offer to review someone's else code.

Code is a bit like music, there is very little right or wrong, but a lot of flavours and opinions.

<comment><USER37> Very little wrong? You haven't seen enough code! I have seen everything in merge requests: From liquibase scripts that would have wiped the production database to production secrets in yml files.

</comment></comment></comment><comment><USER39> Helpful and interesting.

However, you can tell this was written by an engineer. The acronym CL is used about a hundred times. There is not a single page where the first usage of the acronym explains the full term.

<comment><USER40> It is explained at the top-level document: [https://google.github.io/eng- practices/#terminology](https://google.github.io/eng-practices/#terminology)

</comment></comment><comment> awinter-py in real companies that don't have G's resources, quality and velocity are tradeoffs, not things you can have both of

god bless them for trying though

in particular, the idea of having one or more reviewers doing multiple rounds in a day is pure fiction in strapped startups. Rejecting a code review for readability isn't always an option. Even getting a timely review from someone who understands this part of the codebase can be unrealistic -- sometimes there is no such person. Sometimes nobody is left in the company who understands the affected module and even the PR author is taking confession before merging it.

Love the phrase 'unless it's an emergency'. In resource-constrained cos _everything_ is an emergency because to get any non-emergency work done requires emergency level urgency.

G's way of life requires an even power balance between eng & other silos. And also requires a baseline level of technical involvement by PMs which isn't present outside big tech cos. Most companies just aren't hiring PMs with a programming background. They could never justify the spend.

Major missing section in this is 'what _shouldn 't_ you review' \-- various kinds of nits and out-of-scope changes that derail the process, waste expensive CI cycles, and make people take the rest of the day off from frustration.

<comment><USER41> And yet. Technical debt costs you time and money over time. Fixing code six months down the line takes 5-10x as much effort than just fixing it while it's still fresh. Worst case scenarios is where you end up throwing away an application and rebuild it because the technical debt has made progress grind to a halt.

If there's nobody left who understands the code, or if there's hero coders who 'own' one section of the application, it's a huge risk to the company - <USER2> can, and has, bring a whole company down (there's a few stories on the daily wtf iirc).

A recurring thought with me and my projects after about six months is always "I wish we had done this properly the first time around"; in hindsight there was more than enough time, and it's costing a lot more time to fix it now.

<comment> awinter-py when a group of people decide together what 'properly' will look like in hindsight in 6 mos, you can end up with some interesting outcomes

</comment></comment></comment><comment><USER42> When I receive a PR that has actual problems, I usually make a branch from the code in question, and submit a PR to that branch with tests highlighting the problem, or the beginnings of a refactor that I'm asking for. I often don't have time to fully flesh out the problems, but helping to write the software with the requestor makes for much faster and effective feedback than plain text comments.

<comment><USER43> You are a hero and deserve a medal!

</comment></comment><comment><USER44> A bit of useful flavor of how this looks in real life:

On my current team a typical code review of about 300 lines will involve about 3 to 4 reviewers, 20 comments, and maybe 10 changes, usually over the course of about 48 hours. Because this is a culture shock to people who join the company, we explicitly train every new team member ahead of time that code review suggestions are _not_ a reflection on your code quality or your coding ability. Reviewers are expected to err on the side of raising a comment when in doubt, even (and especially) when the issue is about the approach being taken rather than the correctness of the code itself. Not every suggestion needs to be accepted, but every concern should be addressed. While not an explicit requirement, the expectation (and typical outcome) is that the committed code represents the combined expertise of the author and all the reviewers, and everyone is happy to go on the record as having been "responsible" for the code that got submitted.

A zero-question LGTM isn't an indication of good code, it's a red flag for an incomplete review.

</comment><comment><USER45> I feel embarrassed to even ask... what does CL stand for?

<comment><USER46> Changelist, it's perforce for "patch"

</comment></comment><comment><USER47> Terminology:

There is some Google-internal terminology used in some of these documents, which we clarify here for external readers:

CL: Stands for "changelist," which means one self-contained change that has been submitted to version control or which is undergoing code review. Other organizations often call this a "change" or a "patch."

LGTM: Means "Looks Good to Me." It is what a code reviewer says when approving a CL.

quote from: [https://google.github.io/eng- practices/#terminology](https://google.github.io/eng-practices/#terminology)

</comment><comment><USER48> Nit: Under _Every Line_ The term "scan" is used where "skim" would be a better term.

Scan can mean _either_ "to investigate thoroughly by checking point by point and often repeatedly" _or_ "to glance from point to point of often hastily, casually, or in search of a particular item". Skim leaves no room for doubt: "to read, study, or examine superficially and rapidly"

</comment><comment><USER49> I love how the first-mentioned "hardest thing in computer science," naming things, is one of the shortest sections:

> Did the developer pick good names for everything? A good name is long enough > to fully communicate what the item is or does, without being so long that it > becomes hard to read.

They mention several times a "Nit:" or other prefix for nonblocking comments. I wonder if that is purposeful and/or reflects the experience of the company.

I also like a lot of the points made in the CL Author's Guide [0]. I've recently finished a similar document at work on how to form good Git commits. I generally like to be able to review a GitHub PR by stepping through a sequence of well-formed commits one by one, each of which sounds like what Google is describing in this document. Regardless of how it's sliced up, by commits or PRs or whatever, in general I just wish I could get more folks on board with this part of writing code.

[0]: [https://google.github.io/eng- practices/review/developer/](https://google.github.io/eng- practices/review/developer/)

<comment><USER50> "Nit" is a Google convention for comments that don't block an overall approval. In other words, you can fix the nits and submit without needing another round of review.

</comment></comment><comment><USER51> A great guide. Maybe it is out of scope but I would have liked to see what they do BEFORE they start writing code.

The reason is because by the time to get to a code review may be too late. The comment that you should give is "this is not how it should be implemented. You need to rewrite it from scratch." But most of the time you do not.

<comment><USER51> In my team I like to have a "technical kickoff meeting".

But before that, the person that will implement the story will goes through a checklist that I started and we improved during retros. The engineer sits down with another engineer and they go over again together. If they did their homework it is usually pretty quick.

Sample for web dev:

-Does this feature heavily relay on or modify code that someone else wrote? Should we talk with her? Should we HAVE THEM in this MEETING? In particular for BE work who should we talk?

\- What names are we going to use for Components, Pages, Folders, etc?

\- Is the visual design/flow clear and complete? \- Do we have every assets from design? Do we need to ask for more? \- Do we have dependencies on other work being done now on a branch or in the near future ? \- Do we have overlap with other pieces of code (possible conflicts)?

\- Will we reuse some other components or any other relevant utility functions?

\- What code can be reused?

\- Do we want to make some of the code for this feature reusable?

\- (Redux) What reducers will we use (if any)? In particular do we need new ones?

\- What are the most important tests to write ?

\- Are we going to phase the feature?

\- Do we have to compromise and create some tech debt? If yes, what, why and when do we plan to pay it?

I found that this meeting makes most of the code reviews fast as well.

</comment></comment><comment><USER52> I appreciate this:

> In general, reviewers should favor approving a CL once it is in a state > where it definitely improves the overall code health of the system being > worked on, even if the CL isn't perfect.

Reviewers are human too, and can occasionally get lost in the weeds nitpicking a PR/CL.

</comment><comment><USER53> "Technical facts and data overrule opinions and personal preferences." So true, so true!

Now if teams pay careful attention to this statement, the Code Review Guidelines can be shortened by an order of a magnitude! ;-)

<comment><USER54> As a general rule, absolutely! Unfortunately, if applied too strictly though, it can be weaponized or stifling in ways you may not anticipate (which tends to be true of almost any rule used too universally).

For example: I've seen cases where there's disagreement as to which of two technical paths to pursue, where one side (not liking the way consensus is currently leaning) demands a data driven proof that one of the choices is best. Ordinarily this would be fine, but in this case, it would take no less work/time to gather said data than to entirely implement _both_ solutions and directly compare them.

<comment><USER55> > in this case, it would take no less work/time to gather said data than to > entirely implement both solutions and directly compare them.

So why not do this?

<comment><USER54> In this case either of the solutions would satisfactorily solve the problem, so implementing both would be redundant and wasteful. The problem appears in this case when there's disagreement on which of the two satisfactory solution paths should be taken. Implementation work cannot proceed until it's decided _which_ solution path is to be taken (even though they both work), but there's no way to prove which is best aside from general intuition arguments, or actually implementing both (which as mentioned, would be a waste of resources for no benefit).

</comment></comment></comment></comment><comment><USER56> I found the DS100 course textbook and the author describes the phenomenon here: [https://www.textbook.ds100.org/ch/02/design_srs_vs_big_data....](https://www.textbook.ds100.org/ch/02/design_srs_vs_big_data.html)

This is insightful, but how does one deal with determing if your dataset is non-random? I can imagine manually inspecting the data and using cross- validation are ways to help identify skewed datasets. Are there any other ways to test if your data is non-random?

</comment><comment><USER57> When a development team is following XP Principles, mostly two developers are doing Pair Programming with Test Driven Development (TDD) and rotating pairs every week, how much value will it add with code review ? We recently had a discussion where some of us think it is still good to skim through the change request by a second pair while other's think it's just a waste of time.

I am curious to know if code review is encouraged by a second pair in following XP practices ?

<comment><USER58> At Google if person 1 and person 2 pair, then one can be the official author, and one can be the reviewer. Depending on the people and the change, they may also ask for review from others as well.

<comment><USER59> Jeff Dean and Sanjay Ghemawat coded like this for years.

</comment></comment></comment><comment><USER60> If you were wondering what CL stands for since its not defined anywhere in this doc, it is apparently akin to a Pull Request.

</comment><comment><USER61> One of the things not being discussed on this thread is all to the requirements around the side of the commit and how that impacts everyone else. I wonder when companies or projects get mature enough for these types of practices to apply. I know google has a complex lifecycle for projects internally as well.

</comment><comment><USER62> What about the importance of handling high-level architecture and design before writing code? This can be done in design docs, discussion on tickets, slack discussions or in person with a whiteboard. I think it's more productive to handle these discussions and reviews before writing any code.

What do other people think?

<comment><USER63> I would agree. I think if you're talking about high-level design in a code review then either:

A) You've revealed a need to get more alignment on design, and should probably be explicit that the discussion has this purpose.

B) You're doing a code review of a spike so that you can get alignment about the design lessons the spike teaches...and should be explicit that the discussion has this purpose.

</comment></comment><comment><USER64> What's really amazing about this whole thing is that it's more a guide as to not give bad (nit-pickey, overly critical, discouraging) code reviews, than how to give good ones. I think that alone should give us an idea about the state of code reviews in our current industry as a whole.

</comment><comment><USER65> I had to Google it because I couldn't find any definition anywhere. A "CL" is a change list - maybe, that's what I found from my Google search. It is a term used dozens of times on that site but never defined, as far as I could find.

</comment><comment><USER66> > Also, if a reviewer makes it very difficult for any change to go in, then > developers are disincentivized to make improvements in the future.

Google requires you sign CLA in order to make contributions :)

</comment><comment><USER67> I stopped reading before finishing the third page. It seems to me that what many paragraphs advise is to be reasonable, which is meaningful, but a bit too loose for guiding code reviews.

</comment><comment><USER68> OT: but does somebody know a good code review tool, that fits nicely into git? (Bonus points if it works containerized) Should work for 5 people.

<comment><USER69> GitLab

</comment></comment><comment><USER70> How at this point code review not entirely automated?

There are numerous fuzzy tools, memory leak detectors, linters and standards. Code is data, and it can be analyzed as much as one wants with programs. Sonarqube for example can find bad patterns, code smells, etc, there is no limit to what can be added to such tools.

As long as you don't want to prove that the code terminates, you can probably write an automated checker for the rule.

<comment><USER71> > How at this point code review not entirely automated?

There is no automated way to check intention. I can write perfectly correct code which also drops the database.

<comment><USER70> In this case, wouldn't you use some kind of permission/security groups/roles at the db level or firewalls that would block such intents?

Wouldn't it be possible to add an automatic linter pass that does "grep DROP" on the source code? Even unusually things such as code obfuscation can be automatically detected to some extent.

An automated way sounds more fair, robust and scalable. To me, there is something in human code review that is not engineering, it's all about judging people (unless the code review is fully anonymous for both side)

<comment><USER71> Dropping the db just an extreme example. There are infinite ways a developer can use tools correctly but build wrong things. Don't get me wrong, automating things is great, but you're never going to replace code reviews. Unless you have some crazy advanced AI that can interpret requirements and detect incorrect implementations. But at that point I would imagine the crazy advanced AI might as well be creating the implementation in the first place...

</comment></comment></comment></comment><comment><USER72> Mandatory pre checkin automated testing. Did you do this? Ok, you're good! ;-)

</comment><comment><USER73> Excellent guide. It would be fantastic for Google to adopt these practices.

</comment><comment><USER74> At my first job at front Dev higher up on chain from me left every code review with "we here don't do this.." .. it wasn't long before I caught onto his brewing imposter syndrome

</comment><comment><USER75> what is a CL

<comment><USER76> A CL is a "Changelist". The terminology comes from the Perforce version control software. Technically analogous to a "commit" in git.

The CL terminology stuck within Google even when the underlying version control system is not perforce. For example the Gerrit code review system also calls them "change lists".

It's the unit of granularity for code reviews at Google. In that respect it's analogous to a Pull Request or Merge Request in the outside world.

CL are meant to be updated (edited) in place during the code review process. This is something some people would also do with git commits (amending commits and force pushing) while others would add many individual commits to address code review issues (That's why PR is a better analogy).

</comment></comment><comment><USER77> As a side note, their github hosts 1600 repos. Just wanted to say thank you, google.

<comment><USER78> I would wager that a vast majority of them are personal projects. If you work at Google and want to do some open source project on the side, the code is owned by Google and is under Github.com/google. See: [https://news.ycombinator.com/item?id=15592968](https://news.ycombinator.com/item?id=15592968)

<comment><USER79> Here I am just wishing my company would even allow me to post the source of a project I've worked on with any license and apparently Google isn't worth praise for hosting all such projects with an Apache license by default and a review process if you'd like to try to keep copyright.

[https://opensource.google.com/docs/iarc/](https://opensource.google.com/docs/iarc/)

<comment><USER80> If you live in CA, you're good to do it:

[https://codes.findlaw.com/ca/labor-code/lab- sect-96.html](https://codes.findlaw.com/ca/labor-code/lab-sect-96.html)

as long as you do it on your time, using your own resources, and do not compete with your workplace.

The fact that google (or other employers) do not go out of their way to tell you this is, of course, understandable.

<comment><USER44> You'll be hard pressed at a well-established tech company like Google to find even one programming topic wherein you're not legitimately competing with your employer.

Google's IARC process (where they officially sign over their claim to a given invention) is really, truly unusual. They absolute _are_ going out of their way to be accommodating. Even their (super liberal) open-source process was practically unheard of when they started it. The fact that Chris DiBona runs that office is probably (definitely, absolutely) a factor.

Also, I would exercise extreme caution when using the section 2870 argument with a random employer; there's nothing in there that says you can't be fired if you try it, even (and especially) if you win.

<comment><USER80> Being fired isn't a big deal. In silicon valley you could spit, and hit three companies that'll hire you, at least one of them good

</comment></comment></comment></comment></comment></comment><comment><USER81> I feel like the term "open source" is overused. For code, which is where the term came from in the first place, it's relatively easy to define; but what is "source" for something non-code? Is Google really wanting you to contribute to changing its internal processes? I'd say ..."are now public" makes more sense for releasing this document.

<comment><USER82> The submitted title was "Google's internal code review guidelines are now open source". We've since replaced that with the article title, in accordance with the HN guideline, " _Please use the original title, unless it is misleading or linkbait; don 't editorialize._"

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment><comment><USER83> Just be prepared to say NO, this is what a good reviewer is all about: [https://www.yegor256.com/2015/02/09/serious-code- reviewer.ht...](https://www.yegor256.com/2015/02/09/serious-code- reviewer.html)

</comment><comment><USER84> CL? Is that perforce? Hopefully it works better than the real perforce. A really tough and confusing versioning tool.

<comment><USER85> > CL: Stands for "changelist," which means one self-contained change that has > been submitted to version control or which is undergoing code review. Other > organizations often call this a "change" or a "patch."

source: [https://google.github.io/eng- practices/](https://google.github.io/eng-practices/)

<comment><USER84> Yes, I understand, I used it every day. Just very surprised google used perforce, given my bad experiences with it as a whole.

</comment></comment></comment><comment><USER86> It disturbs me greatly that this is needed. I understand why it is needed, but it's still disturbing.

</comment><comment><USER87> That advice is what I try to do more. I think people who veer more into the logic/engineering side of it forget some obvious emotional common sense:

> If you see something nice in the CL, tell the developer, especially when > they addressed one of your comments in a great way. Code reviews often just > focus on mistakes, but they should offer encouragement and appreciation for > good practices, as well. It's sometimes even more valuable, in terms of > mentoring, to tell a developer what they did right than to tell them what > they did wrong.

</comment><comment><USER88> > Some hardward manufacturers only ship new hardware once a year.

A line snuck in through their code review.

One big issue that I'm not really seeing discussed is that in many cases code reviews end up being very subjective. "hard to maintain", "not readable", "brittle", "needs more tests" are all super subjective. There is no magic tool that can tell you the future maintenance costs (vs. the current costs), whether some area is more likely to see issues, etc. A lot of this is a matter of judgement. One old recommendation I recall is to limit the scope of code reviews to finding bugs. If there is a bug that's pretty objective, the code does not work.

<comment><USER13> You can draw bright lines about some of these things. If a change claims to fix some bug, a test must demonstrate that. If I patch just the test into HEAD and run it, it should fail. If this is not the case then the change "needs more tests".

"Not readable" is why Google also has the "readability" process. A person without readability needs the pre-submit approval of someone with readability in that language. After a while, new people become acculturated and gain readability.

"Matter of judgement" is why hiring is absolutely critical to success in software. You must hire people with good judgement, and to the extent that you might intentional or unintentionally hire bozos, do so at a low enough rate that you can indoctrinate them.

<comment><USER88> "every bug fix must be accompanied with a test that demonstrates the bug/fix" is just dogma IMNSHO. (also see "closing the barn doors after the horses have escaped" or "lightning doesn't strike twice at the same place")

The typical rationale is the tests will now catch a re-introduction of the bug or regression. The reality is that often the tests bloat the code base, they cost in future maintenance making the code harder to refactor, they may introduce their own flakiness (the test itself might have bugs), and the bug that's fixed is generally unlikely to recur. You want good tests- not just a random collection of tests that reflect the history of bugs in the code. I often end up writing a test as part of trying to understand or reproduce the bug, and that test will often stay... But not always.

Sometimes it's the right thing to do. Sometimes it's not. I.e. subjective. The lines aren't always so bright.

To complicate things further it's very hard to gauge the effectiveness of various processes. Is following those specific guidelines a net positive or negative? who knows. I think there's consensus that code reviews in general are a good idea so probably just by having a second person read the code, have a discussion with the author, with no guidelines, you're getting most of the benefit (obvious issues surface, more than one person is familiar with the code etc.). My gut feel is that the rest is in the noise.

I do agree hiring is critical ;) yet another subjective process there. Ideally you'd only hire people with a track record of producing good software in your area of business, most other indicators are probably pretty random. If you're looking to build a first person shooter you should hire John Carmack. Hope he likes your code review guidelines though.

Another random side comment is that IMO design issues should probably be identified before code is written.

EDIT: random semi-related trivia: [https://kotaku.com/the-exceptional-beauty- of-doom-3s-source-...](https://kotaku.com/the-exceptional-beauty-of- doom-3s-source-code-5975610)

<comment><USER13> [https://mobile.twitter.com/dvyukov/status/116954416787113165...](https://mobile.twitter.com/dvyukov/status/1169544167871131653)

This tweet perfectly captures why all bug fixes must have tests. Linux has no tests and no testing culture and it is 17 million lines of juicy hot garbage. Google is mostly tests and it is one of the largest and most successful C++ projects in history of our industry. I feel justified in standing my ground when reviewing under-tested code.

<comment><USER88> > Google is mostly tests and it is one of the largest and most successful C++ > projects in history of our industry.

I'm not quite sure what you mean here? Are you talking about Search? Ads? Cloud? Self driving cars? Google has various products of varying business and technical success levels. Some stuff I feel is a good example of quality software (let's say Go for example or maybe Maps) and some stuff seems to just be very poor software (let's say Google Hangouts Chat or Google Sheets). Some stuff is really good business and some gets cancelled (with little apparent correlation to quality).

Google is so rich that perhaps it is succeeding despite some practices and not because of them. It's initial success probably predates all these practices and there's plenty of quality software in the history of the industry that has been produced using a variety of other practices.

Even if you are right and Google is _the_ most successful C++ code base ever that's still not evidence that some particular practice is the cause of that. There is no way to measure any of this and "feeling" doesn't really cut it. Some practices apply more to certain kinds of software and possibly less to others.

Doesn't Google use Linux? For juicy hot garbage it's done pretty well. With a budget that's a fraction of what Google has. It's also not C++.

re-EDIT: Another thing to note is that Google has a large number of engineers developing internal tools, build systems, test engineers etc. With all the automation around dealing with flaky tests and testing in general at scale perhaps this works better for Google. Other companies who do not have the luxury of having 100's of engineers work on their build or test systems may run into different problems when they try to do things the Google way. Because Google is overall fairly opaque (the open bits are exceptions) it's hard to really come to a conclusion about how well they do software. I've heard different stories from different sources and I'll bet there's lots of internal variation as well. The success as a company is undeniable but there's more to that than software.

</comment></comment></comment></comment></comment><comment><USER89> Am I the only software engineer in the world who hates diff-based code review?

Imagine trying to evaluate the quality of a novel by examining diffs to the manuscript. Reviewing every diff means that every single change needs to yield a good novel. But that's an absurd constraint on the creative process - <USER3> if you want to introduce a new important character? You check in a new version of the first chapter where the character figures prominently, but the reviewer complains that the new character's plot arc never goes anywhere.

The main goal of this diff-based code review seems to be to prevent people from checking in bad code. But of course you should sometimes check in bad code (especially in the early stages of a project)! You might consciously check in some bad code temporarily, intending to upgrade the code at some future point. More importantly, you generally don't know how or if you're actually going to end up using any given piece of code. Spending a lot of time polishing and reviewing code that doesn't eventually go into the project is a classic example of premature optimization (the root of all evil).

<comment><USER90> Because grokking 20 diffs across 5 files is a lot easier than grokking the entirety of those files and the context on which they live. If you assume the rest of the codebase meets some reasonable standard of quality the diff should be the only important thing.

That said, for particularly complicated changes I'll check out the code and read through it locally but diffing is surely optimized for the most common case.

</comment></comment><comment><USER91> > At Google, we hire great software engineers, and you are one of them.

That's a pretty presumptuous comment.

<comment><USER92> I don't know a single company that doesn't hire great engineers.

</comment></comment><comment><USER93> To me this doesn't look a very good guideline. It's needlessly verbose and unintuitive. Instead of writing a long sprawling list of things, just using bullet points and figures would be better.

It mentions the importance of getting a big picture of the code in question first, but the guideline itself is pretty bad at presenting its big picture.

Here's the gist of it as I understand:

\- Long-term health of the code is important.

\- Development should be incremental and steady.

\- Beware of the contexts: style, use cases and technical complexity.

\- Suggest them changes with reasons.

\- Make it quick enough.

<comment><USER94> Guidelines this big is there for a reason , lot of minds have gone behind this and every thing is a read to resonate with and come up as you understand it. Bulleted points and gist are good , but we are here to revise what we studied last night. This is a senior developer talking to a junior developer who is starting out. Also this is something go back and discuss and enhance.</comment></comment>


A Visual Introduction to VC Financing (2015) - <AUTHOR> https://dlopuch.github.io/venture-dealr/ <comment><USER2> Do most VC companies provide training or mentorship like YC? What if you're a sole engineer with a good product and a patent but no idea how to turn that into a business. Do you even need venture capital if you're just selling one thing? I don't even know how to spend $1000.

<comment><USER3> > how to spend $1000

It's really funny because when building something, I will often look at overall cost as one of the main motivators for doing something for a personal business.

</comment></comment><comment><USER4> We recently launched a simple stock option value calculator on our jobs pages [https://about.gitlab.com/handbook/people-group/global- compen...](https://about.gitlab.com/handbook/people-group/global- compensation/calculator/) that has a few scenarios. I love how this calculator gives a lot more variables to try. Maybe we should link to it.

</comment><comment><USER5> Was just looking for a refresher on cap tables and the like, and being a visual learner, this is great.

Another tool some might find useful, which I was introduced to during YC Startup School:

[http://growth.tlb.org](http://growth.tlb.org)

Startup growth calculator that helps get a basic feel for funding requirements and runway length. Really helps when it's visualized like that.

</comment><comment><USER6> I really like how the visualizations are animated based on scroll waypoints. What libraries have support for that?

<comment><USER7> Author here! (neat, didn't think I'd see it submitted it here again, glad the person who dug this up found it useful!)

I made this four years ago as an experiment in D3 when the scroll-to- transition style was first getting popular (think nytimes and such).

All of it is basically hand-rolled D3 transitions with lots of debugging around enter/exit state... haven't looked at D3 lately so not sure if it's any easier. Charting libraries are a dime a dozen now, but these days when I need some easy charting, I like the D3+React bindings from VictoryCharts [https://formidable.com/open-source/victory/docs/victory- char...](https://formidable.com/open-source/victory/docs/victory-chart)

Kinda hard to wrap your head around how they do transitions in react-eese, but well, so is raw D3...

</comment></comment><comment><USER8> @robbya - Really enjoyed your visualization, time-lined interactive visualations like these are great!

Quick suggestion: You mention "Venture Makr" at the end but dont provide any way to capture my email and no way to be notified of Venture Makr's launch.

<comment><AUTHOR> I believe @floatrock is the author for this.</comment></comment>


Massive study on the genetics of educational attainment - <AUTHOR> https://blog.23andme.com/23andme-research/massive-study-on-the-genetics-of-educational-attainment/ <comment><USER2> Educational attainment or educational access? A person can't attain something they do not have access to and educational access hasn't exactly been equal over the past generations.</comment>


Truly Secure Voting Is on the Way - geek-advised https://www.scientificamerican.com/article/truly-secure-voting-is-on-the-way/ <comment><AUTHOR> The article barely misses the main point:

> _In the end, an election is a complex sociotechnical machine, which means > all citizens—not just election officials—will need to be on guard in 2020 > and beyond._

Sure, but you have just brought " _uses video selfies to verify voters ' identities and sends blockchain-encrypted votes to a digital lockbox_" into the process. How exactly is a non-programmer citizen supposed to be on guard for something like that?

It's amazing to me how far people are willing to go in order to avoid paper ballots.</comment>


Ask HN: Use a banker to sell a seed stage company? - <AUTHOR> (Going anonymous for obvious reasons)
My B2B software company raised a pre-seed round, built a product, and got some great customers. Our industry's long sales cycle, along with resistance to buy from startups, has made raising our next round of funding harder than we thought it'd be.
An investment banker with deep knowledge of our industry thinks they can sell our current product and team for ~20X what we've raised. As a good steward of my investors' money, I'm inclined to give it a shot.
Has anyone on HN used an investment bank to sell a seed stage company? I would have thought it was crazy, but this bank is really confident in their ability to elicit a transaction. <comment><USER2> It's certainly not unheard of. But you are going to be paying a hefty commission. And if it's a sale of you current product "and team," what would be going to the investors vs. being reserved for employee incentives post acquisition?

Do you have a sense of the players that would potentially be interested in acquiring your company? If so, I would start using your network to reach out to those players.

An i-banker may be great if you are looking for a private equity-type deal. But if your potential acquirors are companies like Salesforce or Google or some other tech company, you might be better off exploring on your own.

To the extent you engage an investment banker, be very, very careful about what you sign. Those agreements can be incredibly onerous...</comment>


Just How Big Are The Eyes Of A Giant Squid? - <AUTHOR> http://www.npr.org/2012/03/15/148694025/just-how-big-are-the-eyes-of-a-giant-squid

<comment><USER2> _"... Scientists didn't even have photographs of a live one in the wild until 2004. Occasionally, a fishing boat will haul in a big dead or dying blob. ..."_

Back in 2008 I watched a giant squid dissection & captured images of the dissection ~ [http://www.flickr.com/photos/bootload/sets/72157606211764544...](http://www.flickr.com/photos/bootload/sets/72157606211764544/with/2676995608/) But I don't remember viewing the eye. If memory serves me I think the eye was a casualty of the ascent.

 _"... There's things down there where their entire bodies are made of snot, they've got detachable heads, their teeth fall out, they explode and they eat their snot jackets. ... There is just weird things going on everywhere. ..."_ Dr Mark Norman.

It was caught at a depth of 550m by a commercial fishing vessel, 'Zeehaan' off the coast of Portland, Victoria. Weighing in at ~245Kg with a length of 12m the dissection concentrated on finding things out like the length, contents of the stomach, sex & also looking for sperm capsules injected by male squid at speed. The place stank of ammonium and no you couldn't eat it. The flesh is infused with ammonia for buoyancy.

There is also a video of the entire dissection & running commentary by _"Squid (Cephalopod) nerd"_ , Dr Mark Norman from Museum of Victoria ~ [http://museumvictoria.com.au/pages/7003/MVLiveSquidDissectio...](http://museumvictoria.com.au/pages/7003/MVLiveSquidDissection.wmv) (400Mb @ 1hr+) and the highlights ~ [http://museumvictoria.com.au/learning- federation/video-temp/...](http://museumvictoria.com.au/learning- federation/video-temp/public-dissection-of-giant-squid-video/) (10min)

<comment><USER3> Anecdotally we once had a dish of raw squid at a Japanese restaurant. They tried to dissuade us from ordering it. I could taste nothing but ammonia. There's also the ammonia (aka Liquorice?) flavored vodka: <http://en.wikipedia.org/wiki/Salmiakki_Koskenkorva>

Take home: what is edible may depend on where you grew up (deep ocean, etc.)

<comment><USER2> _"... They tried to dissuade us from ordering it. I could taste nothing but ammonia. ..."_

That is funny, don't say they didn't warn you. The room I was in was pretty big, 2 levels but the smell was like putting your nose to bleach. The taste doesn't seem to matter to Sperm whale.

</comment></comment></comment><comment><AUTHOR> BBC report with animal size comparison charts:

<http://www.bbc.co.uk/news/science-environment-17365736>

Link to abstract of article in Current Biology that is prompting the press reports:

[http://www.sciencedirect.com/science/article/pii/S0960982212...](http://www.sciencedirect.com/science/article/pii/S0960982212001820)

</comment><comment><USER4> How does the "large eye to see large objects" thesis make any sense at all? I can see the moon just fine with my puny little orbs. I get that the large eye will have an extremely narrow "depth of field" for small objects, but how does that mean it will see larger ones any better?

It seems a whole lot more likely to me that it's "large eye to catch more photons because it's _DARK_ down there".

EDIT: maybe something to do with the fact that the light that is down there falls off quickly so a larger aperture somehow lets you correlate the scattered light better?

<comment><USER5> The simple answer is: the larger the eye, the more "pixels" (cells of the retina which respond to light energy). So larger eye == higher resolution.

The current theory regarding "why is all that resolution necessary?" is: there are tiny creatures swimming alongside the squid, which respond to a sperm whale's sonar by emitting a tiny amount of light. When the squid sees this light, it knows that a whale attack is imminent, and runs. (Well, jets.)

If the eyes were smaller then there wouldn't be enough resolution to make out the tiny dots of light emitted by those tiny creatures.

Another way of thinking about it is: the eye needed to evolve larger in proportion to how tiny the creature is. If the creatures were twice as big, then the eye would've evolved half as large as it currently is. (If the theory is true.)

Mathematically, there need to be enough retina cells such that "1 tiny creature at distance D can be detected per degree of viewing angle". E.g. if the squid has a 130deg field of view, and it needs to be able to see the creature light up within 1 foot of its eye, then it needs enough retina cells in order to scan the entire conic volume of the space between the eye point and "1 foot in front of the eye point". By the Nyquist frequency, that suggests there need to be at least two retina cells per "tiny creature body length projected from a distance of 1 foot". (The farther it is from the eye, the smaller its projection; and thus correspondingly more retina cells are required, which requires a physically larger eyeball. Note that as the eye gets larger, the field of view remains the same.)

To clarify: the squid isn't looking at the whale at all. Rather, the squid is looking at tiny sea creatures very close to its face that light up when hit by a whale's sonar. Thus they act as an early warning system for the squid.

<comment><USER6> The squid doesn't need to resolve the little sea creatures in order to detect a whale. It only needs enough resolution to resolve a huge number of the little lights into a whale-shaped blob. For that, it needs an eye with the biggest possible aperture and sensitive sensors. The increased resolution may be an additional benefit of the better light-gathering ability of a big eye but isn't necessary.

The article says _the researchers calculate that the squid eyes they measured are the optimal size for seeing something far away and massive_. Why isn't the biggest possible eye that can be grown the best? Is there some other constraint besides the mechanical structural issue or risk of damage, etc.?

</comment></comment></comment><comment><USER7> I'd wish there would be a browser extension that would find all the occurences of numbers with imperial units (like "40 feet" or "10 miles") and offered a metric conversion as a hovertext, or whatever. Just like this dumb, annoying Skype extension that converts everything that looks like a phone number to Call-By-Skype button, but without the dumb & annoying part.

It's hard for me, as well as probably for the majority of this planet, to easily visualize what the article is about, when everything is given in alien units (and constant CTRL+TABing to Wolfram|Alpha kind of breaks the reading flow).

<comment><USER8> I wish American teachers would follow the advice given by The Oatmeal: <http://theoatmeal.com/pl/senior_year/science>

</comment></comment><comment><USER9> It's eye looks like the eye Argonauts used to draw on their ships. I am posting a link to an image when I find one.

</comment><comment><USER10> I wonder if eyes like that would help you spot bugs easier

;)</comment>


Prometheus: Monitoring at SoundCloud - <AUTHOR> https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud

<comment><USER2> Prometheus is really nice. It focuses on the right things needed to monitor distributed systems (complex expressions and alerting) where others (e.g. opentsdb and influxdb) fall short, at the expense of deferring the issue of massive scalability which, let's face it, it's not a real requirement for most scenarios.

</comment><comment><USER3> This looks really interesting - thanks for sharing!

</comment><comment><USER4> Thats pretty cool, can it be used with HA proxy?

<comment><USER5> Yes, I've written up a blog post on how we do it: [http://www.boxever.com/haproxy-monitoring-with- prometheus](http://www.boxever.com/haproxy-monitoring-with-prometheus)

It's been very useful.</comment></comment>


Draw A Stickman - Interactive Canvas Story Telling - <AUTHOR> http://www.drawastickman.com/

<comment><USER2> Awesome stuff!

</comment><comment><USER3> Raphael.js, in case you're wondering.</comment>


Japanese Company Makes CBD from Orange Peels - <AUTHOR> https://www.labroots.com/trending/cannabis-sciences/17757/japanese-company-makes-cbd-orange-peels <comment><USER2> Ah, yet another company that has a process to create CBD from the terpenes found in orange peels. This isn't the isolation of CBD, as you would from hemp, but the creation of CBD from precursors using chemistry. I don't know if this is usually the labroots style, but this is a press release disguised as an article.

</comment><comment><USER3> Flagged, because the author clearly has no idea what they're talking about:

> Until now, the company has not tested the effectiveness of orange peel CBD > against CBD derived from hemp. Although they said they might look into it > soon, whether or not their version of CBD is effective is thus still open > for debate.

<comment><USER4> The next paragraph however:

> Early studies have found that other alternatives for CBD are just as > effective as more effective than regular CBD. A study conducted by Peak > Health on its hops-derived CBD product, ImmunAG, found that it was more > effective at reducing calcification in the heart than cannabis-derived CBD > at 'every concentration'.

</comment></comment><comment><USER5> I can't find it now, but I'm pretty sure a very early version of The Onion had an article that predicted this for THC.

</comment><comment><USER6> If you want CBD get a dry herb vaporizer and the devils lettuce and set it to the temperature for the terpines you want.

</comment><comment><USER7> I've been reading lately that CBD alone doesn't do much, maybe they can also synthesize some THC out of the peels?

<comment><USER2> Out of the peels? Perhaps. It depends on the kinds of chemicals that are in there. The question is, why bother? This quora thread goes over some of the reasons why synthesizing THC is a fairly pointless exercise (barring cetain highly specific conditions such as unavailability of hemp etc). [https://www.quora.com/Can-THC-be-synthesized-Can-you-make- TH...](https://www.quora.com/Can-THC-be-synthesized-Can-you-make-THC-without- a-marijuana-plant)</comment></comment>


Are You An Entrepreneur? - <AUTHOR> http://www.infochachkie.com/are-you-an-entrepreneurial/

<comment><USER2> Nice article, and I agree.

I think I could summarize it this way though: if you're spending time thinking about _how to become an "entrepreneur"_ , then you probably aren't one.</comment>


Kingston just introduced a record-breaking 2TB flash drive - <AUTHOR> http://bgr.com/2017/01/03/kingston-2tb-flash-drive-release-date/ <comment><USER2> Some discussion about this is already happening:

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


Show HN: Directory Index Media Player - <AUTHOR> https://github.com/andornaut/dimpl

<comment><AUTHOR> DIMPL is a small React-based Chrome app that lets you stream (some) audio and video files from your webserver, using only the directory indexes that your webserver can be configured to create.

You can also install DIMPL as a standalone Electron application.

[https://chrome.google.com/webstore/detail/directory-index- me...](https://chrome.google.com/webstore/detail/directory-index-media- pla/bcanaaidccjjjigbdiegafllllpbgkdg)

</comment><comment><USER2> I thought this would be a media player that discovered music/video on the web via Apache/etc directory indexes :(

</comment><comment><USER3> Can it be used with Owncloud?

<comment><AUTHOR> I haven't used Owncloud myself, but judging by the docs on ArchWiki, it appears that Owncloud is served by a web server such as Apache or Nginx. If that's the case, then you would just need to mount your media directory to a web-accessible location and then enable automatic directory indexes.

More info:

[https://wiki.apache.org/httpd/DirectoryListings#Directory_Li...](https://wiki.apache.org/httpd/DirectoryListings#Directory_Listings)

[http://nginx.org/en/docs/http/ngx_http_autoindex_module.html](http://nginx.org/en/docs/http/ngx_http_autoindex_module.html)</comment></comment>


Any Writers?  Need Testers for my app - <AUTHOR> http://litlift.com/alpha-release-ready-for-testing

<comment><USER2> Thought maybe it was geared towards blogging =( Have an upvote though.</comment>


Carpocalypse now: Lyft's founders are right – we're in the endgame for cars - <AUTHOR> https://www.businessinsider.com/carpocalypse-cars-automobile-sales-data-us-europe-2019-3 <comment><USER2> Good news. The amount of resources devoted to cars is nuts. Just for parking in an average city.

We do need transportation but private cars are an incredibly inefficient solution for most people. Sharing / renting, public transportation and... walking work great in at least 80% of my needs. I'm gonna guess the same applies to at least 80% of urban and suburban dwellers (and if not, resources should be shifted from Free Parking and other car oriented things to excellent public).

I've lived nearly my entire life without one. I do live in cities but so do half the population.

<comment><USER3> Your experience is not universal. Public transportation covers maybe 5% of my needs, and that's if I'm being generous.

<comment><USER2> Honestly? I walk most palaces. Bad weather is my biggest reason to riding. And most people in cities can do that much more. Within an hour I can walk to most of my meetings throughout town. I live in a central-ish spot. Nice, affordable and walk-able - part of the choice. Driving takes almost as much time. The trams or metro save time only if the walk is over 30 min - and even at 60 min save only about half the time at best.

But as I posted, I didn't claim to be some universal example. I guessed 50% of people live in urban or sub-urban areas - high enough density to make public transportation practical. And I guessed that walking / public is appropriate for of transport needs.

Those who live in rural areas and/or have special needs would not be covered by the 50/80% easily (but I bet a very high percent would be covered by shared or taxi services)

Owning a car is absurdly inefficient. It sits parked 90% or more of its existence. We all pay taxes to support massive infrastructure for private cars - such as street parking in cities and police for drivers who can't stay within the law and choose to endanger my kids lives for their own convenience. Our whole view on car ownership is backwards.

I'm not preaching though - it's my choice to spend my money on things I find more useful than a status symbol parked where it might get stolen, broken into, and generally cost money. Everyone gets to make their own choices. :-)

</comment></comment></comment><comment><USER4> I'm not convinced by this argument. One factor he isn't addressing is that cars may be getting more reliable, as in people drive them for longer. My grandmother for instance switched to Toyota 25 years ago and has two cars that whole time.

Another problem I see is that car sales aren't necessarily in s huge of downturn as he says. 2016-2017 according to his own graph shows massive growth and it looks like the UK has returned to 2016 numbers. Considering the weaker pound and the fear around Brexit, this doesn't seem to me to be all that bad long-term.

China and Turkey are both having economic downturns along with Britain. I wonder if he could make the same argument while using economicly stable countries.

One thing I'm thinking that might aid his argument is that the baby boomers are beginning to get old enough to stop driving or dying. Could that harm sales? Also I'd like to see how Lyft came up with the 300k riders who stopped owning a car.

<comment><USER2> I agree with you. Though your grandmother is obviously more sensible than the average car buyer, she's not representative.

I think 300k is fantasy.

But, that Lyft is actively taking on the car economy is encouraging. They aren't a band of hippies, it's a business that sees an opportunity in doing so. They may fail, or they may be what Tesla is to electric cars. That I find encouraging.

</comment></comment><comment> frosted-flakes From the article:

> Although extreme, Turkey proves one thing. Today's cars last so long that if > bad times happen consumers can simply stop buying new ones and get along > just fine with their old ones.

Is this true? Despite (or perhaps because of) the many improvements in technology, cars are also becoming more complex. Certainly what I've seen is that you can't do anything without an expensive diagnostics tool anymore, and it's harder to get by with simple fixes an average car owner might be able to do.

For example, I drive a 20 year old VW whose windshield wipers recently decided to keep going non-stop. Diagnosis was simple: the clicking relay unit under the steering wheel was malfunctioning. Repair was even simpler: popping open the relay revealed the simplest, most organised piece of electronics I've ever seen, and it was clear that all that was necessary was to clean the contacts on one of the relays and pop it back in the car. Job done.

Compare that to a modern car in 20 years, where any similar problem will likely require an electrical engineering degree to even diagnose, if planned obsolescence hasn't done its work by then.

<comment><USER5> This is exactly why I like older cars instead of new ones.

The car company that make a simple, good, mechanical-& environmental-friendly car will earn a lot of money.

But they are so concentrated on high-tech and owning the vehicle/dealerships, that they forget what's truly important for their consumers.

I would love to see a modern Mercedes 190 Electric version, that is easy to repair.

</comment></comment><comment><USER6> Allow me to doubt that Lyft (or Uber) or both actually influence a market where they do not exist at all or are very, very marginal (like - say - Turkey) and even if they do, they alter it by 60%:

[https://isturkeysafe.com/Is-Uber-safe-in-Turkey](https://isturkeysafe.com/Is- Uber-safe-in-Turkey)

</comment><comment><USER7> I'm afraid that the reduction in demand for cars may also be a result of an expected economic downturn?

</comment><comment><USER7> > It's hard to say whether car manufacturing is hurting because the greater > global economy is faltering, or whether the faltering economy is hurting > cars.

Hmm, aren't both parts of the sentence saying the same thing?

</comment><comment><USER8> I'll always want my private vehicle, in the future it will just drive itself. But I want to own mine. I like to go to Utah and go off roading

<comment><USER9> Cannot you just rent on an extended period of time then? Even if you want to "go off roading" once in a while, you probably are not constantly using it.

</comment></comment><comment><USER10> Subprime car loans may explain the delinquency rise. That business was expanded hugely in the last 10 years, and was one of Uber major loss areas.

</comment><comment><USER11> I always want a nice high performance vehicle with luxury features as long as I can drive. Pub transport is not an option for anything but work and cars are one of the last pleasures in the gen X life.</comment>