7 ms·

The idea of naming developers based on the tools they are currently using is akin to name an mechanical engineer a wrench guy or a carpenter a hammer guy. Of c

The idea of naming developers based on the tools they are currently using is akin to name an mechanical engineer a wrench guy or a carpenter a hammer guy. Of course not everyone is a computer scientist but even then everyone who is worth their salary should be able to get up to speed with a new language or deployment scenario. That being said, how many job postings do you know that explicitly mention "we work with XXX - do you think you want to, too?"

ohaideredevs 7y ago
I think devs who think they can do everything are lying to themselves. Sure, I can do Java and understand the environment. Sure I can do React and there is nothing special about it. But I am better at C#/.NET/Angular, because I have been working with edge cases for the past x years. To say I can lead a team in a Java environment would be a lie, because of all the minor details. Just because you can do something in a language doesn't mean devs are truly universal and "it's all the same." Can I write some function integration in C/Go/Powershell, etc? Sure, but when I do, I am not nearly as efficient as when I am using my daily languages/frameworks.
- aequitas 7y ago
  > Can I write some function integration in C/Go/Powershell, etc? Sure, but when I do, I am not nearly as efficient as when I am using my daily languages/frameworks. Should you be so efficient though? At the end of the day the only thing that matters for most employers is that you get the job done and the product out of the door. If your general programming knowledge with other languages frameworks allows you to quickly asses a problem and write a fix you create value, even if it not the most idiomatic solution. Of course everyone should write the best code in the most efficient and idiomatic way possible. But we don't live in an ideal world. As long as you take responsibility and apply your general knowledge together with common sense and best practices. Just don't go cowboying around a codebase just because you think every language is the same.
- JohnFen 7y ago
  > I think devs who think they can do everything are lying to themselves. I don't think I agree with this, but there's an underlying truth here. Personally, I have at least dabbled in pretty much everything that I've come across. I do this intentionally for two reasons -- first, it makes me aware of what tools exist, so I can make better tooling decisions, and second, it gives me a little head start if it becomes desirable to actually achieve competency in one of them. I'm minimally competent in a very large variety of things. I can accomplish pretty much anything with a tech if I'm minimally competent with it. It will just take me longer to do so. I'm competent in a variety of things, and I'm expert in a handful of things. An expert dev should be able to at least muddle through with pretty much any tech, where "muddle through" means that you can produce using that tech, but it will take you longer than with someone who is at least competent. But you can still do it, and recognizing that isn't lying to yourself.
  - ohaideredevs 7y ago
    I don't think we are in disagreement on "should be able to." The argument is that it's not an efficient use of time.
    - JohnFen 7y ago
      Yes, that was why my assertion was qualified. The part I disagree with is "I think devs who think they can do everything are lying to themselves." I agree that devs can't do everything efficiently.
      - bryanrasmussen 7y ago
        I think there might be some devs who can do everything, but given that nobody has ever been tested on everything how do they know - at best you know that you have never yet been unable to meet a challenge and considering some challenges you have had you can estimate how long it should take to complete similar ones.
        JohnFen 7y ago
- dpark 7y ago
  > To say I can lead a team in a Java environment would be a lie, because of all the minor details. Minor details shouldn't stop you from leading a team. If putting you in a slightly different context means you can't lead anymore, you probably weren't actually leading in your preferred context.
  - ohaideredevs 7y ago
    I wouldn't say it's a slightly different context. There is also a difference between being a "white glove" architect and a practical technical lead, who is expected to be able to help with the details. I have me a bunch of "architects" who can "do everything", until you ask them to solve a practical problem.
    - dpark 7y ago
      It's absolutely a "slightly different context". You said yourself that it's "minor details". If you can successfully lead a C# project, you can successfully lead a Java project. Would there be ramp-up? Of course. But if your leadership consists primarily of esoteric .Net knowledge, you're not actually leading.
      - ohaideredevs 7y ago
        I don't think it's esoteric at all. A co-worker is leading a .NET project, his background is Java/Ruby. He comes to me for things like: What to use for dependency injection in .NET core, Unity or native? The answer used to be Unity, now it's native. What to use for unit testing NUnit, XUnit, why? Test project separate from main proj or not (ok, this one is an obvious "separate"). Then there are questions like whether to use Entity Framework, etc. Can you read about these best practices? Sure, but knowing right off the bat (and why) is part of what makes you a lead dev imo.
        dpark 7y ago
        Regurgitating things you can learn from Stack Overflow in 15 minutes does not constitute leadership. You could write all of that stuff in a Wiki and share it with your team and suddenly your “leadership” is a commodity. Now, sure, knowing this stuff is valuable, but it’s not leadership. At best it demonstrates tenure in the particular area. Leadership is when your team members come to you to solve difficult technical tradeoffs. It’s when you are giving valuable unsolicited feedback because you see problems and want to help the team. Leadership is driving difficult changes that may not be popular but are necessary, and finding a way to sell those changes to the team. It’s taking on work that matters and postponing your own features because the success of the team matters more than the success of your particular project or area. Leadership is about leading. Not about being able to answer basic questions that anyone with a few years of experience should be able to answer. If your “leadership” is only applicable to one narrow technology, you don’t have leadership. You just have familiarity.
