
Ask HN: What do top engineers you know do that others don't? - aledalgrande
Just wanted to get into the top 0.01% axons. :&gt;
======
stickfigure
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 comes from having
enough aggregate experience that new information just clicks into place like
jigsaw puzzle pieces. Some of this ability comes from the confidence of having
climbed enough seemingly insurmountable learning curves that this next one is
"just another day at the office".

A sign you're doing this wrong: "I need training!"

#2 Understand The Customer

IMHO, the best engineers are half product managers. You can easily get a 10X
improvement in productivity by building the right features and not building
the wrong ones. Yes, professional product managers are great, but technical
limitations often impact product design. A great engineer knows when to push
back or suggest alternatives. This requires empathy not only for the customer,
but for the product management team. This ability is also tightly coupled with
#1 - you need to quickly come up to speed on the problem domain, whatever that
may be. If you wan't to be a great engineer, don't study algorithms (until you
need an algorithm, of course), study the particular business that you're in.

A sign you're doing this wrong: "Whatever, just tell me how you want it and
I'll make it that way!"

~~~
pmiller2
That’s a rather poor attitude you have toward your colleagues if any of them
dare suggest they need a little training.

~~~
stickfigure
"I need training!" says that _you_ need to figure out how to make _me_ good at
this role. It shifts responsibility onto the organization; if I suck at the
job, it's someone else's fault. A great engineer figures out what to do no
matter how dysfunctional the organization.

It's not that it makes you a _bad_ engineer if you can't thrive in an
imperfect organization. All organizations are varying levels of imperfect.
_Great_ engineers figure out how to be great anyway.

~~~
Scarblac
What if training is simply the most efficient way to get the required
knowledge and it has nothing to do with the level of perfection of the
organisation?

~~~
brianwawok
Maybe, but it means the guy who can teach himself via google is going to get
his similar project done a lot faster.

~~~
Scarblac
I don't think Googling is the fastest way to learn things in general.

But I was mostly thinking of stuff that can't be found on Google, e.g. the
last time I said I needed training was when I was going to do maintenance at
some company, on some internal application that I had never seen. I didn't
know the domain either. But I had heard that a two-day training course for
users existed (also given by internal people). So I said I wanted that
training (developers before me hadn't), people thought that was a good idea
and it turned out to be very helpful.

------
ericb
* 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 problems with more angles of investigation.

* Have more tools in their toolbelt for debugging like adding logging, monkey-patching, swapping parts out, crippling areas to rule things out, binary search of affected code areas.

* Consider the business.

* Consider user-behavior.

* Assume hostile users (security-wise).

* Understand that the UI is not a security layer. Anything you can do with PostMan your backend should handle.

* Whitelist style-security over blacklist style.

* See eventual problems implied by various solutions.

* "The Math."

~~~
huffmsa
> _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 first thing I do with a new product / what I do with the
competitions products.

3\. It is the developers responsibility to mitigate the above cases.

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

~~~
huffmsa
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"

------
giancarlostoro
One 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 look into it and figure it out, then they share with you what they
found vs what you found in order to determine if it is indeed a bug. Then
there's developers that think all their code is perfect and sacred. Nobody
likes working with those kind of developers.

~~~
bob33212
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?

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

~~~
bob33212
It is one thing to understand that you are not perfect and you could learn
something from everyone and to respect your co-workers.

It is another thing to be a legitimate expert and to not voice your opinion to
avoid conflict. I have seen smart people who avoid direct conflict at all
costs. Even if that means working on something you know is a bad idea.

~~~
giancarlostoro
They do it out of fear of conflict probably, or in other cases you're so
burned out you don't want to argue anymore. I've been burned out enough to
where I didn't care anymore I just wanted it to be over with.

------
tetek
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,
reassign JIRA ticket, write two emails and wait for new a graphic)

6\. Top programmers deliver well packed, documented software, keep repository
clean with easy setup steps accessible for everyone.

7\. Top engineers enjoy what they do, and are making the project enjoyable for
everyone, keep high morales and claim responsibility

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

~~~
bpodgursky
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 of sprint planning with less than a quarter day
allocated. You've turned a 20-minute task into a whole day of wasted effort.

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

~~~
bpodgursky
My point is that the overhead of writing up a ticket description becomes a
significant fraction of the total work involved. Write a commit message if you
want it documented.

