hamidpalo

Relevant quote from Otellini, the former CEO

"The thing you have to remember is that this was before the iPhone was introduced and no one knew what the iPhone would do... At the end of the day, there was a chip that they were interested in that they wanted to pay a certain price for and not a nickel more and that price was below our forecasted cost. I couldn't see it. It wasn't one of these things you can make up on volume. And in hindsight, the forecasted cost was wrong and the volume was 100x what anyone thought."

It was the only moment I heard regret slip into Otellini's voice during the several hours of conversations I had with him. "The lesson I took away from that was, while we like to speak with data around here, so many times in my career I've ended up making decisions with my gut, and I should have followed my gut," he said. "My gut told me to say yes."

Source: http://www.theatlantic.com/technology/archive/2013/05/paul-o...

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.

There actually is containerization for windows that does not do VMs: http://www.microsoft.com/en-us/windows/enterprise/products-a...

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.

Also check out http://www.decalgirl.com/ .

I made this for my mbp: https://twitter.com/hamidp/status/463408033670774785/photo/1

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?

This isn't really material, but more of a "I've copied the colors and misused them."

A huge part of material is animations and behaviors and this doesn't have it. Simplest example is buttons. Go to http://www.google.com/design/ and over over the more button (or anything else that's clickable). You'll see it elevate a bit as if to come up and meet your cursor. Compare that to the buttons from the toolkit.

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.

I'm a Fog Creek employee who is also an immigrant and did not go to an Ivy League school.

I also do a fair bit of interviewing at Fog Creek and we don't really care about which school you went to. We look for smart people who get things done. It's as simple as that.

Dart requires a major redo of everything. Kotlin is a nice evolution with an easy and soft transition.

My biggest hope for Google IO '14 is the announcement of Kotlin as the Android language. Yes, you can already use Kotlin for Android actually but it's not well-supported and the community is small.

The benefit for Google and developers would be clear -- no more Java and Oracle shenanigans. Google already has a solid relationship with JetBrains due to the fact that Android Studio is just IntelliJ CE. They could hammer out details about who owns it, what the future looks like, etc. The transition would be easy since Kotlin already plays well with Java.

JetBrains would have a massive win as well since it would drive sales of IntelliJ like no other.

The biggest issue with this benchmark is the unrealistic data model and the access pattern.

From my admittedly limited knowledge a better benchmark would involve:

- String keys because who uses int keys? It would be important to create a new set of query keys for retrieving values that would contain a mix of newly created strings as well as older ones to account for any hashcode memoization. - Non-primitive values. This would address the boxing overhead someone mentioned and would be much closer to real life usage. - Many more runs. Since there are performance implications of data access patterns due to spatial locality using a larger number of runs this would help even those out.

Another question is, why? The ultimate choice of Java vs C++ won't depend on how fast the standard hash tables are.

Another Trello dev here.

Basically, we have many clients that are consuming the API, including our mobile apps. We never change the published interface so that if you're getting some board fields that will always work. This means that we don't change the types of fields (for example string vs object) or the names of fields since that changes the published service contract.

What we do instead is add more fields. A very good example of this is emoji. We added emoji support a while back and instead of changing the "text" fields to be objects or embedding HTML (gah) into them we added another field called "textData" that has the extra info.

This is copy/pasted from an actual call for getting card actions:

        "textData": {
          "emoji": {
            "daft": "https://trello-emoji.s3.amazonaws.com/4f820a995a03e8e82d134ac4/ae846ca70bf7aa95dd3330b8fd1c70cb/art-daft-punk-steampunk-951631.gif"
          }
        },
        "text": "Custom emoji! :daft:"

Another Trello Android dev here.

We use gradle for building. The actual app is split into two, trello-app and trello-lib. Anything that can be done w/o Android like SQLite caching, API calls, etc., is done in trello-lib which is a plain Java library. It makes the dev cycle much faster since you can write a unit test and run it in a second.

We don't have CI setup yet. For the server we use something custom but will most likely be moving to Buildbot and with that we'll also setup Android CI.

Trello dev here.

The web client (trello.com) has a cookie that has the auth information. The actual code executed for both examples is identical.

Why? You already have it just the way fanout has done it with an extension.

XMPP as a protocol is very throughly thought out and mature with tons of libraries, clients and servers.

Not familiar with Linux kernel development practices, but wouldn't have any semi-capable static analysis tool caught this?

Is there a way to cancel an account w/o an angry blog post and then waiting for a call from PR?

I created a Windows Store account when I was a MSFT employee and it's straight up impossible to cancel it. There are circular links but no actual way to get in touch with someone.

Genymotion is absolutely amazing. Not only is it super fast but also has images with Google Apps, which are almost impossible to get on an emulator.

The downside of using Genymotion is that it's so fast it will hide a lot of performance issues that you will see when running on an actual device. So please, test early and often on actual hardware with extreme amounts of data.

Thanks!

Speed is only one of the tradeoffs. You also lose access to the native interactions, controls, transitions etc.., which makes a lot of the mobile web apps be very alien to the users since they don't really quite fit with the rest of the apps.

I am curious, can anyone point to an well-done mobile web app? The best way to shut up all of us yelling "js is worthless for mobile development" is to point to such apps and explain how they were made.

The product itself looks very interesting, but Samsung is horrible at product launches. I've just bought the new Haswell Macbook Air and am interested in possibly returning it and getting the Ativ Book 9 Plus. I thought that samsung.com would have availability information and more detailed specs, but it's not even mentioned anywhere. In fact, such information isn't available anywhere.

Causation vs correlation.

I have eaten approximately 50% more Chobani since the PRISM story broke, so PRISM has definitely had a huge impact on my consumption on Chobani.