Ask HN: As a programmer, how do you know if you're a good one or not? - <AUTHOR> I always want to be a better version of myself, but it's unclear how to quantify my quality. In sporting, there're many stats about athletes to look at. In academia, you can look at some indirect indexes about your research quality. But as a programmer at work, I often receive feedbacks from 1 or 2 persons at most. It's easy to think that I'm good enough, when the truth may be not.
So, as a programmer, how do you quantify or estimate how good you are?
Thank you, <comment><USER2> You're asking the wrong question. You should be asking "Am I an efficient or effective programmer?"

      Do I get things in on time / under budget?
      Do I avoid common programming pitfalls?
      Do I solve more problems than I create?
      Do I see simple solutions to complex problems?
      Can I refactor terrible code to more easily maintained code?
      Can I avoid terribly written code in the first place?
      Can I effectively communicate with people in order to get the answers I need without wasting their time with needless questions?

Then you know you're effective when:

      You're asked for help often.
      You're the go to person by the boss.
      You're often asked for your opinion for engineering decisions.
      Your opinion holds weight with others.

<comment><USER3> One of my gotos has been 'Can I avoid writing code in the first place?'

Zero code has zero bugs, and zero maintenance cost.

<comment><USER4> A great programmer is like a peaceful master samurai, he first tries all other options before resorting to violence (code) he may also reduce violence (code) where ever he goes ...

</comment></comment></comment><comment><USER5> Programming is a craft once you reach a certain level their is no checklist or metric that can be used to measure you ability. Only experience and battle scars tell how good you might be when solving the next problem.

Only ever measure yourself against yourself. As long as you make sure you are a better programmer today then yesterday then you have nothing to worry about.

<comment><USER6> This. After 15 years as a professional developer I have a fairly good idea where my boundaries are, and that's about it.

Expect to learn new things every day, and from every conceivable source: your fellow developers, junior and senior, of course, but also your PM (for example, prioritization, techniques to organize work), designers (information flow, HCI), business analysts (how the client ticks), etc.. Very likely everyone you ever worked with could teach you _something_ , and you'll never have time to learn it all.

</comment></comment><comment><USER7> I put in the work. I once heard a very good fencer say that the way they keep calm during competitions is to tell themselves that they've put in the hours of training and the blood, sweat and tears necessary to win. I spend hours of my days writing code, reading about how to become a better programmer, constantly analyzing my work and finding ways to improve. I'm not going to spend my time worrying about whether I'm a good programmer. I _will_ be a good programmer.

<comment><USER8> Hours of deliberate practice is said to be the deciding factor in how good you are. Or at least, we can't be good without it. So yes, counting the hours we spent writing and analyzing code gives us an idea of how good we might be as programmers.

</comment></comment><comment><USER9> This is a general problem.

In sports, for most people, staistics are meaningless. I climb 5.10 okay... am I good climber? I'm not world class, but I do stuff that I like.

I've been an academic. I know I was a bad one, because in retrospect I had to step away from a lot of my ideas and research... at the end, I didn't see value in the projects I was doing.

As a programmer... who knows. I don't usually have a lot of problems coming back to old projects and building new stuff. I don't have a lot of systems I put together breaking down and requiring work. I know that there are at least 10-20 other folks think I am good, because I've solved things for them and they have told me I am good.

But I just build CRUD apps, admin some linux servers, and put together custom code for WordPress. Some folks would look at that pile of day-to-day tech cruft and say that I am not even a "real" programmer (even if I do know how to implement a buffer with TTL and I've written toy mouse drivers and serial implementations).

All that comes down to this: it really comes down to you and your goals, and what you want to get out of your life. You are the only measure of what you consider to be a good person. Most of us are sane enough to peg that estimation to feedback we get from other people. But fundamentally the metrics are still our own.

</comment><comment><USER10> Programming is an open ended non competitive (generally) activity. I don't think there is any meaning in trying to quantify "goodness" and in fact might blind you to possibilities.

So, for myself, the thing I pay attention to is my ease of expressing the things I want to create. I also pay attention to my ability to produce things with certain "qualities" correctness, simplicity, and how modular and composable my code is. There is no objective measure of those things and my understanding of those things constantly expands. I learn these things through by my own experience and looking at what other people are doing and having in depth discussions about programming ( and outside of programming ).

So I have no idea how good I am, but I have confidence in what things I can create and confidence in my ability to learn more.

</comment><comment><USER11> Does my code still make sense to me 6 months later?

Did I introduce new bugs?

Are people using my building blocks to add features or working around them/ redoing them?

These are not good metrics. I have researched this and it seems there is no good way to measure coding improvement except subjective measurements.

</comment><comment><USER12> There are many ways to quantify how good of a programmer you are.

\- You can compare yourself to other developers (there are plenty of qualities to compare)

\- You can review your statistics (commit frequency, average file size, accuracy of time estimates)

\- You can compete in programming competitions

\- You can evaluate yourself using the Programmer Competency Matrix: [https://sijinjoseph.com/programmer-competency- matrix/](https://sijinjoseph.com/programmer-competency-matrix/)

Also, "Good" is subjective. Some programmers are "good" in certain contexts, but "not good" in others.

<comment><USER13> Wow, this competency matrix is very useful. Thanks for sharing!

</comment></comment><comment><USER14> 1\. read others code. think. ask questions. why and how certain code is written in certain way.

2\. Read more code.

3\. Write more code.

4\. If your code which you wrote few years back looks bad to you, then you are on right path.

5\. How much you understand the core concepts. New languages and frameworks are more of an glitter.

6\. You want to be better version of yourself, then your progess is your stats you need look at. How many books did you read year on year? How much code you read year on year ? How much code you wrote ? How much fun you had :)

7\. Adding, if you can think of the future maintainer of your code in mind and code, then you are lot better than many programmers out there in business.

8\. Try to be a clean code enthusiast.

<comment><USER15> > 4\. If your code which you wrote few years back looks bad to you, then you > are on right path.

What if the recent stuff looks bad too? :)

<comment><USER16> Then why are you writing it?

<comment><USER17> Because you have a working, but ugly, solution to a problem and can't figure out a solution that _does_ look good. Or because it's a trade-off: the thing you think would be better requires more work than you think the feature is worth. Maybe you want to tractor to make it more reusable, but decide it is unlikely to be reused, so not worth the effort.

</comment></comment></comment></comment><comment><USER18> The more experience I get, the more I realize that I'm pretty average.

<comment><USER19> I just purchased a coffee mug that says "World's Okayest Developer" so I'm right there with you.

In all seriousness, though: I've learned that it's better to just accept that sometimes you'll do really good or exceptional work, sometimes you'll do awful work, and most of the time you'll do work that's pretty good and gets the job done but isn't perfect.

