What makes a great software engineer?
A couple weeks ago, a presentation made the rounds online about Netflix culture. The presentation featured the many benefits of working for Netflix and how the company goes about hiring (and firing) employees. While there was a lot of information about Netflix’s treatment of employees, which clearly makes Netflix an attractive place to work, the missing part is a list of employee expectations. The beginning of the presentation touches upon the company values that point in the direction of expectations but doesn’t go far enough to lay those out.
I don’t work at Netflix, of course (I work for Yahoo!), but I feel strongly that what makes a great employee and a great engineer is the same regardless of where you work. There are a few things that great engineers always do.
Always do it the right way
One of the challenges of software is to learn how to do it the right way. The right way is different depending upon what you’re working on and who you’re working for. Exactly what “the right way” consists of is less important than doing it that way all the time. Junior engineers tend to have the most trouble with this, but it does happen with senior-level people too. There’s an “emergency” project, or something that seems so different that it must have its own set of rules. That’s bogus. Good engineers know that the right way applies to all situations and circumstances. If there’s not enough time to do something the right way, then there’s really not enough time to do it. Don’t make compromises, the quality of your work is what ultimately defines you as an engineer. Make sure that all of the code you write is done the right way 100% of the time. Expect excellence from yourself.
Be willing to suffer
This may sound silly, but good engineers are willing to suffer for their work. Show me a great engineer and I’ll show you someone that has, at various points in his or her career, spent days trying to figure out a problem. Great engineers relish the challenge of a problem that keeps them up day and night, and knowing that it must be solved.
Not-so-great engineers call for help at the first sign of trouble. They routinely ask for help whenever something goes wrong rather than trying to fix it themselves. Their favorite line is, “can you look at this?” Great engineers first and foremost want to solve the problem on their own. Problem solving is a skill, a skill that great engineers take seriously.
Good engineers become great engineers by suffering. Suffering means not asking for help unless you absolutely cannot handle the task. Asking for help is a sign of defeat, so ring that bell infrequently lest you draw unwanted attention to yourself. Be willing to suffer. Spend time toiling over the problem. That’s how you learn.
Note: I am not saying that you should never ask for help. I am saying that you should try to accomplish the task on your own first, and if you get stuck, then ask for help. Don’t simply ask for help every time without first trying to solve the problem yourself. Chances are, you’ll find that you could have figured it out on your own once you know the answer.
Never stop learning
Any engineer who claims that they don’t need to learn anything new is not someone with whom I’d like to work. In some careers, you can get away without learning anything new for years; technology changes too quickly to not pay attention. Your employer is paying you for your expertise and if that expertise goes stale, you become expendable. In order to be a great engineer you must first admit that you don’t know everything, and then you must seek out more knowledge in every way you can.
Identify someone in your current company or organization from which you can learn and attach yourself to him or her. Ask for advice on complex problems to see how they think. Show them solutions you’ve come up with and ask for a critique. If you can’t identify anyone in your organization that can serve as a mentor, then either you’re not looking hard enough or you’re at the wrong company. If you can’t grow in your current job then it’s time to look for another.
Read blogs. Attend conferences. Go to developer meetups. Great engineers never stop learning.
Share your knowledge
There are some who believe that their sole value is their knowledge, and by sharing that knowledge they therefore make themselves less valuable. Nothing could be farther from the truth. What makes you valuable is not your knowledge, it’s how you make use of your knowledge to create value for your employer. How better to create value from your knowledge than to share it with others?
I’ve interviewed at companies where hording knowledge seemed deeply-rooted at the organizational level. In that type of environment, a fierce competition develops between co-workers, and this opens the door to politics and backstabbing. I don’t want to work in an organization like that. You can’t learn if everyone is keeping information to themselves.
Great engineers want others to know what they know. They aren’t afraid of losing their position because someone else can do the same thing. Great engineers want to see their peers succeed and grow. Organizations rally around people who share information, and as they say in sports, people who make other people on the team better.
Lend a helping hand
Great engineers don’t consider any task to be “beneath” them. Always willing to lend a hand, you can see great engineers helping out junior engineers in between doing their own work. If something has to get done, and no one else is able to do it in time, great engineers volunteer to take on the work. They don’t scoff when asked to help on a project, whether it be small or menial or low-profile. Great engineers are team-focused and therefore are willing to do whatever it takes to help the team. Whether that be writing 1,000 lines of code or editing an image, great engineers jump at the chance to help out.
Take your time
Great engineers aren’t born, they are made. They’re made by following the advice in this post and by hard work. If you’re just starting out, there’s still plenty of time to become a great engineer. Patience is key. You don’t become a great engineer over night. For some it may take a couple years, for others it may take ten. There’s no one keeping score. Strong organizations recognize when someone has the potential to be a great engineer and will guide you along. You prove yourself through your work and how you make your team better. Focus and self-discipline go a long way towards becoming a great software engineer.
Update (5 Sep 2009): Added disclaimer paragraph to “Be willing to suffer.” Seems like people are greatly misunderstanding my point.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.




