4 ms·

I'm currently working with a C++ dev who has exactly zero previous experience with the web, but because he essentially finished his part of the system, he picke

by Tade0 5y ago

I'm currently working with a C++ dev who has exactly zero previous experience with the web, but because he essentially finished his part of the system, he picked up web-related tasks. My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program". I mean, the guy has a PhD in physics - I bet that what he's doing now isn't even his final form.

nicoburns 5y ago
> My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program". > I mean, the guy has a PhD in physics - I bet that what he's doing now isn't even his final form. I don't doubt that they guy you work with is excellent and is able to seamlessly make this switch, but I have previously worked with someone who was excellent at C++, and had a PhD in something maths related (can't remember what exactly), and completely failed to get anywhere with JavaScript. As in: took 2 weeks to write a script that would take me a couple of hours, and it was still in a pretty bad state at that point. It seems that they hadn't encountered async programming before and really struggled to get their head around it. The silly thing is their program didn't actually require any concurrency so they could just have stuck an `await` on each async function call and treated it like synchronous code, but they were convinced that async-await was too complicated to learn up front so they had a complete mess tracking everything with callbacks.
- blahgeek 5y ago
  I won’t say someone is good at programming if he/she cannot learn JavaScript in two weeks
  - nicoburns 5y ago
    Perhaps not in a general sense. But that they were certainly good enough at C++ that my employer was quite happy with their performance at those tasks. They just weren't very good at translating that to areas they were less familiar with.
  - jiggawatts 5y ago
    I agree, you'd have to be a pretty bad programmer if you can't wrap your head around JavaScript in a couple of weeks. TypeScript even. Also, React. Babel. Grunt. Gulp. NPM. Node. Cobertura. Comfey. JQuery. Angular. Vue. Bootstrap. Flutter. Mocha. Minior. Yarn. Leftpad. Webpack. Npx. JSON. Rest. CORS. XMLHttpRequest. WebSockets. Web Storage. IndexDB. Actually, I think some of those might be Pokemon.
    - brimble 5y ago
      I've never had the experience that learning a language is harder than learning the culture and (usually bad) tools around it. Stuff like "oh no, I know the official docs say that, but no one does it that way" or "this tool is a 'hip, faster, drop-in replacement' and you'll see it recommended everywhere but the last part is actaully a lie" or "the platform says it supports this language but actually the tools are so broken that it effectively does not" et c. [EDIT] I had in mind Android, Yarn, and AWS Lambda + Java (as of a couple years ago, anyway), in order, for those examples, for the curious :-)
