I am reading a article(http://www.danielslater.net/2017/07/how-do-i-know-if-im-good-at-programming.html) where a senior developer try to explain the answer of it. I also want to know more answers?
How you all know that you are good?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (26)
I don't think there's any good reductionist way to measure how good you are at programming. There are a number of good programming principles that you can consciously choose to practice, and if you practice all of them, you are probably good at programming (not necessarily amazing, but at least good). SOLID architecture is a decent place to start.
If you need a quick self-check, though, one of my favorite questions is: "Do I understand why this code works?" or "Do I understand why this code doesn't work?" Anyone can write working code by accident (or by trial and error) but good programmers write working code intentionally. These questions are especially powerful when you're reading code written by someone who is much more experienced than you are. You may not know if you're a good programmer, but you probably know if someone is significantly better at it than you are. If you can understand how they got from A to B, you're one step closer to being as good as they are.
Yeah, I definitely agree with this.
Totally agree.
These are all good points, but when I think of what it takes to be a good programmer, I usually think about how your abilities relate to the tasks your trying to accomplish. Nobody is good in a vacuum. Not that the article doesn't make that point, but I'd like to go further with that.
I think being good at programming is an ability to understand the problem at hand and take the appropriate steps to solve the problem. More novice programmers don't quite have the ability to understand the current and future problems, and might not come up with the right solution, even if it is technically correct on some level.
Part of solving the problem has to do with the team's makeup. If you're on a solo project, your role and plan of execution is a lot different than if you are on a team of 20 working together on something. Understanding your own strengths and weaknesses, communicating them with the team and finding ways to be productive are all part of it.
Beyond writing extensible code in and of itself, being good at programming is about having developed the toolset to be able to take on a problem with your full creativity, and not be hampered by the basic "how do I even start to approach this?" questions you might have at an earlier level. When you are good, you can see a problem and develop a coherent path to appropriate solution, then execute on it.
The more you learn about "coding", the more you realize how much there is you really don't know. I've gone from BASIC and Logo, then BinkleyTerm BBS scripts, then COBOL, VB, Java, VB.NET, PHP, C#, F#, JavaScript, along with HTML, CSS, SQL (raw, but including Hibernate/NHibernate and Entity Framework) and a few specific DSLs (along with enough assembler experience with two different architectures to be grateful I don't have to make a living in assembler).
But am I any good? Good question. :) There is certainly "goodness" to be found in specializing and really learning things deeply (I can make Unisys COBOL or C# do pretty much whatever I want), and the linked article is good when it talks about how to structure code. IMO, it goes deeper than that. Your entire career, you will be encountering things you don't know. How do you take what you do know, and devise a solution for what you don't?
Let's take a practical example (one that I've encountered so many times I've lost count). What would you do if someone asked to you debug code in a system you'd never seen before, using a language you'd never heard of before the question? (because "hey, you're a programmer...") The answer to this reveals how you think. A person who is "good" at programming understands how computers work, understands development paradigms, and isn't afraid of code. Not that you answer the question with false bravado; don't promise something you can't deliver. However, the difference between "no" and "well, I've never worked in that environment before, but I'll take a look" is huge.
Of course, this is based off my experience, as a part-time freelance developer and a full-time developer for nearly 20 years in a "large air-based defense agency". Yes, you need to understand scale, Single Responsibility Principle, why the functional paradigm helps, etc., but what I've described is a deeper understanding of how you can get computers to do what you want them to do. The language is an implementation detail*. :)
* Not that these details are insignificant; as a "good" developer, you'll likely uncover these in your learning of the language.
** This is "good" at programming in general. I wouldn't answer a Swift job posting with "I'm good at Swift!" because I've literally never read a line of it in my life. However, if I were to apply for that position, I would explain my grasp of development principles, similar experience, and my go-get-'em attitude when encountering a new environment.
*** What I'm describing could be described as a "polyglot" programmer, but I think it goes beyond just knowing how to write the same line of code in [x] number of languages.
I think one of the best way to know if you are good or not, is to simply ask other developers if you are good or not. I would also like to point out that the article is really talking about construction of code, it doesn't really speak about being a good developer, software engineer, programmer, or whatever title you like to use. Code construction is only one aspect of a developer. One more thing, I think if you don't know if you're good, then you might not know enough. That's okay. It just means you should keep learning and absorbing as much as you can from different sources. You will reach a point where you can compare your work with others and know you have reached a level of competency you are looking for. Wishing you the best and keep learning!
I would add the caveat - ask other TRUSTWORTHY, SUPPORTIVE developers. People who respect you as a person will be honest about your skill. But if you ask in a random community, while SOME will be supportive, you'll also have people lining up out the door to tell you you're a fraud. (That behavior is usually due to imposter syndrome turned hostile.) ;)
Yes! Thank you for pointing that out Jason. Having those trustworthy and supportive developers is very important. I would also add finding a good mentor falls under this as well.
I believe the mark of a good developer is four-fold:
(a) LEARNING: When you stop learning, you stop growing. No programmer will ever reach a point at which they no longer need to learn just as much as they did as a beginner. There are always new languages, patterns, paradigms, practices, interfaces, abstractions, and goals.
(b) TRANSLATION: The easy part is deciding what you want to do (i.e. "scrape all tweets with the word 'programming' in them). The hard part is deciding HOW to approach that problem. This can be thought of us "translation" - converting human thought into computer logic. The human brain and the CPU are inherently incompatible devices. The coder translates between the two by thinking like both.
I would say that TRANSLATION is the "coder's instinct" that is so important to what we do.
(c) CODING: The best code in the world is worth very little if no one can maintain it. The article you linked to summarizes good code very well for this purpose, I think.
Side note, CODING is why I have very little respect for certain people implicitly considered coding "idols" - reading their code is an exercise in futility. They're the only ones who can ever hope to really understand their own code, which is a mark of a poor coder.
(d) COMMUNICATION: It was Joel Spolsky who said that the ability to communicate is the single most important skill a coder can have, even more important than technical skills! I've found this to be true time and again.
A good communicator can engage in exchanges with other people that allow them to LEARN (a). They can understand human user needs, ask questions, and explain limitations as part of TRANSLATION (b). They can write, comment, and document god CODE (c).
A Word Of Caution: I have met coders who, while inexperienced and tripping along with shaky legs, aim for all four of these points. I would consider them GOOD CODERS, even in their inexperienced state. Indeed, one of these coders will accomplish far more than even a 20+ year veteran coder who lacks these skills.
Asking if you are good at programming is like asking: "Am I good at writing a book?"
There are many ways to write books. Some books are short and to the point, and might be considered well written. Others are long and considered epic and full of details and intricacies that make the story fun to read.
I would first ask: Does my code work? If yes, then that's good.
Then I would ask: How can I improve my development process?
If the tools you are using enable you to get your job done, then how can you make them help you with the little annoying things you do every day. How can you test your code to help keep yourself from going insane during a large code refactoring.
Then I would ask: Am I good at communicating my ideas?
Do people understand you when you try to speak technically about a topic? Do you know enough to talk the talk? If you don't, then you need to brush up on basics or read up tech blogs about your specific area of emphasis. Become an expert.
Always keep learning.
1) Do other developers read your code and not want to punch you?
2) CAN other developers read your code at all?
3) Do you look back at previous code and improve it if time/resources allow?
4) Do you feel like you're kicking [insert platform]'s butt?
If you answered yes to most of these, you're killing it ;)
Also agree with some of the other points listed here - it's hard to measure how "good" you are, but if you're comfortable in the environment, and your code doesn't feel like walking through the jungle with a machete, I'd say you're doing just fine.
A lot of things go into being a good programmer. But I will say that an enjoyment of solving problems with a technical bent is the primary ingredient to being a good programmer. Learning patterns is the (relatively) easy part, like buying tools for your tool bag. Knowing the proper place to apply those patterns is the hard part and comes with experience. In the process you may often observe others (or yourself) getting a shiny new hammer (pattern) and all problems start to look like nails, as the adage goes. It is part of the learning process. It helps you figure out quickly where that pattern doesn't work. :)
Agreed! What you describe is what I call (in my own comment below) "translation" (between human thought and CPU), but "problem solving" is another very good name for it.
Whatever it is, I believe this is the inherent "programmer's instinct" that, with occasional exception, is a trait one is born with, although it must be trained.
A good gut check for me - step into someone else's code outside your codebase but related to your domain. For example, step into the logic in an HTTP Client library, or an in-house framework that drives your code, written by teams of people. Just start in your code, but follow your IDE debugger into the unknown. Do you understand what the code is doing? Do you understand why it was implemented that way? I find that if I'm content in my piece of the product, and if I can't grasp the outside unknown, that I need to study, read, learn and seek mentorship from good people with good experience in that domain. It helps to travel outside your part of the ecosystem for a while. 🙌🏼
If you are competent your code will explain how it solves the problem space
If you are a good programmer your code will explain what the problem space is
This
Over this:
Depends on the situation in which you are programming. If you are in a big corp-y OO codebase, and you like that, then all the "Clean Code" and "SOLID principles" crap could help you. They are the amalgamation of people trying to cope with terrible "best practices" designed to make productivity numbers make sense when throwing people at code.
If what you really want to do is drive your own knowledge and skill, you need to practice the discipline of sitting down on your own for an hour a day and program something you find interesting. Take very small steps, ensuring that your program compiles and runs as expected after every change. Get something on the screen (and/or on your debugger watch window) as early as possible. Write the simplest code you can that does the thing you want to do, and put absolutely all programming methodologies, recommendations, and practices out of your mind. After each change, think about what the code is doing and what would be the simplest and most sensible thing to try next. If it that doesn't work, step back and try something else.
Don't worry about code "cleanliness" using this method. Pile the code on, and do not "pull" things out into separate functions until you actually are using the same thing in more than one place. Reuse is secondary to figuring out where everything goes at this point.
Don't worry about programming abstractions, focus your care on what the computer is actually going to do when it runs your code.
Don't worry about code "performance" as long as it is working well enough to prove the design you are expressing in code. After your design is fully realized, then you can go back and optimize.
Wait until the end to get OCD with the actual code. Like performance optimization, you have to have a written, working initial design first before trying to apply whatever code "aesthetics" and "beautification" organization you think it should have without confusing yourself.
I only have a year of experience as a programmer and i have moments where i doubt myself.I am a junior developer at a very small company and they do not make use of "good programming principles", for lack of a better term.
I can see that if i do not move on or try to introduce ways in which we could improve the quality of the software we produce, I will not become a better programmer.
Yes, my code compiles and produces the desired output but i do feel like there is more to it. So I am still learning to be a good programmer. :)
Before telling whether someone is good at programming there needs to be a definition of what is "good". The problem here is that this is always subjective. Here are some examples where there are different opinions: Use language X or Z, write automated tests or not, write automated tests before or after the production code, use mockist or classic style for for test-driven development, and maybe not everybody agrees on the guidelines in the "Clean Code" book or "code smells" classified in the "Refactoring" book.
However, a lot of interesting criteria where mentioned in the previous comments, the article linked in the question, and other resources like the The Programmer's Oath from Uncle Bob.
Here is my excerpt:
However, it is said that you "cannot measure productivity" of software developers. This doesn't mean that productivity doesn't vary, just that no-one can tell it for sure. Still there are some possibilities to find out whether you are a good programmer:
You don't. That's how you become complacent. Speaking from personal experience it is better to always think or put yourself in mindset of your are just starting out. You that hunger to consume as much knowledge as you can. That being said as you get better others around you notice the difference because you don't only do better job but you help the be better at it; with peer reviews and the likes.
Well, I always think that I'm not good because there is always things to learn. But I'm good at wondering and learning. Some of people can say that these features are the characteristics of a good programmer.