Skills Poor Programmers Lack - <AUTHOR> https://justinmeiners.github.io/the-skills-programmers-lack/ <comment><USER2> The skills cited in the article are:

1\. Understanding how the language works. Additionally understanding how the language infrastructure interfaces with the computer.

2\. Anticipating problems. Prefer solid foundations over veneers that appear to get the job done.

3\. Organizing and designing systems. Essentially, SOLID.

Two things on this:

First, bad code often results from conflicting goals. Moving goalposts _and_ on time shipping, for example. The result appears to have been written by a poor programmer, when this may not be the case.

Second, the most valuable skill a programmer can have isn't technical, but rater social: empathy. The best programmers I've seen have it and the worst completely lack it.

Lack of empathy leads to poor communication. If programmer can't anticipate or read his/her audience's perspective, there's no way s/he can communicate a complex concept to them. The temptation will be to blame the audience when in fact the failure lies squarely with the programmer doing the speaking or writing.

Lack of empathy also leads to disregard for the needs of users and future maintainers. Systems get built that don't need building, and systems that should be built aren't. Should the two happen to coincide, the system is a nightmare to maintain because the programmer simply didn't care about the people who would need to maintain the contraption.

A lot of the 10x programmer discussion focussed on people who lack empathy. For some reason, it's easy to conflate lack of empathy with technical skill.

<comment><USER3> Yeah, context and empathy are two things that I'm only appreciating more and more as my career goes on.

I once had this small but terribly written module written by an inexperienced developer who wasn't given the kind of feedback and code review that he should have been given. It was still running in production years after that person had left because it was in a corner of the code base that was basically never touched. What made it interesting to me was that it was badly written at almost every level from the high level separation of concerns to low level coding practices, while still basically getting the job done.

I started giving this module as an exercise during interviews for a certain position, with the framing of "This was written by an beginner developer on your team. What kind of feedback would you give them to help them improve?" This sort of thing was actually a major part of the job, as it was a position that would be a kind of consulting resource for other teams and would involve many code reviews and encouragement of best practices -- basically providing subject matter expertise to full stack, cross-functional teams.

The results were fascinating to me because it acted like a Rorschach test of sorts and told me a lot more about the focus on the interviewee than the code they were criticizing. More junior candidates immediately jumped on the low level issues like the boolean assignment example, naming conventions, or small snippets of code duplication, and spent all their time there. More experienced folks often mentioned the low level issues but spent more time on the higher level problems -- the class should be broken out into two, extending in the most obvious way would be hard because XYZ, this etc. Some of the best candidates would ask for more context on the situation and overall codebase.

It also helped weed out the jerks who, despite the prompt, decided that the exercise was an opportunity to show off and insult the original author (who was of course anonymous), venting about how stupid something or other was or using it as a springboard to attack their current co-workers. Everyone starts somewhere. It's fine to wince a little at something that's poorly written, but the point is to actually help them improve. The better candidates were there trying to understand what their gaps in understanding were that would cause them to make certain mistakes. The very best candidate was trying to map out a staged plan of more easily digestable things to work on so that they're not overwhelmed all at once -- extrapolating a whole technical mentorship model out of what they could glean from the code review.

<comment><USER4> bookmarked.

i don't suppose you could publicly share the module? this is a stellar interview question.

or maybe there's a library of such code? (yes yes, jquery/openssl or your favorite true but not useful reference comes to mind)

<comment><USER3> I don't think I can, sorry. Though I imagine that if you have a code base of any size that more than a couple dozen people have touched, you'll be able to find something similar if you ask around.

</comment></comment></comment></comment><comment><USER5> As an addendum perhaps to the Organize and Design Systems section, I'd propose including mise-en-place as it applies to project maintenance and the development environment.

This centers on tooling and documentation, especially the README. I want a README that gets me set up and running as quickly and in as few steps as possible. Recently I needed to test out some stuff one of my teams was working on. It was a somewhat complex Wordpress project. I was able to get set up using our documentation, but a couple key steps were missing making it error- prone and unnecessarily aggravating.

Anthony Bourdain explains it as only he can:

 _The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm's reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you'll quickly find yourself spinning in place and calling for backup. I worked with a chef who used to step behind the line to a dirty cook's station in the middle of a rush to explain why the offending cook was falling behind. He'd press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped away with a moist side towel. "You see this?" he'd inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef's palm. "That's what the inside of your head looks like now."_