<comment><USER20> I consider myself okayest because I can fix the stuff I break or improve something I did months ago. Believe it or not, a lot of people I have worked with can't.

</comment></comment></comment><comment><USER21> There are no such things as good programmers. Humans have no idea how to program computers, and anybody who tells you differently is lying.

The most honest person here is [https://news.ycombinator.com/item?id=18538092](https://news.ycombinator.com/item?id=18538092)

</comment><comment><USER22> If people are explaining stuff to you all the time, you're the dumbest guy in the room.

If you're explaining stuff to people, you're the smartest guy in the room, and you should find a place to work where you're the dumbest guy in the room.

</comment><comment><USER23> This is a very complicated thing to answer concisely, but I'll take a stab at it from a product development perspective.

You know you're a good programmer if the things you build "just work." It should be near impossible to find flaws in your solutions. This is actually rare. Most developers I've worked with will declare something "done" well before all of the flaws have been worked out.

<comment><USER24> _You know you 're a good programmer if the things you build "just work."_

How do you quantify, "just works?" For a large enough project, perfection, or even just getting pretty close to it, ends up being pretty expensive.

 _It should be near impossible to find flaws in your solutions._

I had a boss who declared he could find a bug in any page of code, so long as you let him lawyer the specs in great enough detail. Granted, we were working in a pretty complex domain, but as far as I could see, he was always right about that.

As Matt Easton keeps saying: "Context!"

Maybe the company you're working for finds it much more valuable to do lots of iterations so they can tinker with the product and keep refining it. In that case, it might be even better than "perfection" if the things you build mostly work, but that you can respond to change and bugfix requests quickly. (Without introducing regressions.)

</comment></comment><comment><USER25> Depends on how you measure it, if you gave me a programming test that measured how much i knew and if i knew the intricacies of a language and memorised the manual, while also testing me on computer science questions that only get talked about in universities, then i'd probably perform poorly.

However, i'm a get shit done developer, while i've been doing this 14 years and know my area very well, i dont know it nearly as well as someone who has rigorously studied it and has been doing it for only 3-5 years. What i can do is deliver, and thats whats valuable to businesses.

So, is "good" an academic measurement or a business one? Its all context.

</comment><comment><USER26> Ha! So, so many definitions of good. But, at a basic level, you can boil it down to:

* Does my code work?

* Does my code look after itself and its user when things don't go according to plan?

* Is my code simple?

* Can my code be maintained?

There are very serious sub-plots involving (ie) what does "work" mean? are simple and maintainable the same thing? But if you hit the four points above and don't fart in the office, you're good to go.

</comment><comment><USER27> I knew I wasn't very good when I worked as a programmer. I based that on watching others, and how often I could figure out problems without asking for help. I could see I was waaaaaayyy behind even the newest people around me. That was a long time ago, I'm still in IT, but not a coder now. I do ok with the basics still, but I ask for help all the time.

</comment><comment><USER28> Some basic heuristics I use for determining the capability of _other programmers_ and myself:

1.) Does the code have a good _bus factor_ i.e If the maintainer dies tomorrow by being knocked down by a bus, can other people pick up where he/she left off? Further research into the Bus Factor can be found here: [https://www.youtube.com/watch?v=0SARbwvhupQ](https://www.youtube.com/watch?v=0SARbwvhupQ)

2.) Is the code well documented? This is so obvious that it is painful to write this comment, but it is a very simple heuristic for determining capability. Documentation can include code comments.

3.) Is the code resilient to weird input? The code should perform well under heavy fuzzing and where possible, sanitize different input. It should be tested against this: [https://github.com/minimaxir/big-list-of-naughty- strings](https://github.com/minimaxir/big-list-of-naughty-strings)

</comment><comment> alex- If your employer is happy with your performance then you are probably "good enough" as you say.

However if you truly do always want to be improving your ability as a software engineer, then you are in luck, this field is so vast and deep that you can easily spend more than a lifetime improving! Finding out how and measuring it is another matter.

</comment><comment> sahil-kang I would recommend contributing code to a well known FOSS project, or at least an existing project that you use or respect. I think hacking on meaningful projects will be clear milestones for yourself, which seems to be what you're looking for.

To encourage you, here are a couple of contributions I have to Linux and Hadoop:

_[https://github.com/torvalds/linux/commit/0bef71093d446165964...](https://github.com/torvalds/linux/commit/0bef71093d4461659643ddcef431d88a078e0407) _[https://github.com/apache/hadoop/pull/114](https://github.com/apache/hadoop/pull/114)

If you read through the commit messages and look at the patches, I think you'll find that reaching these clear milestones doesn't take an unattainable amount of skill; just a bit of patience and curiosity.

</comment><comment><USER29> I find as I get more experience I realize my limitations as a programmer so I can predict much further out where I'll run into trouble. It usually ends up being avoiding bad architectural choices, avoiding bad abstractions, avoiding introducing bugs into code that works. It's easy to spot a bad programmer, I find that a lot of the time a good programmer will be known for their faults in other areas (ie. Bad communicator) but people take their skill for granted. And then there's the rare programmer who can solve things that others can't understand. There's way more bad programmers than star ones, but my guess is a lot of people here fall into the good not great category unless their track record is exceptional. A lot of people try and fail early, much like companies, so if you've been in the game for a while it's a good indication.

</comment><comment><USER30> Granted, I'm a lone wolf (mostly) scientific programmer, not a commercial software developer. I look at a few things:

1\. Keep an eye on how big or elaborate my programs get before I lose control of them, and have to either stop development, start from scratch, or massively refactor in order to know what the heck is going on. Being able to maintain a larger program, or participate in a larger project, without doing too much damage, seems like a reasonable informal metric.

2\. Look at programs that I've written months or years ago and critique my own work. A year-old program should hopefully look better than a decade-old program.

3\. Try to stay abreast of improved programming techniques, incorporate them in my work, and have faith that my programs will gradually improve.

I just realized these things are not about how good I am, but about the _rate of change_ of my skills.

</comment><comment><USER31> Just from pure introspection, you might be able to glean an answer by thinking about these questions:

— Are you capable of distinguishing opinion from fact? Are you capable of distinguishing _your own_ opinion from fact?

— Any project will have easy bits and hard bits. How accurate are your predictions of which bits are easy and which bits are hard, for projects within your domain of expertise?

— When you think about your software, how good an idea do you have of what's "cheap" to achieve, and what's "expensive" (e.g. which endpoints or queries are fast and which are slow)? What's easy, what's hard? Do you understand how the people who consume your software use it? Do you know whether common operations for them are cheap and/or easy? Do you understand why (or why not)?

— Turn the previous question around — do you understand the design behind the software that you consume? Are your own common operations things that are cheap and/or easy to achieve using that software? Do you know why (not)?

— When you think of technical choices, do you tend to think in terms of absolute right and wrong, or do you prefer thinking in terms of tradeoffs? If the latter, how capable are you of articulating why a given tradeoff makes sense in one situation but not another? Are the tradeoffs you consider limited to technical matters, or do you consider "softer" aspects in your analysis (such as recruiting costs, time to market)?

— How well do you know your tech stack of choice? How well do you understand your own limitations within that stack? How does your stack of choice measure up against the alternatives? Where is it better, where is it worse?

— And, finally — why does any of this matter? Do you genuinely want to work on the sort of project that _actually_ requires so-called "rockstar" engineers, or are you happy working on projects where good enough really is good enough? How much effort would it take to actually become a rockstar? What would it cost you? (you might want to go over the bit on tradeoffs above again)

</comment><comment><USER32> I believe that you get good by getting better. And I think it's easier to tell that you've gotten better than it is to tell that you've gotten good.

Look back 6 months, a year, 2 years. How have you grown? What can you do now that you couldn't do then? Are there things that you'd do differently? Things you wouldn't do at all? That might give you a sense of where you are now.

Repeat the process of getting better many times. Then one day you'll take some call, draw some diagram, write some code and you'll know. For a brief shining moment you will know without a doubt that it is good and you are too. Then the moment will pass and you'll spend a couple of years trying to find the next one.

</comment><comment><USER33> > But as a programmer at work, I often receive feedbacks from 1 or 2 persons > at most

Oof, yeah, that's rough. It's hard to say something conclusive with little data, and most of the data is likely biased (yourself). I'd recommend finding opportunities to work with other devs. Open source is a good path forward.

Otherwise, estimating your performance is super hard. Are you right more often than you're wrong? When you're wrong, do you consistently fix your flaws? Are you learning? Are you contributing more and more business value? These are all very opaque questions, and even if you answer all of them you're likely to have gaps.

Get more data!

</comment><comment><USER34> If your code 1) runs the first time with no non-trivial errors or obvious bugs, 2) does at least what you intended it to do, reliably, efficiently, and isn't easily de-railed...