There's no need for a ticket for small tasks, unless you are being evaluated
on number of tickets closed (which is a separate problem)

~~~
ropman76
Like all things in life it depends on the team and workflow. I have my PM’s
make tickets because many times I am in the middle of a different feature or
bug and don’t want to have to have the mental load of remembering what the
issue was. Secondly I work with very solid PM’s who document the ticket very
well and it saves me time having to reproducing the issue. My team does have a
lot of tickets but we make it work for us and our process flow.

------
kthejoker2
I can't recommend Gary Klein's Sources of Power enough, it is stuffed with
awesome mental models, real life parables, research findings, and one quotable
passage after another on expert decisionmaking.

From the book, things experts do more/better/faster/etc than novices.

* Identify patterns faster and successfully predict future events more often.

* Recognize anomalies - especially negative anomalies i.e. something didn't happen that should - quickly and take appropriate actions.

* Identify leverage points within their architecture to solve new problems and deliver new features faster and with less effort.

* Make finer discriminations of events and data, at a level of detail novices don't consider.

* Understand the tradeoffs and consequences of an option.

* (I like this one) Recognize expertise in others and defer as many decisions as possible to that expertise.

* Their ability to "context switch" when describing a situation to other experts vs novices vs non-particpants.

And one that's not explicitly from the book but is contained in its wisdom:

* Skate where the puck is going, not where it is.

~~~
BoiledCabbage
All great advice - will have to check out the book

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

------
analog31
I call myself a scientist, not an engineer, so I conveniently rule myself out
of contention. But I think the best engineers...

* Multidisciplinary

* Quantitative

* Scientific

* Curious, skeptical

* Thorough

* Willing to abandon a bad idea

* Willing to advocate a junior colleague's good idea

As an add-on question: Which of the properties mentioned in this thread do
your organization actively drive out of people?

------
celim307
Know when the juice is worth the squeeze, whether it be a refactor, a
political fight, or even the job itself. There are not a lot of hills I'll die
on anymore, while when I was younger everything seemed life or death. Now I
got other things to worry about.

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

------
xwowsersx
The best engineers I've worked with always ask the question "what are we
trying to solve here" whenever working on something that involves more than a
trivial time investment. Nine times out of ten, answering that question
clarifies critical issues and avoids going down to a high cost path.

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

------
FunnyLookinHat
* More interested in working methodically than frantically. (If the alarms are firing but they still follow method over shotgun approach.)

* Reads the docs of dependencies rather than blindly googling.

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

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

~~~
ahartmetz
The second part may read as a non-sequitur. The connection is that in
organizations that have separate architect roles, architects are shielded from
their mistakes because they don't work on implementation, and their work
usually isn't questioned.

The worst thing I remember is a web API where some call could fail but didn't
tell you, it just gave you some kind of plausible looking inert data. The call
to query system status was separate, so there was always a time of check /
time of use problem. Also there was a transition period when the original call
did return an error but the system status API didn't yet. Nobody (I hope)
comes up with such a disaster while implementing and testing it.

------
jdsully
The #1 trait is they will dig until they fully understand the problem. When
writing code if the first draft Is not good they will rearchitect until it
makes cohesive sense.

Time spent getting it right the first time saves significantly more time than
dealing with the fallout of not doing the right thing.

~~~
jasonpeacock
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. They understand why their solution works, they
know its limitations, and their solutions are understandable and supportable.
This significantly lowers the total cost over time and is what helps projects
deliver on time with quality.

~~~
ScottFree
> 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 is always tight. Asking why
we're doing this task is rarely received well and the tight time estimate
means there's barely time to make the change work in the first place, let
alone understand why it works.

We're literally training our devs not to be top devs.

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

------
acd
Key to good app performance starts at the data structures used in the app. If
those algorithms have good run / insert time the app will run good. Cache
layers is another key to good app performance.

It is important to test the code base.

The central bank system is making every day people poorer as they print new
debt. They got wage inflation imported from cheap globalized goods wrong. This
part is annoying to know since most do not understand this flow fully. It’s
engineering but financial such. New printed money is flowing to automation and
are deflationary. Understanding other engineering areas other than your own
field and seeing strength/weaknesses in those.

