How do you decide a programmer in front of you is good? What are the three things that help you determine this? 🍺
Well, the programming it is a way of thinking, not matter what language, framework, library ..etc the programmer using, the languages and tools every day changes, so the important thing in programming is the logic.
Not matter for me the code is it look beautiful or documented, theses are small things and easy to fix, the good programmer mean good logic and mean this programmer can switch from technology to another very fast and no need to explain more, he/she can understand the problem from little words.
So, about your question, What are the three things that help you determine this?
When I think about the little probes I send out to see where another developer might be at in their journey I focus mostly on these traits. There's a lot more to being a good programmer than these three, but it lets me know if this person is the kind of person you can spark a good conversation with - the kind where you both learn things from each other! :D
Being intuitive is a key trait of a creative problem solver. Do they happen to be smart and have the right education for this topic, or are they equipped with the mental tools it takes to learn new things? How quickly could they respond to new knowledge and learn what to do with it?
As long as there is more than one way to accomplish something, humans will form opinions about which is best. Are they able to separate what they are doing from the opinions they hold? If the problem they are solving changes do their opinions change too, or are they acting in a dogmatic or superstitious way? Are the opinions they hold ones they have set themselves, or are their opinions inherited from others?
Solutions being built from code can usually be expressed in more than one way, just like there are many ways to rephrase a verbal explanation of something. When I was a beginner I could only express a code solution one way, and if you asked me to express it differently I wouldn't know how. I might be able to explain my code in english only one way too, but I wouldn't be able to summarize, simplify, or express it much differently than the way I had written the code. Now that I've grown a little more, when I write code I might be aware of a few different ways the same thing could be expressed. If you asked me to explain the code in english I might now be able to match the complexity of my explanation to your level of understanding. Can this programmer express and explain code solutions in different ways? Are they able to match the complexity of their explanation to people of different levels of understanding? The more flexible they are at articulating and expressing their thoughts in code and speech, the more likely it is that they truly understand the solution.
First of all this is pretty subjective. I agree with the other two as well although I don't see consistent code-formatting, swearing or team-spirit as a quality necessary for a good developer. Although I probably prefer working with developers having these traits more than with the ones without.
So my list would be.
Patience and Structure
In our craft doing things quick usually leads downhill. Having the Patience to do the hard thing first .... to think before acting. creating a plan before executing random deep dives. I don't wanna go so far as say TDD although I think it helps. Using pen and paper, talk about the problem (even to yourself) and than work on it. That's in my experience more stable.
Acting based on Context
I like to quote the new star trek series:
Universal law is for lackeys. Context is for kings.
every assumption that this is the "only way" to do something, is a sign that usually people don't understand the problem. Because every assumption you make is based on a model of your current knowledge which leads me to another favorite quote...
Essentially, all models are wrong, but some are useful.
(George E. P. Box)
Knowing when to use what, knowing that all your decision basically are wrong but you picked the trade-off that made sense at the time.
Ability to grasp functional elegance
usually developer are obsessed with syntactical elegance, it's something easy to understand we have guidelines like _clean code _or the pragmatic programmer and other good books that explains "how we should work" and "how we should structure our code" which are great (although once again .... context never commit yourself to a dogma).
functional elegance can be in a piece of code that looks ugly based on the assumptions above, but it solves an issue you would solve with 200 lines of code with 20 if conditions in maybe 10. For example moving the mathematical base to 2 and using shift. Instead of trying to catch the "exceptions" with complexity they eliminate them and create simplicity.
Those are only a fragments of my opinion about what a good programmer should do and are of interchangeable. But they are currently the first 3 ones on my list.
Still I will surely change my mind which leads to another quote:
No one can keep you from changing your mind over night. No one can keep you from getting a little bit smarter over night.
(this is a rough translation, it works better in german)
1) Clear Consistent Code formatting. If they cannot be bothered to use tab, shift-tab, and follow a style guide, it is unlikely they will make code that interacts well with what anyone else writes -- NOR is it likely that anything they make will be easily maintainable by others.
2) Ability to do simple tasks WITHOUT a framework. This is particularly true in HTML, CSS, JavaScript and PHP where the 'frameworks' are more often than not pointless code bloat, defeat the purpose of the underlying language, or try to shoe-horn into the code programming "paradigms" that don't match the language functionality. (such as the sheer idiocy of forcing the event driven MVC concept on the linear executing PHP).
You hand them something simple -- Let's use JavaScript as an example and tell them "we have <div id="currentTime"></div>, create a 1 second timeout to plug the current time into it." -- if they start out writing $('#currentTime') it's time to show them the door.
3) Ability to articulate ideas and document their work. There is nothing worse than someone with piss poor communication skills who cannot clearly state what it is they are doing, why they are doing it, in a manner others can understand it.
This last one is a skill sadly missing in a LOT of workplaces as more and more developers become reliant upon software to do things like version control, instead of THE HORRORS picking up the phone or walking across the hall to talk to fellow employees. Because of it projects are getting bloated, NOBODY is properly double checking with anyone else, conflicts and regressions are becoming MORE common not less so, and on the whole it's become so impersonal there's no life to it any more.
Something I had drilled into me in the '80's was that if you write a function DOCUMENT its calling conventions and return values in a separate text file like you were writing a manual. Nobody seems to do this anymore and the result is a lot of staring at code going "what the **** is this and what does it even do?!?" a few months later.
Said situation is only exacerbated by the sheer number of "Twitter Generation TLDR mouth-breathers" who likely won't even get this far into my response to realize I insult them in it. The people who go "280 characters now on Twitter? What is anyone going to do with that much?!?" -- as a rule we have a lot of people who lack the comprehension, understanding, or literacy to meaningfully contribute to any project.
I'm going to add a FOURTH one... I'm half joking... but ONLY half.
4) Do they swear, a lot... incessantly? I don't trust a programmer that doesn't ****ing swear. You take some simple non profane words like crap or garbage and throw them into the conversation, use a few similes that RESEMBLE a bit of harshness; like something Gordon Ramsey would say.
This HTML has so many blasted pointless classes it's pre-med!
If they get their panties in a wad, make sure the door hits them in the arse on the way out.
Attitude - you can teach skills, you can coach behaviour, but attitude is very hard to change. I'm looking for someone who can work on the team; who wants their peers to succeed (not just themselves). People who champion ideas; who encourage people to grow and support them when they're struggling; who share their knowledge... they make a massive difference.
Passion - it's hard to get much out of someone who doesn't give a crap. This doesn't mean they work stupid hours pulling hero efforts, it's about enjoying what they do and having a desire to do it well. It doesn't have to be their first or only passion in life, but they should care.
Curiosity - some people call it the hacker gene, it can show as habitual learning and experimentation. Basically I want to see some evidence that they are curious about how things work, what comes next, how they can build things with it, etc.
...
In a more literal sense, how do I decide if they're good at a particular skill? I try to ask them open questions that get them to tell me what they do and don't know. I'll have them talk through their approach to solving a problem. I'll dig into specific areas the job absolutely requires and make sure they talk confidently about working with that tech.
Ben Buchanan (200ok)
I make some bits of the web.
Vipin Jain
Vipin Jain is the Co-founder & CEO at Konstant Infosolutions, a leading mobile app development company.