5 ms·

Spot on - 40 years of coding, 33 professionally, and your list resonates with me. I'd also add: write code in tiny pieces where you don't do the next piece un

Spot on - 40 years of coding, 33 professionally, and your list resonates with me. I'd also add: write code in tiny pieces where you don't do the next piece until you're confident the current piece works. I get fidgety when I have a bunch of code I don't know works. Mostly, though, I can tell a grizzled veteran (and I've known some that hardly had any years under their belt, it's all in the soul!) because they rarely claim to know The Answer, and have a weary self-confidence that, even though they don't know how, they will get the job done. Last year, after experiencing several individuals that fit the term, I came to calling some people "Medium Developers" - generally falling in the 4-8 years of experience, that get much of their knowledge from Medium articles, and believe the dogma wholeheartedly. Complete lack of nuance in all things, and are very evangelical about their dogma. Shitty managers are enthralled with them, and the code written (slowly) in such situations is horrific. "Throw it out and do it the Right Way (tm)" is the mantra. Honestly, the blog post in the OP sounds like a Medium Programmer. They're worship of TDD is one symptom! "I don't know, but we'll figure it out" is what I like to hear, versus, "This is how it Must Be Done!"

jmilloy 7y ago
> write code in tiny pieces where you don't do the next piece until you're confident the current piece works. I get fidgety when I have a bunch of code I don't know works. I think getting to this point really helps with the "flow" issue ("coding is not a social activity"). The more you can isolate small steps, you can more easily weather interruptions. > They're worship of TDD is one symptom! My suspicion is that this person is very good at writing the tests, at the right level of isolation and detail, and that watching them work would feel less dogmatic that the text of the blog post suggests.
JimboOmega 7y ago
> "I don't know, but we'll figure it out" is what I like to hear, versus, "This is how it Must Be Done!" I've had this argument multiple times recently. Usually when I say the former the response is something like "But how can we really estimate it or plan it before we know exactly what we're doing" Writing overly detailed requirements without coding gives me the same feeling of fidgetiness you mention. My attitude is "Plans are worthless, but planning is essential" , and you have to cut off design at some point because the risk (that you discover something in coding that invalidates the plan) outpaces the value (of knowing what you're doing). Reminds me of another problem I've seen recently - an obsession with writing code that is "overly correct". There are times where a small change of a few lines accomplishes a thing but produces some undesirable side effect - it breaks an expectation somewhere, for instance. But the alternative is rewriting a huge portion and adding a ton of code and adding complexity as a result, even if the methods and their responsibilities are more clear. "Throw it out and do it the Right Way", in other words. We've become very conditioned (especially mid-career) with focusing on never allowing tech debt and doing it the right way. But sometimes you actually add complexity in trying to achieve perfect cleanliness. And in fact, even if the resulting code is slightly less complex, there is a lot of risk in the rewrite. At my stage of my career - 15 years - the biggest conflict I see is between business that wants estimates and the inherent unpredictability of writing software. Business wants the list of things I'm going to get done, meanwhile I want priorities. Are you able to say "Hey, this thing I thought might take a week is actually a quarter long project, should we set it aside knowing that?" Often the org is simply not flexible enough to handle that (or handle scoping it down so it can get done in a reasonable amount of time). I'd almost say what you describe is the sign of a mid-experienced manager, too. They've realized it's important to shield their team from some organization problems so they can write quality code (moving past the "yell at them until it gets done" phase). But they haven't really learned how to get past the mid-level engineer obsession with beautiful code, or to handle the general complexity of the inherent clash between business goals and engineering goals - they've gone full towards the engineer side of that spectrum.

jmilloy 7y ago

> write code in tiny pieces where you don't do the next piece until you're confident the current piece works. I get fidgety when I have a bunch of code I don't know works. I think getting to this point really helps with the "flow" issue ("coding is not a social activity"). The more you can isolate small steps, you can more easily weather interruptions. > They're worship of TDD is one symptom! My suspicion is that this person is very good at writing the tests, at the right level of isolation and detail, and that watching them work would feel less dogmatic that the text of the blog post suggests.

JimboOmega 7y ago

> "I don't know, but we'll figure it out" is what I like to hear, versus, "This is how it Must Be Done!" I've had this argument multiple times recently. Usually when I say the former the response is something like "But how can we really estimate it or plan it before we know exactly what we're doing" Writing overly detailed requirements without coding gives me the same feeling of fidgetiness you mention. My attitude is "Plans are worthless, but planning is essential" , and you have to cut off design at some point because the risk (that you discover something in coding that invalidates the plan) outpaces the value (of knowing what you're doing). Reminds me of another problem I've seen recently - an obsession with writing code that is "overly correct". There are times where a small change of a few lines accomplishes a thing but produces some undesirable side effect - it breaks an expectation somewhere, for instance. But the alternative is rewriting a huge portion and adding a ton of code and adding complexity as a result, even if the methods and their responsibilities are more clear. "Throw it out and do it the Right Way", in other words. We've become very conditioned (especially mid-career) with focusing on never allowing tech debt and doing it the right way. But sometimes you actually add complexity in trying to achieve perfect cleanliness. And in fact, even if the resulting code is slightly less complex, there is a lot of risk in the rewrite. At my stage of my career - 15 years - the biggest conflict I see is between business that wants estimates and the inherent unpredictability of writing software. Business wants the list of things I'm going to get done, meanwhile I want priorities. Are you able to say "Hey, this thing I thought might take a week is actually a quarter long project, should we set it aside knowing that?" Often the org is simply not flexible enough to handle that (or handle scoping it down so it can get done in a reasonable amount of time). I'd almost say what you describe is the sign of a mid-experienced manager, too. They've realized it's important to shield their team from some organization problems so they can write quality code (moving past the "yell at them until it gets done" phase). But they haven't really learned how to get past the mid-level engineer obsession with beautiful code, or to handle the general complexity of the inherent clash between business goals and engineering goals - they've gone full towards the engineer side of that spectrum.