------
franzwong
# Prefer simple or replaceable solution. Avoid unnecessary layer of
abstraction. If you can't explain to others within a few words, you will
forget how it works and it will be unmanageable few months later.

# Prefer un-opinionated framework. This comment is opinionated. From my own
experience, opinionated framework only looks good in the first 5 minutes. You
always need to implement a more difficult solution to solve problems
afterwards.

# Offload your task to your subordinates People can only gain experience by
failure. It won't become a serious problem if you can give guidance and
review. The major benefit is you can spend more time on anything else.

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

~~~
tgsovlerkhgsel
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

~~~
huffmsa
"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

------
m_ke
The most impressive engineers that I've worked with were great at focusing on
the task at hand and finishing them without getting distracted by other issues
that they came across in the process. They didn't optimize things prematurely
or try to come up with new abstractions for things that might come up in the
future. They didn't get into stupid arguments over minor details and were
focused on completing and shipping features.

------
vidanay
Have the ability to distinguish causes from symptoms.

------
ScottFree
They're interested in things other than their primary domain. Some of the best
web developers I know spent some time making video games, programming
microcontrollers, designing telecommunications systems, etc. They take the
experience and knowledge they've gained from those other areas and use them to
make better web applications.

------
AndrewKemendo
Being able to type/write accurately and quickly. Seriously overlooked skill.

Huge in the terminal, huge on the business/product side.

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

------
l3db3tt3r
Tact: They have a broad and inclusive means of understanding/managing
perceptions, and motivations that starts from humility.

Their ability in troubleshooting, problem solving, risk-assessment, is detail
oriented, and seeing the forest for the trees. Being keen-sighted, and
maintaining a field of view, and depth of field.

Informing, teaching, educating: They have a pervasive means of being able to
explain, walk through a problem and/or solution to a verity of audience types.
Some of the best at ELI5.

Understands the Intent, over just the labeled end goal. (As basically what the
US Military defines Intent as.)

Ability to give and take critique (also sharing with Tact above). This always
seems to infer just the negative, criticize/criticism, and the opposite is
often overlooked.

------
chrisbennet
If you’re working at the edge (or beyond) of your competency _that’s normal_.

------
karmakaze
They understand the difference between essential and accidental (I prefer the
term incidental) complexity. This isn't a simple categorization as something
that may seem extraneous, may have a near-term benefit making it somewhat
essential. What's absolutely undesired is that which is added by complex
designs that serve no pragmatic purpose for the user or developer, other than
the satisfaction of an executed grand design. This can sometimes be summed up
as that uncommon form of common sense.

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

------
hprotagonist
* Consider ethics first.

* Happy to ask the uncomfortable questions early.

* Will ask technical questions proactively without caring about maintaining face.

* Has good discipline and communicates well.

------
Rocafella888
The best engineers I worked with were very respectful of my work (UI Design)
and were always happy to share their knowledge. They also ask me questions and
ask me about how we can do things better. They are constantly looking for ways
to improve our products for the customers, in contrast to the developers who
have an attitude of "this'll do".

------
srikz
There 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

