gravity13

Does this mean we can crowdsource and buy the private browsing history of our favorite representatives and post them online for everybody to see?

ctrl+left is back in browser :(

Everything is unclear until you become used to it, though. I mean, used to it, as in, you can read it without stepping yourself through the steps manually. And to a novice programmer, pretty much everything they come up against represents this.

Turning five lines into one line with a reduce function sounds like a normal thing to do for experienced programmers, but to a beginner, they'll think you're a genius for pointing it out to them. So it's not surprising when they try to apply their genius and come up with something clever, too.

I think cognitive load is a perfectly acceptable term here. Taken within the context of Cognitive Load Theory, we assume that any individual can only maintain a few items into their working memory. These items are portions of the code that you need to think about at once in order to achieve a task, and good code partitions off the logic so that in order to understand individual components you only need to reserve a few slots of your working memory.

Of course this is a bit contrived, but I would argue that pretty much everything we've come to understand as "easy to read code" all reduces down to how effectively it organizes itself given the limitations of our working memory. And in that case, it's one of the first things you should be sure to understand on your path to becoming a better programmer.

I find this kind of strange, given that both of them seem to be sinking massive amounts of money into subsidizing rides. Like, they're going to be all about user retention when people are only going to care about which option is cheapest. Google, or somebody, is gonna come in and mop up on the ecosystem they've created. They won't even have this huge ethical problem of laying off thousands of drivers.

This is an interesting question. I'm not a neuroscientist or anything, but I'd wonder how this question relates with brain waves, as well. I guess there's research into how these signals cause integration within the brain http://www.nature.com/nrn/journal/v2/n4/full/nrn0401_229a.ht... - I guess I'll check back here in a couple hours and hope somebody's chimed in.

I agree. Make Toasters Great Again.

I'm personally hoping for Basic Income, myself.

I don't want to make blanket statements about any group of people, but this has been my experience with everybody I've worked with that has come from Yammer.

I think my favorite part of all this is that Sacks has dubbed his start at Zenefits as "Day One" and is dubbing this Tony Hsieh move "The Offer".

I imagine that after today he will go home to The Woman and sit in The Chair and pat David The Dog on his scruffy head while feeling well accomplished.

I feel like this is a classic example of abusing your knowledge about your product. You gotta account for the fact that users will usually come in having little knowledge about what your product is and will derive that from the functions available on your page. In the previous designs, you look at it and see:

- user generated requestst - crowdsourced voting - how easy submitting a request is, and what it entails - the volume of requests you have

I see this in the larger context of icons8 and I get the sense that is akin to voting for a feature. This is something I could do, if I wanted.

The new design shows me:

- Weird titles that may or may not be some sort of request

And that's about it. Only five of them. Take that in the context of icons8 and I really can't parse what it means so I would probably just completely ignore it. On the request page, I don't see how approachable the request feature is, so I ignore it.

Uservoice does it better.

Because they don't know how to. (so even if they do test it, they fuck that part up too).

This is where I feel like the title "project manager" ought to be reconsidered, perhaps to "project secretary." That way, it's a bit more clear there's less of a hierarchy and more of a duty.

The article misses some key things I would throw out there, here's to hoping they come to value with you.

1. Bake rules into your workflow. For instance, enforce daily or semi-daily standups. Make git commits a portion of things in those - so everybody has to say what they've done in git commits (obviously, this isn't 100% of things). Other coders on the team will be annoyed by the person who isn't committing code daily, so this will mean that coder is admitting not to you, but to them, they're playing by different rules.