[https://books.google.com/books?id=XAsRYpsX9dEC&lpg=PA65&ots=...](https://books.google.com/books?id=XAsRYpsX9dEC&lpg=PA65&ots=dOy2B3EFxH&pg=PA65#v=onepage&q&f=false)

<comment><USER6> Mise-en-place is so important.

Inexperienced engineers sometimes find themselves in teams which don't appreciate it. Because confrontation can be nausea-inducing, they sometimes don't endure the discomfort to insist on it.

———

When a customer walks into a restaurant, does he ask about the temperature of the fridge the chicken is stored in? Does he ask if the kitchen is clean and organized? No. Thats the chef's job to insist on. But the customer does care if his food is late or laden with salmonella.

Likewise, its an engineer's job to care if she has automated tests and well- structured code.

<comment><USER7> I'd argue that missing on _mise en place_ is symptom of a team leadership failure, as well. Allowing excessive tribal knowledge vs. repeatable process (docs, dev tools, tests, well organized code, etc.) is an organizational risk. There's the efficiency loss side, but also the possibility that an incapacitated team member becomes a critical business loss – the team becomes unable to meet goals or worst case, to ship at all. Not empowering new team members to efficiently onboard is just one facet of this. With new hires, there are also the power issues that result, particularly blaming new hires for poor onboarding performance.

I "fondly" recall one early job in my career starting with the promoted-from- the-ranks dev lead filling a whiteboard with boxes and acronyms... an overwhelming brain-dump to a newcomer that took hours of time spread over days. By the time I'd sorted out what we really did, months later, I could explain the whole thing to a new hire in fifteen minutes. One easily understood diagram, pointers to the two actually-important directories in our codebase, and some context – and they would be off to the races. Funny enough, I met a number of other people at that gig that thought of their work as "irreducible". One was, to use the recent meme, a "10x engineer" for whom the company maintained a rotating roster[1] of tech writers to follow around _everywhere_ and try in vain to record what the heck they were doing.

[1] "rotating" as in "hired, then fled screaming"

<comment><USER6> I agree deeply.

</comment></comment></comment></comment><comment><USER8> Most programmers do not follow the Golden Rule, which is to write code you'd like to maintain with minimal training. It's a principle, but there are various skills involved in doing it successfully, including writing, automation, design, seeking quality peer review, and a few other things.

Similarly, writing code that can be deleted is an important skill.

Using "good design" and "knowing your language" are fairly nebulous and somewhat tautological goals out of context. What is good design? Design that works well, I suppose?

Most code is actually fairly easy to change in the future. Just slap another "if (isLeapDay(today)) dailyProfit * 28 / 29" wherever will solve the immediate bug. Is this a good idea? Nope. Why is it a bad idea? Well, it's the S in SOLID, probably, but the real reason is that someone would be surprised and chagrined to discover that design choice the hard way. Hence the Golden Rule.

<comment><USER9> > writing code that can be deleted is an important skill

Are you saying "I can easily delete this code from the project" is a metric for modularity? That's really interesting, is it your own thought?

<comment><USER10> I saw it before. Deletion Driven Development is one of the many names. For me a good rule of thumb is: removal of a feature should result in a diff that deletes a bunch of files (classes in case of oop) completely, and only single lines in other files: the call sites to that feature.

</comment></comment></comment><comment><USER11> Most programmers work in passes, and don't write everything in one shot. But a common mistake I see is not doing enough passes still. Programmers jump on making polished commits they can show off to their peers.

Instead, what should be use more often is what I would call "postit commits". Simple strokes of code that are certainly not final (if any code can be final) but achieve a purpose. Their postit nature makes it very easy to change. Those commits still need to point in the right directions though because they may stay here for a while (think 15 years). As long as they aren't hurting the customer or the codebase (like a supposedly-temporary hack, even though those are sometimes required), then it's all fine, a program is never finished anyway.

Working with more passes allows you to think more at every step and shape a solution that's more efficient. For example, take a piece of code that's too slow for the requirements and for obvious reasons. Don't necessarily jump on optimising it right away. You may find later that you will finally get the whole subsystem in which that piece of code is included better by using another more powerful idea. And when you come up with that new idea, the only thing that will stand in your way is "postit commits". You can change things now because you're not facing polished ones. You can change things now, not in 10 years when you find out every one of your competitors has finally implemented that idea, in which case you would take the cost of a full rewrite.

This is essentially how you do things well from scratch (and by extension, how you do anything well with code). Keep postits as long as you can, because it's a better strategic position. Only harden a solution when you can't give it more time or because it just hardened itself with cool ideas. At the end of the day, you will win time, if you worry about that. You will crush your competitors even. They will have 3 times more code with bad solutions, you will have 3 times less code with all the super cool stuff and nice subtleties (it doesn't always play out like that, but often enough).

<comment><USER12> This forms part of what Alan Kay calls "late binding" [see link below] and describes as part of what makes Lisp and Smalltalk great, which is something of a lost art today, mainly because most contemporary programming languages (the usual suspects in the statically-typed camp but also languages one would not expect, Python / Javascript) go out of their way to de-emphasize it. I feel that Perl was the last, massively popular language that promoted late binding.

[https://ovid.github.io/articles/alan-kay-and-oo- programming....](https://ovid.github.io/articles/alan-kay-and-oo- programming.html)

</comment></comment><comment><USER13>
        > Programmers who only work on small temporary
        > projects (like an agency) may get by without
        > ever improving how to design programs.

Amen to this. We recently ended our engagement with a _very_ well-known Ruby consulting shop for exactly this reason.

Their engineers were very smart and wrote very pretty code.

However it was not suitable for the real world once even a little bit of scaling was required, and this was an app that needed to store and move a fair bit of data as a Day 1 requirement.

The real tragedy is that they were fairly arrogant about it. _They didn 't know what they didn't know._ It's OK to not know how to build things at scale.... as long as you know that's not one of your core competencies. I don't know how to fly a plane, or create a design system, or write assembly code. That's OK, because I know my limitations there.

However, these folks were arrogant and dismissive about scaling concerns.

Well, they were dismissed as a result of their dismissiveness.

Which is a shame, because they did have some talent there.

<comment><USER14> This is the problem I've got at my current job. While I try my best to write code in a way that it'd work many years ahead, the lack of scale requirements and relatively freedom I've got on my own decisions are double edge sword most of the time. Would love to work in a large shop with more senior people than am.

<comment><USER13> Both kinds of experience are so valuable. "Consulting shop" experience where you get to play with a lot of stuff, often very cutting edge stuff.

"Long lived legacy app" experience where you really get into the nuts and bolts of engineering some software, but you are often locked into a particular stack and the cutting edge is your enemy and not your friend. Can suck big time when you look for your next job and your skills are 5, 10, whatever years out of date...

</comment></comment></comment><comment><USER15> Well, where he says

"You may have seen code which misunderstands how expressions work:

if isDelivered and isNotified: isDone = True else: isDone = false;

Instead of:

isDone = isDelivered and isNotified "

I think that's a matter of style, I prefer the isDone = isDelivered and isNotified style myself, and I think the people who write the other way have very poor style but as arrogant as that sounds I don't think I would be so arrogant as to say they don't know how expressions work.

<comment><USER16> In college they taught me that every line of code should do one thing and one thing only. So doing both a test and an assignment on one line would not be prefered over the first example(split over multiple lines). I don't have a lot of experience with programming so for now I do what I was taught. :)

<comment><USER17> The code is doing one thing: assigning the result of a boolean expression. It's not different in structure from, say, `x = a + b`.

<comment><USER15> it's sort of an interesting problem in intention - if the reason why the expression

"isDone = isDelivered and isNotified" was written is because the programmer saw "if isDelivered and isNotified: isDone = True else: isDone = false;"

and thought I can improve that, then what they have done is managed to wrap the checking and assignment into one expression, they are logically now doing two things in the one line - it just so happens that they can do that because one of those things was not really necessary to do.

</comment></comment></comment></comment><comment><USER18> The most lacking skill that I tend to see is an inability to think in types, and to design software accordingly. Too many software developers never progress beyond primitives and basic control structures - I call them Int, String, and For Loop Developers.

Second biggest issue I see is failing to incorporate our cognitive shortcomings into code design, assuming that you'll remember these dozens of little details from today forever, and failing to enforce or make explicit one's "today knowledge" in the code.

<comment><USER19> Can you give a clear example on "thinking in types" approach ?

<comment><USER20> It's the anti-pattern "Primitive obsession"

[https://refactoring.guru/smells/primitive- obsession](https://refactoring.guru/smells/primitive-obsession)

Let's say, for example, that we need to handle distances in on our code with different units (meters and inches, for example). I've seen code bases that use integers or floating points for this and it's always confusing and error- prone what is the unit. In fact, you could accidentally use some other values (money) as distances.

Instead, if your programming language allows this, you could define a type Distance and make sure that all the code that handles distances only use this Distance type. Everyone is forced to think about distances when maintaining the code, conversions routines are implemented and instantiated in one place etc.

<comment><USER21> This is why I like type defs in a language.

</comment></comment></comment></comment><comment><USER22> > Using sleep(), cron jobs, or setTimeout is almost always wrong because it > typically means you are waiting for a task to finish and don't know how long > it will take. What if it takes longer than you expect? What if the scheduler > gives resources to another program? Will that break your program? It may > take a little bit of effort to rig a proper event, but it is always worth > it.

While I understand the sentiment of this post, which I feel is mostly correct, it's interesting to see how divergent this statement is from my experience building "modern" microservice architectures, devops, and distributed systems design is from this view point that I used to hold so true. Async background tasks that self-heal and are entirely outside of the serving path? Yes, please.

<comment><USER23> I initially had the same reaction, but I don't think that's the author's intentions. He's saying don't use sleep() and cron to constantly poll if some asynchronous thing has completed, have a proper event fire at the end and handle that. Don't think that's in conflict with what you like about your systems :-)

<comment> yoz-y Yes, but in the article author also argues that proper definitions are important. In more general case I'd say that expressing ideas in a non- ambiguous manner is important.

</comment></comment></comment><comment><USER24> "I believe OOP and relational database get a lot of flack because programmers tend to be bad at design, not because they are broken paradigms". This is very true. Another more charitable interpretation is that sometimes deadlines prevent programmers from thinking their models thoroughly and so an imperfect model ends being used, causing problems in the future.

</comment><comment><USER25> This article says more to me that the author(s) are inexperienced themselves rather than shed any light on the practice of software development. I'm imagining some recent boot camp graduates attempting to conflate their months of programming experience into something more than that. "Hey old dudes in company I just joined, I found some things I think are basic so I'm going to write an article to indirectly shame you in hopes our manager will see how valuable I am already." They know something isn't quite impressive about their older co-workers but this list isn't it and the authors don't even come close to being experienced enough to put a box around it and be thought leaders of any kind.

<comment><USER26> I don't think these accusations are fair. The author has been programming since at least 2009, and is degreed in math. They also wrote the "think in math write in code article" that people here seemed to like quite a bit last week.

<comment><USER27> > The author has been programming since at least 2009

Which is to say, since the author was 12 years old if they followed a standard K-12 + undergrad program (graduated from a Utah Valley University last year it seems).

I think the irony in the article is that the author is very likely 22 or 23 years old and opining about how developers that have been coding for longer than he's been alive still just-don't-get-it. I guess you'd just expect this kind of article from someone with more experience in the field.

I did like this, however:

> Poorly designed software lacks conceptual integrity...It usually looks like > a giant Rube Goldberg machine that haphazardly sets state and triggers > events.

That is, it seems, the modern web :)

<comment><USER26> >Which is to say, since the author was 12 years old if they followed a standard K-12 + undergrad program (graduated from a Utah Valley University last year it seems).

Graduated the university in 3 years (check the dates), which doesn't nullify your proposition, but it makes as likely the other possibilities, such as that they went to university well into their adult life, applying credits from a previous (unlisted) university career.

</comment></comment></comment></comment><comment><USER28> >However, there is a certain level everyone should know

Sadly that's still debated and you can only get piecemeal ideas from blogs and job postings.

There's no central authority to approve developer skill levels that says "these skills every programmer should know before joining the profession - after that, it's up to the specific job" and then it's _legally enforced_ via certifications and official exams.

Right now, it's up to specific jobs and blogs and you have to figure that out.

It's ambiguous and that frustrates people who like exact and measurable goals when learning things.

I know it seems like one blog isn't a big deal, but I've read many blogs that add things like "10 things every programmer should know" and this language just never ends.

If you took a union set of all the things from every "things programmer should know" article, you'd be studying for about 6-8 years before you got a junior position.

>For example, if a successful login generates a session token and it collides with another token, you could reject the login and have the user try again

Eh, don't even go back to the user. Collisions should be a rare occurrence that you can make a second call to the token generator and just replace the bad one. If you get common collisions, you need a better token generator.

</comment><comment><USER29> Kinda frustrating that an article calling out where programmers fall short was a non-responsive document that was almost unreadable on mobile. Mildly ironic?

<comment><USER6> Does blocks of text need responsiveness in order to be readable on mobile?

What problem are you experiencing?

<comment><USER30> The text is very, very small on a mobile device (XL devices may be easier). Requiring anyone with a small/normal sized device without near perfect vision to zoom in and swipe left/right to read a single line of text.

For example I'm on a normal sized device and can't read the text at a zoom level that shows an entire line without my glasses (and my vision isn't too bad, I'm legally allowed to drive without my glasses).

<comment><USER31> This is what "reader mode" is for.

The text is using good oldfashioned html markup (basically just h2, p, code, a, em).

So there's no reason why you should have to use the stylesheet provided by the site, and with a sensible browser you don't have to.

</comment></comment></comment></comment><comment><USER32> Well, I do agree with some points in the article, but I don't believe even the author really understands how the env. he runs his code on works. There is more to it than just knowing the language, one might argue that you have to know the OS (see fsync misuse by Postgres), how all the involved drivers work, how CPU works, and the list never ends.

It is quite idealistic view, in reality you have to realize you never know how everything works, otherwise you will spend a lifetime in academia.

On Software Engineering side (not just programming), the most important skill to me will be curiosity towards business, not just code. Endless devs are dying in arguing over tabs vs spaces, when their job is to deliver for the business, not for their ego. Surprisingly, it is a common decease (based on my Google and other companies experience). They create their wonderful world of logic and sense, and think that everything that violates it is stupid (like business person asking for a feature).

The skill poor engineering lack is actually common sense.

</comment><comment><USER33> In all fields there is a minority who are not very good at what they do. I think, though, that in programming that minority might actually be a majority. The thing is, if you are a poor plumber who causes floods in peoples houses you are not going to be in business for a very long time. In programming there seems no such discipline because it actually takes somebody good at programming to perceive the difference between good and bad programming. And if the programming project is a disaster right now the cause of this might be bad decisions made 5 years ago and the people who made them are already gone thereby shielding themselves from the consequences of their actions. In a healthy programming department there should certainly be a small influx of new people and new ideas but also the stability of people who see the project as their personal responsibility.

<comment><USER34> Programming is more like trades than you think. A bad plumber might occasionally cause a flood, just like a bad programmer might occasionally cause a hard crash during an important sales presentation, but actually bad plumbers use sub par material, and install them incorrectly, and you don't know until 5 years later when your first floor is flooding because a pipe joint inside the wall finally burst after the 1000th time water hammer slammed it.

And, like programming, sometimes you'd find someone who actually just didn't know what they were doing because they were inexperienced, and sometimes you'd find someone who was rushed and underfunded, but in either case they are generally long gone, and the cause of the ultimate failure isn't perfectly clear, so the world turns and everyone keeps plumbing, for better or worse.

I can tell a similar story for almost all trades.

<comment><USER14> Used to work in plumbing. One morning coming to work and see a waterfall coming from the 3rd floor..The apartments were complete with kitchen furniture installed. Turns out one idiot didn't solder an elbow,while other didn't test it properly and the third signed it off and gave green light to turn the water for the entire block.. It took many people and a lot of time to undo this. Not much of a difference when things go wrong in code.

</comment></comment></comment><comment><USER35> The example is interesting.

      if isDelivered and isNotified:
        isDone = True
      else:
        isDone = false;

is not the same code as

      isDone = isDelivered and isNotified

in ruby, python, js (and more?).

[edit: while I'm nitpicking... breaking webpage text selection is also a clear sign of poor programming]

[Edit2: more unsubstantiated "absolute truth" from OP]:

      Using sleep(), cron jobs [...] is almost always wrong.

_false_. Any hw related code (most of the code humanity had created?) relies on such timing considerations.

      Another common mistake I see is generating a random file or identifier and hoping that collisions will never happen

_false_. This is a 100% valid approach, the odds of uuid collision are 0 to any practical consideration.

<comment><USER36> Assuming those variables are all booleans why wouldn't it be?

<comment><USER37> They're not booleans in ruby, python, js; they're objects that can be null.

<comment><USER38> null (or None) is still a valid Falsey value, and in both examples isDone will be a boolean (strict) value, as it is the result of a boolean operation (and).

So the point of the comment is moot...

<comment><USER39> JS: undefined && undefined -> undefined

Python: None and None -> None

<comment><USER40> On top of that, truthy values also propagate, so if isDelivered or isNotified are something else that's truthy (such as a 1 from mysql), isDone will not be True either and risk failing in more interesting ways down the line.

</comment></comment></comment></comment></comment></comment><comment><USER41> > Organize and design systems

To extend on that point, I think that better programming happens when you don't simply apply prefab design patterns to every problem or be overzealous with those patterns.

This is where things like object-orientation, MVC, SOLID, DRY, abstraction, inheritance, overly-organized code with lots of categories for different things, decoupling, etc. can be taken too far or be applied to the wrong problems.

Basically, don't _believe_ in any one thing. Just understand different approaches and realize that nearly all of them have a % probability of succeeding. That can even mean writing things in a more procedural way.

</comment><comment><USER42> > I believe OOP and relational database get a lot of flack

Who gives relational databases flack? The RDBMS and SQL is the cleanest, simplest, and most productive technology stack I've ever used.

<comment><USER43> I don't think you understand. Maybe this video would help enlighten you on the subject.

[https://www.youtube.com/watch?v=b2F-DItXtZs](https://www.youtube.com/watch?v=b2F-DItXtZs)

</comment></comment><comment><USER44> My standard for writing "good' code is...

\- can my team read & understand it now

\- would my team likely be able to read & understand it later

Earlier I wasted a lot of time trying to impress people with clean code, only to later learn those people were never going to care. Now I'm more in the camp of getting it done, which is a heck of a lot easier when you work on a team, and at a company, that shares enough of my values. Getting hung up on "what is good?" is a waste of time, because everyone cares about different things. When you ship stuff, the people who don't care don't speak up don't, and the people who do care do. When the people who care speak up, that's when you have an opportunity to learn what is important to them.

Don't write complete crap, and don't try to make everything. Just try to be productive and not ridiculous, what that means will vary from project to project. Your polished diamond is someone else's stinky turd, and vice versa. For example, I initially learned to write code while hanging out with people who really valued testing everything and aggressive decomposition (e.g. a line of code should only do one thing). I wrote code like that on a new job, and the team hated the number of classes and functions I was asking them to read in a code review.

</comment><comment><USER45> Some of the bad code cited is produced by high management pressure, in my experience. Be careful how you manage programmers, and try to incentivize optimally.

</comment><comment><USER46> i call bs on this kind of observations and all advice that claims you need to know A,B,C to be a "real programmer"

imho, you need to 1) be curious 2) continuously learn and want to improve 3) don't make the same mistakes over and over again 4) share your thought process and be willing to both learn and teach others

yes, sometimes the delta in level of experience is inconvenient but we are all somewhere in our journey. be nice to others.

that is all.

</comment><comment><USER47> Advising against sleep(), cronjobs, etc. seems insane to me, and I don't understand the rationale here. Wanting to yield until there's more work to do (or poll periodically), or run things on a schedule that need run on a schedule, etc. are all very common and very valid use cases. Unless the author's recommending using something else?

Maybe that's just because I'm a poor programmer, though :)

EDIT: I guess in the context of waiting for something to asynchronously finish happening, it'd be more ideal to check for an actual indication of success (e.g. via an await, or by listening for a response message) instead of doing a sleep(5) and hoping for the best. Unfortunately, there are disturbingly many scenarios where that ain't exactly possible (or it's "possible" but not practical), especially when interfacing with external systems written by poor programmers :)

Still, the author should probably clarify how the "cronjobs are bad" opinion fits into that context, because without further elaboration it sounds _really_ silly.

</comment><comment><USER48> The question is: if making a schema to distinguish between "good" and "poor/naive", can one do so whilst keeping biases in check, viz. without inadvertently putting one's own understanding (or unknown lack of understanding) in the "good" camp?

Unless you're EWD, the answer is "no". No you cannot.

</comment><comment><USER49> > You may have seen code which misunderstands how expressions work:

> if isDelivered and isNotified: isDone = True else: isDone = false;

> Instead of:

> isDone = isDelivered and isNotified

Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.

<comment><USER50> I've seen it in professional work. If it's actually a single variable conditional, that's irritating but by itself not worth more than a comment in the PR. However, in practice it's rarely this cut and dry. I usually see conditions expanded like this for clarity reasons. For example, I consider this kosher if it's in some business logic... instead of writing:

> return a && !(b || c) || d;

I've seen (pardon the formatting, I'm typing on my phone):

> if (d) {return true}

> else if (a) {return !(b || c);}

> else {return false}

It's usually a choice to be verbose for clarity.

<comment><USER51> I think that would be clearer as "return a && !b && !c || d". Also, your second example doesn't directly correspond with the first, because condition 'a' is evaluated first.

The major problem with code that's "overly branchy", as in containing a lot of if/else, is that you're forced to go through each case when trying to understand how it works, and it often proliferates into even more branchy code as someone makes a bugfix (with another if/else) in one of the cases, but neglects to see that a similar if not identical change must be made to some of the others.

In other words, if/else cases like your second example optimise for _micro_ -readability when what's often important in debugging and understanding is _macro_ -readability.

<comment><USER50> While I get your point, several thoughts:

1\. I'm talking about acceptable code, as opposed to "the best choice". There are good reasons to go for verbosity. Depending on the problem domain I might agree with your expansion of the parentheses, but when we get to this type of discussion, usually my overwhelming reaction is "this is bikeshedding," because...

2\. If it's "overly branchy" code and you're worried about causing macro- readability issues, the answer is to refactor, not to compress. Modifying inline conditions runs just as much of a risk of becoming inscrutable. You choose between following branches and enumerating binary tables. If it's showing up too many places, you're likely extracting either expression into its own function.

When overly branch code happens, my experience is that the root cause is underthinking/overthinking the method, not taking time to design the right high level abstractions, or as you mentioned a case of too much repeating yourself. Generally, the fixes for those issues don't have that much to do with your choice of boolean expression vs conditional.

</comment></comment></comment></comment><comment><USER52> I read it. To me, it came off more as edgy, brash and inexperienced than what it intended to do - to influence people on what skills they should pick up, so that they may, according to the author, not be a 'poor programmer'.

Often, there are two factors that lead to very different code than usual:

\- Lack of time and hence taking shortcuts

\- Simple code is different from clever code

And, the TL;DR that I wish to convey back is:

\- All code sucks given the right circumstances

\- A skill learnt over time: being a snob is not the way to influence people

\- Everyone starts lousy and gets opportunities to learn and become better - even better than you

\- The way people think and envision things is very different, and operating philosophies are very different. There are multiple pathways to succeed and the skills you mentioned do not appear in all of them.

Any time you wish to state such an opinion, please think about what would influence 'poor programmers' to do better than status quo.

</comment><comment><USER53> Poor programmers are optimistic:

* computers will always run my code fast

* infrastructure problems will not happen

* our team will always have plenty of time to understand my code

* users are not malicious and the libraries I depend on are not malicious

* I will always have to plenty of time to diagnose and fix problems in this code

The author covers some of that.

But you can care about those, and still be a poor programmer: being too pessimistic is problematic. You need to pick your battles and spend your time mindfully.

Now, I have a problem with this:

> Naive programmers think that design means "don't make functions or classes > too long". However, the real problem is writing code that mixes unrelated > ideas.

How do you enforce that policy using a linter? How do you audit a large project for these issues? You can count characters in a line, you can count lines of code in a function or file, and you can count import statements. All those are indicators of coupling unrelated ideas together.

<comment><USER54> You don't. (to both questions)

I don't know about you - but I can spot it by glancing through MR and just expect code provider to explain his solution in description or be "obvious" to me. So sulution to not having these problems is code review.

And if you have this problem then well, you have bigger problem (bad CR). But fixing it all at once is bad idea. Just fix modules you are working with/at.

EDIT: I spot it by checking imports/exports and API surface, so could be automated.

<comment><USER53> You cannot do CR retroactively.

</comment></comment></comment><comment><USER55> "There are no tricks or rules that you can follow to guarantee you will write good software. As Alex Stepanov said, 'think, and then the code will be good.'"

Excellent conclusion, can't think of anything else. I don't know how many times I've seen programmers apply latest patterns and use trendy libraries only to make a terrible mess out of thing.

I literary heard a guy say last week "we should use MongoDb, it is better than SQL". No context, no arguments, just read a blog entry or I don't know what.

There are no golden bullets, think, and then the code will be good :)