------
heurist
Trust your intuition, but don't be a dick. Pick your fights. Software is more
art than science. Learn from those who have gone before you. Also:
[https://www.youtube.com/watch?v=E86phiV8w2M](https://www.youtube.com/watch?v=E86phiV8w2M)

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

------
diehunde
Then don't hesitate when choosing a simple and maybe old-fashioned solution if
it's the right one for the problem. This could go from simple algorithms,
database engines, languages, to architectures and system design.

------
okareaman
If you believe Uncle Bob Martin it's the ability to pair. He recently tweeted
"If you don’t like pairing, don’t pair. But be prepared for the folks who have
developed the pairing skill to fly past you."

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

------
pomnia
Top engineers understand. The hardware, the OS, the protocols.They use that
understanding to solve problems. The comprehension is the differentiator
between top and anyone else.

------
haidrali
listen this talk by DHH you might get an idea

[https://www.youtube.com/watch?v=9LfmrkyP81M&app=desktop](https://www.youtube.com/watch?v=9LfmrkyP81M&app=desktop)

~~~
aledalgrande
I had missed that video, it's great!

------
backspaces
From 50,000 feet: \- Top engineers are able to solve a problem, and are hired
to do so. \- Others are able to solve tasks, and are hired to do so.

------
gargarplex
Are there any books you know that have been recommended to you by top
engineers? Preferring recommendations for books with exercises.

------
awill
They're better owners. They ship, and follow up on bugs until they're proud of
what they shipped.

------
fpalmans
Whenever someone talks about senior engineers, two close friends spring to
mind immediately, one of which is my brother (software development).

Even Though I am convinced that experience (and thus age) contributes to the
segregation between engineers and _senior_ engineers, I also think that it is
a special frame of mind which enables some people to truly become the top of
the crop. Despite my inflated self image and overly optimistic assessment of
my own intelligence, and despite the fact that I am convinced I would have
little trouble convincing an f500 company to give me the title of senior
engineer, I know that I can never attain the 'seniority' my brother and friend
already possess.

Having scanned through the responses, I didn't immediately see the specific
behaviors I have found in top engineers. First of all, I disagree with the
humility trait. I would not call top engineers humble. I would not call them
arrogant either. Top engineers have strong opinions, yet are flexible. They
have their ideas about best practices, yet are 100% comfortable adopting
something else.

Using a stupid example in software development, tabs or spaces. Number of
spaces. Top engineers will have their preference, whichever it is. And they
have thought about it, deeply. Not just from their perspective, but from the
perspective of all engineers, future, present, and past. You may probe as
deeply as you want, they will have looked at it from every possible angle and
will be able to explain to you in every detail why they prefer the one over
the other. And! This is so, so important... And! They will put their
preferences immediately to the side if that's just not how things are done on
this particular project, in this particular team. I wish I had better words to
convey this thought...

Top engineers will work with what they have to get to where they want to go.
And, that's not just the technology, it's also the team. Senior engineers in
your team will automatically make everything better. Sometimes their value is
educating the entire team on best practices, sometimes it is just driving
towards success despite the all of the feces.

Sometimes they might come over as arrogant, because they can speak with
confidence on certain topics. That's another thing that sets top engineers
apart from junior and regular engineers, whenever they speak with confidence,
it is because they are in fact confident. And they are only confident when
they have analyzed an issue sufficiently deeply and from everyone's
perspective that they are comfortable being probed deeply.

When they do not speak with overzealous confidence, it is because they are
still learning about the subject. And they will learn and analyze it deeply if
that is necessary.

A single inconsistency, or a single counter example, or even a single
ambiguity is sufficient for them to reconsider their position completely.

Also, senior engineers will never assume they know anything. They tend to
listen attentively whenever anyone is talking. When someone says something
'stupid' they won't assume that the person is stupid, or said something
stupid, they will assume they did not understand something and ask for
clarification. They tend to not jump to conclusions... If something is
ambiguous, they will identify it and ask for clarification. As a result, they
will often ask for follow-ups in the future... such as: "Thanks for the
information, can I get back to you if I have more questions?" Now that I think
of it, I don't think I have ever seen someone whom I consider to be a top
engineer not keep that door open....

I hope this helps.

------
ilaksh
Maybe some don't subscribe to narcissistic worldviews.

------
hadiz
Play video games. I am actually serious.

~~~
aretaic
I'm curious, could you please elaborate?

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

~~~
someisaac
What games do you recommend?

~~~
hadiz
Unfortunately I don't play games myself. But Anno 1800 is something my very
good colleague plays these days.

------
EsssM7QVMehFPAs
Care about their responsibilities

------
notyourday
De-risk. De-risk. De-risk.

------
sys_64738
They say No.

------
BerislavLopac
Abstraction.

------
rasengan
Code all day and all night.

~~~
AnimalMuppet
For the most part, no. That's what wannabes do, trying to prove they're top
engineers. Most top engineers quit when they're tired, because they know that
if they keep going when mentally tired, they create more problems than they
solve.

There are a _few_ top engineers that get bored when they're not coding, rather
than getting tired after doing it too long. But that's kind of orthogonal to
whether they're a top engineer or not. In over 30 years, I've known _one_
person who was both a top engineer and a "code all day and all night" (or at
least all evening) person.

~~~
rasengan
You just said I was right lol

~~~
AnimalMuppet
Wrong. Doubly wrong, in fact. Wrong in your first post, and wrong now. I did
not say you were right, no matter how you try to spin it.

------
rado
UX don't matter

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

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

