Live data from Hacker News

Effective Engineer – Notes

gist.github.com

201–210 of 236 posts

Re: Effective Engineer – Notes

#201

I work on a team in which a few people adopted the strategy of doing 20% of the work for 80% of the impact. That leaves the rest of us doing the remaining 80%. If the people doing most of the work are not getting the credit for it, how is it going to play out in the long run?

Why does that 80% need to be done?

Re: Effective Engineer – Notes

#202
post #199

Earlier quoted context omitted.

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

The Apple Newton was clearly what happened when Jobs had the idea for the iPad 20 years before the technology could actually deliver a usable experience for it. And even then you can see sketches of it all the way back to the 60s: https://books.google.co.uk/books?id=CEc1OOGmA5IC&pg=PA91&lpg...

Jobs had nothing to do with the Newton and killed it when he came back to Apple.

Re: Effective Engineer – Notes

#203

Earlier quoted context omitted.

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.

You may be right. Only the people who bought that “tactical toolkit” from that sales page are effective engineers. Everyone else may just not be up to it. We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks. The whole premise of the content appears to be a “get rich quick” scheme. The most vulnerable pe…

Wow. The author really pissed your cornflakes, didn’t he? I’ve been an engineer for 30 years, this is the first i’ve heard of author or his book, but i have to say i agree with much of his advice.

When you have a choice, you should always choose high leverage. You should work to limit distractions and get more focus time. This is all great advice.

Re: Effective Engineer – Notes

#204

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

It's strange how obsessed software engineers are about methods of working.

So you are surprised that a bunch of people whose work is to create mental models and automate them are obsessed with creating mental models of their own work and automate it?

It's fascinating, but at the same time I wish it was all simpler.

Actually it is, IMHO. A lot of the parafernalia around the job is useless obsession indeed. We're just that way for good or bad.

Re: Effective Engineer – Notes

#205

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

Business process improvement is similar.

Re: Effective Engineer – Notes

#206
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.…

You're literally criticizing the book based on it's website cover? To put it mildly, that's not what effective anythings do.

Re: Effective Engineer – Notes

#207

Earlier quoted context omitted.

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.

You may be right. Only the people who bought that “tactical toolkit” from that sales page are effective engineers. Everyone else may just not be up to it. We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks. The whole premise of the content appears to be a “get rich quick” scheme. The most vulnerable pe…

> We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks.

You haven't even read the notes, if you're conflating these two ideas.

Re: Effective Engineer – Notes

#208

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

This seems like something worth mentioning on the gist.

Re: Effective Engineer – Notes

#209

Earlier quoted context omitted.

You may be right. Only the people who bought that “tactical toolkit” from that sales page are effective engineers. Everyone else may just not be up to it. We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks. The whole premise of the content appears to be a “get rich quick” scheme. The most vulnerable pe…

Wow. The author really pissed your cornflakes, didn’t he? I’ve been an engineer for 30 years, this is the first i’ve heard of author or his book, but i have to say i agree with much of his advice. When you have a choice, you should always choose high leverage. You should work to limit distractions and get more focus time. This is all great advice.

I see what you are trying to do here. But please go read the sales copy of the book. Everything in that copy is a symptom of "moral decay" in the tech valley.

Which one did you purchase? "The master package" to become effective engineer.

It makes bold claims like it will make you 10X engineer and it some how guides you to figure out which technologies you need to work that will succeed in the future and keep reading, you will find more gems in there. The whole content is preying on the vulnerable.

We have had great advice in the tech industry so far like, "put customer first" or "think lean" or build beautiful products etc but this is the first classic that says to put yourself first and work on things that elevate you at the expense of the team and company and more narcissistic gems bundled with gossip from engineering teams with famous name companies.

I seriously doubt anyone who is looked upon for guidance by others would suggest something like this.

adios while I read the "Tactial Toolkit" to become effective engineer.

Re: Effective Engineer – Notes

#210
I pwrsonally found that Refactoring often and unit testing don't play nicely together. A huge refactoring lead to a lot of rewriting of unit tests since they weren't compiling anymore. I was able to reuse test logic though.
Post reply on HN