then you're getting close. If 3) you find you can easily and quickly modify it to add features... months later... that's closer still.

Of course if you have to answer to someone about why you did it this way or that way, or who can't comprehend your code, then (in that environment) you may have farther to go.

Longer, bigger, harder projects may test your skills. Be your own best critic, always strive to do more with less.

</comment><comment><USER35> How do you define "good" and "quality"? This is the difficulty in measuring skill or productivity in this kind of work. Is it the number of uncaught bugs that have been released? How well what you produced matches with what the askers (product mgrs, customers, etc.) asked for? How much test coverage you have?

As others have suggested, it's useful to look at code that you wrote 3, 6, 12 months ago and ask yourself: do I understand this? Could I write it better now? What would I do differently now? You might try keeping track of these reflections in a journal.

</comment><comment><USER36> Do you mean programming as a job, or programming as an activity/art? They seem two very different things; some people are answering one or the other or a combination.

I noticed some refer to programming as a craft - maybe programming as a job is usually a craft. For myself, I am motivated to write a program because I don't know what the output will be - i.e. not a craft, where the end result is known and aimed for. It's like an experiment - it's worth doing because I don't know what will happen.

</comment><comment><USER37> This can only be answered with context.

Someone may or may not be a good programmer depending on a whole bunch of factors, the project being built, their familiarity with the codebase, familiarity with the technologies used, how happy they feel in their job, how happy in their personal life, if they really like the project they are working on, whether they get time/space to concentrate. It goes on and on.

There's no answer to "is person X a good programmer" within context and even then it's purely subjective.

</comment><comment><USER38> If you can manage to stay interested in what you're doing, you're going to learn and improve over time.

If you lose the passion, and get bored with what you do, you're not going to care, and that's a worse fate than even staying still skill-wise. It's a very common fate for those who have to work at this 8 (or likely more) hours a day, nearly every day of the week for years or decades.

So I'd just try to keep the flame alive, focus on always doing what you genuinely enjoy, and not sweat the rest.

</comment><comment><USER39> My favorite definition of a "good" programmer is someone who ships! Done is better than perfect. Knowing what compromises to make in order to ship without creating a future nightmare.

<comment><USER40> Oh my gosh, no. That might be a "good" software developer, but I'd probably think not on that, too.

I've had to follow behind such programmers who wrote their code with the primary goal of getting done as fast as possible never expecting to have to come back to it. It's literally the worst code that exists.

Usually they no longer work at the same place they created such code, because later they were asked to maintain it. That's why I got the job. Usually we start over.

<comment><USER41> The majority of software developers are payed to ship product to a deadline. It should meet the requirements of your customers and be thoroughly tested. There are always trade offs but the biggest impediment to shipping is the procrastinator or the perfectionist.

If you miss deadlines then you are failing at your job.

<comment><USER40> "...the biggest impediment to shipping is the procrastinator or the perfectionist."

I don't necessarily think that it's the "biggest" but I'll agree it's certainly one of the problems. I think I'd put "unclear specifications" as the biggest problem.

I've seen a lot of code delivered on time to meet the deadline that clearly was not ready but was delivered anyway. I've never the temerity to say, "I told you so," but I thought it. There's a balance to be had. Sometimes the deadline and the customer requirements and future maintainability cannot all be satisfied. Something has to give.

</comment></comment></comment></comment><comment><USER42> If you work in a moderately sizeable organisation and manage to delete more lines of code than you add, while still adding features, you may be a good programmer.

</comment><comment> core-questions Easy, I know I'm a bad one

<comment><USER43> If you know that, then you might be a pretty good one...

<comment><USER44> It comes back to:

"The only true wisdom is knowing that you know nothing"

Problem is - hubris is generally considered a virtue.

</comment></comment></comment><comment><USER45> It's a question I've asked myself too. I've also wondered how often others are being aggressively pursued by former colleagues to join them at another company. I've seen team strongly believe they hire strong candidates only, but rarely seem to pursue these same people after moving to a new company.

</comment><comment><USER41> Would you hire yourself?

</comment><comment><USER46> There is no point in measuring yourself against other people, even in sports.

You should measure yourself against yourself. Your goal should be to become your best self, not the best X in the room/world. X is mostly picked arbitrary.

This means you should always try to become better at what you value.

</comment><comment><USER47> When you maintain a piece of code, that only you have written, for a couple of years, and making changes to it is as easy as the first day, then you're a good programmer.

If every change to the code feels like adding another twist to the maze, then you're not a good programmer.

</comment><comment><USER48> Late but we don't have stats on world's best plumber/doctor either. It becomes a practice at one point and your results/impact becomes the true measure.

