Live data from Hacker News

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

news.ycombinator.com

41–50 of 155 posts

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

#41
post #12

1. Knowing when it's okay to implement a "good enough" solution versus taking the time to implement the "academically correct" solution. Or otherwise put, knowing when to do things by the book, and when it's okay not to.

I'd go further: - knowing how to make the solution "the right level of good", as opposed to "academically perfect" or "unmaintainable hack". - being able to design and implement a "good enough" solution that is still reasonably maintainable (if needed) much better and/or faster than others

"Correct enough" is the phrase I usually use here.

Knowing where on the scale to set that mark requires being able to bridge speed of implementation, execution, maintainable, upgradability and the overarching business goals you're building for.

So really a broad range of understanding that only "excellent" senior developers will possess

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

#43
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…

> Bad engineer will report to manager that design team did shitty job, reassign JIRA ticket, write two emails and wait for new a graphic

I hate this sentence so much. "Bad engineer"? Being a good or bad engineer doesn't come down to a single thing, ever.

A lot of organisations, like mine, which is a well known public entity, REQUIRE this sort of operational procedure.

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

#44
A few I don't see mentioned:

They are strategically lazy, putting a lot of thought into how to simplify at all levels. Great engineers loathe complexity and indulge in it reluctantly. Solutions should never be more complex than what the problem domain demands.

A corollary to above: they use language features and constructs to solve problems, not to show off how smart they are by constructing the most "clever" bit of language gymnastics with which to waste the time of those who have to maintain the code later (including the author!).

They know assembly language and the basics of CPU architecture regardless of what language they use so they understand what is actually happening. They also have a grasp of other aspects of the system like networking and storage even if they do not do much with those directly.

They know the history of computers and computing and how things have been done at various points in the past. This helps them spot fads and rediscoveries of old things that have been tried already as well as generally deepening understanding.

They are skeptical of fads and don't instantly adopt whatever thing is trendy unless it's a genuine improvement.

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

#45
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…

Many things are not testable. Not sure I'd use that as a reason to judge someone down. In fact all the most productive teams I've worked on or with, don't have anywhere near full test coverage. The best had none in fact.

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

#46
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…

> 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.) This kind of thing can be dangerous in the wrong sort of organization, be careful about stepping on other people's toes. What you call Bad engineering is adaptive behavior in an organization like this. Bad organizations incentivize bad behavior and punish go…

I read this like "good engineers will unblock themselves with interdisciplinary action". I think the follow up on that example involves getting a resized asset from the UI team, but that should not hold up development and testing.

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

#47
A lot of good points were made. I'll add one I think was missed (and I'll avoid the title "engineer"): A top developer knows that the stack does not matter to the user. The stack provides interest or a familiar or economical grounds to said developer but the user - they couldn't care less.

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

#49
One thing I haven't seen mentioned yet that I think to engineers do is read the side code of the third party libraries and frameworks that they use. Usually when they are trying to figure why something is broken, but sometimes just when they are learning how to use it.

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

#50
post #11
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…

> If it's use is not clearly marked, it will be used incorrectly.

In my experience clear markings aren't enough to stop it being used incorrectly.

Post reply on HN