2. Force them to write design docs for implementing new technologies, before they're implemented. Then write a retrospective about how things went over, a week or two after the project is launched (things that were unexpected?). This can serve as documentation, but adds a bit more clarity to the overhead that comes with these changes, which is easy to miss when you're in the thick of things. Perhaps it's all they need to understand what kind of complexity they're adding (or what kind of simplicity you're not giving them credit for).

Funny thing was this place did espouse "test everything" except it came in the form of our Product leads "test only the things I don't agree with." Which of course meant we were using all of our testing budget on dumb things.

I'll just consider myself happy I don't work with a manager like you, then.

The company doesn't exist for me to hack on cool new things. Of course not. But what you fail to understand is that I'm a very intelligent person who is not planning on spending the rest of my life doing shitty simple e-commerce UIs, or whatever it is that you do. It's easy to think nothing but the goals of the company matter, especially if you're an awful founder, but the world just doesn't work that way. We all need to move on when the company likely dies, and I don't want four years of "I had no choice but to work with crap" on my resume when this happens, just because I had an asshole boss who hated other people who did smart things around him.

I got to disagree with the whole continuity over ingenuity trope. It's how I can continue to remain modern as an engineer, and if done correctly, leads to vast gains in cognitive complexity by delegating concerns to newfangled tools that handle it better. Sure, it's a bit less stable, but this is how we keep the industry moving quickly, and I hope managers see it more in terms of trading technical debts than a stubborn "oh great, you want to introduce another new tool!?"

ha! Very same experience here, too. I was just working at a place where one of the designer-founders redesigned a page to look one way. Then three months later, he redesigned it again, to look back the old way. He actually put these into the pipeline, assigned it to different engineers, and there was no reasoning over choosing one way or the other. Both designs had the same functionality and the same glaring flaws. He just kept wavering and wouldn't even consider doing any user testing or A/B testing on it. Glad I don't work there anymore.

> is just shooting yourself in the foot in a future time, as this has shown

only because of a design oversight by npm which is now being fixed. Like I said, fix the issues in handling your dependencies, and you remove the overhead of including them, such that "depending on several hundred things" is managing it.

Checking your needed dependencies into your source tree can either be done by recreating them in your source tree or pointing to them. Your pick.

> By the time you've read the explanation, you've moved past it

Not with dense material. Often, I'll read through a chapter quickly, then go through the derivation of something three or four times until I understand it deeply, then re-read the chapter again once or twice to fully grasp it (at which point the derivation is just taking up space and I want to understand the grander scheme). Granted, I'm applying my approach to upper-division to grad-level physics textbooks, but that's the extreme I'm personally hoping to make more approachable for people.

I've actually been thinking about doing the same thing in a side project of my own, and while I think you're somewhat correct, I don't think this is all necessarily attributable to affinities for symmetry.

For instance, if you convey a concept, and then show the derivation of the equation for that - the derivation mostly does not matter in the communication of the concept. Sure it's important to understand this, thus why we always have the derivation, but often it adds cognitive weight that distracts from the more germane understanding of the material (so keen authors will try and be elegant about the complicated things, skipping steps and keeping as much on one page).

It takes up cognitive load, and often a different type of load than the big picture. By collapsing the content, you get back to the more pure "short version" of the material and you can presume to understand or trust the more complicated bits that are hidden away.

> A little copying is better than a little dependency.

I actually disagree with this. Given that we're already working with projects that can have several hundred dependencies - I think the goal ought to be in removing the weight of including the dependency.

sindresorhus says it better than me though https://github.com/sindresorhus/ama/issues/10#issuecomment-1...

I imagine it also depends on whether your place of employment is writing one giant single-repository codebase vs. several modular applications, as the latter clearly affords a package manager while the former eschews the complexity of composing systems.

Or a "Sales ALL THE THINGS" manic ex-CEO, who used massive rounds of funding to hire uncontrollably fast, was replaced by a more product-oriented one.

I did something like this for Neo4j, if you're curious:

image: http://www.gravitypersists.com/assets/neo3.gif

https://github.com/neo4j-contrib/versal-cypher-gadget/blob/m...

This is exactly what happened to Digg. You had people getting paid to get stuff up on Digg's front page. So Digg introduced friends and the ability to see what friends are digging. And they banded together to really ruin the experience for others.

During the time it happened, I did a bit of offhand calculation and found that of all the posts on Digg's front page, most had the same 100 or so "power diggers" in the first 200 likes of the submission. And these 100 users were authors of at least half the submissions on the front page, many of which were clear promotional ads.

Check out notion too (think it's notion.so). They do a great job with this

Re: There cannot be these many quality engineers.

I've seen grads come out of boot camps that are better programmers than people who have been programming for years. They might lack the knowledge, but they've got good sense and hustle, and at the end of the day, I'd take that over a stubborn engineer who looks like they're gonna age into a Dilbert comic.

> The definition of artist, that I could find, is recursive so that's the first problem with that.

Huh?

The comments in here today are a bit out of touch.

>You can't do that with React.

You can. Other than React's rather hefty size, there's nothing stopping you. React is just a view layer, is unopinionated about how you get your data to it, and for rendering to a DOM needs nothing other than a DOM node to render into.

Try it out. You can have 100 different React components slowly eating your legacy app alive. You just gotta be smart about it.

I get the sense Manhattan was established, and then tapped out, hence Brooklyn. Whereas San Francisco is neither of those. San Francisco is the hip place to be (for tech) and Oakland is perceived as the fallback for companies that can't afford to host. Which really surmounts to: I would much rather work in SF than Oakland (I really base my decision on what food & bar options I have around me, though).