Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What do top engineers you know do that others don't?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 155 posts

Re: Ask HN: What do top engineers you know do that others don't?

#91

Post by jasonpeacock »

jdsully wrote: post #82

The #1 trait is they will dig until they fully understand the problem. When writing code if the first draft Is not good they will rearchitect until it makes cohesive sense. Time spent getting it right the first time saves significantly more time than dealing with the fallout of not doing the right thing.

So many people stop when it works, without understanding why it works. Or not caring how ugly it is.

They have no long-term perspective about the future cost of support - fixing bugs, adding features, or just understanding what was done.

When something changes and their snowflake solution breaks, their first reaction is to blame the external change for causing their poor solution to fail.

Top engineers don't do this. They understand why their solution works, they know its limitations, and their solutions are understandable and supportable. This significantly lowers the total cost over time and is what helps projects deliver on time with quality.

Re: Ask HN: What do top engineers you know do that others don't?

#92

Post by karmakaze »

They understand the difference between essential and accidental (I prefer the term incidental) complexity. This isn't a simple categorization as something that may seem extraneous, may have a near-term benefit making it somewhat essential. What's absolutely undesired is that which is added by complex designs that serve no pragmatic purpose for the user or developer, other than the satisfaction of an executed grand design. This can sometimes be summed up as that uncommon form of common sense.

Re: Ask HN: What do top engineers you know do that others don't?

#93

Post by jki275 »

haecceity wrote: post #87
huffmsa wrote: post #11

Earlier quoted context omitted.

> Assume hostile users (security-wise). Ah, a personal favorite of mine which often makes other people uncomfortable. 1. Users are like Marines, if it can be broken, it will be broken. If it's use is not clearly marked, it will be used incorrectly. If it can be fucked (literally or figuratively), it will be fucked. 2. Users are malicious and are actively trying to backdoor everything you do. Why? Because it's the fir…

Why is that like marines?

There’s an old story about a Marine left alone in a room with two bowling balls for thirty minutes.

At the end of the thirty minutes one bowling ball was in a bunch of little pieces scattered all over the room and the other one was pregnant.

Re: Ask HN: What do top engineers you know do that others don't?

#94

Post by edanm »

stickfigure wrote: post #51

I boil it down to two things: #1 Rapidly Climb Learning Curves The ability to quickly learn enough about new subjects to be useful. New technologies or APIs; new algorithms; mathematical or statistical subjects; and most importantly, your problem domain. Some of this ability is a skill, "knowing how to learn", which covers google-fu, reading comprehension, prioritization, time management, etc. Some of this ability co…

> IMHO, the best engineers are half product managers.

Absolutely agreed. I think this is part of the source of the endless fighting around "10x engineers". In most discussions where people are trying to "prove" their existence, they will usually bring up things that are outside of the scope of a traditional engineer, that involves some kind of outside/customers/business perspective on a problem/solution.

Re: Ask HN: What do top engineers you know do that others don't?

#96

Post by mceachen »

stinos wrote: post #16
codesternews wrote: post #5

Earlier quoted context omitted.

Also, Don't bitch about other's code. You don't know in what constraints they have to write it.

You mean apart from code review?

There's a huge gap between bitching about bad code and coaching someone to refactor code into a good (or at least better) state. A code review is ideally the latter.

Re: Ask HN: What do top engineers you know do that others don't?

#97

Post by tartoran »

sunasra wrote: post #39

1. Research & Finalize architecture design before jumping to code 2. Take code as documentation. This helps to debug things faster 3. Focus more on problem solving than language/tool priorities 4. Listens more and always towards exploring and experimenting new things. This improves breadth knowledge

1 1/2 Do a prototype to get a better picture

Re: Ask HN: What do top engineers you know do that others don't?

#98

Post by hadiz »

aretaic wrote: post #61
hadiz wrote: post #25

Play video games. I am actually serious.

I'm curious, could you please elaborate?

Much like a codebase, some of the brilliant engineers I've met relish the video games that lets them scour around the universe, think about strategy, and get into action. It's like watching someone attempting an Olympic weight-lift move.

Re: Ask HN: What do top engineers you know do that others don't?

#99

Post by haecceity »

masukomi wrote: post #40
bobosha wrote: post #10

Earlier quoted context omitted.

Just "don't bitch" period.

other than avoiding hurting people's feelings. why not? (honestly asking) bad code should be called out. It's reasonable to feel frustrated by bad to terrible decisions that your predecessors made and left you to clean up the consequences of. when a group of people is presented with a shitty situation verbally commiserating with your co-sufferers is a form of group therapy. Yes, it has to be tempered with hope and hu…

All existing code is bad code.

Re: Ask HN: What do top engineers you know do that others don't?

#100

Post by greenyoda »

bpodgursky wrote: post #55
AllegedAlec wrote: post #35

Earlier quoted context omitted.

> My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now. Sure, but that doesn't mean you can't create a ticket for it. It just means that you have tickets which fall outside your sprint planning flow.

My point is that the overhead of writing up a ticket description becomes a significant fraction of the total work involved. Write a commit message if you want it documented. There's no need for a ticket for small tasks, unless you are being evaluated on number of tickets closed (which is a separate problem)

On the other hand, being forced to write something up gives you extra time to think about what you're about to do. I've had many experiences when I was about to commit what I thought was a trivial change to the code, but then suddenly realized that it was going to break something.
Post reply on HN