27 Comments
I totally agree with you and would like to add that it’s not something you automatically are by having a degree. It has be almost like a hobby, the thing that you do in own time just for fun…
Cheers, Micke!
micke on August 21st, 2009 at 2:54 pm
Hi,
I strongly disagree with the suffering point. Your scenario is a more specific description of how rational introverts function in general.
There are plenty of ways to evolve. Not just spending days on one problem.
Cheers
Marek Stasikowski on August 22nd, 2009 at 7:32 am
@Marek – You’re certainly welcome to disagree. In my experience, people who give up and ask for help too quickly don’t evolve as quickly as those who are willing to be lost in the problem for a while. Seeing a problem through to the end, no matter how long it takes, is really key in developing a “can do” mentality.
Nicholas C. Zakas on August 22nd, 2009 at 1:31 pm
Hi Nicholas
Great post! I agree with both you and Marek. The learning experience is best when you solve a problem on your own, but if time is money and the client is waiting, you are going to cut the corner where possible. If I know I can ask someone and get an answer really fast, I’ll do that, bearing in mind, that if I keep the other guy from work by asking too often, I’m not doing anyone a favour.
Cheers
tj
TJ on August 22nd, 2009 at 3:33 pm
Giving up is not what I have in mind. Rather being rational in the time invested into a single problem.
Once I feel I’m not going to crack that nut – I’ll either let my mind rest and try again in an hour/day, or ask someone more experienced.
It is more a question of attitude – if you just let someone else do it, and just pretend nothing happened – you’re stuck where you were. But if you analyze the solution – you learn, and know what to do, once you get the same nut again.
Marek Stasikowski on August 24th, 2009 at 5:32 am
I have worked with people that when finding a minor problem, first thing they do is ask/cry for help to his coworker next cubicle.
Asking for help is ok, but when poping the question “have you tried solving it yourself” renders zero answers in every scenario, then you realize that the person needs to develop means to solve their own problems. That would be looking it up in a book, a simple google search, a newsgroup/bbs/forum, a technical side. Whatever. If they don’t know wheter to use char() or varchar() for a column declaration that is easily and quickly find out in google and interrupting someone to ask is, imo, just plain rude.
A minimum of 15 minutes trying to solve the problem yourself, followed by a simple search in google and testing a couple solutions should be the rule before crying out for help.
Most of the times the people that ask for help immediately just don’t learn. They ask for help, they apply the solution. When the same problem arises, since they made no effort in figuring out the solution they just forget. “Uh.. this happened to me before? How did I solve it? Oh yeah, I asked Randy. I’ll just ask him again”
[...]
It’s a complete differente scenario with those people that are just too obsesive, and spend one week or two in solving a simple problem, instead of asking for some guidance. There needs to be a balance. There are times where it’s better asking the guy that spent 3 weeks solving the problem instead of reinventing the wheel.
Rigel Kentaurus on August 24th, 2009 at 10:17 am
@Rigel – I agree that balance is required. I’m not suggesting that spending days working on every problem is the right approach, just that great engineers are willing to put in the work whenever necessary and don’t look for shortcuts first.
Nicholas C. Zakas on August 24th, 2009 at 9:40 pm
I have an issue with the first point because I see that attitudes to “The Right Way” are really the mark of a mature developer. An immature developer will do things whatever way gets the job done. An average developer will always do things the right way even when this would hurt the customer in the long run. A mature developer will sometimes do things in a less than optimal manner, incurring technical debt, in order to meet a short term customer need. Mature developers HATE doing this but will accept the tradeoff when necessary. Too many times I have seen developers insist on doing things the “right way” when this is unnecessary or will blow the schedule or budget.
Peter Kelley on August 25th, 2009 at 7:40 pm
@Peter – your definition of “the right way” is different than mine. My definition is the way that fulfills all of the requirements on time and with a quality of which you’re proud. Your definition is some philosophical programming nirvana that some developers think exists and therefore chase fruitlessly. That’s why I said that the right way depends on your situation, because the right way isn’t some magical set of steps that is right all the time. It’s all circumstantial.
Nicholas C. Zakas on August 25th, 2009 at 11:57 pm
I personally think there is a bit of a contradiction between your 2nd and 3rd point. Point two highlights the need to solve problems on one’s own, but three then instructs the reader to directly solicit a mentor.
I’m all for solving problems on my own, but after one exhausts their means of defeating a problem, I see no reason why one couldn’t ask a question about it. Asking for help isn’t admitting defeat, it is admitting you don’t know everything (which is expounded upon in your third point, hence the apparent contradiction).
Also, if you enjoy your work, it isn’t really “suffering”.
Knowles Atchison on August 30th, 2009 at 4:41 pm
[...] blog post is in response to this one. It is a good read and I agree (overall) with the point the author was/is making. However, there a [...]
What Makes A Great Software Engineer – A Continuation… » knowlesatchison.net on August 30th, 2009 at 4:42 pm
@Knowles – I think you’re taking some of my points a bit too literally. I’m not suggesting you should drive yourself crazy solving a problem or not ask for input. What I’m saying is that you should spend time solving the problem yourself before asking for help. If your first reaction is, “I don’t know how to do this,” and you immediately go for help, you’ll never learn. I use the term “suffering” as a tongue-in-cheek reference to what software engineers usually describe their jobs to be.
Regarding your mentor comment: A mentor doesn’t solve problems for you, a mentor points you in the right direction so you can solve the problem on your own. This absolutely doesn’t contradict the previous point. You should always try to solve problems yourself. When you fail, seek advice but not a solution, then try again.
Nicholas C. Zakas on August 30th, 2009 at 4:59 pm
You’re right. Perhaps it’s just my take on what asking for help is. To me, asking for “help” is always advice, rather then a solution. If someone does it for me, I don’t learn anything (as noted in your post).
Knowles Atchison on August 30th, 2009 at 5:12 pm
NIcholas –
I definitely agree with your general message. I think it is worth emphasising that although it is an ideal, it’s easy to take it to heart, in spite of important practical considerations. (Actually something of a hypocritical statement – although I maintain that following such advice is more difficult than being aware of it!)
I actually used to believe quite vociferously that I’d been “defeated” if I went and asked for help, and saw it as some sort of failure if somebody else had to explain something to me. I suppose that deep down, there’s a cell or two feeling pain any time I have to admit that I’m actually stuck.
The reason that I have been forced to suppress this is that in hindsight it has lead to a lot of wasted time. On several occasions I have been forced to re-evaluate whether the understanding gained from cracking a problem has actually been worth the hours put in. For example, I might have simply been looking in the wrong place for the answer, or I might just have had a lower-level misconception that would have taken me a lot longer to get round to examining. If somebody else can put something right, then things often fall into place much quicker.
On a related note, there’ve been many occasions in which I have been badly sidetracked by an perennial desire to understand things from first principles, instead of being happy that certain things have been proven to the satisfaction of somebody else. Needless to say, in such instances exam results have suffered or deadlines have been tight or even missed.
So sure, figuring things out for yourself is always going to be the ideal, but more often than not there are also important practical considerations to take into account. “The balance” is very important, even if psychologically it can be difficult to strike.
Jonathan on August 31st, 2009 at 12:55 pm
Awesome !!!! Taking the pains to show the right points for making a great engineer
Siddarth on August 31st, 2009 at 11:04 pm
I agree with most of this. But these days you can’t always afford to sit and try to figure something out by yourself until you get it resolved. We had a guy like that on our team… could only work on one thing at a time and would immerse himself in it and would rarely, if ever, ask for help. He would noodle on a problem for weeks at a time, totally tangled up in the weeds. He never understood the business aspect of software development and really expected everyone to just sit and wait until he solved his little puzzles. Hey, if you know of jobs that let you set your own timeline in the pursuit of the perfect solution, please tell us! In reality, we have deadlines, customers and managers. Your time is the company’s money. Get it done, do it quickly and if you can’t then ask for help…that’s what a team is there for.
Jason on September 1st, 2009 at 3:36 pm
@Jason – I think you’re actually agreeing with me. If you’re never given enough time to solve a problem on your own, you’re never going to learn and never going to grow. It sounds like, at your company, this isn’t a place for people who need to learn – it’s a place for people who already know how to deliver.
You’re absolutely right, not every environment is one in which you can afford to take time and try to solve it yourself. That being said, not every environment is one in which you can’t due to deadlines. My job is pretty demanding, and there are a lot of deadlines to manage and deal with, but that doesn’t mean I don’t try to solve problems myself first. I’d argue that it’s just as unproductive to have multiple team members going to the same person for help on every issue. If someone is too quick to ask for help, it means they didn’t even try, and those are people that you also can’t afford to have on your team.
Nicholas C. Zakas on September 1st, 2009 at 8:13 pm
@Nicholas – I have yet to see an environment that afforded you ample time to work on esoteric puzzles. Maybe product development is like that? Not sure. Corporate IT is certainly not. I agree with the asking for help too quickly thing. I never condoned that. As several have stated, it’s a balance. That balance comes along with a good work ethic and some degree of maturity. I love to figure things out on my own. But I have enough sense to weigh that against the deadlines and project expectations. If I start to see that I’m impacting or risking other tasks, I bounce the idea against my teammates. They do likewise. That’s collaboration…and it’s something that traditional hard-core engineers (in my experience) have trouble acclimating to. We have had a few of that type and they always impact our productivity overall. Emphasis on the word “had”…if that tells you anything.
Jason on September 2nd, 2009 at 8:27 am
@Jason – Again, I think we’re agreeing. I said earlier that the “right way” is dependent on your organization, and that there is no universally appropriate right way to be found. The balance that you mention is also mentioned in my post. Note that I said you shouldn’t be too quick to ask for help, not that you should never ask for help or that you should risk deadlines because you refuse to ask for help. My point is exactly about balance, making sure that you’re trying to figure out problems on your own before seeking help from others. Too often, people stop trying to figure things out way too soon, and you’ll never become a great software engineer if you do that.
I’m not sure why you’re bringing esoteric puzzles into this conversation. I’m only speaking about a workplace with real, tangible deadlines. The problem is when you focus too much on the deadlines, you only worry about the fastest way to complete work, and that leads to poor habits such as asking for help too early. I want people to ask for help when they’ve reached a point that they don’t understand, and not a moment sooner. When people ask me for help at work, and I perceive that they just haven’t looked deep enough, I’ll send them off to keep looking and get back with me when they have results. I find that this makes them more responsible and teaches them more than if I were to give them the answer immediately. I also find that they frequently figure it out on their own relatively quickly at that point.
Nicholas C. Zakas on September 3rd, 2009 at 11:20 pm
IMHO: Can you estimate how much time it’ll take you to find solution? It’s very hard especially if it’s new ground. But it’s real shame if you didn’t try:) So ask for help if deadline is comming, and you’re in tight spot. The important thing is to understand the solution – 1)you’ll learn 2)you can extend and 3)you can share
Regards
Darek
PS. I’ve learned a lot by asking for help.
Darek Adamkiewicz on September 5th, 2009 at 5:04 pm
This was a nice article, but the second headline, “Be willing to suffer”, ruins it for me.
Firstly, suffering is something very bad (some would say that it is the very definition of bad). Being “willing to suffer” is an unhealthy state, sometimes referred to as masochism. This sentiment is to be avoided. There is no shortage of people glorifying suffering. This needs to stop.
Secondly, and more importantly, focusing intensely on solving problems is extremely pleasurable! If one does not enjoy being frustrated by hard problems, why in the world does one become an engineer?? You obviously know this, since you contradict the headline by writing: “Great engineers relish the challenge of a problem that keeps them up day and night…”
Martin on May 8th, 2010 at 7:59 pm
I think you’re taking the “suffering” bit a little too literally, Martin.
If you’d like to debate semantics, I’d say that suffering isn’t bad unless you view it as such. Suffering is undesirable, for sure, but I wouldn’t say it’s “bad.” Undesirable circumstances are sometimes avoided too quickly, and I’m not sure anyone can say they learned the most by avoiding undesirable circumstances – it’s that which makes us grow and push beyond what we are.
Nicholas C. Zakas on May 8th, 2010 at 8:36 pm
Yeah I think suffering is a continuum and you are speaking to those who at the first sign of not knowing an answer they think “oh crap, I don’t know this. I had better ask for help.” Whereas if they want to evolve into a great engineer (or even a good one) then they have to be able to “suffer” through the pain of not knowing so they can build the mental skills necessary to solve problems. The people who are or will be great, relish these moments of unknowing because they know that somewhere in their mind they are building the underlying mechanisms that will help them become better problem solvers, and I couldn’t agree more.
Random Cole on May 8th, 2010 at 10:32 pm
Interesting article, but I think a lot of your examples are a bit contrived, or that they hit upon this engineering ideal that don’t hold up to the scrutiny of actual everyday engineering.
Take the first point about doing things “the right way always”. Well, you say that it depends on the project and the company, but beyond the glaringly obvious (e.g., follow your company’s coding standards), I don’t see how this is a meaningful statement. I mean, “right” for one project may very well mean hacking something together in PHP with raw HTML, while another project may require a Javascript templating library and backend Java services. The core point here isn’t doing things “right” or “wrong”, but rather whether you’re spending the time necessary to evaluate the design and the appropriate tools to use.
Or the next point about how you don’t ask for help until you get stuck. One of the greatest assets to a senior engineer is the knowledge of their team’s specialties as well as who to ask when problems crop up. Sure, if a Javascript error pops up in your browser’s console and you’re a front-end engineer, you may learn something; if your Search API is returning bad results, setting up a Java dev environment so you can debug it yourself is a tremendous waste of time and resources.
And the point about always ready to lend a hand – again, that only works for the simplest examples. I think a much more important skill is recognizing what you’re good at and work in that realm, and again – delegating or passing off what you’re not qualified to work in instead of charging your way into whatever stands in your way. For example, having a backend engineer try to “edit an image” – as per the example – is usually a bad idea, as they don’t have the right tools (e.g., Photoshop) or the expertise (they’re not UI designers or artists), and engineers who think they’re “great” by doing this produce shoddy products with suffocating UI and ugly icons. Similarly, a junior dev who thinks he can follow the path of greatness by rewriting a bunch of low-level library code will at best take up a ton of a senior engineer’s time in code reviews and fixes and at worst crash the service from inexperience and weak design.
Datheron on May 9th, 2010 at 1:54 am
RE point 1, “Always do it the right way:” Great artists fill sketch pads with preliminary studies before applying oil paint to canvas. Throw-away charcoal sketches allow people to “think with their hands,” to work things out experimentally. When tackling a really tough problem that is at or beyond the ragged edge of your ability to grasp the complexities, take a first pass or two when “all rules are off”. Temporarily hack C++ include files to make private fields public so you can get them wherever you feel like it! Throw a jumble of class definitions together into one file! On your initial pass, the goal is to figure out a path through the maze that works. When you have something that works, let your mind grapple with a succession of cleaner, better, and more clear re-factorings. At some point you will have internalized the right abstractions and the problem solution will seem clear and obvious to you. At that point, make the code reflect the clear, obvious, and in retrospect inevitable “right” way to do things. Get those fields back where they belong in the “private” section. Build separate classes into separate files and run around modifying project files as necessary. Integrate your final, clean, elegant, “right” code from your sandbox repository into the mainline repository. Bottom line: You’ll cripple and paralyze yourself it you try to get the ultimate “right” solution on your first try. The first breakthrough proof of a really hard open problem is typically a bit of a hairy jury-rigged mess. Subsequent efforts streamline and simplify it until what Erdos referred to as a “from the Book” beautiful, simple, and clean proof emerged. Take a tough problem in two passes: Pass 1, mess around all you like until you figure out some way, any way, to correctly solve the problem. (I’m not suggesting hack’n'pray here; you are looking for a solution that is conceptually correct.) Pass 2, re-factor, clean up, document, perfect, and check in a polished, clean, minimal, understandable, well-documented, well-tested highly professional piece of work!
Greg Johnson on May 9th, 2010 at 2:34 am
@Datheron/Greg – You’re both reading way too far into the word “right”. The “right way” to me means you’re not cutting corners, you’re doing it the way you know it should be done. That may mean doing some investigation before you start coding, it may mean prototyping before you commit, it may mean sketching something out on a whiteboard. The point is, you don’t just hack something together and consider it done, you do it the way that you know it should be done and settle for nothing less.
@Datheron – I disagree that asking a backend engineer to edit something in Photoshop is a bad idea. If the team is coming to you, asking you to play a role that helps the team, it’s either because they know you’re capable or because they’re desperate for help. Either way, turning down that opportunity to help out your team isn’t the right thing to do.
@Everyone – As I said in the original post, a lot of these are specific to projects and/or companies. Coming up with exceptions doesn’t prove that what I’ve said is false; in fact, it proves my point about things being fluid and different for everyone.
Nicholas C. Zakas on May 9th, 2010 at 1:25 pm
I agree with nicholas!!
An different approach, in a project that must take an 8 hours, first copy-cut solution from out of web, but after finished, try to solve yourself that(issue) on a free time!
Like in music, there’s best practices, but that’s not the only one approach on a issue, is just the most popular, I’m just a begginer on Web Development, but in music, relationship, advices are there, but there are other ways on resolving problems!!
Thanks for the advice, and I use your Book(Professional Javascript) along side alexi’s book( JS Programmer) for Real-World, and ES spec. to know-how the JS engine works on browsers!!
E
Alexandre Bars on October 31st, 2010 at 2:23 am
Comments are automatically closed after 14 days.