We hired a greenhorn dev several months ago. He had two years experience at a larger company. I only have about five so far and my company doesn’t really pay all that well to field great talent, so I wasn’t hoping for the world. But we were expecting at least something a little above entry level experience.
The guy did know how to write basic code. Frankly not to the degree I hoped for, though. Also lacked all auxilliary skills like effective use of version control, logging in to remote servers over SSH, documenting code with doc comments. He doesn’t even write particularly legible code without the formatter to fix it for him. Very sloppy with spacing, braces, etc.
But those are all of little concern. Those could all be taught. It meant more effort needed to be spent in onboarding than we wanted, but it could be done. Helps that he has a very positive oulook on constructive criticism and he uses it to improve.
One thing that I don’t think I can teach him in any reasonable amount of time, though, is how he mentally tracks the structure of the program he’s working on.
When I program, every time I change anything, I construct a mental web of everything this piece of code might affect when changed, and the ramifications it might have. I think of neighboring code and concepts looking for patterns, and whether the new thing I’m adding or changing could be better expressed differently to leverage those patterns. I think of the future trajectory of the module or feature, and whether it would be advantageous to bake-in a certain kind of forward-thinking extensibility now rather than after it becomes partially entrenched later. And most of all, I think of how someone completely unfamiliar with this code might read it, and how I can improve the way it is written to make the most important parts stand out clearest.
And when I’m debugging code, even if I see the problem and think I immediately know the solution, I still take time to read the surrounding code. I try to piece together the original bugged code’s intent. Is this onvious-looking problem the real problem? Or is it a poorly documented, poorly structured mess that looks like it wants to do one thing but is intending to do an entirely different thing? This hesitation has saved my ass on several occasions.
New dev doesn’t do any of these things. He pulls a bug ticket, figures out what module or function is the supposed source of the problem, and bangs on it until the effects of the problem disappear. Little research done to understand what the intent of the code he’s altering wants to do, and even less spent on figuring out what downstream systems will be affected. And once he achieves his singular result, he just pushes it as-is. No cleanup pass, sometimes forgets to format it the way we ask him to.
To be fair, it’s a big new codebase. I can’t expect him to reason around things he is not familiar with, nor would I think it reasonable that he study the entire codebase before touching it.
I also don’t think these things can’t be learned. I had to learn them at some point, after all. But I do believe that people like myself and one of my fellow devs are more predisposed to picking these programming soft skills up, whether it be through nature or nurture or some combination. That, and I don’t think these kinds of soft skills can really be “taught” in the traditional sense. These are wrenches you can only really learn to dodge after being hit by a few.
Ironically, as I’ve become more senior (11+ years at a faang company) I’ve had to do less and less of that “look around and understand everything” work because of time pressure. But I rely on my experience to be more confident that I can ignore the details and focus on the reason I’m in this file.
Well, that, and if it gets too messy I give up and call in a junior engineer…
Yeah, how much time you get to dwell on it will depend on lots of factors and the needs of your client/employer.
I happen to work at a place where timeframes for fixes are quite lax, and the codebase I’m working with is slowly being recussitated from a decade of bad decisions from a D-tier web developer. (Dreamweaver was involved… let’s leave it at that.) I can imagine if you have a codebase that was somewhat competently designed from the start and/or your client/employer has a “I need this fixed yesterday or else your ass is FIRED” urgency, you don’t have time to dwell on such things. But it helps to have the experience that at least lets you do it a little bit rather than not at all.
I’d say it’s more than just practice. It requires a certain way of thinking too.
We hired a greenhorn dev several months ago. He had two years experience at a larger company. I only have about five so far and my company doesn’t really pay all that well to field great talent, so I wasn’t hoping for the world. But we were expecting at least something a little above entry level experience.
The guy did know how to write basic code. Frankly not to the degree I hoped for, though. Also lacked all auxilliary skills like effective use of version control, logging in to remote servers over SSH, documenting code with doc comments. He doesn’t even write particularly legible code without the formatter to fix it for him. Very sloppy with spacing, braces, etc.
But those are all of little concern. Those could all be taught. It meant more effort needed to be spent in onboarding than we wanted, but it could be done. Helps that he has a very positive oulook on constructive criticism and he uses it to improve.
One thing that I don’t think I can teach him in any reasonable amount of time, though, is how he mentally tracks the structure of the program he’s working on.
When I program, every time I change anything, I construct a mental web of everything this piece of code might affect when changed, and the ramifications it might have. I think of neighboring code and concepts looking for patterns, and whether the new thing I’m adding or changing could be better expressed differently to leverage those patterns. I think of the future trajectory of the module or feature, and whether it would be advantageous to bake-in a certain kind of forward-thinking extensibility now rather than after it becomes partially entrenched later. And most of all, I think of how someone completely unfamiliar with this code might read it, and how I can improve the way it is written to make the most important parts stand out clearest.
And when I’m debugging code, even if I see the problem and think I immediately know the solution, I still take time to read the surrounding code. I try to piece together the original bugged code’s intent. Is this onvious-looking problem the real problem? Or is it a poorly documented, poorly structured mess that looks like it wants to do one thing but is intending to do an entirely different thing? This hesitation has saved my ass on several occasions.
New dev doesn’t do any of these things. He pulls a bug ticket, figures out what module or function is the supposed source of the problem, and bangs on it until the effects of the problem disappear. Little research done to understand what the intent of the code he’s altering wants to do, and even less spent on figuring out what downstream systems will be affected. And once he achieves his singular result, he just pushes it as-is. No cleanup pass, sometimes forgets to format it the way we ask him to.
To be fair, it’s a big new codebase. I can’t expect him to reason around things he is not familiar with, nor would I think it reasonable that he study the entire codebase before touching it.
I also don’t think these things can’t be learned. I had to learn them at some point, after all. But I do believe that people like myself and one of my fellow devs are more predisposed to picking these programming soft skills up, whether it be through nature or nurture or some combination. That, and I don’t think these kinds of soft skills can really be “taught” in the traditional sense. These are wrenches you can only really learn to dodge after being hit by a few.
Ironically, as I’ve become more senior (11+ years at a faang company) I’ve had to do less and less of that “look around and understand everything” work because of time pressure. But I rely on my experience to be more confident that I can ignore the details and focus on the reason I’m in this file.
Well, that, and if it gets too messy I give up and call in a junior engineer…
Yeah, how much time you get to dwell on it will depend on lots of factors and the needs of your client/employer.
I happen to work at a place where timeframes for fixes are quite lax, and the codebase I’m working with is slowly being recussitated from a decade of bad decisions from a D-tier web developer. (Dreamweaver was involved… let’s leave it at that.) I can imagine if you have a codebase that was somewhat competently designed from the start and/or your client/employer has a “I need this fixed yesterday or else your ass is FIRED” urgency, you don’t have time to dwell on such things. But it helps to have the experience that at least lets you do it a little bit rather than not at all.
True. I have issues comprehending text and I suck at coding since I can’t read documentation well. Being bad at math is the cherry on top.