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

51–60 of 155 posts

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

#51

Post by stickfigure »

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 comes from having enough aggregate experience that new information just clicks into place like jigsaw puzzle pieces. Some of this ability comes from the confidence of having climbed enough seemingly insurmountable learning curves that this next one is "just another day at the office".

A sign you're doing this wrong: "I need training!"

#2 Understand The Customer

IMHO, the best engineers are half product managers. You can easily get a 10X improvement in productivity by building the right features and not building the wrong ones. Yes, professional product managers are great, but technical limitations often impact product design. A great engineer knows when to push back or suggest alternatives. This requires empathy not only for the customer, but for the product management team. This ability is also tightly coupled with #1 - you need to quickly come up to speed on the problem domain, whatever that may be. If you wan't to be a great engineer, don't study algorithms (until you need an algorithm, of course), study the particular business that you're in.

A sign you're doing this wrong: "Whatever, just tell me how you want it and I'll make it that way!"

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

#53

Post by ailideex »

tetek wrote: post #3

1. Don't bitch about legacy software 2. Are willing to help with getting proper requirements 3. Don't need a JIRA task for everything 4. Don't say they are done if something is untestable 5. Are willing to do stuff other than their skill (eg. one of the graphics required for the project is too big, top engineer opens up gimp, resizes and continue. Bad engineer will report to manager that design team did shitty job, r…

> 3. Don't need a JIRA task for everything

Is this common outside of organizations where people are told to not work on anything that is not a JIRA task? And do people that do that not come mostly from such organizations?

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

#54

Post by tartoran »

giancarlostoro wrote: post #27

One thing I havent seen posted which I mention in threads like this one anywhere I am online: humility I don't care how good you are, if your personality is hostile and toxic, you're not making the team productive. If you can't take honest feedback during peer review, or QA or even from the client, then you need to evaluate why. The best engineers I know are humble. They don't freak out when you point out a bug, they…

Humility is underrated. I know a few devs that are not only a pleasure but inspiring to work with. Unfortunately few appreciate this virtue, schmoozers always get ahead.

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

#55

Post by bpodgursky »

AllegedAlec wrote: post #35
bpodgursky wrote: post #26

Earlier quoted context omitted.

My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now. Organize your team so engineers feel free to knock off quick tasks at their discretion. If you try for an hour and it's still not done -- make a ticket. There's nothing more annoying than seeing the same trivial task get shuffled around 4 sprint planning meetings, taking mental overhead from 8 people. And nothing comes out…

> 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)

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

#56

Post by bob33212 »

giancarlostoro wrote: post #27

One thing I havent seen posted which I mention in threads like this one anywhere I am online: humility I don't care how good you are, if your personality is hostile and toxic, you're not making the team productive. If you can't take honest feedback during peer review, or QA or even from the client, then you need to evaluate why. The best engineers I know are humble. They don't freak out when you point out a bug, they…

There is a grey area where a non-technical manager wants to make a decision without understanding the long term impacts of that decision. Is the good engineer submissive here and go with the flow or does the good engineer put their foot down and suggest that that is not a good idea?

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

#58

Post by lawn »

AllegedAlec wrote: post #35
bpodgursky wrote: post #26

Earlier quoted context omitted.

My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now. Organize your team so engineers feel free to knock off quick tasks at their discretion. If you try for an hour and it's still not done -- make a ticket. There's nothing more annoying than seeing the same trivial task get shuffled around 4 sprint planning meetings, taking mental overhead from 8 people. And nothing comes out…

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

Some of us are lucky enough to not have a sprint planning flow, and we can have a lot of leeway how we plan our time, which doesn't require tickets.

You can create tickets for every small thing, but it might not be very efficient.

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

#59

Post by xwowsersx »

The best engineers I've worked with always ask the question "what are we trying to solve here" whenever working on something that involves more than a trivial time investment. Nine times out of ten, answering that question clarifies critical issues and avoids going down to a high cost path.

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

#60

Post by kthejoker2 »

I can't recommend Gary Klein's Sources of Power enough, it is stuffed with awesome mental models, real life parables, research findings, and one quotable passage after another on expert decisionmaking.

From the book, things experts do more/better/faster/etc than novices.

* Identify patterns faster and successfully predict future events more often.

* Recognize anomalies - especially negative anomalies i.e. something didn't happen that should - quickly and take appropriate actions.

* Identify leverage points within their architecture to solve new problems and deliver new features faster and with less effort.

* Make finer discriminations of events and data, at a level of detail novices don't consider.

* Understand the tradeoffs and consequences of an option.

* (I like this one) Recognize expertise in others and defer as many decisions as possible to that expertise.

* Their ability to "context switch" when describing a situation to other experts vs novices vs non-particpants.

And one that's not explicitly from the book but is contained in its wisdom:

* Skate where the puck is going, not where it is.

Post reply on HN