6 ms·

I am one of these python+go+javascript+perl+php folks (minus go and python)... Yet somehow I know about memory access and associated gotchas. I am even able to

I am one of these python+go+javascript+perl+php folks (minus go and python)... Yet somehow I know about memory access and associated gotchas. I am even able to heavily modify, debug obscure C codebase. Even made my own LLVM pass that does quite a tricky modification of the LLVM bytecode prior to final compilation and linking. I learned about LLVM bytecode existence about 3 months ago. I started tinkering with this C project about 8 months ago... Yes, there are differences, but they are not fundamental. And with google, it really takes little time to learn things on the go. And with a team sharing necessary experience it will take no time at all. EDIT: "I might want someone who can hit the ground running" - this is luxury, so one wanting it gotta pay up... And such short projects where such quick ramp up is important perhaps will be a better suited for contracting out the work anyway.

JAlexoid 5y ago
Know of and being proficient are two different things.
- morelisp 5y ago
  Unless you are a startup that needs someone cranking out features within two weeks, the time it takes a senior[0] developer to get familiar with the company's actual work vastly outstrips the time it takes to get familiar with their commodity tech stack. (And if you are such a startup, you want mostly senior generalists anyway.) [0] Well, this is also probably begging the question. For me that's part of the definition of senior. Based on resumes I see lately it's far from everyone's.
  - JAlexoid 5y ago
    That's not universal. The lat thing I need about any of my colleagues is to learning all gotchas, at the same time as integrating into our team. Some tech I'll argue against, other tech I will require. Some tech is fundamental to a domain. Some tech is a nice to have. Some tech is just generic. My current team will not hire anyone for a senior role, without Spark experience. No matter how good you are in C++...
    - morelisp 5y ago
      > My current team will not hire anyone for a senior role, without Spark experience. An example close to my heart. The company I'm currently at had a totally ossified Spark monolith and data eng team because they only wanted Spark developers. Drop one C++ developer in there to start spreading the good news about data-oriented design and suddenly there are a dozen previously-intractable "big data" problems we can rip out of the ball of mud and run outside of the cluster. Drop in another SRE who doesn't know shit about Java but can actually write shell scripts, and hey alerts from bad orchestration from weekly to twice yearly. Yeah if you have a Spark job, you probably need a Spark dev. But if you have a team of Spark devs, suddenly everything that involves more than 1MB of input data looks like a Spark problem and you're in for a real bad time in a couple years. C++ programmers know map/reduce/filter too.
      - JAlexoid 5y ago
        Well... Funny enough. The person that our team of Spark engineers is cleaning up after was - a C++ dev. For some reason we, Spark engineers, had to rewrite his all Spark application into different components with relevant tech. Thanks for generalizing Spark engineers to an insulting level, though.
        hippich 5y ago
        I can't know for sure, but I think person you are replying to meant that in a team lacking diversity (in this particular case, diversity of expertise) all solutions tends to receive same, less than optimal treatment no matter what. If anything, it is insult of managers who create such bubbles, not engineers stuck in these bubbles.
        morelisp 5y ago
        > Thanks for generalizing Spark engineers to an insulting level, though. I have no clue how you got that from what I wrote. I even said a Spark project needs a Spark dev! It really sounds to me like you're the one generalizing from "the one C++ dev we hired couldn't do data engineering right at all" to "senior programmers are dangerous to us unless they are Spark developers" (which imo, is more indicative of serious deficiencies in your architecture / design process), to "all senior programmers crossing subdomains are dangerous."
  - magicalhippo 5y ago
    We just hired some new guys who had never developed in the language we use. They had some Java, Python and PHP background. Sent them on a course and within a couple of weeks they were committing stuff with minimal review needed in terms of language things. It's now been a year and they're still learning about our code base. For me it took about two-three years before I felt comfortable on my own in the most-used areas.
    - nevermindiguess 5y ago
      They are still learning about your code base because they are spending most of their time learning the new language. And struggling to understand your code base written in the very language they are still learning.
- hippich 5y ago
  I've solved serious problem using these two technologies, and it makes a significant impact right now. (sorry, can't discuss in more details). Sure LLVM or C pro will cringe looking at my code. But the business problem is solved, by someone who is not LLVM/C pro, and there is no need for more of that LLVM/C skills for now at the organization...
  - nevermindiguess 5y ago
    I’d never hire someone like you on my team. Sorry. You are troubleshooter: concocts something together that kind of works until they leave for their next job leaving others “with actual experience” to design solution properly. No thanks. I’ll pay for professionals rather than for someone to learn on the job, at my expense (I own the company) and deliver half backed solutions. I’ve been writing code since I was 10 (I learnt from my father, who was a developer in the 60s) and I am staggered by the lack of modesty among the new generation of developers. They all think they know so much but in my opinion when compared to the old guard they know jack. Which is fine, since they are younger - but yet, so arrogant.

