What Makes a Great Software Engineer? [pdf]
faculty.washington.edu
faculty.washington.edu
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.
The other thing I've noticed is that the separation and challenge of raising children has made me more productive. You don't know stress until you've had a newborn. There are things at work that used to affect me and I look back now and think "how was that even a problem?"
That doesn't sound like a recommendation for becoming a parent. In fact it sounds the opposite - "don't have children, or you'll guilt yourself out of every other thing you could be doing".
There's tonnes of reasons why I wouldn't recommend parenthood. I don't think I was ready by any margin. All I'm saying is that I don't regret it and I consider it the best decision of my life.
My personal recommendation us when in doubt, err on the side of not having children. Don't make life harder on you than it has to be.
Hopefully I do a good job and it'll be my honour when my children look after the old when they grow up.
Sorry to hear that man, cannot imagine what you're going through - I've come close with my Mrs and it's not nice.
Your kids should be your number one priority, absolutely.
Make no mistake though: when you have kids you are trading off professional development outside of work for raising a family.
Nothing wrong with that, but the trade off definitely is there. People who ambitiously work on personal projects in their spare time will, on average, advance faster than those who are 9-5'ers.
If I "ambitiously worked on side projects", I'd at best miss times I'll never get back and at worse be downright neglectful.
That's a "trade off" I haven't thought twice about making. There is no mistake. As I said, my kids are number one.
In fact, I'd argue it isn't much of a trade off at all. Time with my kids is infinitely more valuable than time spent on my career.
Someday :)
What changed was my partner's boy, and now my boy for all intents and purposes. It made me rethink my stance and I decided to expand my family.
I believe that having children gave me more motivation and reason to be better at the things I do. It also forced me to structure my life a lot more which can have beneficial effects on productivity too.
One of the many reasons I remain childfree.
You cannot know the feeling of it until you do. You cannot really understand it until you do. It changes your world.
That's my main problem with it, it's super selfish to procreate. I don't feel I have the right to force new life (with all the pain and suffering that entails) onto this world for the sake of making me happy. I love my potential children too much to do that to them.
How is it not self-indulgent to have a child to fulfill your own sense of purpose?
You are utterly alien to a lot of people.
People argue all kinds of insane things.
Having kids to fulfill your own sense of purpose is very selfish.
On the flip flip side, there is some chance your child may take 1 or more lives.
Arguing about the selfishness of procreation is silly. It is your biological purpose. Whether you choose to run with that or not is down to you. It is not selfish if you choose whatever way.
As a parent, my children come first. I would die for them. You make that choice when you have children. That is NOT selfish.
Give one reason to have children that doesn't include words like "I want".
Wanting something isn't selfish. It entirely depends on what it is you actually want.
Oh yes, you could argue from a hardcore libertarian stance that altruism does not exist and every action is inherently selfish but is that a good way of looking at the world? I think not.
Define 'good' ? It's an accurate way of looking at the world. You can try to convince yourself otherwise but you don't really live in that world.
You don't want kids because it's selfish? That must mean, using objectivist reasoning, that to you not having kids is even more selfish. So your reason for not having kids is no reason at all if you subscribe to that sort of shit.
As for good, in the same way that you reduce a lot of things down to one thing that is objectively true but isn't really useful for everyday life.
Sure, I accept that it's possible to reduce down and argue all behaviours are selfish. Does that provide insights about the world? Nope. Does it explain human behaviour adequately, even if fundamentally accurate? "Why does inequality negatively impact inequality?" Because people are selfish?
But I read all sorts of technology and programming stuff just because I’m interested in it. And that knowledge ends up coming in very useful.
I’d rather have someone like me than someone who does their coding at work but never reads anything that they weren’t assigned to by their job.
To use your analogy, would you want to musician who worked 9 to 5 but never listened to any music outside of their job?
PS: What side projects do provide is a way to have more experience than your number of years in the field would suggest. But, that has heavy diminishing returns.
In addition, there is a real danger early in a developer's career that their resume becomes a signal of being a weak developer if they don't put in the effort to progress - I have seen this happen to multiple developers who did not take seriously the need to reach a certain level.
Now to tackle the analogy directly, there is a lot of competition for positions in the music world - musicians have to work pretty hard to get stable jobs, or carve out positions of prestige. The most successful musicians I know do it very often, whether it be arranging songs, practicing their musicianship, and immersing themselves in as many musical communities as possible.
When he got hired to do boring tech work at the company I worked at, he just freaked everyone out. The questions he asked were too pointed and he would just do things correctly instead of doing what his boss said. Since he was extremely gifted and had offers to work at other (better) firms, threat of job loss didn't mean anything. All his managers basically hated him.
A rockstar developer wouldn't ask questions of their coworkers that would embarrass them; a rockstar developer would phrase questions and concerns in a way that the other people on their team could understand. A rockstar developer wouldn't do something contrary to what their boss said, they would explain why would do something a different way before doing it (or explain why it's better). Now, if coworkers or management are too incompetent for even that, sure, even the best developer would have a bad time.
Part of being a rockstar developer is, in short, knowing how to work with developers who may not be as good as you. I've been there before and while it can be tempting to use that opportunity as a way to establish hierarchy (sadly important if your company stack ranks) by asking technically challenging gotcha questions and showing off how smart you are, it creates a toxic work environment and disrupts other people's work. It's much better to help people grow and not to overwhelm them with technobabble
I haven't worked with his team, but based on my experience with the company, it's possible that there was some of this, and people being so demoralized that they let the incompetent guy with the most standing make stupid decisions and then just do what he says. But they may not have been as bad.
Don't. At least some of us are having a bad time working because of it.
I found programming in my early teenage years, and - excuse me if I sound arrogant - by now, I've already seen or worked with anything even remotely interesting programming-wise that a regular coding dayjob could throw at me. Gluing together CRUDs from random libraries gets boring very quickly. Solving problems in large systems becomes day-to-day drudgery, because you know that there isn't much smarts there either - all those problems are, unavoidably, self-inflicted. As the codebase grows, you spend bigger and bigger fraction of time allocated to a task on routing - figuring out how to transport some information or command from one piece of the system to another, without turning everything into spaghetti or setting it on fire.
The usual things I see cow-orkers excited about is "oh, I'll get to use generics in Java for this, I've never used generics before!", or "this will teach me Framework X, it's surely a powerful tool that will be very useful for me in the future". They didn't get through this phase in high school, so they're full of excitement about work, however bullshit the project is. If you "found your passion early", you don't get that - all that remains is the bullshit project.
The point being, most of the work I've seen in this industry is pretty meaningless, and it's harder to do if you don't have the comfort of being constantly excited by even most trivial insights in programming. People who started late are better off, because the enjoyment they get through learning also helps them show up and do the work they're being paid for. They don't need to spend time on side projects after work just to retain their love for the craft.
But about the time my kids were old enough to no longer need constant, unrelenting supervision (all my kids were born by the time I was 25) I began taking up side projects again, which has largely renewed my love of programming.
So now I put up with the drudgery of the day job so I can go home and work on something I enjoy (I mean really, the day job could be anything at this point - programming just pays better than anything else I could do, and occasionally an interesting problem at work pops up). Which is also why I tend to become extremely resentful if forced to work very much overtime :)
> 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.
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.
This describes exactly the type of people the corporate IT department at my company. Really pleasant people until you actually need something.
Career wise these people can go very far though.
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."
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.
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.
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.
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!
Beyond a basic ability to think logically and enjoying doing so, programming is 99% perspiration aka patience.
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.
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.
> 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.
See, I can move goalposts too.