#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!"
* 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."
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.
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
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.
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
* 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?
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.
* Reads the docs of dependencies rather than blindly googling.
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
Time spent getting it right the first time saves significantly more time than dealing with the fallout of not doing the right thing.
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.
# 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.
Or otherwise put, knowing when to do things by the book, and when it's okay not to.
Huge in the terminal, huge on the business/product side.
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.
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!
* Happy to ask the uncomfortable questions early.
* Will ask technical questions proactively without caring about maintaining face.
* Has good discipline and communicates well.
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
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.
tongue in cheek, yes, but with a grain of truth, I'd argue.