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

131–140 of 155 posts

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

#131

Post by muzani »

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…

Arguably the best engineers are also good designers, and everything else related to the product.

Some of the best ones I know dabble in things like art and music, and do it better than most of the people who are full time specialists. It reminds me sort of like watching sports, where a world class defender can attack better than a second division forward. Maybe they just have really outstanding soft skills.

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

#132

Post by someisaac »

hadiz wrote: post #98
aretaic wrote: post #61

Earlier quoted context omitted.

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.

What games do you recommend?

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

#133

Post by mvind »

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…

> Anything you can do with PostMan your backend should handle

Can someone expand on this and explain this? I'm just starting to build my first API, and it's not clear.

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

#134

Post by aledalgrande »

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…

Could you elaborate on The Math?

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

#135

Post by ericb »

aledalgrande wrote: post #134
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…

Could you elaborate on The Math?

Sure. You can draw conclusions about what will be a good design, or where a problem is occurring, or what you should optimize from doing "the math."

The simplest example is probably using a Big O approach to view how to walk a large data structure. The math works out that certain approaches to walking it are cheap enough in terms of total operations at small scales, and incredibly expensive at large scales. By doing the math, I mean that you can both know when you can get away with sloppy approach, and when you have to be careful to not touch each object more than once.

I didn't just mean big O, though. You might do calculations like "if every user creates these structures in a database, every 5 minutes, we can expect that this table will have n records by time y. If that happens, one, is the size tractable, does it need an index, and do we want to reconsider this approach in favor of a cleverer design that can avoid this query? Things like that.

A recent example for me was researching max zookeeper writes per second and deciding if it can be used for super high volume writes in a system. The conclusion, based on some napkin math of the system needs, and some benchmarking of ZooKeeper was that a different tool needs to fill that spot in the architecture because it was too write-heavy for zookeeper.

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

#136

Post by Lythom »

mvind wrote: post #133
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…

> Anything you can do with PostMan your backend should handle Can someone expand on this and explain this? I'm just starting to build my first API, and it's not clear.

PostMan allows you to send any query to a server. When building an API, you expect some required parameters (ie. "login" being a string) but postman can send or not send the required login parameter and it might or might not be a non-empty string as expected. On the other hand your web form will consistently send the login parameter and check it is a non-empty string before sending to to the server. So it's straightforward to implement the API assuming your required parameter will always be sent but in practice it's not always the case.

The point here is great engineers make sure the API answers correctly even if the query is messed up.

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

#137

Post by jakemal »

muzani wrote: post #131
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…

Arguably the best engineers are also good designers, and everything else related to the product. Some of the best ones I know dabble in things like art and music, and do it better than most of the people who are full time specialists. It reminds me sort of like watching sports, where a world class defender can attack better than a second division forward. Maybe they just have really outstanding soft skills.

> Arguably the best engineers are also good designers

Is there an implied caveat that this applies mostly to Frontend engineers? Or do you think this is something Backend engineers should also be good at? Or I suppose there is third option that great engineers should do both.

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

#138

Post by aledalgrande »

ericb wrote: post #135
aledalgrande wrote: post #134

Earlier quoted context omitted.

Could you elaborate on The Math?

Sure. You can draw conclusions about what will be a good design, or where a problem is occurring, or what you should optimize from doing "the math." The simplest example is probably using a Big O approach to view how to walk a large data structure. The math works out that certain approaches to walking it are cheap enough in terms of total operations at small scales, and incredibly expensive at large scales. By doing…

Interesting, somewhat similar to what I do, but at a deeper level.

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

#139

Post by aledalgrande »

mtnGoat wrote: post #128
viklove wrote: post #68

Earlier quoted context omitted.

What were they building, a todo app?

One of them is the web/system app that powers an Alexa top 10 site. Keep trying. ;) In fact I can think of at least 10 sites in the alexa top 100 that don't have any tests.

Lots of QA people?

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

#140

Post by aledalgrande »

ScottFree wrote: post #123
jasonpeacock wrote: post #91

Earlier quoted context omitted.

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

> So many people stop when it works, without understanding why it works. Most work environments train programmers to act that way. I find this is especially the case at workplaces that (sort of) follow scrum and agile. In most of these places, junior to mid-level programmers are given a task to work on that already has an hours estimate on it. Managers like to optimize efficiency and programmer time, so that estimate…

The reverse side of the coin is an engineer who has complete leeway on what they do and they spend time "redecorating" their code ad nauseam. I think there is a golden mean to be found.
Post reply on HN