I love all of Edmond Lau's stuff. I accidentally found one of his Google talks while trying to find something for my team when we started on fixing a massively underscaled tech stack. I bought the book read it and shared it with a few other engineers. Super valuable and a lesson I keep trying to teach to our organization is how worth it is to build better tooling.
Effective Engineer – Notes
151–160 of 236 posts
Re: Effective Engineer – Notes
#152Earlier 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…
Wow awesome - I love this comment in particular:
“For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.” CVS!!!
Re: Effective Engineer – Notes
#153Earlier quoted context omitted.
I will try to elaborate without trying to insult anyone. It might be harsh but I am sure the author can handle it. First of all look at this sales copy of the book. https://www.effectiveengineer.com/book It looks like a weight loss e-book product designed to trick ambitious people into impulse buying. It tries to build credibility by name dropping "google", "facebook", "insert big company here" every other paragraph.…
> To sell this content first create and exploit an insecurity in jr.Engineers or fresh job seekers in technology by saying they are not an effective engineer unless they buy this book/package Where are you reading this?
Read the sales copy. I just copied the first few lines of the first paragraph.
"The most effective engineers — the ones who have risen to become distinguished engineers and leaders at their companies — can produce 10 times the impact of other engineers, but they're not working 10 times the hours."
Taken from https://www.effectiveengineer.com/book
Re: Effective Engineer – Notes
#154Earlier quoted context omitted.
> To sell this content first create and exploit an insecurity in jr.Engineers or fresh job seekers in technology by saying they are not an effective engineer unless they buy this book/package Where are you reading this?
Read the sales copy. I just copied the first few lines of the first paragraph. "The most effective engineers — the ones who have risen to become distinguished engineers and leaders at their companies — can produce 10 times the impact of other engineers, but they're not working 10 times the hours." Taken from https://www.effectiveengineer.com/book
That doesn't imply what you claimed at all.
Re: Effective Engineer – Notes
#155On the topic of reading code “written by brilliant engineers”… Code bases can be so large that you might find brilliantly-written things intermixed with things that are not brilliant (and some of those parts may even have been added by the brilliant engineer on an off day). Therefore, it’s risky to just absorb an entire blob as Good without also understanding its history. An interesting side effect of languages/ecosy…
Somewhat unrelated, it would be great to have a Medium-style highlight feature for codebases, where you could onboard developers toward excellent practice by highlighting good code in a repository that consists of various levels of code.
That's actually a really brilliant idea.
We have people sometimes produce the software equivalent of a Picasso, but it so rarely comes to light, and even more rarely codified to guidelines/standard-practice.
Would be very good to have "greatest-hits" of a company's codebase, that could serve as internal knowledge-sharing.
Re: Effective Engineer – Notes
#156"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…
It's definitely a gamble. When the Apple Newton came up I thought pen computing would be the future, threw everything into it and was at the forefront for a few years. But by 2000 or earlier it was pretty clear that I had bet on the wrong horse. I guess my lesson is to jump ship sooner but then you also often hear that perseverance is the key. Tough equation. Now my belief is that you have to be persistent but also need a lot of luck to be at the right place at the right time.
Re: Effective Engineer – Notes
#157I love all of Edmond Lau's stuff. I accidentally found one of his Google talks while trying to find something for my team when we started on fixing a massively underscaled tech stack. I bought the book read it and shared it with a few other engineers. Super valuable and a lesson I keep trying to teach to our organization is how worth it is to build better tooling.
Thank you! It means a lot to me hear its impact on you -- stories from readers are what keep me excited about doing this work.
Re: Effective Engineer – Notes
#158This is effective nonsense. Based on my personal experience, effective engineers I know do not follow a formula like this. This looks like a list of how to be teacher’s pet. A superficial need to be praised by others as effective only takes to “mediocre”.
I will try to elaborate without trying to insult anyone. It might be harsh but I am sure the author can handle it. First of all look at this sales copy of the book. https://www.effectiveengineer.com/book It looks like a weight loss e-book product designed to trick ambitious people into impulse buying. It tries to build credibility by name dropping "google", "facebook", "insert big company here" every other paragraph.…
The perspective I'll offer is that good sales copy is also a skill, just like engineering or any of the other skills you mention.
To be good at sales copy also involves many factors, like interviewing your prospective customers, understanding what language they use to describe their problems, listening for what dreams they actually have, addressing their concerns by establishing credibility, and having a strong desire to help them achieve their goals.
Good sales copy doesn't aim to "trick" people; it aims to show that the product being sold will achieve the prospective customer's goals.
The reason I'm sharing this perspective is that many engineers do look down on marketing and sales copy as something that's automatically "bad." And that automatic association does them a disservice.
They write awesome code or build awesome products and features that could add so much value to the world, but they then just expect anyone to automatically see that value. They don't take the time to understand what their users' problems might be, to share how what they built might solve those problems, and to "market" their solutions. That mismatch of supply and demand ends up being a missed opportunity, and sadly, this happens all the time.
Re: Effective Engineer – Notes
#159It's strange how obsessed software engineers are about methods of working. At a surface level it's just: sit down and write the code. But actually there are thousands of programming languages you can choose from; there are build tools, code standards, testing(to TDD or not to TDD) and mental models you have to wrap your head around before you even can start to consider yourself a decent programmer. It's fascinating, but at the same time I wish it was all simpler. I wonder if there are other occupations in the world that are so much focused on tools, paradigms and methodology as software engineering(investing and trading come in mind. And it's interesting that these notes use so much investing and business lingo).
Re: Effective Engineer – Notes
#160Earlier quoted context omitted.
I really liked this post, and I'm again saddened to see 'take downs' in the comments (not solely addressing you). The author said "prioritize" not to sacrifice profitability in order to learn. By prioritizing learning you may very well increase profitability over the long term. See the recent Google Maps is a moat post.
Challenging an idea is not a "take down".
At the time I posted there were 3 top level comments, all negative on the post.