hamidpalo

Mint provides value and it's a trusted brand, so people feel okay about giving them access.

I could potentially trust Mint but anything smaller and not based in the US definitely not.

This definitely is in the right direction, but leaves out a lot of very important things.

I think of a senior developer as someone who is effective. Roughly that means:

* Planning: Ability to take on large, ill-defined problems, define them, break them up, and execute the pieces. A senior developer can take something big and abstract and run with it. They will come up with a few options, discuss them with the team and implement them.

* Execution: When something is planned a senior dev can execute quickly. They make tradeoffs, and they know why. They know where to be dogmatic and where to be pragmatic. They also can code well obviously.

* Communication: Effective developers are great communicators. They probably overcommunicate, gather feedback on non-trivial things, and thoroughly investigate feedback received. People often will say "give me feedback" but what that means is "tell me why my solution is right." For senior developers it's "poke holes in my solution." This can be very evident in pull requests -- junior devs can easily become attached to their solution, become myopic, and be unable to take feedback.

* Leadership: They are aware they're on a team. They view it as a part of their responsibility to mentor others. This can range from pair programming with junior devs, to taking unglorious tasks of writing docs or tests or whatever else needs to be done.

* And finally, they've been burned a lot. They can foresee where the problems will be before a single line of code is written, because earlier in their career they've been burned by a lot of things. An intermediate dev (or perhaps a junior dev) has been burned by poor spaghetti code, and has swung over to nailing everything with the GoF hammer.

Another thing that I have noticed how much of the above applies to senior designers as well.

You're thinking about it wrong. It's not about the complexity of code or any measure thereof, but a simple communication issue.

Telling someone that their code is too complex can very easily be interpreted as a personal affront, especially by more junior developers. It can very easily communicate that they are a shitty developer and don't know what they are doing. When that happens you will get nowhere.

In that situation, the other person feels that they have to defend themselves. They get myopic and unable to see whatever argument you present. They simply will not accept it, or if they do they will resent you for it.

The best way to go about it is to acknowledge their efforts and validate their thinking. Look at why the code is the way it is, and try and understand why it's written that way. Approach the situation not as "I am right, you are wrong" but as "I don't understand this part, can you explain it to me." When they explain and you think it's complex say something like "Ah, yes! That's what I thought it did. It seemed a bit complex so I was wondering if it did anything else. Have you considered x or y?"

The more opportunities you allow to the other person to save face, and the more you value their efforts and work the further you will get.

I will give you $5K cash if you can get me a decent 1 br in the 20s for $1500.

even if you own just the condo fees will run $1500

TCP is usable everywhere. Socket.io builds on top of websockets.

Socket.io is useful when you have legacy web browsers that may not do websockets. Beyond that, it does not bring much over regular websockets.

The really interesting thing is that the Economist has been able to increase their rates while still growing subscriptions. Their digital subscription is as much as print as well. They have been blessed by a wealthy readership that is price-insensitive.

I subscribe and would probably continue to subscribe if they jacked up their rates to $200/yr.

I work at Trello. We actually don't think of Trello as Kanban. Trello at its core is a collaborative list of lists. You can use Trello to implement a Kanban workflow but Trello is not an implementation of Kanban. A lot of people use Trello for things like to organizing their soccer teams where there isn't a hint of Kanban -- each list could be a game and people add themselves to indicate that they want to play.

I work at FC and this is the way it pretty much works, except people rarely go out since our caterers are really good.

I can't tell -- does it support upserts?

We have never rejected anyone based on which school they went to, and conversely have never extended someone an offer based on the school they went to. The schools we actively recruit at all admit less than 30% of applicants because we have found that they tend to do better.

In an interview the school you go to doesn't really matter if you can't code.

A great github account would probably help you more in our interview process than a degree from MIT.

I have a green card, so no visa necessary.