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

71–80 of 155 posts

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

#71

Post by huffmsa »

kingbirdy wrote: post #50
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…

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

Ah yes. Should be revised to "unless it is clearly marked, it will rarely be used as intended. Even when clearly marked, users will misuse in ways you couldn't imagine"

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

#72

Post by drewcoo »

mindtricks wrote: post #62
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…

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.

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

#73

Post by tracer4201 »

bpodgursky wrote: post #26
AllegedAlec wrote: post #19

Earlier quoted context omitted.

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

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…

Just do it now maybe works on small projects, but large projects that span multiple teams and stakeholders typically have enough little tasks to complete that “just do it” might be referring to 1 of 50 different things.

You need some way to prioritize and work against those priorities, typically measuring impact or some variation of ROI.

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

#74

Post by icebraining »

mtnGoat wrote: post #45
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…

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.

I think you're thinking too narrowly about what "testable" means. Everything can be made testable.

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

#76

Post by honkycat »

1. NEVER practice Coincidence driven development.

If you get lost, and no longer know why something is not working, do not just keep fiddling and changing things.

Simplify the problem. Disable all confounding variables and observe your changes. Open up a repl and try to reproduce the issue in your repl.

Read the source code of your dependencies. I have seen this a lot: People fiddle with dependencies trying to get them to work. Crack the code open and read it.

2. Choose your battles. Not every hill can be the one you die on. You cannot control every part of a code-base when you are working on a team. People are going to move your cheese and you need to learn to not let that affect you.

3. Learn to lose. Similar to the last one. Treat technical discussions as discussions, not a competition. Use neutral language that frames your ideas as NOT your ideas, but just other options. Keep an open mind and let the best idea win.

4. Write tests. There are outliers here, but the majority of talented engineers I have worked with are all on the same page: If you don't have tests, you cannot safely refactor your code[0]. If you cannot safely refactor your code, you cannot improve your codebase. If you cannot improve your codebase, it turns to mush.

5. Simplicity is golden. Keep your projects simple, doing the bare minimum of what you need, and do not refer to your crystal ball for what you might need later. Single responsibility principle. Keep your Modules and your functions simple and small, and combine them to create more complicated behaviour.

6. Quit shitty jobs. If you are not learning at a job, or they are abusing you, you need to get the hell out of there. Burn-out is real. Burn out on something cool that helps YOU, not pointless toil for some corporate overlord.

0: Martin Fowler's Refactoring 2nd edition

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

#78

Post by davidivadavid »

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.

Customer data and asking customers isn't fool proof either. That's why the best shortcut to being a great engineer/product manager/designer is working on stuff you would use yourself to solve a problem you really have. That way you limit misinterpretations.

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

#79

Post by logandavis »

Great thread, great answers!

Follow-on question: OK, so how does your company's interview process test for these traits?

It's mind-boggling to me how many organizations understand that the most important traits of a great engineer are "soft skills" (how many answers here are about really understanding big-O complexity or pointer math?)... and yet are content to interview candidates with whiteboard algorithms problems.

Interview for greatness, not for having-brushed-up-on-Djikstra's-ness!

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

#80

Post by AnimalMuppet »

rv-de wrote: post #33

overengineer and prematurely optimize everything because a pragmatic approach to software development is too boring and you couldn't use a lot of fancy tools and features otherwise. tongue in cheek, yes, but with a grain of truth, I'd argue.

I'd argue that those who do so are "top engineers", but not actually top engineers. They have the reputation (especially in their own minds), but they're not the real deal.
Post reply on HN