- injidup 5y ago
  And why wasn't someone there to ease him over the culture hurdle? I've taken people who had no idea about Async and baby sat them till it clicked. But left alone it would never have happened. New hires should not just be thrown a task, left alone and then be slandered two weeks later on hacker News when they get it wrong.
  - nicoburns 5y ago
    A combination of bad management (nobody set up that mentoring relationship), and insecurity on their part (I tried to do just that, but they wouldn't accept the help). > New hires should not just be thrown a task, left alone and then be slandered two weeks later on hacker News when they get it wrong. They were certainly not a new hire (they'd been at the company 7 years - if anything I was the new hire!), but I generally agree. My point was merely that while some people will easily transfer their skills to different languages and domains, this won't be true of everyone.
    - wildmanx 5y ago
      > They were certainly not a new hire (they'd been at the company 7 years - if anything I was the new hire!), but I generally agree. That tends to make it harder. I've experienced quite a few people more "senior" than me (either age-wise or company-tenure-wise or both) who had trouble having the less-senior guy telling them things like suggesting different designs or code refactors. Some things were just not obvious why my suggestions were better, but they were based on experience with this particular technology. So they preferred to ignore the advice and run into the issues I and other colleagues had run into 3 years prior cause they didn't want to listen. Sadly, they didn't always have to live with the consequences since some of them moved on before the consequences became obvious, so we had to clean up the mess we were suggesting against in the first place.
    - injidup 5y ago
      Ok. That's a bit different. Somebody who has been at the company for 7 years should also have the sense to ask around. But you are also right. I've worked with mathematicians and PHD's much smarter in the domain than me who wrote spaghetti code and often couldn't see the point in good code hygiene.
- yodsanklai 5y ago
  > It seems that they hadn't encountered async programming before and really struggled to get their head around it. Seems totally normal. And most likely, after a few weeks this person would get the concept.
  - FpUser 5y ago
    This is interesting. Personally I did not need to "encounter" async. At some point I realized that I needed it in my project (it did not have that official name back then) and had written an implementation in a few days. I also written preemptive multithreading library in ancient DOS based product with having zero prior experience. Again took me few days.
- dgb23 5y ago
  Can confirm, async programming - whether done with callbacks/promises/sugar is tangential here - is a conceptual stumbling block for some at first, and that includes smart programmers who haven't done much in terms of Web or GUI programming. Add the concept of static scoping and closures and you have a few things to absorb first, before you get comfortable. It has to click. Reminds me of stochastics in school, which was a subject that wasn't immediately natural for some who were otherwise very good at math in general. For me it's bit fiddling for example: I bought Hacker's Delight some months ago and first had to really work through even the most basic things on paper until it stopped to feel like magical hieroglyphs.
oblio 5y ago
I don't agree with this assumption because of a hidden variable: time. Even the smartest person on this planet still needs time to learn things. Someone just starting to use a new environment won't have the months and years of practical experience with the many frameworks and libraries out there. They won't have the battle scars to know out why one library is better than the other one for this specific use case. They won't have the experience to know why structuring the code in this specific way is better than the other way. And thing about the other myriad gotchas every environment has, that someone only picks up over time, as they try to use all the corners of a specific software stack. I mean, yeah, sure, a smart dev will look up best practices and carry over some of their existing experience, but unless they're a true polyglot (and that takes many years as you probably need at least 1 super intense year with each or more like 2-3 years with several), they will still be a solid mid level dev, but not a true senior dev using the new framework.
- NicoJuicy 5y ago
  Ask someone more experienced to suggest a framework. Read documentation and implement.
  - oblio 5y ago
    And that takes time. If you're telling me that anyone can be as good as someone else who is equally smart but with 2-3 years of experience with that specific tech stack, I'd say that can't be true, almost by definition.
    - withinboredom 5y ago
      Have to agree with you there. I started a job using the exact same stack I was using in a hobby project. I had my dev environment fully up in less than two hours and had production ready PRs by noon. On my first day. Then someone got it in their head to rewrite everything in react (2014) and we slowed to an absolute crawl. We never saw the momentum we had pre-react, at least before I moved on two years later.
    - NicoJuicy 5y ago
continuational 5y ago
But is it efficient? I would say web programming takes about a decade to become proficient in, after you learned to program. There are so many (perhaps accidental) things to know about the DOM, CSS, HTTP, web standards and practices, interactivity, hosting models, database tech, caching & CDNs, integrations & APIs, and god forbid, any "connect the dots" design and ux work that lands on your table.
- Tade0 5y ago
  Let's just say that we're in a large corporation and the bar is set appropriately. His tasks are currently backend-ish(still TypeScript though). I wouldn't throw anyone into the deep waters of frontend unprepared.
sokoloff 5y ago
> My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program". That’s seems an off-axis question to me. “These devs are expensive and a constraint on our growth. I want to hear more tappy-tappy…” What’s the alternative if you have a good backend programmer and an excess of front-end work at the moment? Have the backend plow further ahead? Move items that “belong” in the front-end to the backend just for dev capacity reasons? Decide your architecture based on which devs are free in a given sprint? That backend dev might be 50% as efficient and still result in more total value delivered.
- mwcampbell 5y ago
  Alternatively, one could go with a one-person framework [1]. In addition to Rails, I think Phoenix is pushing in that direction. On the JavaScript side, Remix and Blitz are interesting, though I generally don't like the SPA approach. I don't see frameworks in other mainstream languages, such as Django, Spring, or ASP.NET Core, trying to unify front-end and back-end like Rails and Phoenix are. [1]: https://world.hey.com/dhh/the-one-person-framework-711e6318 https://world.hey.com/dhh/the-one-person-framework-711e6318
gilbetron 5y ago
I've worked with numerous people with PhDs in Physics (and Math and other heavy science fields) and they tend to be pretty awful at production software while at the same time having very strong opinions that the field is "broken". I mean, think about it, 99.99% (at least) of physics and math is learning what has already been solved. It is heavy, complicated learning, but is far from the type of learning you do in a new field like software development.
- lubesGordi 5y ago
  Non-CS people tend to be completely pragmatic in my experience. They aren't the ones having arguments over the 'art' side of software engineering like everyone else.

by Tade0 5y ago

nicoburns 5y ago

> My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program". > I mean, the guy has a PhD in physics - I bet that what he's doing now isn't even his final form. I don't doubt that they guy you work with is excellent and is able to seamlessly make this switch, but I have previously worked with someone who was excellent at C++, and had a PhD in something maths related (can't remember what exactly), and completely failed to get anywhere with JavaScript. As in: took 2 weeks to write a script that would take me a couple of hours, and it was still in a pretty bad state at that point. It seems that they hadn't encountered async programming before and really struggled to get their head around it. The silly thing is their program didn't actually require any concurrency so they could just have stuck an `await` on each async function call and treated it like synchronous code, but they were convinced that async-await was too complicated to learn up front so they had a complete mess tracking everything with callbacks.

blahgeek 5y ago
I won’t say someone is good at programming if he/she cannot learn JavaScript in two weeks
- nicoburns 5y ago
  Perhaps not in a general sense. But that they were certainly good enough at C++ that my employer was quite happy with their performance at those tasks. They just weren't very good at translating that to areas they were less familiar with.
- jiggawatts 5y ago
  I agree, you'd have to be a pretty bad programmer if you can't wrap your head around JavaScript in a couple of weeks. TypeScript even. Also, React. Babel. Grunt. Gulp. NPM. Node. Cobertura. Comfey. JQuery. Angular. Vue. Bootstrap. Flutter. Mocha. Minior. Yarn. Leftpad. Webpack. Npx. JSON. Rest. CORS. XMLHttpRequest. WebSockets. Web Storage. IndexDB. Actually, I think some of those might be Pokemon.
  - brimble 5y ago
    I've never had the experience that learning a language is harder than learning the culture and (usually bad) tools around it. Stuff like "oh no, I know the official docs say that, but no one does it that way" or "this tool is a 'hip, faster, drop-in replacement' and you'll see it recommended everywhere but the last part is actaully a lie" or "the platform says it supports this language but actually the tools are so broken that it effectively does not" et c. [EDIT] I had in mind Android, Yarn, and AWS Lambda + Java (as of a couple years ago, anyway), in order, for those examples, for the curious :-)
injidup 5y ago
And why wasn't someone there to ease him over the culture hurdle? I've taken people who had no idea about Async and baby sat them till it clicked. But left alone it would never have happened. New hires should not just be thrown a task, left alone and then be slandered two weeks later on hacker News when they get it wrong.
- nicoburns 5y ago
  A combination of bad management (nobody set up that mentoring relationship), and insecurity on their part (I tried to do just that, but they wouldn't accept the help). > New hires should not just be thrown a task, left alone and then be slandered two weeks later on hacker News when they get it wrong. They were certainly not a new hire (they'd been at the company 7 years - if anything I was the new hire!), but I generally agree. My point was merely that while some people will easily transfer their skills to different languages and domains, this won't be true of everyone.
  - wildmanx 5y ago
    > They were certainly not a new hire (they'd been at the company 7 years - if anything I was the new hire!), but I generally agree. That tends to make it harder. I've experienced quite a few people more "senior" than me (either age-wise or company-tenure-wise or both) who had trouble having the less-senior guy telling them things like suggesting different designs or code refactors. Some things were just not obvious why my suggestions were better, but they were based on experience with this particular technology. So they preferred to ignore the advice and run into the issues I and other colleagues had run into 3 years prior cause they didn't want to listen. Sadly, they didn't always have to live with the consequences since some of them moved on before the consequences became obvious, so we had to clean up the mess we were suggesting against in the first place.
  - injidup 5y ago
    Ok. That's a bit different. Somebody who has been at the company for 7 years should also have the sense to ask around. But you are also right. I've worked with mathematicians and PHD's much smarter in the domain than me who wrote spaghetti code and often couldn't see the point in good code hygiene.
yodsanklai 5y ago
> It seems that they hadn't encountered async programming before and really struggled to get their head around it. Seems totally normal. And most likely, after a few weeks this person would get the concept.
- FpUser 5y ago
  This is interesting. Personally I did not need to "encounter" async. At some point I realized that I needed it in my project (it did not have that official name back then) and had written an implementation in a few days. I also written preemptive multithreading library in ancient DOS based product with having zero prior experience. Again took me few days.
dgb23 5y ago
Can confirm, async programming - whether done with callbacks/promises/sugar is tangential here - is a conceptual stumbling block for some at first, and that includes smart programmers who haven't done much in terms of Web or GUI programming. Add the concept of static scoping and closures and you have a few things to absorb first, before you get comfortable. It has to click. Reminds me of stochastics in school, which was a subject that wasn't immediately natural for some who were otherwise very good at math in general. For me it's bit fiddling for example: I bought Hacker's Delight some months ago and first had to really work through even the most basic things on paper until it stopped to feel like magical hieroglyphs.

oblio 5y ago

I don't agree with this assumption because of a hidden variable: time. Even the smartest person on this planet still needs time to learn things. Someone just starting to use a new environment won't have the months and years of practical experience with the many frameworks and libraries out there. They won't have the battle scars to know out why one library is better than the other one for this specific use case. They won't have the experience to know why structuring the code in this specific way is better than the other way. And thing about the other myriad gotchas every environment has, that someone only picks up over time, as they try to use all the corners of a specific software stack. I mean, yeah, sure, a smart dev will look up best practices and carry over some of their existing experience, but unless they're a true polyglot (and that takes many years as you probably need at least 1 super intense year with each or more like 2-3 years with several), they will still be a solid mid level dev, but not a true senior dev using the new framework.

NicoJuicy 5y ago
Ask someone more experienced to suggest a framework. Read documentation and implement.
- oblio 5y ago
  And that takes time. If you're telling me that anyone can be as good as someone else who is equally smart but with 2-3 years of experience with that specific tech stack, I'd say that can't be true, almost by definition.
  - withinboredom 5y ago
    Have to agree with you there. I started a job using the exact same stack I was using in a hobby project. I had my dev environment fully up in less than two hours and had production ready PRs by noon. On my first day. Then someone got it in their head to rewrite everything in react (2014) and we slowed to an absolute crawl. We never saw the momentum we had pre-react, at least before I moved on two years later.
  - NicoJuicy 5y ago

continuational 5y ago

But is it efficient? I would say web programming takes about a decade to become proficient in, after you learned to program. There are so many (perhaps accidental) things to know about the DOM, CSS, HTTP, web standards and practices, interactivity, hosting models, database tech, caching & CDNs, integrations & APIs, and god forbid, any "connect the dots" design and ux work that lands on your table.

Tade0 5y ago
Let's just say that we're in a large corporation and the bar is set appropriately. His tasks are currently backend-ish(still TypeScript though). I wouldn't throw anyone into the deep waters of frontend unprepared.

sokoloff 5y ago

> My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program". That’s seems an off-axis question to me. “These devs are expensive and a constraint on our growth. I want to hear more tappy-tappy…” What’s the alternative if you have a good backend programmer and an excess of front-end work at the moment? Have the backend plow further ahead? Move items that “belong” in the front-end to the backend just for dev capacity reasons? Decide your architecture based on which devs are free in a given sprint? That backend dev might be 50% as efficient and still result in more total value delivered.

mwcampbell 5y ago
Alternatively, one could go with a one-person framework [1]. In addition to Rails, I think Phoenix is pushing in that direction. On the JavaScript side, Remix and Blitz are interesting, though I generally don't like the SPA approach. I don't see frameworks in other mainstream languages, such as Django, Spring, or ASP.NET Core, trying to unify front-end and back-end like Rails and Phoenix are. [1]: https://world.hey.com/dhh/the-one-person-framework-711e6318 https://world.hey.com/dhh/the-one-person-framework-711e6318

gilbetron 5y ago

I've worked with numerous people with PhDs in Physics (and Math and other heavy science fields) and they tend to be pretty awful at production software while at the same time having very strong opinions that the field is "broken". I mean, think about it, 99.99% (at least) of physics and math is learning what has already been solved. It is heavy, complicated learning, but is far from the type of learning you do in a new field like software development.

lubesGordi 5y ago
Non-CS people tend to be completely pragmatic in my experience. They aren't the ones having arguments over the 'art' side of software engineering like everyone else.