gravity13

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).

There's a really interesting book called [A Pattern Language](https://en.wikipedia.org/wiki/A_Pattern_Language) that goes into this.

They attribute tall buildings with insanity, as denizens begin losing scope of their world simply by virtue of not being able to see beyond buildings.

Another thing to note is that "Centers of Culture" are beginning to become more amorphous, as tech gentrification is whitewashing a lot of what gave San Francisco its identity. The Mission is probably the most glaring example of transformation, for better or worse.

Angular: for people who think programming UIs is all about two way data binding.

I've gone back and forth on this with a previous coworker before.

My opinion on it now is: there's two common general ways to use css. One way is as a style class, which is something you'd apply in multiple places around your project (like `.error` setting font colors to red, for example). The other way is to markup specific content so that you can apply specific styles to it - for instance, pixel pushing a header to fit exactly where you think it should in this one instance (perhaps to align an upvote button with a username, or something).

The latter way really seems to just markup dom nodes purely for the sake of identifying them within their structure (I might use BEM or rscss especially for these).

The way I structure my css in projects follows from this - I extract common styles and pepper them throughout my app where needed (but they are never referenced in any js/$ selectors). These are intended to cascade.

And then I will scope my more specific css under a selector (using sass, or cssnext or whatever) to avoid polluting the global scope:

  .some-view {
    .header { ... }
    .note { ... }
    .icon { ... }
 }

In the case of these nested selectors, they are more identifying tags for the content of the node, than they are declarations of a specific style. These are not intended to cascade.

So even though css classes "exist for styling purposes" I think they have two paradigms for use. One for marking up content for a general application of a style and another for marking a node to be given special treatment.

And taking that approach, I argue it's fair to use the same selectors for js as well as css.

Besides, in practice, you're going to realize you're just adding the same class name appended with `js-` everywhere `<div class='error error-box js-error-box'></div>` when you're using that `error-box` really only to mark the node for use.

Though I'd be curious to hear more about why you think this:

>Using CSS classes for both style and data binding would result in a maintenance nightmare, IMO.

uhh, don't know what beach you guys are working from, but I appreciate a strong 'Work hard' vibe, myself.

You want a chilled out work-to-life ratio, there's a number of places out there for you. Hell, some of them are startups. But part of the appeal of working at a startup is that you gotta get shit done.

Work hard and be nice to people. Not a bad thing to see on your wall.

>At this point I don't even think they know who they're targeting they're just trying to do a little bit of everything

They're basically trying to brute force their way by now.

Yeah but the action of maneuvering through the content is fleeting. Rather than squinting and parsing a whole bunch of stuff - you're just filtering as you move down the page. I do the same exact thing on HN. It's just that I can be lazy with the affordance of a large screen.

Also, reddit is different as a consumption medium, rather than news aggregator. With reddit, you consume. With HN, you peruse.

Only in the context of our fleeting industry.