</comment><comment><USER56> > On the other hand, what if you generate storage files with random names and > you have a collision? You just lost someone's data! "This probably won't > happen" is not a strategy for writing reliable code.

If the entropy is high enough, and the likelihood of collision low enough, then this is a very useful tool for certain situations, particularly distributed systems. I suppose IPFS (and even Ethereum) was written by "poor programmers"?

<comment><USER57> There's a lot to get right here. I wouldn't call using a UUID or its equivalent a random name. It has random components - sure, but the format is intentionally structured to reduce collisions.

<comment><USER56> Aren't Ethereum wallet private keys 'completely' random?

</comment></comment></comment><comment><USER58> Skills are nouns, but the list was all verbs. Weird.

<comment><USER6> Skills which someone has put a name to already are nouns. But if you are trying to say something meaningful about the skills required in a rapidly- evolving field, it is going to be hard to find prepackaged nouns and so you are going to need to use verb phrases.

——

EDIT: for example, the notion of a language "working" in a mechanical sense has only been around for the past 60 years. If there is a specific noun to refer to understanding those mechanics as you type, it is obscure. This 28-year old software engineer who has worked in both the US and UK has not heard it.

</comment></comment><comment><USER59> > In JavaScript, this is often indicated by new Promise inside a .then().

I have found myself doing this sometimes, why is it considered bad practice?