pbhjpbhj 7y ago
>name an mechanical engineer a wrench guy or a carpenter a hammer guy // Isn't it more like "we need a Snap-on 12mm operator", or "a Picard hammer user".
- dsr_ 7y ago
  We need candidates who have 3+ years of Picard hammers with WireWright nail systems (especially looking for WireWright 6d and 10d experience). Please no open-source hammer-and-nails people.
  - silversconfused 7y ago
    What? Why? I just lovingly forged this hammer shaped thing and some crude nails for you! Surely they are as good as any off the shelf hammer and nails! In fact, 70% of this whole village was built with these little puppies!
    - pseudocodon 7y ago
      I'm sorry, but this coding challenge was just intended to be a demonstration of your skills. We ask you to write the code "as if it were going to be deployed to production" because we want to assess your talent, but we don't actually intend to deploy your code to production. We regret to inform you that we've decided to hire another applicant.
    - dsr_ 7y ago
      The recruiter can't answer these questions; they were told by HR. The recruiter does not know that when HR asked the manager what tools the team had, the manager picked up the nearest hammer - it was a Picard - and then picked up two boxes of nails and said "these are the ones we use the most". HR helpfully copied over the information from the side of the box and then specified 3 years because the manager said that they wanted people who could be trusted with a hammer and nails already.
  - bryanrasmussen 7y ago
    When all you have is an open source hammer every nail can be configured to be hit.
jgon 7y ago
I actually think that this metaphor proves the opposite point you are trying to make. Mechanical engineers are definitely segregated based on the types of systems they work on, in much the same way that we would describe the "back-end" "front-end" split. You don't hire a "mechanical engineer", unless they are truly a new grad. You hiring an HVAC Engineer (have friend with Mech. Eng. degrees who do this), or a drilling engineer (again have Mech. Eng. friends who do this), or an engineer to work on mechanical control systems for chemical plants, etc, etc and you won't find these engineers boldly saying "Yeah I spent 15 years working on HVAC systems but how hard can these avionic systems be?" So yeah, we don't name mechanical engineers "wrench guys" or "hammer guys", but those fields definitely don't presume that there isn't an incredible depth of acquired knowledge and lore that one needs to be effective in them, and that can only be acquired through experience, and which is generally not transferable to other fields.
aequitas 7y ago
I would rather compare it to car mechanics. Even though every car has the same parts (engine, wheel). Every brand has their own specific way of putting things together. The general principle is the same, but one mechanic just perfectly knows the ins and outs of a specific brands diagnostics tools or the failure symptoms and solutions. Where for another brand he would have to consult a manual.
andrewmcwatters 7y ago
"I'm looking for a guy who does drywall." "Sorry, I specialize in lath and plaster."

ohaideredevs 7y ago

I think devs who think they can do everything are lying to themselves. Sure, I can do Java and understand the environment. Sure I can do React and there is nothing special about it. But I am better at C#/.NET/Angular, because I have been working with edge cases for the past x years. To say I can lead a team in a Java environment would be a lie, because of all the minor details. Just because you can do something in a language doesn't mean devs are truly universal and "it's all the same." Can I write some function integration in C/Go/Powershell, etc? Sure, but when I do, I am not nearly as efficient as when I am using my daily languages/frameworks.

aequitas 7y ago
> Can I write some function integration in C/Go/Powershell, etc? Sure, but when I do, I am not nearly as efficient as when I am using my daily languages/frameworks. Should you be so efficient though? At the end of the day the only thing that matters for most employers is that you get the job done and the product out of the door. If your general programming knowledge with other languages frameworks allows you to quickly asses a problem and write a fix you create value, even if it not the most idiomatic solution. Of course everyone should write the best code in the most efficient and idiomatic way possible. But we don't live in an ideal world. As long as you take responsibility and apply your general knowledge together with common sense and best practices. Just don't go cowboying around a codebase just because you think every language is the same.
JohnFen 7y ago
> I think devs who think they can do everything are lying to themselves. I don't think I agree with this, but there's an underlying truth here. Personally, I have at least dabbled in pretty much everything that I've come across. I do this intentionally for two reasons -- first, it makes me aware of what tools exist, so I can make better tooling decisions, and second, it gives me a little head start if it becomes desirable to actually achieve competency in one of them. I'm minimally competent in a very large variety of things. I can accomplish pretty much anything with a tech if I'm minimally competent with it. It will just take me longer to do so. I'm competent in a variety of things, and I'm expert in a handful of things. An expert dev should be able to at least muddle through with pretty much any tech, where "muddle through" means that you can produce using that tech, but it will take you longer than with someone who is at least competent. But you can still do it, and recognizing that isn't lying to yourself.
- ohaideredevs 7y ago
  I don't think we are in disagreement on "should be able to." The argument is that it's not an efficient use of time.
  - JohnFen 7y ago
    Yes, that was why my assertion was qualified. The part I disagree with is "I think devs who think they can do everything are lying to themselves." I agree that devs can't do everything efficiently.
    - bryanrasmussen 7y ago
      I think there might be some devs who can do everything, but given that nobody has ever been tested on everything how do they know - at best you know that you have never yet been unable to meet a challenge and considering some challenges you have had you can estimate how long it should take to complete similar ones.
      - JohnFen 7y ago
