Effective Engineer – Notes • Hacker News Board

Re: Effective Engineer – Notes

#121

Post by shrimp_emoji » Thu, Dec 28, 2017, 9:41 PM UTC

IronKettle wrote: post #57

edmondlau wrote: post #55

Earlier quoted context omitted.

There's for sure a tricky balance on what fits into a CS education. I remember when I was at MIT (oof, over a decade ago), many project-based CS courses where students were just put into teams and expected teamwork to just happen. Sometimes people got along, and the project would go fine. Other times, not so much. I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair…

> I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work. I guess my point is more that primary school really should've prepared you for this: Group dynamics and how to handle these "group tensions" is more of a basic learning skill that we should be developing very early on. I'm not arguing that this is a useless skill to teach, more that it's far…

Why can't the managers with business backgrounds be the social engineers expertly manipulating the asocial software engineers? I thought that's what they were for. Distribution of labor!

Re: Effective Engineer – Notes

#122

Post by quadcore » Thu, Dec 28, 2017, 9:44 PM UTC

rifung wrote: post #101

quadcore wrote: post #44

Earlier quoted context omitted.

The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas." That is describing what it takes f…

By group of men are you using that like group of people or are you saying it's specific to males?

I meant human

Re: Effective Engineer – Notes

#123

Post by quadcore » Thu, Dec 28, 2017, 9:45 PM UTC

brucephillips wrote: post #82

quadcore wrote: post #44

Earlier quoted context omitted.

The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas." That is describing what it takes f…

What about this is specific to men?

I meant human.

Re: Effective Engineer – Notes

#124

Post by jedrek » Thu, Dec 28, 2017, 9:48 PM UTC

edmondlau wrote: post #116

nostrademons wrote: post #106

"Opportunity cost of working on wrong ideas can set back growth by years." I feel like this is spoken by someone who hasn't seen more than one technology cycle come and go. What I've observed - having started my career back in the Java-will-eat-the-desktop days and then adapted through webapps, big data, mobile, and now AI - is that the people who are best positioned to capitalize on an emerging technology wave are t…

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…

> there are also many others who rode the wrong ones.

My buddy wrote a book on VRML.

Re: Effective Engineer – Notes

#125

Post by edmondlau » Thu, Dec 28, 2017, 10:00 PM UTC

nostrademons wrote: post #114

brucephillips wrote: post #107

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…

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.

Re: Effective Engineer – Notes

#126

Post by edmondlau » Thu, Dec 28, 2017, 10:01 PM UTC

henrik_w wrote: post #117

Really great book! The things that stood out for me: - Optimize for learning - Invest in time-saving tools - Shorten the debugging loop - Don’t sprint in the middle of a marathon - Recovery over prevention - Automate mechanics, not decision making - Make batch processes idempotent We read it in the book club at work a year ago, and I wrote a longer review of it here: https://henrikwarne.com/2017/01/15/book-review-the…

Awesome! Thanks for adding your notes to the discussion.

Re: Effective Engineer – Notes

#127

Post by golemiprague » Thu, Dec 28, 2017, 10:02 PM UTC

Too many rules and things to follow, nobody in their right mind can do that, certainly not successful people. Need a list of maximum five thumb rules to follow, otherwise it is ineffective.

Re: Effective Engineer – Notes

#128

Post by dwaltrip » Thu, Dec 28, 2017, 10:03 PM UTC

IronKettle wrote: post #111

dualogy wrote: post #103

Earlier quoted context omitted.

> You can see the author using the word "leverage" here repeatedly Or maybe devs/engineers are just growing more eloquent than used to be? "Leverage" is truly the most intrinsic essence of everything engineering/developing. Reducing man-days, eliminating manual efforts, extracting infinitely reusable abstractions, code that emits+evals code .. I could go on and on and on --- hard to find a more sufficiently terse umb…

I've heard multiple similar arguments in favor of the word "synergy" or "paradigm". Let me turn the tables: Why is "leverage" acceptable to use but "synergy" engenders scoffing?