<comment><USER23> I guess because inside of a then() you can simply return the success case and throw the error case, no need to create a new Promise and call the resolve/reject functions.

<comment><USER60> Was trying to think of exceptions to this when I read and and could only think of one: When you need to wrap a callback API with unusual callback arguments, where a `promisify` like helper won't work. Then again, I still feel the wrapping function should be defined outside of the `then`, as it feels like this is a separate utility to the work being done in the Promise chain.

<comment><USER59> This is the context I've used it in

</comment></comment></comment></comment><comment><USER61> > Programmers who work only on old programs never learn to write new ones.

Maybe give Linus a shout and ask him to call it a day. ;)

</comment><comment><USER62> Another skill: making a website readable on mobile.

</comment><comment><USER63> >I believe OOP and relational database get a lot of flack because programmers tend to be bad at design, not because they are broken paradigms.

OOP has Fundamental and Intrinsic problems that can be described in a very concrete way.

If you believe OOP gets a lot of flack just because programmers are bad at design, then you are the one that is also bad at design.

I will say this, OOP is bad for many and most design problems, and most people who hate OOP also don't even know why OOP is bad. They just have this gut feeling and bad experiences but they can never pinpoint the concrete reason for why OOP tends to lead to bad designs. A lot of people who like OOP, really like the mind bending design patterns but they don't realize that these patterns often offer limited flexibility and the catharsis of creating a design pattern abstraction is just an illusion.

So really what's going on is nobody knows the true nature and goal of design in programming. There's no theory behind it. To first know why OOP is bad you need to know the fundamental nature and goal of design when it comes to programs.

The goal and nature of design is abstraction. When designing programs we want to start from primitives, then compose those primitives into higher level abstractions, then take those abstractions and also form those into even higher level abstraction until we achieve the final level of abstraction that represents the program itself. The key insight here is because everything starts with a primitive, the way your abstractions are designed, depends entirely on your primitives and choice of primitives.

A good primitive must be able to additively compose with other primitives to form every other possible abstraction that the program may possibly need. "Additively" being the keyword here because if you subtract information from your primitive during composition it means your primitive is not "primitive" enough and that in actuality the "thing" your dealing with may be two primitives representing what you tried to "subtract" from the primitive and the remaining part of the original primitive itself.

Bad design often involves dealing with bad primitives. You may find yourself realizing that you have abstractions that cannot be built out of the composition of the primitives that you have. You may find that you have to split up one of your primitives and realize that since it's all encapsulated in a micro-service there's no easy way to do this, so you take on technical debt by making a redundant component that does what you need. You may not even have a notion of what the primitives of your programs are and designed things at the highest level of abstraction with Zero code re-use. 99.999% of all programmers will not have a notion of what primitives are, and design programs in a way where they have a potpourri of components that are a mishmash of high level logic combined with low level logic and no notion of forming higher levels of logic with lower level composition of primitives. Yes 99% of programmers are like this, literally take a look at yourself and your colleagues and tell me who out of all them actually has linked the notion of the "design of programs" with "choice of primitives." In fact the entire blog post never mentioned the word "primitive" or "axiom" once in the entire write up on design.

Which brings me back to the initial topic of why OOP is bad:

OOP is bad because the object is a bad primitive.

Objects are actually arbitrary mixtures of lower level primitives: functions and data. It is far easier to compose functions with functions and data with data than it is to compose these arbitrary mixtures called objects with other objects. Object compositions often involve surgical grafts of one object into another object resulting in a hideous dependency. A lot of people like to use tricks and have this happen at runtime; People tend to call it dependency injection, a very abstract and clever concept but also very very very bad.

Meanwhile composing two arrays:

       [1,2,3] + [4,5,6] = [1,2,3,4,5,6]

Composing two functions:

       function compose(f, g) {
          return function(x){
             return f(g(x))
          }
       }

       b = function(x){return x+1}
       c = function(y){return y*2}
       a = function(j){return j-3}
       d = function(e){return e*e}

       g = compose(b,c) // g(x) = (x*2)+1
       t = compose(a,b) // t(x) = (x+1)-3
       l = compose(d,d) // l(x) = x*x*x

... you get the picture.

<comment><USER64> The real idea for OOP is quite similar to the actor model ala Erlang. OOP as implemented and C++ and Java is an abomination. I still don't get how Bjarne Stroustrup did not steal co-routines from Simula.

It's very easy to implement actual actor model style OOP with procedural code. You can get most of the benefits by using a message bus.

<comment><USER63> >C++ and Java is an abomination.

It's also the OOP version I'm talking about. Most people are talking about this when they talk about OOP, not smalltalk. Why does everyone turn it in this direction... yes smalltalk was the first, but nowadays the traditional term used is not OOP as defined by smalltalk, it's OOP defined by JAVA.

</comment></comment></comment><comment><USER65> This is just an arbitrary collection of a couple of things. A lot of programmers lack a lot of skills.</comment>


Freakonomics: Unintended Consequences in Tuna Fishing - <AUTHOR> http://freakonomics.blogs.nytimes.com/2009/09/24/unintended-consequences-in-tuna-fishing/

<comment><USER2> I feel the bigger thing that needs to change are the giant trawlers and helicopters that catch fish today. They are simply over fishing too fast and their effects are much worse than dolphin safe netting; I honestly don't know how the article came to this garbage conclusion with little support.</comment>


