What makes a good developer?

Communication. Whether written or verbal, most every big error is due to poor communication. Customer to Developer. Developer to Customer. Developer to Developer. Etc. Be explicit. Be detailed. Don't make assumptions about the other's knowledge or understanding, verify. Get someone to read a document you write to find sources of misunderstanding. Get written agreement that your document is accurate (but understand that it means nothing, you'll still have to make changes.)

Along with communication, I would argue curiosity and passion. I think it's good to have a drive to learn more and have fun. It's way more fun to work with people that have fun or that like what they are doing. When you start, you don't know everything, but then you work with other people, they show you what they learn and you show them what you learn. That makes everyone grow and become better.

This likely is not the audience for this speach, but here we go anyways. Software development is not magic. It's just like anything else; it's something you learn how to do and then apply a lot of hard work.

Imposter syndrome is really common in this field. And if you look at what kind of projects new programmers come up with, it's pretty easy to see why; most often they use a bunch of frameworks and purpose-built libraries with just a little bit of glue holding it together. But here's the thing; everyone's first projects are like this. In the dawn of personal computing, new programmers would write their own versions of common utilities that do such extremely simple tasks they couldn't get anyone else to use them. So know this; if you wrote any program and it does everything you intended it to do, then you are a software developer.

With that being said, the most important thing for any software developer is the same thing needed for any profession; motivation. It is the one thing absolutely required. If you give up after your compiler throws up an error, you can't be a developer. It's as simple as that.

I'll even go one step further; you need an internal motivation. There is only so much work you can muster over things like raises and recognition, but knowing you will finish this project because you have pride in your work can take you all the way.

Something I can appreciate now, having worked for 10 years, that I couldn't when I was in your shoes, is how bad most people are at interviewing others. It really is a skill and a lot of the people you'll sit an interview room with aren't good at it. You could get yourself a job purely by actively answering more interesting questions than the ones they are asking. And if they are so fickle that they fight you on this, then know that is a person too stubborn to work with / who recognize good sense when they hear it.

Preamble out of the way, way makes a good programmer?

1. You have to pick the right solution for the problem. This is the 'goal' of programming interviews, but even the programmers I have worked with haven't realized why they are asking their questions or what they are actually looking for, apart from correct answers. More on this later.
2. Psychological safety. This will vary team to team and contrary to what you'll hear there is no one-size-fits-all solution to this. Some people can handle hearing their code broke and other people can't handle even the faintest whiff of a suggestion that they maybe possible wrote something less than perfect. The fundamental underpinning is that you need to make them feel like they can make a mistake/give input/etc without ruining a relationship / job opportunity / status. The less competent people are, the more sensitive to bad feedback they become, especially the more they are paid.
3. Curiosity and genuine interest. You have to go find new stuff on your own or at minimum be able to hear a good idea and run with it once you hear about it.

Those are really the three skills that matter. Everything else can be taught, but those three things you have to possess yourself to be of any value. So, on to the programming interview. A favorite question of mine is "Write a function which returns a count of all quoted strings in a block of input." I care about exactly one thing when I ask this question: Do you build a state machine; yes or no. If you build a state machine and don't realize it, you're a marginal programmer. If you build a state machine and know it, you're a good programmer. If you don't even build a state machine, or anything that can become a state machine, you're hopeless and I won't hire you.

The rest of the programming interview, outside of that one question, will be me figuring out how you react to feedback, how you handle stress (everyone is stressed in coding interviews, even me; regardless of whether I'm the interviewer or the interviewee), how you talk about your code (do you understand what you are doing and why, or do you just spout smart sounding BS?), etc. I'm more interested in what you can be taught to do and how hard that will be rather than what you are right this second.

As for curiosity and general interest: if you give me a programmer whose hobbies are golf and gardening, and another whose interests are writing their own neural nets just to understand how they work, I'll be far more interested in the neural net guy unless the golf guy just happens to simulate something about his golf game or automates watering his plants with an Arduino or similar item. The person I am the least interested in is the person who leaves work and doesn't want to touch a computer. This person may be a fine employee, but they'll never be an exceptional one. The base interest just isn't there. They are doing something they have to do, not something they want to do.

Neural Networks and AI are things you should 100% study. Understand how they work, do something with them. For example, write something that can identify all fish in a collection of photos, or something like that, and write as much yourself as possible, rather than re-using frameworks, so that you can say you understand how it works, rather than just manage to bolt it all together.

• Experience means a lot. It shapes and hones your senses and habits, and having better habits vs worse has long-lasting impact as you work with a given codebase. So, as a student, look for opportunities to get experience, whether that be diving into existing open source projects, or internships, or playing around with things at home.
• Professional software development (in contrast with academic or personal software development) is very much a human, inter-personal endeavour in addition to being a technical one. Getting good at this inter-personal side of coding is crucial to success. Here are some examples of what I mean.
  • Write code so that it's easy to improve and augment. (It's interpersonal because you're being considerate of the people that are going to do that improving or augmenting.)
  • Write good commit messages. Be considerate when working with the codebase repository: branching, merging, rebasing are done in ways that help your team and not hinder it. Even if your team size is 1, you still have more than one developer working on your codebase: you of today, and you of the future, coming back to work with the codebase N months from today. Or, you could be moved to another project at some point, and someone else in the department has to come and take over what you built.
  • Give helpful, respectful code reviews; receive code reviews humbly; in both giving and receiving, keep emotions in check, and focus on the technical matters at hand, avoiding (or ignoring) things like ad hominem attacks, provocative or offensive wording.
  • Get good enough at basic professional inter-personal communication, because you'll be dealing with non-engineers rather a lot: managers, product managers, designers, artists, quality assurance, and sometimes even sales and marketing. Communicating with these people poorly (particularly product management and quality assurance) will have lasting negative impact on your ongoing work on the project at hand.
• Be humble and continuously seek improvement. Try to assess things objectively, so you can effectively sort through the stuff of life and pick what to keep because it's good or better, and what to discard or avoid because it's worse, not effective, not valuable. This could be techniques, habits, guidelines, books, frameworks, libraries, languages, operating systems, third-party services, process, methodologies.
• A good programmer has a good team around him/her. Early in your career, you'll have a hard time influencing this, but the sooner you can get into a good company, the better. And, to be clear: By "good team" I don't just mean a time that is good technically, but also good at the things I've talked about, and are "nice people". You're going to be working with your team 5 days a week, 40 hours a week, 50 weeks a year. It makes a big difference whether your day after day after day is exhilirating, fun, joyful and life-enhancing, or is boring, depressing, taxing, loathesome, irritating, frustrating, stressful, traumatizing.