All of this is subjective. This may or may not have any value. I’m just rambling :)
A good programmer is not easily defined. Some might argue “A good programmer is someone who writes good software.”
And generally I am inclined to agree with this statement, but I see two big issues with this statement.
First of all, what is it what you do every day at your job as a programmer? Sure you write code and that’s no doubt the most important part, but is that all that you do? Probably not. You do code reviews, you attend client meetings and you design the software architecture. You end up discussing a lot of things, especially with clients. There will be features your client wants which don’t really end up being what the client really wanted. At this point either your product manager or you the programmer need to step in and suggest a different more fitting solution. But recognizing scenarios where this is the case is not always easy but important. And recognizing when to shut up is even more important. All of this means being a programmer – sadly – involves a lot of social skill. Which doesn’t really fit the classic picture of a programmer as one might imagine it.
Secondly, defining a good programmer as someone who writes good software raises the issue of defining good software. What is good software? Software which runs correctly? Which runs fast? Or software which makes a lot of money? Or software which follows your favorite coding style,rules and paradigms?
This question is not easily answered and like any other hard question in computer science the answer is it depends. What are the goals of your software? Often times this unanswered question can be the reason for widely different expectations between the project manager, programmer and the client.
At last one really important aspect I need to mention is “being a team player”. I feel a bit icky writing this because this phrase has been tainted by LinkedIn posts and “HR speech”. But yes chances are that in a large enough project you will work with other developers, which can be really great but also really exhausting. Knowing how to act and knowing what so say and not say is not always easy, especially for us programmers.
bike-shedding * is the concept of trivial things becoming a highly discussed topic, because everyone has something to say. This results in whole projects coming to a stand still because developers argue about things like code style or minor design decisions. Don’t get me wrong there is a time and place for in depth discussion, some topics require a lot of attention, but the name of the iterator variable isn’t one. Programmers have a lot of opinions and that’s totally fine you should have your own opinions, but one really important skill is knowing when to let go of them. There is a difference between “this won’t work because…” and “I like it better that way”. The latter is commonly referred to as a “nit” or nitpick inside of a pull request. In my opinion these nitpicks usually don’t have much value. Of course as always it depends if you encounter a beginner programmer using a,b,y,n and l as their variable names, then there is value in telling them to be more explicit. But two seniors arguing about calling it “rej” or “reject” really doesn’t help your software. Having opinions about style is totally fine, but be mindful of the difference between style and function and know when to concede. You will move forward much quicker and probably be happier in the end.
Sooner or later there will be issues with your software and often times one of the first questions after “what happened?” is “who did it?“. This isn’t a productive question. It’s our software and our problem, no matter how sure you are you did nothing wrong that doesn’t matter. Look into it, find out what you can. And yes maybe someone else did push some bad code but there is no value in blaming that specific person there is however a lot of value in analyzing the problem and providing or at least consult each other about the solution. And sometimes maybe it just might be you who caused the problem.
A lot of times you will be trapped inside a discussion about architectural choices you made inside of the code and you will hear something along the lines of “That’s not how you are supposed to do that.”. An avid Clean Code enthusiast will tell you that your 15 Line functions IS WAY TOO LONG!!!! on the other side you will have your favorite junior dev who just read Design Patterns tell you that this if-else if-else statement should be converted into a strategy pattern. These books have some really good content and if you find yourself never adhering to any suggestions or ideas specified in them you probably are doing something wrong. But often times programmers use the advice given, apply it to everything and stop thinking. Really think about why you are doing things and think about why something might be a problem and if it applies in this case. And don’t forget, computer science is a really young field. If you compare it to mathematics barely anything happend. Everyone is trying to figure out software and everyone is mostly going off of vibes. There is a lot still to actually figure out and I fear this will still take a lot of time considering no vibe coder is going to think that hard about his software.
There is a lot of talk about readable code but like I mentioned in the last paragraph readability is mostly determined by vibes. There are a lot of subjective points which influence how readable a piece of code is:
I can show my grandma the most beautiful piece of code ever written, but no matter how good your variable names are, she probably won’t understand.
I am not trying to say you shouldn’t try to write readable code you should always strive for the best you can do, but keep in mind when arguing about readability that most points are subjective and they always will be.
Programmers love to say “computers are so fast now, don’t even care about that inefficiency”. I hate that sentence. You are correct, computer hardware is really really fast, but software performance is so so much worse. This attitude and practices like Clean Code really do not help. I am not telling you to hyper optimize everything, but we as an industry should at least strive for “reasonable” performance. A web page should not run at 20fps. My WhatsApp Chat window should not take 2 GB of RAM. My Windows start menu should not take 3 seconds to open.
Software doesn’t have to be slow, we can do better and I am sick of pretending that performance is a non issue.
I recently read the amazing book Writing Solid Code by Steve Maguire. One really important point of this book comes down to that programmers should always step through their code and verify all the changes. This sounds stupidly obvious but in reality many programmers – myself included – may test the happy path or “most” of the code that they changed but more often than not there are some special cases which remain untested. This often occurs when change is deemed to be minor or unimportant. But you can never guarantee that you didn’t accidentally produce an unwanted side effect or overlooked something like an off by one error. So try to be meticulous and try to be careful about producing code.
The best programmers I know are people who actually have fun programming and have an interest in learning things. The field of programming has so many great things to learn this sometimes might feel overwhelming but I think that’s the best part. There aren’t many things where knowledge and the tools to try something are so widely available, you can learn almost anything if you really want to. And ideally your motivation should be to have fun with programming.
A lot of people pick up programming with one or two motivations:
And I can’t blame anyone for this. You will need a job and you will need money. That’s just how it goes. But even if that is the case try to have fun with programming. Don’t learn something because it is good for getting a job. Find something you want to learn. Find something that brings you joy. Do something because it’s cool to you and not because “that would be a great business”. I promise you, if you have fun programming and you learn things you think are interesting you will be a better programmer and you will find a job or improve at your job.
Just try to have fun and do cool things.