JAlexoid 5y ago

Know of and being proficient are two different things.

morelisp 5y ago
Unless you are a startup that needs someone cranking out features within two weeks, the time it takes a senior[0] developer to get familiar with the company's actual work vastly outstrips the time it takes to get familiar with their commodity tech stack. (And if you are such a startup, you want mostly senior generalists anyway.) [0] Well, this is also probably begging the question. For me that's part of the definition of senior. Based on resumes I see lately it's far from everyone's.
- JAlexoid 5y ago
  That's not universal. The lat thing I need about any of my colleagues is to learning all gotchas, at the same time as integrating into our team. Some tech I'll argue against, other tech I will require. Some tech is fundamental to a domain. Some tech is a nice to have. Some tech is just generic. My current team will not hire anyone for a senior role, without Spark experience. No matter how good you are in C++...
  - morelisp 5y ago
    > My current team will not hire anyone for a senior role, without Spark experience. An example close to my heart. The company I'm currently at had a totally ossified Spark monolith and data eng team because they only wanted Spark developers. Drop one C++ developer in there to start spreading the good news about data-oriented design and suddenly there are a dozen previously-intractable "big data" problems we can rip out of the ball of mud and run outside of the cluster. Drop in another SRE who doesn't know shit about Java but can actually write shell scripts, and hey alerts from bad orchestration from weekly to twice yearly. Yeah if you have a Spark job, you probably need a Spark dev. But if you have a team of Spark devs, suddenly everything that involves more than 1MB of input data looks like a Spark problem and you're in for a real bad time in a couple years. C++ programmers know map/reduce/filter too.
    - JAlexoid 5y ago
      Well... Funny enough. The person that our team of Spark engineers is cleaning up after was - a C++ dev. For some reason we, Spark engineers, had to rewrite his all Spark application into different components with relevant tech. Thanks for generalizing Spark engineers to an insulting level, though.
      - hippich 5y ago
        I can't know for sure, but I think person you are replying to meant that in a team lacking diversity (in this particular case, diversity of expertise) all solutions tends to receive same, less than optimal treatment no matter what. If anything, it is insult of managers who create such bubbles, not engineers stuck in these bubbles.
      - morelisp 5y ago
        > Thanks for generalizing Spark engineers to an insulting level, though. I have no clue how you got that from what I wrote. I even said a Spark project needs a Spark dev! It really sounds to me like you're the one generalizing from "the one C++ dev we hired couldn't do data engineering right at all" to "senior programmers are dangerous to us unless they are Spark developers" (which imo, is more indicative of serious deficiencies in your architecture / design process), to "all senior programmers crossing subdomains are dangerous."
- magicalhippo 5y ago
  We just hired some new guys who had never developed in the language we use. They had some Java, Python and PHP background. Sent them on a course and within a couple of weeks they were committing stuff with minimal review needed in terms of language things. It's now been a year and they're still learning about our code base. For me it took about two-three years before I felt comfortable on my own in the most-used areas.
  - nevermindiguess 5y ago
    They are still learning about your code base because they are spending most of their time learning the new language. And struggling to understand your code base written in the very language they are still learning.
hippich 5y ago
I've solved serious problem using these two technologies, and it makes a significant impact right now. (sorry, can't discuss in more details). Sure LLVM or C pro will cringe looking at my code. But the business problem is solved, by someone who is not LLVM/C pro, and there is no need for more of that LLVM/C skills for now at the organization...
- nevermindiguess 5y ago
  I’d never hire someone like you on my team. Sorry. You are troubleshooter: concocts something together that kind of works until they leave for their next job leaving others “with actual experience” to design solution properly. No thanks. I’ll pay for professionals rather than for someone to learn on the job, at my expense (I own the company) and deliver half backed solutions. I’ve been writing code since I was 10 (I learnt from my father, who was a developer in the 60s) and I am staggered by the lack of modesty among the new generation of developers. They all think they know so much but in my opinion when compared to the old guard they know jack. Which is fine, since they are younger - but yet, so arrogant.