frob said:
Though it has been two decades I still absolutely love the old Joel On Software article, looking for people who are both smart and get things done. If they're smart but not getting things done they won't be implementing their features and might work as a consultant, but not an implementer. If they're getting things done but aren't smart about it, people need to go back and redo their work.
I've seen that and always thought “being smart” meant having high intelligence. Didn't realize he meant writing clean code as you suggest. Then it makes a bit more sense (since raw intelligence is difficult to improve). I've seen people be at both extremes. Some people implement stuff quickly and disregard pull request comments and general ways of improvements as “I'll do it later” or “too much work right now”, which means someone else gets the fun job of cleaning up their code later down the line. The people I've seen at the other extreme seem to adore Uncle Bob and care more about generic code (oftentimes overengineered code) which ends up solving general problems which sometimes happen to be the problems we are interested in solving and sometimes the solutions end making things less extensible than the simplest solution would have. Both groups can be frustrating to work with but at least the “smart” group sees it as their duty to write good code whereas the “getting things done” group only seem to care about looking productive to managers, which can be beyond frustrating for someone working alongside them. Obviously these are over-generalisations and even those people were not solely in one camp or the other, but I agree with the sentiment that bad engineers the rest down.
/rant
I do think, however, that there is some duality to “smart” and “getting things done”. Producing clean code quickly is something quite difficult in my view. Just the act of cleaning up code after pull request comments can oftentime take me 1-2 days of extra work (since it often involves learning about a more efficient way of solving the same problem, which takes extra time to research). IMO it is mostly lead developers, with many years experience solving similar issues in the same language/framework, who have the skills to do both things at the same time.
frob said:
When someone has those core skills down, when they're a good software engineer in general, you don't need to explain things multiple times. You can explain it once, they can ask some questions, and you can be confident that they understand, won't screw things up, and get it done.
I agree. Working with someone where you say something once and they “get it” directly is an amazing feeling. It is very rare though because you both have to have a baseline of technical understanding as well as a similar view of architecture and coding practices for it to actually work in this way IMO. Doing pair programming when you find someone like this can be incredibly rewarding since you can feed off each other.
frob said:
A good programmer can learn whatever specialties are needed for the task. They have a broad base of skills, and are both willing and able to pick up more. They're both smart, and able to get things done. They may not be a perfect match, but they can adapt by virtue of being smart and getting things done. They may not have a specific specialty, but they will find and develop specialties that we can use, and someone else with that specific specialty can pair up with them, that's why we're teams.
Too bad most recruiters don't seem to think like that. I would just add that being a good communicator oftentimes seems even more important than the other two, since teaching/learning from that kind of person is much easier than someone who lacks communication skills.
frob said:
I have worked with too many people who are lackluster programmers, they only know a few topics and struggle terribly when something is outside their tiny little island of knowledge. I've also worked with plenty of “okay” programmers, and had the difficulty of terminating their jobs. I feel they're the hardest people to fire because there is no specific thing to improve, other than do more of whatever they do. We don't need okay programmers. When we have amazing programmers and an okay programmer shows up, the okay programmer slows everyone down. The hardest thing I've had to explain to someone is that it isn't anything about lacking a specific skills, they're okay at it all. But being okay isn't enough, at least, not with the groups I work with.
Where I'm from it's against the law to fire someone based on performance so I have never been in a company where people get fired. But I do wonder how I would stack up. I've gotten glowing reviews from several workplaces, however when I read what you are saying I doubt my skills would actually hold water. It's that old cliché of being an impostor I guess. Do the people who end up sticking around have confidence in their abilities or don't you notice any difference in that aspect between the “good” and the “bad”? How do the people you end hiring present themselves in the hiring process?
I'm just asking because when I've gotten rejected for jobs that I really wanted I've been left wondering if they thought my actual technical skills were not good enough or if they thought what they saw from my skills in addition to my perceived lack of confidence sealed the deal. From what I've heard, lots of people lie on their resumes and pretend that they know things they don't, and there are many engineers in general who have lots of confidence in their ideas/implementations even when wrong. It makes me wonder if recruiters base their decisions on what the applicant is showing and then reduce expectations based on the probable fact that they are overselling their abilities. I'm not sure if my strategy of brutal honesty about my abilities is working out as well as I would like or if it's taken as a lack of confidence.