How to Be Polite - <AUTHOR> https://medium.com/message/9bf1e69e888c <comment><USER3> I'm all aboard with being pleasant and respectful of others, but find some aspects of this distasteful. Specifically, the portions of the author's "politeness" that involve performance, or adhering to a script I find off- putting. For example:

"Just ask the other person what they do, and right after they tell you, say: 'Wow. That sounds hard.' "

While it seems that many aspects of "politeness" are intended to trigger pleasant feelings in the other person (which seems harmless enough), I find it hard to be in favor of something so disingenuous. Even when it comes to small talk, I think one can be both respectful and charming without having to fall back on a script and cheapen the interaction.

<comment><USER4> Hypothetically, what if you actually believed it in every instance? That is, what if you genuinely felt (as I do) that nearly all jobs are hard. Granted, some may be harder than others, but I've never met anyone who worked a job I would describe as "not hard."

<comment><USER3> If author had put in an internal check for "do I really believe what I'm about to say" and came back with a "yup" every time before speaking, I'd have no problems at all.

However, as I see it, the pleasant lie baked into the original case is essentially "regardless of what I might genuinely think about what you just said, I'm going to give a response to make you feel good about yourself thereby making me more likeable."

*rephrasing

</comment></comment></comment><comment><USER5> If I could upvote this twice I would. I still haven't gotten to the point where I can be polite all of the time. However, I find that when I try to be pleasant to people on principle, it takes away a lot of stress. I stop worrying about whether they are treating me well, or if I should start pushing back, because I've already made the decision to be friendly and polite. If they choose not to take advantage of this, that is unfortunate. However, I no longer have to react to their perceived bad behaviour in kind. It is remarkably freeing when I can do this.

</comment><comment><USER6> How to be polite IN NORTH AMERICA.

He talks about North American obsession with touch like a normal thing, but in fact it is the exception in the world.

Being polite changes with the culture. In Morocco it is totally ok for male friends to hold hands in the street.

In South America you touch a lot other people. The same happens in Africa. I had India children and adolescent jump over me just after meeting them just playing.

I had played soccer all around Africa and touched shoulders of my playmates, grab their head and hug celebrated with them goals without a problem. Also it was very manly thing to do.

In China or Korea people to burp is ok. Using a kleenex on your nose is not.

In Spain we kiss women when we meet them and we touch kids we recently met a lot. I used to photograph kids a lot. In the US or UK with the obsession in sex they have they can put you in jail for photographic a kid smiling.

<comment><USER7> Oh, if only more of my fellow countrymen could get a worldly experience before they settle down. Many people in my hometown hardly go but an hour or two away except on a vacation.

I remember how I had a culture class before my first deployment to Iraq (USMC, 2007). I, being someone who has always been interested in other cultures, really liked it. I'm not sure my fellow Marines took to it so quickly but after we came back I think they were better people for it (the class and the deployment).

I think your reference to our American Prudish-ness is likely spot on too.

</comment></comment><comment><USER8> Most of this is only true for Anglo-Saxon values of politeness, which many other cultures will see as insincere, fake, cold, manipulative and even downright insulting.

This may not apply to the author, who writes _" I am often consumed with a sense of overwhelming love and empathy"_, but certainly to the vast majority of people who don't have such extreme levels of empathy but use the same tactics.

Yes, like many people I will fall for the _" that sounds hard"_ trick, but if I see you pull that multiple times I'll file you under "manipulative cunt" unless I have a good reason to assume you're that one in a million who actually gives a fuck. Because most of us really, really don't.

<comment><USER9> > unless I have a good reason to assume you're that one in a million who > actually gives a fuck. Because most of us really, really don't.

I'd encourage you to re-evaluate that.

What if you just so happen to live in a world where most people are nice, kind, and caring?

</comment></comment><comment><USER10> I agree strongly on his thesis, that being polite is a good thing to be and that too many folks are oblivious to its usefulness. I'm not so keen on his writing style, but he makes a number of good points.

"Useless in high school but extremely useful later on": yes, school is when you'd expect to learn such skills, but high-school is such a toxic environment that too many folks learn the opposite of politeness (like how to dominate in an interaction, or flee it).

"it provides insulation against bad situations" (the gloves/dirty laundry paragraph): very much so. Politeness and etiquette provides guidelines to interact in situations that would instinctively lead to aggression.

"it lets you gather information about people": I don't like the manipulation undertones of this part, but it's true that with a little skill you can turn many a conversation into a mine of information and bonding.

"touching and personal space": as others have mentioned, this is very flexible across cultures, but I believe that everyone has some level of personal space boundaries. Break these and the other person becomes defensive, uncomfortable.

</comment><comment><USER11> Hair touching aside, the amount of space required between people is bordering on the absurd. I'm sorry you feel uncomfortable but two arm lengths of personal space at all times is not something you're entitled to.

It's like we all want to live in a bubble. In non-western countries bumping into someone isn't the traumatizing horror it is in the US. It's just about expectations, if people didn't expect to have a vastness of empty air around them they wouldn't suffer PTSD for the rest of the day when someone stood almost within touching distance of them.

I'm not saying it's OK to be breathing down people's necks and people should consider the comfort zones of others, but it's kind of extreme in the US. If there's an empty chair next to you, I'll sit in it, and if there's a public urinal available next to yours I'll make use of it. Deal with it.

<comment><USER12> That is because different cultures have different customs. In some cultures it is acceptable to hug and put your arm around someone you have not met before, in others, even non-western ones, it is seen as extremely rude.

My language teacher when I moved here was telling our mixed nationality class about how in her perception, as you moved further north from the Mediterranean, the personal space people have increases, and how this does not mean people are not comfortable with people near them. This was in the same lesson where we started covering different gestures and how offensive in one is fine in another.

Two arms length is a farther than I usually have, but coming within an arms length if I do not know you, especially at a party, unless to tap my shoulder for attention will make me feel uncomfortable. Two arms length requires me to raise my voice to talk to you, which I consider ruder than being close.

That aside, the OP reads more like a "How to social engineer" than a how to be polite.

<comment><USER13> > Two arms length requires me to raise my voice to talk to you, which I > consider ruder than being close.

I've been paying attention to this and have come to the conclusion that this is one of the major factors why Americans are perceived as "loud".

As you indicate, this can lead to another type of invasion of personal space (for those who aren't part of that particular conversation).

</comment></comment></comment><comment><USER14> Just remember, polite varies from situation to situation. Growing up in the Caribbean when I was a teen meeting other people my age was a very physical thing. You might have someone's arm around your shoulder or get jostled around a little within hours of meeting them. In fact that was how relationships formed.

Touching a girls hair, or even giving it a light tug was all part of the flirting game. To be clear it's not like you just met someone and started touching them everywhere and it didn't have to happen everytime, but during the course of conversation if it was appropriate and natural a light touch here and there was just part of how things worked.

Moving to the US I found out very quickly that you give most people space unless you were invited in closer, but I've found Europeans that I've met are more open to an appropriate natural touch

</comment><comment><USER15> Excellent article, and I feel it also applies to me, so I wrote down some thoughts. maqr's comment about this being dangerously close to social engineering rings very true, although I doubt that it's intentional/by choice. Personally I've never had a lot of natural conversational skills, so I find myself falling back to old tricks that work at times when I'm not confident, and sometimes they happen to be tricks that relate to social engineering. I'd like to think that this doesn't make my interactions less genuine. Finding a polite way to proceed through the conversation has not been a problem for me since I learned this.

Lately, rather than moving towards politeness, I'm trying to move away from it. The examples of always replying positively to people, never steering towards or even approach hostility is a very, very tiring path to walk. In my experience, it does pay off on the whole, but I've spent a lot of time talking to people that were just never 'interesting' or 'rewarding' to be with, simply because it always seems easier to please than to confront.

These days I'm trying to move towards blunt honesty with people as soon as I can (after an initial period of polite conversation to gauge if they'd be comfortable with it). So far, I think the people I know appreciate me more for it, and the people who wouldn't appreciate me for it are not in my life.

Or perhaps it just feels good to try something different.

</comment><comment><USER16> I'm surprised at all the approval of this politeness strategy given my modus operandi -- making sure I'm doing interesting-enough things to have a comfortable influx of people, then filter through them by being upfront and asking hard but honest questions.

I don't think we realistically can connect with everyone on a meaningful level, and given there's 7-8 billion people out there, a search/filter strategy just seems more reasonable than trying to please everyone.

That being said, I am not advocating to the burning of any bridges at all -- as the scenes we walk tend to get smaller and smaller the more focused and specialized they get.

</comment><comment><USER10> It's a stereotype that us geeks are poorly socialized. After the all-too- common years of school bullying and stunted social growth that entails, I was lucky enough to meet the right people and learn better skills of communication and empathy.

Politeness for me started as a facade to hide behind, but over time it turned into a tool of empathy and connection. I believe this to be my most useful and powerful skill, far beyond any technical skill I have.

I wish more geeks (such as Lennart Poettering to name just one notorious hacker) would learn this.

</comment><comment><USER17> Politeness serves as a buffer. It gives you time to evaluate the situation and gain more information while keeping you from making a rash judgement - <USER2> positive and negative. Later on, it keeps you from unnecessarily making enemies of the people you don't respect but must nevertheless deal with. It works hand in hand with patience, which I see as being in very short supply these days. In my experience, it is an extremely valuable trait.

