Ask HN: What do top engineers you know do that others don't? • Hacker News Board

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

#31

Post by matthewmacleod » Tue, Dec 24, 2019, 3:23 PM UTC

otagekki wrote: post #22

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…

> 1. Don't bitch about legacy software Bitching about legacy software is often necessary if you want something to change: pay off technical debt, additional time, migrate third party software to a newer version.

That’s a different thing, though. Proposals for change which are backed up by examination of the costs and benefits are welcome. Pointless complaints like “why are we still using PHP for this system, we should retire it” without any analysis of why is much more like “bitching”, is annoying, and something that I’ve noticed almost all less experienced developers do.

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

#32

Post by b0sk » Tue, Dec 24, 2019, 3:23 PM UTC

They have a great mental model of the inner workings on the product. Even for a part of a code they haven't seen in a long time. When you debug code with such a person, you notice that they seamlessly translate the piece of code on the screen to the mental model and back (it probably takes hours for Jr engineers to piece those together). Neo deciphering the matrix is a good analogy.

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

#33

Post by rv-de » Tue, Dec 24, 2019, 3:25 PM UTC

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.

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

#34

Post by dividedbyzero » Tue, Dec 24, 2019, 3:26 PM UTC

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…

I seem to be fortunate to work with almost exclusively top engineers, by your list. Interesting perspective!

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

#35

Post by AllegedAlec » Tue, Dec 24, 2019, 3:29 PM UTC

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…

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

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

#36

Post by tgsovlerkhgsel » Tue, Dec 24, 2019, 3:29 PM UTC

huffmsa wrote: 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

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

#37

Post by masukomi » Tue, Dec 24, 2019, 3:29 PM UTC

otagekki wrote: post #22

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…

> 1. Don't bitch about legacy software Bitching about legacy software is often necessary if you want something to change: pay off technical debt, additional time, migrate third party software to a newer version.

Agreed. I've spent most of my career cleaning up other people's messes. Bitching about legacy software a) makes it clear that the prior practices are not acceptable and can't continue (no tests, ignoring edge cases, ignoring users, all the standard stuff that makes up legacy code) b) helps keep you sane.

The difference, which I hope the original author was alluding to, is that experienced dev accepts that legacy software is a part of life that has to be accepted, and dealt with, and that fixing it / keeping it on life support is frequently the right answer. Whereas junior's see it and run screaming or say there's no hope and it needs to be rewritten from scratch even though they don't really know the details of what "correct" behavior is.

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

#38

Post by chance-name » Tue, Dec 24, 2019, 3:32 PM UTC

The best engineers I know do their best to discover the core problem. They ask why a problem should be solved. They also challenge “known” assumptions and do their best to discover the real constraints to a problem.

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

#39

Post by sunasra » Tue, Dec 24, 2019, 3:33 PM UTC

1. Research & Finalize architecture design before jumping to code

2. Take code as documentation. This helps to debug things faster

3. Focus more on problem solving than language/tool priorities

4. Listens more and always towards exploring and experimenting new things. This improves breadth knowledge

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

#40

Post by masukomi » Tue, Dec 24, 2019, 3:34 PM UTC

bobosha wrote: post #10

codesternews wrote: post #5

Earlier quoted context omitted.

Also, Don't bitch about other's code. You don't know in what constraints they have to write it.

Just "don't bitch" period.

other than avoiding hurting people's feelings. why not? (honestly asking)

bad code should be called out. It's reasonable to feel frustrated by bad to terrible decisions that your predecessors made and left you to clean up the consequences of.

when a group of people is presented with a shitty situation verbally commiserating with your co-sufferers is a form of group therapy. Yes, it has to be tempered with hope and humor, but... bitching is good. Cynicism actually helps ward off burnout (barely, but it's one thing that contributes to warding it off).