Live data from Hacker News

Effective Engineer – Notes

gist.github.com

161–170 of 236 posts

Re: Effective Engineer – Notes

#161

It'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,…

If it was simpler, it wont command such wages, and would be automated out sooner.

Humans' current advantage is the ability to tackle complexity and uncertainty.

Re: Effective Engineer – Notes

#162
post #29

On the "read code written by brilliant engineers" point, as someone just starting to learn Python, where would I find some?

Peter Norvig has lots of expository code that embodies lots of good design. I find I like to learn the flavor of different kinds of code, but practical codebases have so much stuff going on that it's not easy to find the distinctive part. It would be great to see more people do expository versions of familiar software and libraries.

+1 Here's a link to Norvig's (self annotated!) github repo: https://github.com/norvig/pytudes

Re: Effective Engineer – Notes

#163
post #73

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

Like this?

https://github.com/github/hub/blob/master/github/crash_repor...

Or do you mean with comments in the margin?

Re: Effective Engineer – Notes

#164

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

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 desir…

Hope what ever you did works for you. I am probably not your prospective customer. I found the whole sales copy very deceptive. You are selling "Tactical Toolkit" to be effective engineer.

I understand your perspective about engineers undervaluing marketing and sales skills, but I think it's an example of short term thinking. Credibility is a currency, internet never forgets and I would never build credibility like this because I do not know how this will limit my future possibilities.

Re: Effective Engineer – Notes

#165

Earlier quoted context omitted.

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, that is an amazing story. Thanks for sharing. It really hammers home how hard it is to disentangle good & bad advice and how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.

>It really hammers home how hard it is to disentangle good & bad advice and

> how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.

Re: Effective Engineer – Notes

#166

Earlier quoted context omitted.

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.

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.

Re: Effective Engineer – Notes

#167
post #4

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

I'd say you don't seem to understand what makes an effective engineer. You ignore the benefits of introspection and discount the ability to improve yourself. Good habits can be cultivated. A career can be cultivated, any good engineer can target better jobs to move up step by step where they want to be.

The author is just giving you advice for doing those things.

Re: Effective Engineer – Notes

#168

Lot of very selfish anti team ideas here. Shipping requires doing grunt work. That’s the person I want to work with and that’s the person I think is valuable.

Name the things in the list that are anti-team or selfish, or avoid grunt-work. Being more productive would seem to benefit your team, no?

Re: Effective Engineer – Notes

#169
post #76

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

http://www.crn.com/news/security/18821726/microsofts-ceo-80-...

"About 20 percent of the bugs causes 80 percent of all errors, and--this is stunning to me--1 percent of bugs caused half of all errors."

Re: Effective Engineer – Notes

#170
(From the gist's account owner)

FWIW: I didn't produce the content present on this gist.

I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.

Post reply on HN