181–190 of 236 posts
As an example - if you work as an software engineer in finance learn about a few particular financial products at the same level or better than your users, get a masters in finance, applied math, accounting and whatnot. This has the added benefit of staying relevant in the market when you age, as software engineering becomes increasingly commoditized.
Earlier quoted context omitted.
"useless and unlikely to work" -/-> wrong
But without the benefit of hindsight, how do you tell the difference? When I look at some of the giant wins of the last major tech wave, often times the key factors in their success were external events that happened after the formation of the company. AirBnB benefitted massively from the housing bubble & financial crisis (3 years after formation), which created a large class of people who were desperate for income a…
Would saying "success = preparedness * luck" be better?
> 80% of the impact comes from 20% of the work. This simply has no basis in reality nor research and it pains me to see it propagated. The old VLSI design koan is: "The first 90% of the project takes 90% of the schedule. The last 10% of the project also takes 90% of the schedule. 90% of the engineering occurs in the last 10% of the project."
Earlier quoted context omitted.
I like the bottom-line perspective you provide at the end, of "success = preparedness + luck." Preparedness is what we can train ourselves for, and preparedness also has the effect of making you more able to see and take advantage of opportunities that come your way. And to someone who doesn't know how much you've prepared, it appears that you're just luckier.
I used to work for a startup whose founder loved quoting Louis Pasteur: "Fortune favors the well-prepared mind." Then again, that dude was building a medical device based on his PhD research. Most Silicon Valley founders would scoff at that quote.
I'm currently working on commercialising a pharmaceutical manufacturing monitoring device[1], based on the work from someone's PhD.
Earlier quoted context omitted.
It's less about management and technical ability, and more about soft skills and hard skills. A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful: "Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Goog…
>Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. This result seems a bit unsurprising. People who work at Google would already be in the top n-th percent in terms of STEM expertise. If everyone you hire is 'above average' then being a bit better than that has marginal gains and other factors would lead to your s…
Earlier quoted context omitted.
It's less about management and technical ability, and more about soft skills and hard skills. A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful: "Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Goog…
>Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. This result seems a bit unsurprising. People who work at Google would already be in the top n-th percent in terms of STEM expertise. If everyone you hire is 'above average' then being a bit better than that has marginal gains and other factors would lead to your s…
This is totally an incomplete thought, and I'm not trying to be down on this author in particular: It's interesting to see a lot of management thoughts and colloquialisms slowly creep into the "other side" of software development (i.e. the actual developers) and become fairly well-tolerated. We still make fun of phrases like "paradigm" or "synergy", but we're all mostly on-board with phrases like "own " or "growth mi…
It's less about management and technical ability, and more about soft skills and hard skills. A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful: "Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Goog…
Earlier quoted context omitted.
For every person who rode a powerful technology wave, there are also many others who rode the wrong ones. One of my favorite stories from Drew was that when he first started Dropbox, he created a 4-minute demo video showcasing the product that functioned as an MVP for the product. The video drove hundreds of thousands of people to their site and grew their beta mailing list from 5,000 to 75,000 people overnight. On t…
That's true and part of the challenge. It's not always clear what's a powerful technology wave and what's the wrong one. I've actually got a bit more of a personal connection to DropBox - Drew was active on HN before founding it, he posted it here before posting it on Digg [1], and he took me out to lunch right after they'd gotten their Sequoia seed round and asked if he could convince me to be employee #2. At the ti…
When you are working on any idea, there's a temptation to be a visionary about your product's impact. But nothing good comes out of this feel-good bullshit. It's better to focus on solving meaningful problems that exist today, rather than being hopeful that they will become relevant tomorrow.
Hi! I'm Edmond, the author of the book. Happy to answer any questions about my two-year journey in self-publishing the book.
Hi Edmond, is “high leverage” a phrase you use in the book? From the notes, “leverage” is defined as “impact / time invested.” Why did you choose “leverage” to describe this concept? “Leverage” suggests to me that it is grown with the idea of using it to climb a career ladder, but I’d like to hear your thoughts on this, as I have read just these notes and not the book yet.
> 80% of the impact comes from 20% of the work. This simply has no basis in reality nor research and it pains me to see it propagated. The old VLSI design koan is: "The first 90% of the project takes 90% of the schedule. The last 10% of the project also takes 90% of the schedule. 90% of the engineering occurs in the last 10% of the project."