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

81–90 of 155 posts

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

#81

Post by AnimalMuppet »

rasengan wrote: post #52

Code all day and all night.

For the most part, no. That's what wannabes do, trying to prove they're top engineers. Most top engineers quit when they're tired, because they know that if they keep going when mentally tired, they create more problems than they solve.

There are a few top engineers that get bored when they're not coding, rather than getting tired after doing it too long. But that's kind of orthogonal to whether they're a top engineer or not. In over 30 years, I've known one person who was both a top engineer and a "code all day and all night" (or at least all evening) person.

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

#82

Post by jdsully »

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.

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

#83

Post by l3db3tt3r »

Tact: They have a broad and inclusive means of understanding/managing perceptions, and motivations that starts from humility.

Their ability in troubleshooting, problem solving, risk-assessment, is detail oriented, and seeing the forest for the trees. Being keen-sighted, and maintaining a field of view, and depth of field.

Informing, teaching, educating: They have a pervasive means of being able to explain, walk through a problem and/or solution to a verity of audience types. Some of the best at ELI5.

Understands the Intent, over just the labeled end goal. (As basically what the US Military defines Intent as.)

Ability to give and take critique (also sharing with Tact above). This always seems to infer just the negative, criticize/criticism, and the opposite is often overlooked.

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

#85

Post by mindtricks »

drewcoo wrote: post #72
mindtricks wrote: post #62

Earlier quoted context omitted.

As a long-time product manager, I completely agree that customer empathy and domain knowledge go a long way, especially around tactical needs. The easiest way to start is to just ask yourself, "If I were using this product/service/feature, would I want it to work this way?"

That comes right before getting customer data or asking them, right? It's easy to make up just-so stories and completely disconnect from customers' reality if you're stuck in your own head.

Every PM needs to do that, but working directly with a customer isn't always an option for the engineer. Point above is just to point out that thinking about whether you'd use or pay for the service yourself goes a long way in changing a mindset and building empathy. It's not a recommendation to make up stories.

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

#86

Post by bob33212 »

giancarlostoro wrote: post #70
bob33212 wrote: post #56

Earlier quoted context omitted.

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?

No, of course not. Humility doesn't mean you become completely submissive. There's a fine difference between a great engineer blurting out "THAT WILL NEVER WORK, WHAT ARE YOU EVEN SAYING!?" and... "Hey, Jim, I think that's a reasonable proposal, however, I have some concerns ..." which do you think sounds like the professional / good engineer, and which one sounds like a Junior whose ahead of themselves? I've met peo…

It is one thing to understand that you are not perfect and you could learn something from everyone and to respect your co-workers.

It is another thing to be a legitimate expert and to not voice your opinion to avoid conflict. I have seen smart people who avoid direct conflict at all costs. Even if that means working on something you know is a bad idea.

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

#87

Post by haecceity »

huffmsa wrote: post #11
ericb wrote: post #8

* Better googling. Time-restricted, url restricted, site restricted searches. Search with the variant parts of error messages removed. * Read the source of upstream dependencies. Fix or fork them if needed. * They're better at finding forks with solutions and gleaning hints from semi-related issues. * Formulate more creative hypothesis when obvious lines of investigation run out. The best don't give up. * Dig in to p…

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

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

#88

Post by haecceity »

AllegedAlec wrote: post #19
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 Genuinely asking: how so? Tickets are not just some bit of bureaucracy, they are also a living log of what has been done and why that thing was done.

I have my own todo list independent of the bug tracker.

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

#89

Post by lawn »

viklove wrote: post #64
lawn wrote: post #58

Earlier quoted context omitted.

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.

You can also just create 1 ticket with a bunch of small things. The devs on my team are encouraged to move tickets around and plan their time however they want, but JIRA allows our product, design, dev, and qa teams to coordinate without being in the same room every day. It's just another form of async communication that helps us make sure we're shipping everything we promised, and fixing all critical bugs before the…

Yes, it's basically the same for us as well. And we do group together smaller things into one ticket often.

For us tickets are most important to track what gets included in releases and patches, and to tell QA to test our branches (and we almost always require QA to test our branches before they're merged).

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

#90

Post by giancarlostoro »

bob33212 wrote: post #86
giancarlostoro wrote: post #70

Earlier quoted context omitted.

No, of course not. Humility doesn't mean you become completely submissive. There's a fine difference between a great engineer blurting out "THAT WILL NEVER WORK, WHAT ARE YOU EVEN SAYING!?" and... "Hey, Jim, I think that's a reasonable proposal, however, I have some concerns ..." which do you think sounds like the professional / good engineer, and which one sounds like a Junior whose ahead of themselves? I've met peo…

It is one thing to understand that you are not perfect and you could learn something from everyone and to respect your co-workers. It is another thing to be a legitimate expert and to not voice your opinion to avoid conflict. I have seen smart people who avoid direct conflict at all costs. Even if that means working on something you know is a bad idea.

They do it out of fear of conflict probably, or in other cases you're so burned out you don't want to argue anymore. I've been burned out enough to where I didn't care anymore I just wanted it to be over with.
Post reply on HN