hamidpalo · HackerTrans

hamidpalo

no profile record

comments

10 lat temudiscuss

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

11 lat temudiscuss

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.

11 lat temudiscuss

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.

11 lat temudiscuss

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.

11 lat temudiscuss

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

11 lat temudiscuss

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.

11 lat temudiscuss

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.

12 lat temudiscuss

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

12 lat temudiscuss

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.

12 lat temudiscuss

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

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

12 lat temudiscuss

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

12 lat temudiscuss

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

12 lat temudiscuss

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.

12 lat temudiscuss

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.

12 lat temudiscuss

I have a green card, so no visa necessary.

12 lat temudiscuss

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.

12 lat temudiscuss

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

12 lat temudiscuss

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.

12 lat temudiscuss

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.

12 lat temudiscuss

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:"

This may not be sustainable in the long term and if it's not we'll version the API if we have to at that point. So far though, the API has proven itself to be very well designed and adaptable (thanks to @d_lec)