</comment><comment><USER18> Despite his points about politeness helping him, which I appreciate, politeness is still following rules, aka doing what other people tell you.

With social skills, as with any other discipline, merely following rules will make you a craftsperson, not an artist. Artistry comes from knowing the rules so well you can transcend them. I prefer the musician who knows how to improvise sometimes the "wrong" note, the quarterback who shines when the play falls apart, the chess player who develops new moves, ... you get the idea.

Personally, I'm more interested in becoming an artist than just following rules. For example, I prefer to find out how I can quickly create deep bonds, which you can do when you break some of the author's rules. I grew up with poor social skills and the geek scientist in me wanted to understand what was going on. Then the geek entrepreneur in me wanted to use what I figured out and develop it as far as I could. Then the business entrepreneur in me wanted to polish it so people would appreciate it. Now I coach people in it too. I feel like the guy wrote a story about how to play scales on the piano, though I enjoyed the writing style. Who wants to stop there?

My story about my friend and Jack Nicholson at the U.S. Open illustrates the social value in breaking a dress code (from my blog [http://joshuaspodek.com/high-status-living-rules-jack- nichol...](http://joshuaspodek.com/high-status-living-rules-jack-nicholson-u- s-open)). There are a million other role models of people who shine in breaking rules, but I'll just tell that one story about him:

A friend who grew up in Queens and became the senior ball boy at the U.S. Open told me a story about his friend who worked there too.

One day he was working at the door to the U.S. Open's VIP room enforcing the jacket-and-tie dress code. Jack Nicholson came by and started walking into the room wearing shorts and a t-shirt.

My friend's friend, following the rules, in a nervous high school student voice, said "I'm sorry Mr. Nicholson. There is a dress code and I'm afraid I have to ask you to follow it."

With a polite laugh, Jack Nicholson said " _I don't think so,_ " and continued in.

I'll bet Jack Nicholson didn't start breaking rules because he became a star. I'll bet he became a star by breaking rules -- not blindly, but intelligently.

<comment><USER19> Oh look, the PUA community is arriving.

To be more constructive: There are great benefits to having high status, but it's simply unreachable for most of us, in addition to having hidden downsides. Instead, I would focus on being pleasant to people around you and create good personal relationships.

<comment><USER20> I don't understand your first sentence at all.

<comment><USER21> PUA means Pick Up Artists.

There are lots of people in the PUA community who just use the same techniques that work to "pick up" people to be more socially confident and meet people.

Often people will talk about things like maintaining eye contact, escalating, inner game, etc. In the end, its just exploiting how we are as humans the same way slight of hand works and we all clap at David Blane.

<comment><USER20> I got that part. I just didn't see the PUA signifiers in the comment they replied to.

<comment><USER22> I think he's keying off of the "know the rules so you can transcend them" idea. It's used in a lot of PUA material.

<comment><USER23> It's not a thing unique to pick up artists though, it can be applied to most arts or indeed programming.

There was an article posted on HN a while ago that explained a similar effect (dressing differently to show status) outside of the context of PUA. For example Zuckerberg wearing a hoodie to meetings with Morgan Stanley.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> Seems kind of annoying and inefficient to me. If I took someone out on a date and started talking about tumors I'd rather they say to talk about something else than just be polite like he did. Then I could integrate the suggestion and maybe we'd have a good time. He had to wait for years for another chance at something that could have been fixed with thirty seconds of honestly.

</comment><comment><USER25> Here is the daily Medium article</comment>


Switch Back to Original "GitHub Flavored Markdown" - <AUTHOR> https://github.com/isaacs/github/issues/940 <comment><USER2> you're .. mad that github is going to write down some rules about how their software works in practice, publish those rules, and then try to hold to those rules as their software continues to evolve?</comment>


Microsoft patents a way to fit a 3.5mm headphone jack into less than 3.5mm - <AUTHOR> http://pocketnow.com/2017/10/30/microsoft-patents-3-5mm-headphone-jack <comment><USER2> Why not just make a new 2mm-1.5mm port and ship 3.5mm to 2mm adaptors with all phones? I know it would easier to bend but I feel like they would be pretty cheap to replace the adaptors and could be designed so that they break in such a way that you could pull the broken end from the phone. You could also have high grade titanium reinforced plugs/adaptors.

<comment><USER3> 2.5mm audio jacks have been around for decades [https://en.wikipedia.org/wiki/Phone_connector_(audio)#Modern...](https://en.wikipedia.org/wiki/Phone_connector_\(audio\)#Modern_connectors)

</comment></comment><comment><USER4> Um, didn't Apple file basically this exact patent some years ago?

What does the USPTO actually _do_ these days?

[https://www.cultofmac.com/85736/apple-patents-ways-to- make-a...](https://www.cultofmac.com/85736/apple-patents-ways-to-make-an-ipod- thinner-than-a-headphone-jack/)

</comment><comment><USER5> If it's on the top will it prevent you from closing your laptop lid while it's attached?

It seems like if you accidentally closed the lid it might do damage to the screen?

I guess you would have to have a rim around the front of the lid with a notch if you wanted to avoid that?

</comment><comment><USER6> Why not like this? [https://i.imgur.com/dmuGOA5.png](https://i.imgur.com/dmuGOA5.png)

Too small tolerances needed?

<comment><USER7> That floating corner there is very likely to snap off, furthermore it'd require quite a hefty bezel to even fit it without having a weird gap in your screen.

</comment></comment><comment><USER8> Not sure what the point of this is if they have give up making phones. I doubt a surface pro will be made thinner than a phone.

</comment><comment><USER9> I can only wonder why all that work to keep alive a connector that was born defective in the first place, especially when the patent is for something that obvious. I'm strongly opposed to removing analog output from devices, but would hope someone somewhere could make a more modern and reliable design then implement it successfully and release its specs for public use without the aggressive involvement of any law firm. ...Geez, it's a connector!

<comment><USER10> What's defective about the 3.5mm jack? It's worked well for all these years for me and many others until Apple started labeling it "legacy"?</comment></comment>


Icelandic fiction: a family affair - <AUTHOR> https://www.the-tls.co.uk/articles/public/iceland-fiction-ethics-cultural-life/ <comment><USER2> > I spent the rest of the day running around Reykjavík, repeating what I had > learned. Guðrún Ósvífursdóttir was my twenty-seventh generation ancestor. I > was as good as Icelandic royalty. It wasn't until late that evening that a > friend explained that, well, _everyone_ was. In a nation of 350,000 people, > if your lineage remains unbroken from the tenth century, you are the > ancestor of everyone.

I'm sure it's magnified in Iceland, but this is true in other countries and globally. When I traced my lineage back to Charlemange, I had a similar moment, telling a bunch of people at work because I thought it was interesting. As soon as the French guys heard it, they laughed and explained that the big joke in France is everyone's related to Charlemange.

After that, I realized it's actually plausible that everyone is related to Charlemagne. Moving backwards in time, we each have two parents. Conservatively assuming a generation is 30 years, Charlemagne was 40 generations ago. The theoretical maximum number of ancestors I have 40 generations ago is 2^40, or in other words, more people than have ever lived on the planet by many multiples. On the surface, and assuming a reasonable amount of mixing, that seems like it would make it extremely likely than anyone with any European ancestry is related to Charlemagne.

<comment><USER3> To be fair, at this point of removal the amount of DNA you share with Charlemagne is likely to be similar to the amount of silver nitrate in a homeopathic remedy.

<comment><USER2> Yeah exactly, if there's any left at all. Since DNA's finite and has fewer than 2^40 base pairs, any one person's direct DNA influence is likely to have been factored out completely.

Fun to think about the probabilities and combinatorics though. There are 2^40 "votes" in our ancestry for the time Charlemagne lived. Depending on how "prolific" he was, all the population crossover since then means he will occupy many of those 2^40 votes. Some people have a lot more influence than others, but it's nearly impossible to know.

<comment><USER4> Its smaller than that if count just the 21K coding proteins, two copies from both parents. If perfectly mixed you start losing ancestor contributions as soon as 16 generations or 400 years. But meiosis- the halving of DNA during creation of eggs and sperm- is not perfectly random, but chunky. So ancestor dropout occurs sooner.(It is hypothesized much of the other 98% of the genome has some sort of genetic influence too.)

</comment></comment></comment></comment><comment><USER5> It's good to see more mention of Halldor Laxness. His books are always pleasant - and often profound. A good starting place is The Fish Can Sing, which has the benefit of also being a shorter novel of his.

</comment><comment><USER6> This is very interesting and sort of tangential to something I'd realized after I married a Scandinavian woman: If you want to get famous doing some thing, you haven't a shot in hell in a country with three hundred million people like the United States. But for example Sweden. Sweden has only _nine million_ citizens, and more than ten percent of them live in Stockholm! This is such a relatively tiny audience. I imagined that anything you wanted to do: Write a book, sing a song, make a movie, open a restaurant, become a politician, play a sport, anything! It would be easier to attain status as noteworthy in a country with two orders of magnitude fewer people that all speak their own language, have their own culture, their own rules. I'm still convinced that this is the case, and I'd love the chance to test it someday.

Of course, please excuse my broad generalities and extreme oversimplification. But for example, most (non-Swedish) people don't know how much of Western culture is currently driven by Swedes. You go look at famous pop culture musicians and count how many of them are actually Swedes. You'll be surprised. Now, I haven't studied the rest of popular culture to know whether or not there is an equal amount of representation from other places e.g. Norway, Poland, etc. But it makes me wonder if these musicians -- every one of whom of course are as talented as can be -- if they are getting more international recognition because they have recognition in their own homeland? Or does Sweden produce musicians more appealing to Western popular culture? I'm not sure. So many questions, so many thoughts! One example of this type of idea that I've heard about in recent years is some woman from a wealthy family who did some kind of esoteric series of competitions -- skiing, I think? -- and was able to compete in the Olympics because of the lack of competitors for a slot in the team of a particular country. She was able to compete after winning a slot by default. This is sort of asymptotic to what I'm talking about, but not quite there. This is just a super-fascinating thing for me.

<comment><USER7> > But it makes me wonder if these musicians -- every one of whom of course are > as talented as can be -- if they are getting more international recognition > because they have recognition in their own homeland? Or does Sweden produce > musicians more appealing to Western popular culture?

As far as I know, the working hypothesis is that Sweden's extensive social safety net (unemployment benefits,low-cost health care, fair insurance deals, so on and so forth) allows people to feel more secure in trying out things that may not become very profitable.

<comment><USER6> Oh, now that's an interesting proposition! I hadn't considered that, but it seems logically sound. Housing however is still a big issue in Sweden, not only with rent but with waiting lists in metropolitan areas, so it's still not completely safe to throw all caution to the wind.</comment></comment></comment>


GitHub's Game Off is back - <AUTHOR> https://github.com/blog/1972-the-game-has-changed <comment><USER2> This has some amazing potential this year- Unity 5 free, Unreal 4 free, Source 2 just released. I've been playing with a FTL-like prototype in Unity for the past couple weeks, it's been surprisingly easy. It's a brilliant time to be a game developer.

Also, fork me! [https://github.com/JerkyTreats/SpaceshipPrototype](https://github.com/JerkyTreats/SpaceshipPrototype)

<comment><USER3> It's a bit weird what's qualified as a browser based game now a days. For me it's still CGI/Perl/PHP and maybe some JS. :P You barely see those kind of games any more. Now it's mainly plugins and it makes me a bit sad. Why does it Need to run in the browser? What's the point with the browser if you are gonna use plugins anyway? Why not make a "native" game instead!?

<comment><USER4> With Unity 5 [0] and Unreal Engine 4 [1], it's no longer necessary to use browser plugins.

[0] [http://blog.mozilla.org/press/2015/03/unity-5-ships-and- brin...](http://blog.mozilla.org/press/2015/03/unity-5-ships-and-brings-one- click-webgl-export-to-legions-of-game-developers)

[1] [https://blog.mozilla.org/blog/2015/02/24/unreal- engine-4-7-b...](https://blog.mozilla.org/blog/2015/02/24/unreal- engine-4-7-binary-release-includes-html5-export-3/)

<comment><USER3> Yeh, you Only have to download and install Firefox first.

<comment><USER5> asm.js does not require Firefox and runs just fine in browsers like Chrome.

It just performs better in Firefox at the moment due to better support.

<comment><USER3> I did try the demos in the New Opera browser witch is as close as "browsers like Chrome" you can get. But it didn't work.

</comment></comment></comment></comment></comment></comment><comment><USER6> I always love the concept, but it I rarely hear about the winners, plus there is no way to browse the entrants.

Update: Oh cool, this year they finally made a list of everyone who one in the past. [https://github.com/showcases/game-off- winners](https://github.com/showcases/game-off-winners)

I wish they put together a blog post on why they won.

<comment><USER7> Also for GGO 2012 you can view entrants here: [http://pkukielka.github.io/ggo12-viewer/](http://pkukielka.github.io/ggo12-viewer/) (disclaimer: viewer was done by me). If I remember correctly someone forked my code and did the same for 2013 edition.

</comment></comment><comment><USER8> I like the deadline time, smart!

      > ...13:37pm PDT.

</comment><comment><USER9> So, is it required that you start with an existing project? It seems to me that the only requirement explicitly listed is that it needs to be playable in a browser.

<comment><USER10> > The Challenge

> Take an existing game or game jam entry on GitHub, fork it and do something > awesome with it.

> Take a look at the following resources to see if there's one you'd be > intersted in forking....

> Once you've found a game repository, fork it...

> Make sure your code is pushed to the default branch of your forked > repository...

And, on the submission form, talking about your Readme file:

> Mention the Game Off, what changes you made, who was on your team, what > technologies you used, throw in a screenshot, etc.

I dunno, all that seems pretty explicit to me.

<comment><USER11> I would call that very suggestive, not explicit.

      > Take an existing game or game jam entry on GitHub, fork it and do something awesome with it.

Consider the edge cases:

What if you can't fork it because you've already forked it 5 months ago (but made 0 commits on your fork)? This is probably okay, right? If not, you could delete your existing fork and fork again.

What if you can't fork it because you have an unrelated repo with the exact same name already? This is also okay, right?

What if you can't fork it because it's your own repo and you don't need to fork it? This is not okay? Or is it okay? No clear answer.

There are times where it helps to have explicit rules/conditions.

<comment><USER12> Dude, it's not like there is major prize money involved.

This is just a "just for fun, do something cool by forking something that already exists and we'll show off the best."

Relax, have fun, make a cool game.

</comment></comment></comment></comment><comment><USER13> Is there a prize?

<comment><USER14> Anyone else thinks its weird that there is no prize? (nothing mentioned in the blog post at least)

</comment></comment><comment><USER15> That's a pretty bad title. Could mean anything. How about taking the first phrase in the article "GitHub's Game Off is Back". Maybe add an exclamation point.

It's a cool thing to build games for the browser and I'd like to see it get more HN attention.

<comment><USER16> Ok, sure. But not the exclamation point!

</comment></comment><comment><USER17> > The only restriction is that the game should be web-based

That's one hell of a restriction.</comment>


China ends anonymity on its internet starting June 2017 - <AUTHOR> https://www.techinasia.com/china-ends-anonymity-internet <comment><USER2> This is quite unwise from a power-psychophatic point of view- How can you know what people think, if they cant have illusion of anonymity? If they only talk in eye to eye conversations about "forbidden" topics, the world will unravel the day they realize how vast there network of dissent actually is. Could it be that somebody inside the Censorship apparatus of Chinas apparatus is actually trying to prepare the grounds for a revolution?

<comment><USER3> Maybe they don't see censorship the way you do. Maybe it is, in their eyes, about the ethical and honourable protection of their culture and social values.

<comment><USER2> The idea in for itself is actually quite nice, to protect and to serve a culture and the values in it. The problem is, human nature and the circumstances it creates in the short and long term are quite corrosive to culture and to the upholding of values. You can try to enforce the honoring of the previous generations achievement, but if the previous generations has as core value "be fruitful and multiply", you will run into nr^2 < res <=> conflict.

The whole idea of discovering and searching for the new, allowing the unknown to prosper and co-exist - is based upon knowing, that the conservative approach to stabilize society is doomed to failure, as long as a surplus is not provided by a rather liberal scientific society.

Does this make dissent always meaningful? No, but if the peasant can not speak up to the chairman, how can the son of the peasant, speak up to the professor being wrong on fertilizer chemistry? Conflict avoidance in short term is just conflict concentration in the long term.</comment></comment></comment>


Ask HN: Want to connect with Startup School attendees before the event? - <AUTHOR> If you're attending Startup School in September and interested in getting a jumpstart on the networking, add yourself to this list along with anything we should know about you or your company. Share whatever contact info you're comfortable with as well as some guidance about who you hope to connect with.<p>https://docs.google.com/spreadsheets/d/1_XBluxMxSbl4h6vY3qa7cU9xnFEe4IvkMWHiTopV_xk/edit?usp=sharing <comment><USER2> Awesome! Thanks for creating this, heading over now.

<comment><AUTHOR> Certainly! Hope you find it useful!

</comment></comment><comment><USER3> Nice :)</comment>


Show HN: Colors.sh – Bash colored and formatted output made easy - <AUTHOR> https://colors.sh/ <comment><AUTHOR> I created this simple tool to help format the output of bash scripts, since it was not so trivial when I wanted to do this myself, colors.sh lets you easily set the formatting (foreground and background colors, etc), preview it and see how to implement it.

Hope it's helpful for others too :)</comment>


ARM Cortex-A15 Exynos5 Compiler Benchmarks - <AUTHOR> http://www.phoronix.com/scan.php?page=article&item=arm_cortexa15_gcc&num=1

<comment><USER2> In summary, binaries compiled with GCC 4.7 shows better performance compared to binaries compiled with GCC 4.6, on most benchmarks.

But I would like to see a deeper analysis of the benchmark results that are actually worse with the newer compiler.

</comment><comment><USER3> Remember that compiler benchmarks are useful only for telling you how long it takes to compile.[1]

When you cross architectures the effort of compiling can change radically. It doesn't end up telling you anything meaningful about the platform.

[1] which can be the most important metric to you.

<comment><USER4> That is not what this is.

These are benchmarks on running applications on the same piece of hardware, after compiling with two different compilers.</comment></comment>


Ask HN: Which one is better? - <AUTHOR>

Although I couldn't finish all assigned tasks with the deadline, I did some good job. Should I start presentation with completed or uncompleted tasks? <comment><USER2> I'd definitely start with the completed tasks. Anything not completed I'd save for the end and try to brush off as "putting the finishes touches on" or "need to rethink some of the workflow" or something like that.

</comment><comment><USER3> Focus on the good. Focus on what went well. Focus on what got done. Right before you end add a quick whats left and follow with a game plan to get it done.</comment>


Bracketed paste mode (2013) - <AUTHOR> https://cirw.in/blog/bracketed-paste <comment><USER2> Beware that some terminals implements bracketed paste mode in a way that doesn't protect you from malicious pastes.

For example, urxvt is broken in this regard, and the maintainer doesn't seem to be interested in fixing it:

[https://bugs.debian.org/787628](https://bugs.debian.org/787628)

<comment><AUTHOR> This is a fascinating discussion on the philosophical differences in approaches to how pasting is supposed to work, and from skimming through it, it doesn't seem obvious to me which way is best. Reasonable people can disagree.

</comment></comment><comment><USER3> Note: The link to the readline manual is broken. It should be [https://tiswww.cwru.edu/php/chet/readline/rluserman.html](https://tiswww.cwru.edu/php/chet/readline/rluserman.html) ; The server name has apparently changed from cnswww to tiswww.

<comment><USER2> I submitted PR to fix it:

[https://github.com/ConradIrwin/conradirwin.github.com/pull/3](https://github.com/ConradIrwin/conradirwin.github.com/pull/3)

<comment><USER4> Thanks jwilk!

Indeed a lot of this information is now quite outdated - thankfully people (e.g. vim) are beginning to implement it natively, and so I have basically deleted all of my own code and can use existing plugins.

</comment></comment></comment><comment><USER5> I wrote the original xterm patch for this mode, to help the mouse mode of Joe's Own Editor. There were related additional features that didn't catch on:

A mode where you could read or set the selection data with base64 quoted strings. This gives the application full control over its interaction with X's cut & paste buffers. For example, if you Shift-select some text, the application can tell X about it so that other applications can paste. I think there is still an xterm configure option for this one.

The ability for the mouse to send motion events (when a mouse button is pressed) to the application even if it has gone beyond the terminal emulator's window border. It needs to be able to report negative coordinates when you are above or to the left of the window. This is needed to allow you to select text where the scrolling speed is controlled by how far beyond the border the mouse has moved. I still think this is needed, but patch not taken.

Incidentally, JOE has a hack for terminal emulators that don't have bracketed paste. If a new input character is immediately available after the previous character, then assume we have pasted text instead of typed. This works surprisingly well since the communication links tends to keep contiguous writes together in a single buffer.

<comment><AUTHOR> _" A mode where you could read or set the selection data with base64 quoted strings. This gives the application full control over its interaction with X's cut & paste buffers. For example, if you Shift-select some text, the application can tell X about it so that other applications can paste. I think there is still an xterm configure option for this one."_

base64-encoded selection data sounds intriguing, but I'm not sure I understand what base64 has to do with the application being able to tell X about some text being selected.

And doesn't X already know when some text has been selected, simply from the contents of the primary selection having changed?

<comment><USER5> Suppose you select text with the keyboard- in JOE you can do this by holding down Ctrl and repeatedly hit arrow keys (actually there are many ways to this- ^KB ^KK marking is another). In most editors for Windows you can do it by holding Shift and hit arrow keys.

How is X supposed to know that you just made this selection? Normally it can not, because it's a tty/console application not in direct communication with the X server.

The base64 selection feature allows a console application to do it: the program can send selection text to X any time it wants: it's some header, base64 text, and a trailer. When the terminal emulator receives this, it forwards it to the X server just as if you had done a mouse selection.

The base64 is useful in the other direction (pasting into the terminal emulator running an editor). One minor advantage is that base64 is binary clean. Another is that the text is not just sent to the application- instead you get a sequence indicating that middle mouse button was pressed. The application then sends a request to the terminal emulator to have it send the paste data to the application. This is better because it allows you to paste by (for example) using an application specific keyboard sequence, not just a mouse action.

<comment><AUTHOR> Oh, I see. I was thinking of mouse selections, which (in Linux anyway) will instantly make whatever you selected with the mouse available to X.

As to selecting text with the keyboard, Emacs at least does some magic to make copied text appear in the X primary selection. I personally find this more annoying than useful, as it clutters up my primary selection with random junk I've beeing editing in Emacs. So I personally prefer to only send the text to X when I deliberately call for it, by sending the text to the "xclip" utility as needed. It's possible to use the "xsel" utility as well.

I'm not sure what is the advantage of putting the terminal in to the middle of this process. Why can't applications just send whatever text they want to X by using xclip or xsel?

Pasting in to the terminal is another matter, of course, and I can understand the usefulness of being 8-bit clean and using base64.

<comment><USER5> You might be ssh'd to another system, so xsel / xclip will not work.

</comment></comment></comment></comment></comment><comment><USER6> I wish I had seen this five years ago!

I'm always doing

        :set paste

and

        :set nopaste

whenever I need to paste text from other sources into vim. Or, rather, I would paste, see the crazy indents and comment characters auto-repeating, and have to decide if I should revert, issue the :set paste, and try again; or if it would be quicker to manually clean up what I just did.

I just added the code to my .vimrc. Works like a charm.

<comment><USER7> I've been using tpope's excellent unimpaired.vim¹ to handle toggling paste for me², but will probably switch as vim-bracketed-paste is automatic.

I only bring up unimpaired.vim as it provides a whole heap of neat mappings for other toggles you might be manually performing. Most of which follow a simple pattern that makes them easy to remember.

I don't believe any other plugin has increased my productivity as much as unimpaired.vim. Popping up the doc to link to the YOPO note I've realised just how many of those next/previous bindings I use as muscle memory.

¹. [https://github.com/tpope/vim-unimpaired.git](https://github.com/tpope/vim- unimpaired.git)

². [https://github.com/tpope/vim- unimpaired/blob/master/doc/unim...](https://github.com/tpope/vim- unimpaired/blob/master/doc/unimpaired.txt#LC108)

<comment><USER6> Fantastic. This makes the following (very common) commands so much easier for me:

        :diffthis
        :set [no]list
        :set [no]wrap

I know how to map shortcuts, but I never could bring myself to make them, because I've done that too many times in the past and end up with a mish-mash of private mappings that atrophy my vim skills in a way. Hope that makes sense.

But this plugin is super consistent internally. Great mnemonics. I don't mind coming to rely on it.

Thanks.

<comment><USER8> My solution to the atrophy thing is to keep my vim settings (and bash scripts aliases etc) on gitlab where they're always only one git clone away.

<comment><USER9> We are glad to hear that using GitLab helps you with your scripts and settings for vim. That's a really great approach.

</comment></comment></comment></comment></comment><comment><USER10> In practice terminals have to behave in a slightly more complex fashion.

* [https://news.ycombinator.com/item?id=16895939](https://news.ycombinator.com/item?id=16895939)

</comment><comment><USER10> It is important to spell the name of the readline setting correctly. The readline configuration parser is very bad at dealing with errors in its configuration file.

* [https://unix.stackexchange.com/questions/356457/](https://unix.stackexchange.com/questions/356457/)

* [https://unix.stackexchange.com/questions/383670/](https://unix.stackexchange.com/questions/383670/)

</comment><comment><USER11> It's all fine and dandy until your ssh session dies and then pasting does weird things you don't understand.

iTerm2 can detect this if you install shell integration. I wish there were a more standard way to deal with this scenario, which affects everything in a terminal that has a mode (focus reporting, mouse reporting, application keypad mode, etc.).

<comment><USER12> Just use a shell alias for ssh that does a reset if the ssh command exits with an error code.

</comment></comment><comment><USER13> One of the best implementations of adaptive webpages for reading-oriented sites.

<comment><USER14> Yes, I like it too. I tried to resize the browser window horizontally and the page neatly splits the content in multiple columns. Very nice.

<comment><USER4> It's pure CSS columns, and not updated since 2012 or so.. yay for the web.

I'm surprised they've not caught on more, but it is quite hard to control where column breaks end up in a way that lends itself nicely to evenly lengthed columns and to keeping headings near the paragraphs they're describing.</comment></comment></comment>


Show HN: Wisest.one – teach yourself visual programming - <AUTHOR> http://wisest.one
The idea is to teach the core programming techniques through visual and interactive projects.
App uses a custom programming language. <comment><USER2> Interesting tutorial, but equating wisdom with knowing visual programming is not doing it right. At best, programming is learning to write less lines of code, especially in these times of overflowing libraries and frameworks in Github. Always remember: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away".

<comment><AUTHOR> The domain name is a kind of wordplay (the name of the app is "Wisestone"), no claims of superiority intended.

Was everything clear and easy to understand?

Did you edit and run the program?</comment></comment>