The terms themselves don't induce scoffing, it is the specific usage patterns over time, which then becomes associated with the term, devaluing it as a meaningful way to communicate.

Synergy was frequently used in a mindless, vague way by individuals who wished to appear in-the-know. Thus, it was devalued, as people actually in the know did not want to be mistaken for those those who didn't know how to use the term.

This dynamic usually happens with high-level abstractions that have much complexity and nuance, as it is difficult to assess if the term is being used in a meaningful way. "Paradigm" and "synergy" are good examples of such powerful yet tricky concepts prone to misuse and buzzification.

Some philosophers say that the meaning of a word is determined purely by its usage. In this view, a word like synergy loses much of its meaning, as it is commonly used in such a jumbled and unclear manner.

Re: Effective Engineer – Notes

#129

Post by edmondlau » Thu, Dec 28, 2017, 10:04 PM UTC

foopod wrote: post #89

Hang on.. What should I do first? + The most valuable thing? + The riskiest thing? + The simple thing?

They're orthogonal dimensions. My fault that this isn't clearer.

Here's a simpler ordering of operations:

1. Start with the most valuable, highest-leverage thing you want to focus on. 2. Figure out what the riskiest bit of that thing is. Focus on de-risking it. 3. When you're de-risking (or more generally whenever you're just doing that thing), start simple. Beware of adding in unnecessary complexity.

Re: Effective Engineer – Notes

#130

Post by nostrademons » Thu, Dec 28, 2017, 10:05 PM UTC

edmondlau wrote: post #116

nostrademons wrote: post #106

"Opportunity cost of working on wrong ideas can set back growth by years." I feel like this is spoken by someone who hasn't seen more than one technology cycle come and go. What I've observed - having started my career back in the Java-will-eat-the-desktop days and then adapted through webapps, big data, mobile, and now AI - is that the people who are best positioned to capitalize on an emerging technology wave are t…

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 time, I was working on a casual game creation startup with a friend, and I declined, #1 because I felt I couldn't leave my cofounder and #2 because Drew had a startup, I had a startup, and at the time it wasn't clear which of us was actually more likely to be successful.

Before you laugh, consider the environment in Feb 2008 (when this occurred). My cofounder was a consultant at Monitor Group, where he'd been researching the casual gaming space and had run across multiple reports saying it would be a $200M, $1B, etc. space (market research reports never agree on market size, because they're largely bullshit). Kongregate had just raised a Series A from Reid Hoffman, Jeff Bezos, and other luminaries. Max Levchin had just raised $50M for Slide the month before. Zynga had just been founded but Farmville hadn't come out yet. The Web 2.0 bubble was in full swing, AJAX and Javascript were the new hot buzzwords (I had just ported Arc - PG's pet programming language, which HN is written in - to Javascript, which is what caught Drew's interest in the first place), and as you can see from the first comment on DropBox's "Show HN", anything that required installation of software was considered a non-starter. And our product concept let everyone, from teenagers to retirees, build their own games instead of being at the mercy of a studio & professional developers.

My lesson from how things evolved - learned much later, and I'm probably still grasping the implications - was to preference personal experience over industry zeitgeist and prestigious research reports. Drew's personal experience with the problem domain and his 75,000 beta signups were worth a lot more than the famous people and industry market research reports around the problem domain we were solving. And this insight has actually saved me a lot of time & aggrevation chasing fads that people realize are bad ideas 4 years in.

But this is not obvious to someone just starting their career, probably because they don't actually have all that much personal experience to draw upon, and because it takes a certain amount of chutzpah to hear about all these eminent people saying "This will be the next hot thing, you better get in now!" and think to yourself "Actually, sounds like bullshit to me." Personal experience is also inherently limited because you've only got your own and it takes years to build; it turns out that the set of problems you can viably solve is actually quite small.

[1] https://news.ycombinator.com/item?id=8863