15 ms·

I see your point - this guy wrote some nice code that didn't consider "the future". I'd suggest that in a well-rounded team, there should've been a number of pe

I see your point - this guy wrote some nice code that didn't consider "the future". I'd suggest that in a well-rounded team, there should've been a number of people who he either paired with (if you believe in that sort of thing) or code-reviewed his work that should've caught that, right? You implied that would've fixed it but never happened... That's interesting. Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right? Sure, you can sorta solve the immediate problem in front of you but you're an apprentice, or mid/junior sort of a person - and I expect you to mature out of it. If you don't? Not a good fit. I'm not talking about mythical unicorns that do everything exceptionally well - just that the team should consist of folks that can generally do what is considered "Architecture" - and it should come within the team rather than someone outside of it. I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me".

ChuckMcM 14y ago
I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me". 100% agreement. I too have problems both when an individual wants to label someone as 'the architect' and or when someone demands the title. It can be a hint that the person has issues around technical disagreement (I've seen it most commonly in folks who could not reason to a position and so wanted authority to say "just do it this way." and be done with it) Every team will have a 'natural' architect which will be someone who can both engage in disagreements effectively, and they can see why things are going the way they are going, in addition to the how. Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right? In this particular case, writing code quickly was considered more valuable than architecture. But that illustrates another problem, which is often folks get mixed messages about this. Early on in your career writing code cleanly, quickly is a huge win, you get great reviews and promotions. But if you realize that you don't "see" it, when it comes to how the system goes together, well suddenly your conflicted, "Am I this great person or a fraud?" and you may respond in a number of ways. Yes, if it goes on long enough without mentoring you become a liability, if you get slapped down because you utterly failed the 'vision' test that can cause massive depression. Good mentoring is essential here. So this is where we may just agree to disagree, when you write "I expect you to mature out of it. If you don't? Not a good fit." I caution that you might find yourself throwing a great developer under the bus someday with this approach. Your mileage may vary of course, usual disclaimers Etc. Not everyone can be a good architect, not everyone can be a good developer, but not being good in one does not preclude one from being good in the other.
- MattRogish 14y ago
  "So this is where we may just agree to disagree, when you write "I expect you to mature out of it. If you don't? Not a good fit." I caution that you might find yourself throwing a great developer under the bus someday with this approach. Your mileage may vary of course, usual disclaimers Etc. Not everyone can be a good architect, not everyone can be a good developer, but not being good in one does not preclude one from being good in the other." Good arguments; that very well could be. My data is different, but obviously our mileage may vary. Plural of anecdote is not data, and all that. :)
mgkimsal 14y ago
"I see your point - this guy wrote some nice code that didn't consider "the future". I'd suggest that in a well-rounded team, there should've been a number of people who he either paired with (if you believe in that sort of thing) or code-reviewed his work that should've caught that, right? You implied that would've fixed it but never happened... That's interesting." But but but.... YAGNI. There's a constant struggle between building something that might (or perhaps even 'probably will') be needed in the future vs getting something out on deadline now. And had the guy in question built stuff to be configurable and extendable for future work, but constantly missed deadlines, he'd probably have been regarded much differently. Even when those configurability issues are found to be of much use later on, I've found that it's often not valued enough at the time it's built that way.

ChuckMcM 14y ago

I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me". 100% agreement. I too have problems both when an individual wants to label someone as 'the architect' and or when someone demands the title. It can be a hint that the person has issues around technical disagreement (I've seen it most commonly in folks who could not reason to a position and so wanted authority to say "just do it this way." and be done with it) Every team will have a 'natural' architect which will be someone who can both engage in disagreements effectively, and they can see why things are going the way they are going, in addition to the how. Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right? In this particular case, writing code quickly was considered more valuable than architecture. But that illustrates another problem, which is often folks get mixed messages about this. Early on in your career writing code cleanly, quickly is a huge win, you get great reviews and promotions. But if you realize that you don't "see" it, when it comes to how the system goes together, well suddenly your conflicted, "Am I this great person or a fraud?" and you may respond in a number of ways. Yes, if it goes on long enough without mentoring you become a liability, if you get slapped down because you utterly failed the 'vision' test that can cause massive depression. Good mentoring is essential here. So this is where we may just agree to disagree, when you write "I expect you to mature out of it. If you don't? Not a good fit." I caution that you might find yourself throwing a great developer under the bus someday with this approach. Your mileage may vary of course, usual disclaimers Etc. Not everyone can be a good architect, not everyone can be a good developer, but not being good in one does not preclude one from being good in the other.

MattRogish 14y ago
"So this is where we may just agree to disagree, when you write "I expect you to mature out of it. If you don't? Not a good fit." I caution that you might find yourself throwing a great developer under the bus someday with this approach. Your mileage may vary of course, usual disclaimers Etc. Not everyone can be a good architect, not everyone can be a good developer, but not being good in one does not preclude one from being good in the other." Good arguments; that very well could be. My data is different, but obviously our mileage may vary. Plural of anecdote is not data, and all that. :)

mgkimsal 14y ago

"I see your point - this guy wrote some nice code that didn't consider "the future". I'd suggest that in a well-rounded team, there should've been a number of people who he either paired with (if you believe in that sort of thing) or code-reviewed his work that should've caught that, right? You implied that would've fixed it but never happened... That's interesting." But but but.... YAGNI. There's a constant struggle between building something that might (or perhaps even 'probably will') be needed in the future vs getting something out on deadline now. And had the guy in question built stuff to be configurable and extendable for future work, but constantly missed deadlines, he'd probably have been regarded much differently. Even when those configurability issues are found to be of much use later on, I've found that it's often not valued enough at the time it's built that way.