Play video games. I am actually serious.
I'm curious, could you please elaborate?
Ask HN: What do top engineers you know do that others don't?
61–70 of 155 posts
Re: Ask HN: What do top engineers you know do that others don't?
#62I 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?"
Re: Ask HN: What do top engineers you know do that others don't?
#63There are many qualities, which have also been listed by others but I found to be extremely common is this:
Be very organized / systematic..
- in their thoughts and how they articulate their points during discussions
- in building their personal knowledge base
- in how they approach problems, be it during solving a customer problem (adding a new feature) or debugging code
Re: Ask HN: What do top engineers you know do that others don't?
#64Earlier quoted context omitted.
> 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.
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 end of the week.
Re: Ask HN: What do top engineers you know do that others don't?
#65Earlier 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…
> if it is worth doing, and it takes less than an hour -- just do it now
Huh... you've never had 10 things that are worth doing that take less than an hour? Or did you just line them up and work 10 hours that day?
Re: Ask HN: What do top engineers you know do that others don't?
#66One thing I havent seen posted which I mention in threads like this one anywhere I am online: humility I don't care how good you are, if your personality is hostile and toxic, you're not making the team productive. If you can't take honest feedback during peer review, or QA or even from the client, then you need to evaluate why. The best engineers I know are humble. They don't freak out when you point out a bug, they…
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?
There are sometimes alternatives:
- Let people learn from mistakes by making sure they can be backed out easily. Do more prototyping, etc.
- Figure out how to make mistakes more visible to everyone, not just you.
These are also helpful when you are the one making the mistake.
Re: Ask HN: What do top engineers you know do that others don't?
#67Abstraction.
Re: Ask HN: What do top engineers you know do that others don't?
#681. 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.
What were they building, a todo app?
Re: Ask HN: What do top engineers you know do that others don't?
#691. 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
1.5. Be willing to rethink the architecture when it turns out problematic. I have seen systems that probably looked good as a diagram before a line of code was written, but had to work around their own architecture with gross hacks.
Architecture is important, but organizations employing "software architects" tend to be bad at software.
Re: Ask HN: What do top engineers you know do that others don't?
#70One thing I havent seen posted which I mention in threads like this one anywhere I am online: humility I don't care how good you are, if your personality is hostile and toxic, you're not making the team productive. If you can't take honest feedback during peer review, or QA or even from the client, then you need to evaluate why. The best engineers I know are humble. They don't freak out when you point out a bug, they…
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 people who literally believe humility to be a weakness, I think a lot of people misunderstand what it means to be humble these days.