Being personable: "Can I have a beer with this guy?" is the worse in my opinion. I care about your professional skills and if you're communicating well, but you definitely don't have to be a beer buddy, we might have 15 years difference, a very different background and share very few topics in common over a beer (assuming you even drink beer) but you could still be a great engineer to work with.
Also you don't have to be a guy! The authors recognize that they only interview 5% women in the end...
So overall some good advice, but it has a huge sampling bias. therefore the definition of a "great software engineer" is only valid in certain circumstances. For instance the authors recognize creativity is important, but one could argue some of the most creative engineers that can be found are the people who do another, very creative activity on the side (arts etc). These people would tend to be "9 to 5" because their "6 to 8" are already booked, so even if they appear less "passionate" they can be a huge asset to the team.
I think what the engineer is trying to convey is that a great software engineer thinks about code beyond just the job. I don't think the engineer literally means being a workaholic or the literal 9am-5pm shift, but the engineer has pet projects of his or her own that aren't necessarily related to work, as well as thinks of programming beyond just a paycheck as a personal interest (just as a photographer or any other craftsman would).
I've hired many programmers. The most disappointing ones were ones that only did exactly what their work told them to do. They would never read technical stuff or things like Hacker News on their days off.
The best programmers were the ones that built pet projects for their own needs. I remember one guy would write a script to download new wallpapers for his laptop to cycle through the hours of the day. If I recall correctly, Gmail was an engineer's pet project (when 20% time existed). Some contribute to Stack Overflow; others to open-source and to blog posts.
It's a lot like being a good restaurant cook or musician. You enjoy cooking, not just for the pay, but for how the craft empowers you. A good cook will think about what sides will pair with that steak, while an average cook will probably robotically sling together a dish. A good engineer will show passion.
It's a relief because whatever energy I have left I spend on books, articles, papers. Those things have helped my 9 to 5 in a big way. I bring what I learn to the job.
It doesn't beat hands on practice. I do itch to work on practice projects and I'm hoping when the kids are a little older, I'll have more time and energy for that.
In any case, my kids are my number one. The day my first was born was the day my motivations and my reason for being shifted.
I'd rather just get laid off and collect unemployment for a few months then spend another week ruining my life like that tbh
I’m never working 80 hours a week for someone to make them look good. No one should expect that.
I'm not going to disagree with you re: beer buddies. Really the way I read this is not as a requirement that employees participate in after-work events or in mandatory work friendships, but more of a misguided heuristic for something simpler. The general question is whether the average interaction with you is pleasant or not. If your job requires interacting with others (as it often does in software teams) and you're generally unpleasant or difficult to interact with, then people might avoid interacting with you, and that's a hit on everyone's ability to do their job. On the flipside, someone who's easy to interact with can be a great resource to everyone and also learn from all the people they interact with.
Like you can be a very friendly, chill, and fun person, but if professionally you keep overpromising, not own to your mistakes, pretend you know something when you don't (which could make you look cool outside of work but a pain at work), and other negative traits discussed in the paper, then I would avoid interact because you're not work-pleasant.
To me it's an indicator that the "simpler" is that management (and possibly more, given concomitant hiring practices) has only one way they know how to interact with people: after-class mode from college. In Social FizzBuzz it scores a "Fizz."
On the other hand, if the product's like, "This is approximately something I've wanted to work on literally my entire life," my 9-5 is going to be a steady output stream of concise, quality code, with the languages and frameworks of my employer's choice.
My 6-8 is usually arts. I think engineering is art, it's just art whose language is mathematics. A lot of people disagree, but I purchased a GE NE-42 neon bulb and it's good evidence for my theory.
As an experienced engineering manager this is what I've come across - Some of the engineers who put a 9 to 5 clause, are usually the obstinate engineers, who are not very productive during the hours of 9 to 5, but won't make up by working extra hours. The motto is 'This is all I'll deliver, live with it'. Perhaps, this bias factors in and a generalization emerges 'All 9 to 5 engineers are stubborn, non-creative, non-committed'. This is a huge fallacy because, again based on my limited experience, I have worked with some of the most productive, creative and committed engineers who mostly worked 9-5, but sprang to action in the middle of the night when a high priority production bug had to be looked into.
> Being personable: "Can I have a beer with this guy?" is the worse in my opinion.
Social Drinking is a very western activity. In the East (India, Pakistan, China, etc...) a large majority of people are what are called "teetotalers" - never drink alcohol. Yet they socialize as much, if not more.
The only things that are explicitly common would be a general appreciation for good beer and music. I wouldn't say it's monocultural, although it does tend to have a bias for people without (young) children.
9am-5pm, we do for others, 5pm-9am we do for ourselves. Life obligations or not.
An engineer that is great in a startup ("hacker", "moves fast and breaks things") may be pretty bad in a well-established product that just needs maintenance. And the opposite is also true - a very thoughtful engineer that takes time to create thoughtful, simple & extensible designs may just move too slow when the idea was bad to begin with, and just needed to be invalidated. Also - who is "great", a generalist or a specialist? Depends a lot on what you need...
It is true that some engineers are simply better than others (I'll take Peter Norvig any day over someone who fails at fizzbuzz, regardless of the context/problem that needs being solved) - but it is also equally true that people need the right context to really shine. E.g. I bet Peter Norvig would't have done his best work working for, say, Accenture.
Having said that, and having written it, I still believe the absolute core issue in all technical recruiting is that no-one knows exactly what a great software developer is.
In fact, it is entirely subjective, and simply a matter of opinion.
I put it to you that most recruiting processes aren't worth a bent cent because the initial question cannot be adequately answered "OK, you're looking for 'the best' software developers..... PRECISELY what is that" And if an interviewer can't define precisely what they are looking for then how the heck do they know they found it with sufficient confidence to say "here is the right person for the job".
Most recruiting is simply Voodoo Recruiting, a collection of myths, legends, whispers, misplaced beliefs and pure nonsense. Does this person get the job or not? Shake the bones, look at the tealeaves, throw a rabbit over your shoulder and choose the person who gave the interviewer the best feeling.
Outside of very specific fields I haven't seen anyone come up with specific qualities that identify great workers. And the useful attributes will be specific to a field. For height for basketball players, chances created for soccer players, on-base percentage for baseball, etc.
We don't like to say it, but maybe there's something similar in Software Engineering, like "Can code FizzBuzz in under 5 minutes". At the same time I recognise that coding quizzes are not the latest word on what makes a guy good at coding.
The difference between a great engineer and a mediocre one is the latter will just get distracted, stop working the problem and decide to go for good enough.
The great ones will work the problem, try multiple angles until something doesn't just work but offers the right balance of simplicity, elegance, future proofing and does the job well. You can't get there if every 5 minutes you take a facebook break, or can't grind through technical documentation and make experiments.
In order to establish criteria for universally assessing software development talent, we first have to decide what the perfect engineer looks like, and a lot of companies disagree on what that is.
Trustworthy, loyal, helpful, friendly, courteous, kind, obedient, cheerful, thrifty, brave, clean, and reverent!
If it's been 6 weeks since I've worked on/with x and now I need to work with x again, what's important is that I have a process to reproduce x or build on x. I'd argue this is a better practice than trying to commit everything to memory because human memory is pretty corruptible. I also find this helps with complex problems because you don't have to deal with the devil upfront, you just have to be able to do some high-level fuzzing.
That being said, I think it's important to commit mistakes to memory because those are embarrassing to repeat.
Beyond a basic ability to think logically and enjoying doing so, programming is 99% perspiration aka patience.
The greatest software engineers in small businesses (or personal projects) don't do much development work. Instead they are working as true engineers: making good compromises and solving problems outside of the software which usually leads them into roles that don't have "software" or "engineer" in the title.
The Japanese bullet train was redesigned by observing how nature works: https://www.vox.com/videos/2017/11/9/16628106/biomimicry-des...
"A moment of inspiration from engineer and birdwatcher Eiji Nakatsu changed all that."
Nakatsu did not become a birdwatcher to become a great engineer. So if you want to become a great engineer you follow what you want to do with your free time.
Also, I think people put too much emphasis on the degree of technicality over humanism. A unethical technical genius is not a great software engineer because there is no art in the engineering work. Great architects, chefs, and musicians view their work as arts with thoughts.
(1) Metrics. Metrics tend to destroy the sort of motivation that allows a "task to be done for its own sake", where you are capable of immersing yourself fully in the details of a situation without excluding any "secondary" information (with respect to the metric or super-goal). Mastery of a task comes in part from being familiar with the fullest extent of phenomena within a domain. Pleasure proxies mastery by creating immersion, and is common for a hobby.
A master physicist knows all of physics. A civil engineer knows enough to build bridges. Only one of these people I would trust to make be able to create a new method of building bridges that wasn't incremental, or was based on a novel theoretical insight.
[building bridges might not be the best example because it's an older domain with a lot of time to be refined]
(2) I don't see technicality as being the culprit so much as an overfocus on technology. The "art" comes from either the amount of /craft/ that is put into the use of the technology or the amount of /humanity/, that is, consideration and care for how the users will perceive and receive the technology in an interpersonal manner. You mention three domains where aesthetics count but I don't think a focus on the study of aesthetics is necessary for us to apply the concept of art. These things can be done on engineering's terms.
Just hand this doc over the HR and ask all hiring managers to memorize it.
In a big business, a software engineer is only a cogs that follows specific orders. I remember a blog of a former engineer of Microsoft that talked about it, he said that, in the past, Microsoft was direct, and having a technical meeting with Bill Gates was something usual. However, the company grow and those perks are long gone, now MS has a lot of bureaucracy and level and sub levels of complexity (so many executives and managers).
So many diamond-in-the-rough developers out there that would make good team members, but simply lack prestigious resumes or failed to put skill points in "Job Search" or attribute points in Charisma.
Why would anyone work for you on an engineer salary if they are "great" and have all the CEO skills. They shouldn't.
Selecting for passion is selecting for people, usually young who have no life outside work, don't know their real market value and have easy to abuse personality, will tolerate agile micromanagement etc etc. Women usually have more social skills, enough to know not to become software engineers in bigco.
I always reccomend anyone to learn whatever is below their current interest in the 'stack'. for example if you like to learn java code, learn what assembly code and perhaps even C code is, learn to implement oop systems in C or assembly and you will have a much finer understanding of why certain decisions are made in your platform, and what motivates these decisions oposed to others. for a web developer, learning what your browser is doing is very important, and to understand why certain things work that way in the end, you might want to learn about cpus, network hardware, assembly code and all that jazz. dig deeper and deeper for greater understanding. it might seem like a lot of work, but if you enjoy what you do, it's never to much and never to deep ;D
The discipline of software engineering is no undifferentiated mass: but a cultural kaleidoscope of different textures and colors; and a person who excels in one environment can easily tank in another.
For safety critical embedded code: a meticulous personality is essential; only someone who is a stickler for rules and processes will survive, let alone thrive. In a fast paced and creative environment, this person would be absolutely terrible!
The size of the organization is also a critical in determining who thrives and who does not. In a small team, being an independent self-starter and problem-solver is critical; whereas in a large team, that sort of independence will quickly get you into real trouble.
Different organizations have different values and assign different priorities to the various qualities and attributes of the product and the people who design it.
My advice: be as humble and as flexible as possible; do your best to fit into your team and your organization; but do not be afraid to recognize when you are bending yourself out of your comfort zone: Be prepared to move around a few times to find the organization and the team that fits you, too. There is no shame in this, and you will be happier in the long run.
If you confine your practice to the 9 to 5 job then you are investing fewer hours than somebody who writes open source at night, and will likely be a weaker programmer. If you aren't independently finding new problems to solve then you will be a weaker programmer than somebody who is constantly stepping up their game. If you lack confidence and need frameworks, abstractions, and other bullshit to write a couple lines of code you will be a weaker programmer.
Simple. No magic.
So you like to reinvent everything? Do you reinvent HTML & CSS because they are FRAMEWORKS, one of the foundational frameworks of today's web.
If your job only ask you to fix a bug, there here is how to make yourself valuable AND technically challenging:
* go through the bugs and analyze if you can extract any correlations
* propose better process with other fellow engineers and product owners
* implement changes
For example, someone might be duplicating some code to write tests, how about you write a test harness or adopt some open-source harness? How about work with your fellow engineers to begin start collecting some metrics.
Otherwise, time to look for a new opportunity. The absolute worst kind of programmers are the ones who don't don't take care of their health.
See, I can move goalposts too.