I don't think it makes sense to compare a profession to a sport.

</comment><comment><USER49> If someone pays you a lot of money to program and are happy with the results.

<comment><USER50> That might mean you are a good negotiator and salesman.

</comment></comment><comment><USER51> It isn't about your skills now, but if you are improving. If you look back back in code you created 6 months ago and thinks it is a disgrace, then you are very well becoming a good developer.

</comment><comment><USER52> Somewhere I read a measure of intelligence is: the ability to achieve your objectives efficiently. You could say the same about coding. Are you achieving your coding objectives efficiently?

</comment><comment><USER53> Check out: [https://github.com/mtdvio/every-programmer-should- know](https://github.com/mtdvio/every-programmer-should-know)

</comment><comment><USER54> What's a programmer?

I'm very good at breaking down old code and making it modern. Does that mean I'm a good programmer? For that task, yes. In general, the jury is still out.

</comment><comment><USER55> My general rule is that if I look at code from 1 year ago and I'm not disappointed with year-ago-me, I'm not growing as a programmer.

</comment><comment><USER56> Do you do any of the following things?

Start a project by "hitting the ground running" and writing code. Fail to write documentation unless under external pressure. Deeply aware of the powerful and superior features of your favorite languages. Have a considered view that long term systems maintenance irrelevant to most software design. Frequently roll performance optimizations in to your code.

If so, you are probably a bad programmer.

<comment><USER57> I agree on the other points. Can you elaborate on how "Deeply aware of the powerful and superior features of your favorite languages" makes one a bad programmer?

Not trying to be sardonic, just want to know how to improve my programming skills.

<comment><USER43> If you are "Deeply aware of the powerful and superior features of your favorite languages", then you probably are too deeply caught up in language fanboy-ism to actually understand the merits and disadvantages of your favorite languages compared to the alternatives. (You're probably also being a jerk to people who aren't fans of your languages.)

They're tools. They're not rock bands. Don't get caught up in fanboy-ism.

</comment></comment></comment><comment><USER58> Do you solve the solution to the user's problem or just accept the solution given by the business?

Are you a team player?

</comment><comment><USER59> Your development speed keeps being a constant even as your software evolves and you add many new features.

</comment><comment><USER60> Go back and read code you wrote 1, 2, even 5 years ago. If it's still clear and logical, and you don't think "who's the clown that wrote this?" then you're good. If you can hand it to someone else and _they_ don't think "who's the clown that wrote this?" then you're _very_ good.

</comment><comment><USER61> I wouldn't describe myself as a programmer, but I have spent a considerable amount of time and energy thinking about how to become 'better' as a data scientist (as well as how to encourage others to grow their skills and knowledge, and how to measure that growth). So, I can share some tips about learning in general (i.e. metalearning--"learning how to learn") that should apply no matter your field. If you devote yourself to (effective) learning and improvement, you are as 'good' as you can be, and that is what matters.

1\. People learn best by a) effortful 'doing'/practice and b) spacing that effort out over time. (Actually, not just people...almost every organism seems to learn more effectively this way.) Generally, the marginal benefit of learning time is greater when you expend effort directly applying knowledge/skill to a difficult and meaningful, rather than ingesting the output of others. An hour spent solving programming puzzles is more effective than reading an hour of others' puzzle solutions. 10 hours spent doing either is better spent if it's spent as [10 x 1hrs] vs. [1 x 10hrs]. Spend more time working on side projects that motivate you, solve book problems, solve coding challenges, practice explaining a technical concept to someone, etc. Spend less time gliding above the vast wilderness of what there is to know, observing the work of others--hit the ground and blaze the trails yourself (but don't rush it).

2\. Programming, like data science or research or basketball, is not really a discrete skill you can directly improve at. Each is composed dozens/hundreds of sub-skills, and mastery of the field is a lifelong endeavor of building up these individual skills as well as connections between them. What strengths form the core of your identity as a programmer? What about areas for improvement? (relative to what you want to be, not compared to coworkers/HN folks/world-experts)

3\. If you find yourself sharpening the same swords again and again (as I have), then look for an area of both weakness and interest to reallocate effort to. The learning benefit per unit of time is greatest when you spend it on something in your 'zone of proximal development'\--not too easy, not too hard, not too irrelevant, but just right. Sometimes, this may mean diving headlong into the difficult thing you believe you "should" know, but have been avoiding. Other times, being "better" at your field means improving at something that seems tangential (communication/presentation, documentation writing (!), time management, domain knowledge, mathematical skill, whatever). Just don't fall into the trap of 'oversharpening'\--expand your arsenal.

4\. Teach/communicate what you know to others. Interact and network with others both at, above, and below your general level of experience. This not only helps solidify your knowledge into something permanent, but incidentally is one of the best (only?) ways to be perceived (rightly or wrongly) as knowledgeable. You don't even need to do this 'for real' for it to work--I imagine myself explaining code / mathematical concepts to some imaginary audience, whether it happens or not. And if it does, you'll be prepared...(While backpacking in Yosemite recently, I encountered a professor that asked me to explain a ROC curve to him. Another time, I awoke on the train to an elderly lady, seeing the title of book that I fell asleep on, asking me what a stochastic ["stoychistick"] process was.)

5\. Beware that the 'better' you become, the more inferior you may feel. Climbing higher gives you an unobstructed view of the yet taller peaks in front of you, and the canyons blocking your way. Remember to take pride in the struggle.

<comment><USER62> Can you add anything specific to Data Scientists in particular? I am in this field and would like to improve further. Any pointers would be helpful. BTW, Nice post. +1

</comment></comment><comment><USER63> A common mistake is to judge yourself in a vacuum. You aren't a rockstar because you have achieved a certain number of years employed (this is more common than you would think). The Dunning-Kruger effect is very real.

[https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

Objective measures of competence are:

* speed of delivery. Do you deliver faster than your peers?

* extreme problems. Are you able to solve problems nobody else can solve?

* originality. Are you able to demonstrate problems nobody else can see or solve problems in a new way?

* write software everybody wants. Do people frequently consume your software or beg you for certain features?

\---

Sometimes a low aggression (aggressive as far as product not angry people) environment can trap you into a tightly contained cocoon of suck from which there is little or no self-improvement potential. Be aware of this.

</comment><comment><USER64> Good programmers don't concern themselves with such trivialities.

</comment><comment><USER65> If you're questioning yourself, then you're alright.

</comment><comment><USER66> Try leetcode the hard ones

</comment><comment><USER67> I can answer the specific question for you easily: you are not good enough yet. That answer applies no matter how good you are :-) But to be serious, it's very, very important in this industry to cultivate that attitude because as soon as you think you are "good enough", the industry moves under your feet. This is a job of endless learning and self development. For those that are new to the field, take note. If you are the kind of person that just wants to show up at their job, do what they know how to do and then go home, you are at extreme risk to be unemployed and even unemployable in this field in about 10 years time. There is nothing inherently wrong with wanting a job like that, but a programming job is not that (at least not right now -- maybe come back in 20 or 30 years).

On the other hand, I could also say that no matter how bad you are, where you are today is fine. There are so many roads in this industry it's incredible. It is counter productive to judge yourself harshly. I know many very talented people who I never, ever want to work with. I know very many people who don't have so much talent that I am extremely happy to work with. I'm sure most people can relate. No matter what kind of natural talent you have at programming, try to cultivate the sense that others want to work with you.

I saved the most complicated bit for last. How do I know what I suck at so that I can make sure to improve it? This is really difficult. I've seen many people feel very secure about their abilities in one way or another, when in reality the things they were most proud of were part of their weaknesses, not their strengths. If I'm really, really honest with myself, I've gone through patches of that myself. I think everybody does (although some are much more delusional than others).

The best thing to do is to try to work with a wide variety of people who have different backgrounds. When someone disagrees with you, make a note of it. Even if you end up convincing them that they are wrong, try to understand _why_ they had that idea in the first place. Is there anything you can learn? Look for ways to invalidate your current view point.

The most difficult piece of advice to follow, I think, is to celebrate when you are wrong. It is _easy_ to convince yourself that you are right and to put your head in the sand. It is _difficult_ to understand that you are wrong and to figure out how you came to your mistaken conclusions. More importantly, if you really _are_ right, then there is nothing to learn and nowhere to grow. It's only when you are wrong that you can make substantial progress. Cherish that process.

One more thing: I believe that every good programmer must, at some point in their career, build a system of significant size all by themselves. Thing of it as your master project (the project that journeymen do to be recognised as masters). One of the best things you can do is to build that system and maintain it for many years. With that you can see where your weaknesses lie -- all your assumptions will be laid bare. Be very critical of the result. If it isn't perfect, _why_ isn't it perfect. You only have yourself to blame, and that's a wonderful piece of perspective.</comment>


Technology After the Great War - <AUTHOR> https://thefrailestthing.com/2018/11/11/technology-after-the-great-war/ <comment> m-i-l The central point of this thesis is that technological progress was almost universally abhorred in the immediate aftermath of the Great War due to its perceived role in the industrialisation of death and destruction on a hitherto unseen scale, although this became less pronounced over time. The problem is that it wasn't almost universally abhorred. The fascist movement, for example, celebrated technology and embraced Futurism[0], and in their glorification of war they didn't believe that "one is spared or obliterated by chance alone" but saw the deaths as purifying and a necessary part of Social Darwinism. (Not views I subscribe to BTW, just making the point that there certainly wasn't a single common interpretation of the Great War in its immediate aftermath, and that perhaps the left tended to be more anti-technology and the right pro- technology.)

[0] [https://en.wikipedia.org/wiki/Manifesto_of_Futurism](https://en.wikipedia.org/wiki/Manifesto_of_Futurism)

<comment><USER3> The situation with Italian futurism is not so simple.

Most of the futurist ideas on the positivity of the war are from _before_ WWI. After the war, when fascism started to rise, the "second futurism" came to life, a new generation of futurists (although some "old" artists were still futurists, like Depero), much less involved in politics: [https://h2g2.com/entry/A723764](https://h2g2.com/entry/A723764)

They were still promoting technology and speed and the future, but the experience of WWI did change the overall attitude.

</comment></comment><comment><USER4> > The failure of most Europeans to fathom the potential for devastation of the > new weapons they were constantly devising owed much to their conviction that > no matter how rapid the advances, Western men were in control of the > machines they were creating

While the technology was different, I'm not convinced that WW1 was truly more devastating than previous wars. The wars following the French Revolution lasted much longer and devastated Europe from Lisbon to Moscow. The Wars of Religion before that were probably even worse.

The fate of civilians, at least, was actually better in WW1 than in previous wars, as the armies were generally well supplied and disciplined and tried to behave in a "civilized" manner. As for the impact on soldiers, an Englishman fighting in Flanders in 1685 was just as likely to experience trench warfare [1], high explosives [2] and even chemical warfare [3] as his counterpart in 1915 - with far fewer comforts (medical care, consistent supply, news from home etc.).

The real question is not how the war became so devastating (it was like many other wars in this regard) but why it was expected _not_ to be.

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

[2] [https://en.wikipedia.org/wiki/Hellburners](https://en.wikipedia.org/wiki/Hellburners)

[3] [https://en.wikipedia.org/wiki/Chemical_warfare#Early_modern_...](https://en.wikipedia.org/wiki/Chemical_warfare#Early_modern_era)

<comment><USER5> WW-1 at the front was particularly brutal in comparison to the past in that millions died in a mechanical meat grinder and not a heck of a lot of territory changed hands.

It also made the rest of the world look at Europeans (who until then were undisputed masters of virtually the entire world) as being, well, kind of stupid; ultimately unraveling the various political systems that had run the West since post-Roman days. Western civilization more or less died in 1917. We've been dealing with the consequences of this ever since then.

<comment><USER6> The United States economic empire is the most dominant global empire that has existed. Whole cultures are vanishing into the maw. Western civilization isn't dead.

<comment><USER5> It ain't Western civilization any more.

</comment></comment></comment></comment><comment><USER7> > We are living now, not in the delicious intoxication induced by the early > successes of science, but in a rather grisly morning-after, when it has > become apparent that what triumphant science has done hitherto is to improve > the means for achieving unimproved or actually deteriorated ends.

> Huxley

<comment><USER8> Sarcastically speaking, it all started with the division of labor between hunters and gatherers. If hunters had to gather too they wouldn't have had developed a specialization for killing other beings, and many of them would have preferred gathering to hunting due to the risk involved in the latter, so hunting would have been a fringe activity, not an institutionalized part of society (aka armies) Also, women and men who are not so driven by testosterone most likely gravitated toward gathering rather than killing, and so there we have the roots of sexism and machoism, with the assholes doing the killing and normal human beings relegated to "less strong" gatherers. And I believe natural hormones in meat affected the hunters own hormonal balance and pushed them toward more aggression, and the act of killing became normalized. Then we have technology being developed to increase the efficiency of killing other beings and eventually to increase the efficiency of killing other people. The tribes that engaged less in killing and more in gathering got wiped out by the ones that engaged more in killing than gathering. The End.

<comment><USER9> If you're going to look to the "primitives", then it should be assumed that killing was always "normalized": as with any solution, if the conditions are right, and its not _that_ difficult to find such conditions in a primitive society, an expediated exit can be the best and safest solution to a problem.

Combined with the fact that resources are limited, self-preservation and tribal-preservation is embedded, populations want to expand (as part of tribal-preservation) and we actually have some capacity to harm one another, combat is pretty much inevitable. Given a pacifist vegetarian clan, and a non- aggressive predatory one, in trying times, the pacifist must build up their defenses or perish. If they've built up their defenses, they will undoubtedly be capable of waging war, (humans are quite versatile in that) and in trying times, they likely _must_ wage war, or perish.

A purely pacifist stance is only viable if no one does anything; that is, a standstill. The possibility of killing is always there: I'm sure you could convince rabbits to murder one-another if you take enough from them. It is normal, because death, by any means, is normal.

Pacifism is the normalization, not aggression. That we can, through research and technology, better resolve resource contention through more efficient production, than seizing the resource from one another. That, and the realization that we've long reached a point where it's near impossible to wage war without heavy (or even heavier) repercussion from challenging even a weak opponent. The world wars were to an extent a result of failing to make that realization. The cold wars was a direct result of making it.

(Outright) War is no longer as viable an option because peace is intrinsically better, but because its become difficult to successfully do. War was not engaged because it was "ingrained" upon us, but because it was viable strategy (or even defense against passive invasion).

Hunters and gatherers merely allowed us to better engage in war; it did not open the possibility (it was always there), and its absence would not have closed it. Rabbits simply don't have the intelligence to realize the option (or coordinate it, or even the tools to effectively engage), even when it's clearly their best option. But they would have reached the same conclusion as we did, were they capable enough toolmakers to resolve those weaknesses.

Also notably, almost every given collection of humans spends far more time at relative peace than engaging in war (the US today is capable of engaging continously in small wars, but it rarely engages in significant ones). It's difficult to ascribe a "tendency" for war to such a species, except by skipping over the peaceful periods.

<comment><USER8> That's what happens when you think with your brain as opposed to feel with your heart.

</comment></comment></comment></comment><comment><USER10> I disagree with the author's conclusion that we have failed to reject the "myth of technological progress". The progress itself has not slowed - <USER2> people are certainly wary of it. We've kept the pin in the nuclear annihilation grenade for over 70 years, and have moved away from that doomsday in the last 30. Look at our science fiction: it's overwhelmingly filled with technology-fueled dystopias and post-apocalyptic worlds created by fictional but familiar human folly. We know what could happen if the world goes mad as it did in 1914, and it's not entirely accidental that this hasn't happened.

The recently-growing doubt about the ethics of Silicon Valley and the tech it produces is part of this overall techno-skeptic view. The pace of change brought on by the Internet is blistering, but in the latter half of this decade it's started receiving some well-deserved backlash. The lessons on the destructive potential for blind technological progress were hard fought, but they weren't for nothing. I see reason to be optimistic.

</comment><comment><USER11> In reading the WW1 series of Dan Carlin's Hardcore History podcast (highly recommended by the way) it seems part of what led to the scale of destruction caused by WW1 was the relative peace between the end of the Napoleanoic Wars and 1914. There were smaller wars here and there but the great powers had not faced off in a generation, no one truly understood how the new technologies would affect warfare and tactics.

It makes me concerned about the possibility of the next war between great powers, we've only seen nuclear weapons used twice, no one knows how satellites and cyber attacks can affect war on a grand scale, new biological weapons also have not been deployed at scale. There's a lot of theory out there about what the next great war will look like but without any tactile examples we really have no idea.

<comment><USER12> The US Civil War marked the end of the Napoleonic era. The European powers ignored those lessons for various reasons, mostly because the US and Confederate armies were levies of non-professional soldiers. They also didn't really have an alternative as technology was advanced enough for advanced industrial killing, but not enough for WW2 style engagement.

The key advance was the broad availability of the rifle vs. the musket. (Which was an advantage Britain held over Napoleon as well) With a musket, the killing field was about 50-100 yards. The early rifles like the British baker rifle extended that to 200-250 years. Civil War rifles were 500+ yards.

Military doctrine for WW1 armies was all about fast maneuver warfare like what was happening in 1914. Mobilization speed, elan and discipline would win. This was true until the other side mobilized, at which point the modern rifle (800-1000 yard killing range), machine gun, and explosive artillery equated to stagnation.

What you're seeing today is the future. Nobody can afford to lose large standing army engagements, so limited warfare rules the day. Even the US military has been forced to strip alot of resources from things like armored divisions and artillery, and doesn't have a good public strategy for air power. Limited warfare is cheap, and even the US focuses alot of attention on it -- there are like 50-80k special forces type soldiers.

<comment><USER13> There was more than the US Civil War to tip Europe off to what it had been like had they been looking. The Russo-Japanese war, the Franco Prussian war, various colonial wars where the effectiveness of the machine gun against infantry was made obvious, etc, Europe could have learned from these had they wanted to, and indeed some people did but they weren't the people making the decisions.

<comment><USER12> Great point, thanks for reminding of that.

I remember finding it so depressing how rigid thinking killed so many in college.

</comment></comment></comment></comment><comment><USER14> If you stroll through an art museum with a decent stock of art that runs between 1870 and, say 1950, you can mark off the WW1 artists generation without bothering to look at the date. The works scream in horror, constantly.

Another commentator remarked that Western civilization died then; I would hesitate to say _that_ , as I live in a very well appointed state, in the West. But the entire apparatus of moral philosophy imploded in that time, and a theodicy appropriate to the explanation of the Great War has never caught the public mind. Most of modern neo-fascisms, paleoconservatives, and so forth are caught up in this rift - we lost the power to explain evil in a materially useful way, and resolve it in a socially cohesive way. Or, to put in another way, the Great War sliced the social fabric and it's all been unravelling ever since.

I don't think that will last forever, we _are_ adapting. But we have to look forward: what can we build _new_ , not haul out JS Mill, Ayn Rand, or Dewey to situate them in a time and place that they don't really belong.</comment>


In-N-Out Files Lawsuit Against Food Delivery Startup DoorDash - <AUTHOR> http://techcrunch.com/2015/11/11/in-n-out-files-lawsuit-against-food-delivery-startup-doordash/ <comment><USER2> FWIW, Eater published an article 5 days ago that discussed examples of New York eateries who are either OK or annoyed with being listed without permission

[http://ny.eater.com/2015/11/6/9678206/door-dash-delivery- nyc](http://ny.eater.com/2015/11/6/9678206/door-dash-delivery-nyc)

> _But not all restaurants on DoorDash know that they 're listed. Tommy > Ferrick, owner of Delilah's Steaks in Greenpoint, says he rejected an offer > from a DoorDash salesperson months ago due to a 20 to 25 percent commission > fee. More than 50 percent of his cheesesteak business is from delivery, and > he's already paying GrubHub a commission that ends up being three times > higher than his rent every month. He's currently trying to get more people > to just order directly through the restaurant. But a few weeks ago, his > business started getting pick-up orders from DoorDash. He looked on the site > and was shocked to see the Delilah's Steaks logo and full menu listed as an > available restaurant, with significant price markups. A cheesesteak costs > $11 in the shop, for example, but DoorDash charged $16.95 for it. "I was > livid," says Ferrick, who worries about quality control for deliveries he > doesn't know about._

Doughnut Plant seems meh about it:

> _Still, DoorDash lists three of four Doughnut Plants shops on the site > without the company 's permission — but PostMates, Doughnut Plant's > preferred delivery merchant, did reach out before posting the menu, > according to the bakery's creative director Jeff Magness. The Doughnut Plant > logo DoorDash posts is also incomplete, Magness adds. "I don't like [that] > it makes it look like we are working with them," he writes in an email. > "That said, we haven't received complaints from customers."_

<comment><USER3> They should just use their containers to advertise the app and offer a small discount (10% or so) and then Doordash/Grubhub becomes a marketing channel for their app. Thats what I'd do.

<comment><USER4> That's brilliant.

</comment></comment></comment><comment><USER5> I am not a fan of DoorDash's business techniques. DoorDash sent a flyer to my house false advertising a coupon code. I spent half an hour creating an order only to realize that the coupon they sent me was different from what the flyer said. When I called to complain they acknowledged their error but said they wouldn't do anything and that I should just place an order anyways.

</comment><comment><USER6> > Fast food restaurant In-N-Out, known for its delicious burgers and secret > sauce, is suing food delivery startup DoorDash, TMZ reported earlier today. > In-N-Out, which filed the lawsuit on Nov. 6, 2015, claims trademark > infringement and unfair competition. Basically, In-N-Out wants DoorDash to > stop delivering their delicious food because of concerns around quality, > food handling and safety.

Why using so many times the word delicious? Moreover, that's not really the scope of the article.

<comment><USER7> Same goes for the DoorDash spokesperson's statement. That blurb had an entropy so close to zero they just could have left it out.

Is this just lazy reporting or is it an effect of the leaking of corporate speech into everyday language? Asked differently: Have we become so used to the marketing jargon that even reporters start picking it up in their articles?

<comment><USER8> Reporters certainly pick up "sharing economy" jargon, not aware they have been thoroughly co-opted by marketers.

<comment><USER9> _not aware_

I wouldn't be so sure.

</comment></comment></comment></comment><comment><USER10> This does not seem outrageous to me on either side. DoorDash wants to satisfy demand and grow their business; In-n-Out wants to protect its brand.

The details will determine who is right -- hence the lawsuit.

</comment><comment><USER11> Services like this have taken off in Sydney (HungryAndLazy, Menulog, etc)

It's made getting delivery food here SO much better, as it's many smaller family owned stores that now get massive business if they have better food

<comment><USER12> The difference is that restaurants sign up to offer their existing delivery services to customers through H&L and Menulog, who are merely the conduit through which orders are placed. It's still the restaurant making the deliveries, and they can choose to pull out at any time.

It's crazy how popular they've become; just about everybody I know uses Menulog and Eat Now to order food, and if your restaurant isn't on it, we'll probably never know about you.

</comment></comment><comment><USER13> Trademark stuff, ok, it makes sense they can't use their logos and such. But the whole quality control, food handling, meh. Soon as it's paid for and in the customer's hands, it's the customer's business what happens to it next, not In-N-Outs, it's not theirs anymore.

<comment><USER14> If you get a bad experience because DoorDash took too long or dropped the box and didn't tell you I suspect some/many/most? people might blame the restaurant, not DoorDash. So in that sense I can see why In-N-Out would care since from their POV DoorDash is __appearing __to represent them to customers.

<comment><USER15> I understand why In-N-Out might be upset, but I don't understand how they could possibly have any legal standing.

<comment><USER16> Trademark infringement and dilution. By pretending to be In N Out they confuse customers into thinking they are buying from In N Out directly.

There is a first sale doctrine in Trademark, but it might not (probably?) won't apply here. First, courts have found that not all reselling falls under first sale if the products aren't exactly the same. Here, by delivering they are serving different food because it gets cold and soggy. They could also argue that In N Out doesn't provide delivery service and this place is selling that service using In N Outs trademark.

The damage to In N Out is brand devaluation. People might think that In N Out sucks.

A clear example is: You can resell macbooks. You can buy them, sell them, even repair them.

But you can't set up a fake Apple Store that looks like a regular one.

Doordash is argue they are doing the former, and In N out will say the latter.

<comment><USER17> Apple store is an interesting example. If you put up a giant flyer "Macbooks sold here!" but stripped them for parts, replacing the RAM and SSD with slower, cheaper versions, you might expect angry letters from Apple too.

<comment><USER18> Ironically,you couldnt really,since they already are the cheap stuff

</comment></comment></comment></comment></comment></comment><comment><USER19> For a second I thought In-N-Out had hacked the Streisand effect perfectly, but alas DoorDash has indeed removed them from the app.

</comment><comment><USER20> When someone represents themselves as an agent of another merchant but don't have a relationship with that merchant you're literally just buying something from the back of a van.

In-n-out gets exposed to liabilities and bad pr. No brainer.

Funny enough by suing DoorDash actually gets bad PR which to them is still good PR. A lot more people will know about DoorDash than before. Pretty naughty to agree to stop then renege on it, then disregard all attempts there after. Almost as if it was deliberate...

But getting a $5 burger in your mouth in 45 minutes with a $3 delivery fee is the boring part. The larger context of all this is how companies use terminology these days.

Per DoorDash marketing:

 _Through the DoorDash marketplace, people can purchase goods from local merchants and have them delivered in less than 45 minutes - thanks to our revolutionary logistics technology._

Per DoorDash TOS:

 _THE COMPANY DOES NOT PROVIDE LOGISTICS OR COURIER SERVICES, AND THE COMPANY IS NOT A LOGISTICS CARRIER. IT IS UP TO THE THIRD PARTY COURIER OR LOGISTICS PROVIDER, COURIER OR VEHICLE OPERATOR TO OFFER COURIER SERVICES WHICH MAY BE SCHEDULED THROUGH USE OF THE SOFTWARE OR SERVICE. THE COMPANY OFFERS INFORMATION AND A METHOD TO OBTAIN SUCH THIRD PARTY COURIER SERVICES, BUT DOES NOT AND DOES NOT INTEND TO PROVIDE COURIER SERVICES OR ACT IN ANY WAY AS A COURIER, AND HAS NO RESPONSIBILITY OR LIABILITY FOR ANY COURIER OTHER THAN STATED HEREIN SERVICES PROVIDED TO YOU BY SUCH THIRD PARTIES._

Per Postmates marketing:

 _Postmates ' revolutionary urban logistics & on-demand delivery platform connects customers with local couriers, who purchase and deliver goods from any restaurant or store in a city._

Per Postmates TOS:

 _THE COMPANY DOES NOT PROVIDE LOGISTICS OR COURIER SERVICES, AND THE COMPANY IS NOT A LOGISTICS CARRIER. IT IS UP TO THE THIRD PARTY COURIER OR LOGISTICS PROVIDER, COURIER OR VEHICLE OPERATOR (COLLECTIVELY, THE "POSTMATE") TO OFFER COURIER SERVICES WHICH MAY BE SCHEDULED THROUGH USE OF THE SOFTWARE OR SERVICE. THE COMPANY OFFERS INFORMATION AND A METHOD TO OBTAIN SUCH THIRD PARTY COURIER SERVICES, BUT DOES NOT AND DOES NOT INTEND TO PROVIDE COURIER SERVICES OR ACT IN ANY WAY AS A COURIER, AND HAS NO RESPONSIBILITY OR LIABILITY FOR ANY COURIER._

And of course the grand daddy of them all:

 _By seamlessly connecting riders to drivers through our apps, we make cities more accessible, opening up more possibilities for riders and more business for drivers._

And per Uber TOS:

 _The Services constitute a technology platform that enables users of Uber 's mobile applications or websites provided as part of the Services (each, an "Application") to arrange and schedule transportation and/or logistics services with third party providers of such services, including independent third party transportation providers and third party logistics providers under agreement with Uber or certain of Uber's affiliates ("Third Party Providers"). YOU ACKNOWLEDGE THAT UBER DOES NOT PROVIDE TRANSPORTATION OR LOGISTICS SERVICES OR FUNCTION AS A TRANSPORTATION CARRIER._

A lot of aerobatics to contort and redefine words so that one gets the branding benefit of the word's previous meaning but suffer none of word's consequences.

Is this a better or worse turn than the naughtiness of YouTube hypergrowth days shielded by DMCA safe harbor? Or how Facebook drags their feet dealing with users that steal content because it allows them to juice up their view counts?

<comment><USER8> The Postmates and Uber marketing materials look like they were written with lawyers involved. They make the companies sound like third party middlemen. The DoorDash one is less slick. "People can purchase goods from local merchants" sounds like the merchants are on board, which In-n-Out clearly is not.

<comment><USER20> The local merchants are on board in that to get listed DoorDash wants a 20% cut from the merchants as lead gen services. Obviously they didn't get that from big brands but offer it as a means of bolstering up DoorDash's platform value.

I'm curious as to how does one do the dance of saying you coordinate logistics but are not a logistics service provider when the people showing up are wearing your logo, paid by you, and use your app for order information, confirmation, and directions.

</comment></comment></comment><comment><USER21> You know what I wish would happen? Everyone would just get along - the burger guys, the tech guys. Just deliver the things with drones already guys, mmkay? I need that. I live in Europe. I haven't had a proper burger in decades.

</comment><comment><USER22> Dead unicorn list

1\. Homejoy

2\. Theranos

3\. Doordash

4\. DraftKings/FanDuel

5\. Fab

6\. Evernote

7\. ...

</comment><comment><USER23> "...concerns around quality, food handling and safety."

I completely understand. I used DoorDash exactly once to order from a local Chinese restaurant. The food was delivered by a dude who looked disinterested, and the containers were crushed and leaking lots of brown sauce into the plastic bag. It wasn't a great experience. Whose fault was it? I dunno. But I haven't ordered from DoorDash or that Chinese restaurant since.

<comment><USER24> They may have a point with the lawsuit then. It _is_ a matter of maintaining control over quality perception of their brand.

Remember the case of Cristal (champagne) vs. the rappers from 2006? Similar idea - [http://www.economist.com/node/6905921](http://www.economist.com/node/6905921)

</comment></comment><comment><USER25> Good. This latest generation of "doing shit for lazy people" startups really needs a good wake-up call.

</comment><comment><USER26> I don't know how DoorDash could make In-N-Out food worse. Seriously their food is not good. I see the trademark angle but the quality? Please they should start with making something worth while.

<comment><USER27> I'm going to go down the off-topic path with you as I would agree with you. On my last trip out to SF I tried them and I was really underwhelmed. As far as fast food burgers and fries went I enjoyed Carl's Jr. far more.

The fries at In-N-Out is an interesting paradox. Without sauce they taste almost like nothing; the blandest fast food fries I've ever eaten. With sauce? It's okay. A bit too soggy for my liking but okay.

<comment><USER28> INO competes at the $2-$3 burger level, and they are excellent for the price, assuming you like their sauce (which can be skipped). You can't fairly compare them with CJ's $6 burgers, or the $10 restaurant equivalent.

Their fries are made fresh on site, but they do tend to need salt.

<comment><USER27> > You can't fairly compare them with CJ's $6 burgers, or the $10 restaurant > equivalent.

That's fine; I mostly meant out of the fast food places you're supposed to go to in CA I preferred them. As far as INO's fries are concerned I have yet to find a fast food fry that I thought was worse than INO's :)</comment></comment></comment></comment>


Show HN: Rim – Aspiring Vim-like text editor written in Rust - <AUTHOR> https://github.com/mathall/rim/

<comment><AUTHOR> It's been a few months since I first presented my little project here on HN [1], I hope a new thread is justified after the changes that has been made since then.

When posting my last thread, you could basically have a buffer loaded and view it in multiple split windows by moving the caret around.

Since then the following functionality has been added:

* Proper key handling: Commands can be bound to key strokes such as Ctrl-W followed by V, with a timeout between keys.

* Different modes: Basically binds different key-to-command mappings to support say "normal" and "insert" mode.

The two above are arguably one feature, and they combine by binding modes on different "levels" in the key handling module. Putting this together, you can have one mode partially overlap key strokes in another, and have the timeout force keys to be handled by a lower mode.

* Multiple buffers: More than one file can be loaded at a time, and each window will keep state sane for every buffer it has viewed.

* Deletion: Last time there was functionality for inserting text into a buffer but it wasn't "hooked up" for the user, now you can also delete text.. (woo)

* Editing: All this is finally tied together and hooked up so that you can start rim and edit a file. (not by your choosing!) While doing so in the focused window, hopefully scrolls and carets and whatnot is kept sane in the other windows whether they're currently viewing the buffer being edited or not.

All in all, it should hopefully feel a bit like a very primitive Vim.

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