dpark 7y ago
> To say I can lead a team in a Java environment would be a lie, because of all the minor details. Minor details shouldn't stop you from leading a team. If putting you in a slightly different context means you can't lead anymore, you probably weren't actually leading in your preferred context.
- ohaideredevs 7y ago
  I wouldn't say it's a slightly different context. There is also a difference between being a "white glove" architect and a practical technical lead, who is expected to be able to help with the details. I have me a bunch of "architects" who can "do everything", until you ask them to solve a practical problem.
  - dpark 7y ago
    It's absolutely a "slightly different context". You said yourself that it's "minor details". If you can successfully lead a C# project, you can successfully lead a Java project. Would there be ramp-up? Of course. But if your leadership consists primarily of esoteric .Net knowledge, you're not actually leading.
    - ohaideredevs 7y ago
      I don't think it's esoteric at all. A co-worker is leading a .NET project, his background is Java/Ruby. He comes to me for things like: What to use for dependency injection in .NET core, Unity or native? The answer used to be Unity, now it's native. What to use for unit testing NUnit, XUnit, why? Test project separate from main proj or not (ok, this one is an obvious "separate"). Then there are questions like whether to use Entity Framework, etc. Can you read about these best practices? Sure, but knowing right off the bat (and why) is part of what makes you a lead dev imo.
      - dpark 7y ago
        Regurgitating things you can learn from Stack Overflow in 15 minutes does not constitute leadership. You could write all of that stuff in a Wiki and share it with your team and suddenly your “leadership” is a commodity. Now, sure, knowing this stuff is valuable, but it’s not leadership. At best it demonstrates tenure in the particular area. Leadership is when your team members come to you to solve difficult technical tradeoffs. It’s when you are giving valuable unsolicited feedback because you see problems and want to help the team. Leadership is driving difficult changes that may not be popular but are necessary, and finding a way to sell those changes to the team. It’s taking on work that matters and postponing your own features because the success of the team matters more than the success of your particular project or area. Leadership is about leading. Not about being able to answer basic questions that anyone with a few years of experience should be able to answer. If your “leadership” is only applicable to one narrow technology, you don’t have leadership. You just have familiarity.

pbhjpbhj 7y ago

>name an mechanical engineer a wrench guy or a carpenter a hammer guy // Isn't it more like "we need a Snap-on 12mm operator", or "a Picard hammer user".

dsr_ 7y ago
We need candidates who have 3+ years of Picard hammers with WireWright nail systems (especially looking for WireWright 6d and 10d experience). Please no open-source hammer-and-nails people.
- silversconfused 7y ago
  What? Why? I just lovingly forged this hammer shaped thing and some crude nails for you! Surely they are as good as any off the shelf hammer and nails! In fact, 70% of this whole village was built with these little puppies!
  - pseudocodon 7y ago
    I'm sorry, but this coding challenge was just intended to be a demonstration of your skills. We ask you to write the code "as if it were going to be deployed to production" because we want to assess your talent, but we don't actually intend to deploy your code to production. We regret to inform you that we've decided to hire another applicant.
  - dsr_ 7y ago
    The recruiter can't answer these questions; they were told by HR. The recruiter does not know that when HR asked the manager what tools the team had, the manager picked up the nearest hammer - it was a Picard - and then picked up two boxes of nails and said "these are the ones we use the most". HR helpfully copied over the information from the side of the box and then specified 3 years because the manager said that they wanted people who could be trusted with a hammer and nails already.
- bryanrasmussen 7y ago
  When all you have is an open source hammer every nail can be configured to be hit.

jgon 7y ago

I actually think that this metaphor proves the opposite point you are trying to make. Mechanical engineers are definitely segregated based on the types of systems they work on, in much the same way that we would describe the "back-end" "front-end" split. You don't hire a "mechanical engineer", unless they are truly a new grad. You hiring an HVAC Engineer (have friend with Mech. Eng. degrees who do this), or a drilling engineer (again have Mech. Eng. friends who do this), or an engineer to work on mechanical control systems for chemical plants, etc, etc and you won't find these engineers boldly saying "Yeah I spent 15 years working on HVAC systems but how hard can these avionic systems be?" So yeah, we don't name mechanical engineers "wrench guys" or "hammer guys", but those fields definitely don't presume that there isn't an incredible depth of acquired knowledge and lore that one needs to be effective in them, and that can only be acquired through experience, and which is generally not transferable to other fields.

aequitas 7y ago

I would rather compare it to car mechanics. Even though every car has the same parts (engine, wheel). Every brand has their own specific way of putting things together. The general principle is the same, but one mechanic just perfectly knows the ins and outs of a specific brands diagnostics tools or the failure symptoms and solutions. Where for another brand he would have to consult a manual.

andrewmcwatters 7y ago

"I'm looking for a guy who does drywall." "Sorry, I specialize in lath and plaster."