5 ms·

Absolutely, I feel I could be employed tomorrow in a language or stack that I haven’t even heard of and start being productive by the end of the week! I seriou

by demarq 3y ago

Absolutely, I feel I could be employed tomorrow in a language or stack that I haven’t even heard of and start being productive by the end of the week! I seriously think you owe it to yourself to practice learning something new every week. It often takes one afternoon to get a “taste” and small side project to get beyond that. Every programming language. Is literally just a template for instructions, and every technology just an abstraction over some crud somewhere.

scarface_74 3y ago
So could you be a productive iOS/Android developer in a week with no previous experience?
- ChrisMarshallNY 3y ago
  My experience is that learning a new language -at a basic level- can be done quickly (like a couple of weeks, not days). But learning it at an advanced level, is a whole different matter. I've been writing Swift since, literally, a few hours after it was announced, in 2014. I write Swift every day (like, seven days a week), and have been, since that first day. I feel as if I have only had "mastery" of the language for the last couple of years. There's still plenty for me to learn, and they keep adding more stuff. But the language isn't the big deal. The deal for me, is the fundamental SDK/API/Framework. That has been an ongoing project since 1986. As soon as I learn one API, they change it up (and sometimes, the entire OS). During that time, I've written in 68K ASM, Pascal, Object Pascal, C, C+- (the weird THINK C variant), C++. ObjC, and Swift. I've worked with MacApp, OpenDoc(!), Think Libraries (Pascal and C), PowerPlant, and Cocoa (and its expression in iOS, WatchOS, AppKit, and TVOS). I've always considered hiring folks to be an investment. As a manager, I always looked for folks that had the fundamentals down, and assumed that I could train them into what we need. Most of the work we did, was way beyond anything you'd find in textbooks. I was under no illusion that I could hire folks that would be able to start on it right away. That was why my team was always one that I wanted to keep whole and cohesive, over many years. I can't even imagine today's 18-month engineer lifetime. I kept my engineers for many years, and that wasn't easy.
  - scarface_74 3y ago
    I just said something similar in another reply https://news.ycombinator.com/item?id=37099395 https://news.ycombinator.com/item?id=37099395 But as far as employees being an “investment” let’s look at things from the employee side. For context: these numbers I’m about to cite are correct to within a first approximation on the “enterprise dev” side where most of the 2.7 million developers work and in most major cities in the US that are not on the west coast or in NYC Let’s say you hire a Junior/mid level developer and offer them $100K which is fair knowing they are going to do “negative work” for the first few months as an investment. Two years later, they have experience and now can apply for companies that are looking for experienced iOS developers. Their market rate shot up to $135k. Because of salary compression and inversion, you’re not going to be able to pay them 35% more in two years because of HR policies. Yet you can bring in new experienced iOS developers at market rate. If he’s smart your employee is going to jump ship, wasting a lot of your “investment”. As a hiring manager, knowing that statistically I’m only going to get two years out of an employee, why wouldn’t I just poach the person you just trained and pay them the $135K you couldn’t? Another scenario is that now that developer has been reading r/cscareerquestions and decided to “grind leetcode and work for a FAANG”. Now he’s looking at $200K+ as a mid level developer adding yet more bloat to the Facebook app. You couldn’t compete with that if you wanted to.
    - ChrisMarshallNY 3y ago
      > You couldn’t compete with that if you wanted to. Unfortunately, I was forced to. My company was one that paid “competitive” salaries. That’s code for “below average.” This filtered out 90% of applicants, right there. So the ones that applied, did so, out of genuine interest in the company and the technology (we were a “marquee” company). I was forced to look for “diamonds in the rough,” and became fairly good at evaluating whether or not someone could handle the tech and the learning. I kept them, by being a really good manager. I treated them with respect, didn’t burn them out, and shielded them from a lot of the corporate BS. They appreciated that, and stayed. When our team was finally rolled up, after just short of 27 years, the employee with the least tenure had ten years. These were seasoned C++ image processing professionals.
- doix 3y ago
  Not iOS, but I'm fairly confident I could be productive in an Android codebase in a week. The only reason I don't think I could do iOS is because I'd need to use a OSX, and I think it would take me longer to become productive in OSX. It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating new features? Sure. I did a trial week before joining my current gig full-time. I had pretty much no typescript experience, came into a large TS react/nodejs app and had a pull request on the 2nd day for a new feature. I wouldn't try to work on a Haskell or OCaml codebase, they are different enough that I'm not confident I could pick them up quickly. But most mainstream languages are similar enough that it really shouldn't be that hard to pick them up and be productive.
  - scarface_74 3y ago
    > It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating new features? Sure. As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”? And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap.
    - doix 3y ago
      > As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”? I dislike the whole Agile stories/points/sprints thing, so probably not those jobs. But if you're asking if I'm applying to jobs where I write code, then yep! I love writing code and building things. > And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap. I don't know what other experience you have, but probably. At my previous job, I got a bunch of silicon production test engineers, that spend most of their day writing VBA, "productive" in React within a week. I setup the base of the application and sorted out the routing, state management and abstractions for dealing with our data. But they were writing views and features after a week pretty well. I had to point out some performance issues in code reviews but that was mainly it.
- carstenhag 3y ago
  During Covid I had a colleague, mainly web/js/angular dev, join the Android team. It was a new project to him, so he had 0 idea of the business problems, flows, etc. In a timeframe of 1-2 weeks he was making PRs. It needed quite some reviews from me, usually because he didn't know about "how it should behave" on Android, or what the best practices were in terms of using Kotlin or following our architecture. After 2-3 months he was as proficient coding as I basically (but we all know, coding is 50%).
- em-bee 3y ago
  i did this with php and python in two different jobs. i had very little php experience and never worked with any php framework before, but the team i was in consisted mostly of junior developers, so i ended up writing better code than any of them except the team lead. laravel was also very easy to understand. at another job i started with only some rudimentary python experience. they had an inhouse framework, so being deeply familiar with python frameworks and libraries would not have even helped me. they knew i had experience in other languages and it worked out pretty well. most recently i had an interview where it was very clear that i haven't done any work on go before. at least during the interview that was not an issue. after the interview they wanted me to send them code examples of previous work. i didn't get the job, but i don't think lack of go experience was the problem.
- sanderjd 3y ago
  I think all the "a few days" and "a week" stuff that generates these kinds of debate is a total red herring. Yes, it's hyperbole. But it's also true that people with experience successfully applying a bunch of different technologies are great hires onto a team using a technology they don't yet know. It's just a process measured in months rather than days. But if you need to hire someone because you have something that needs to get done this week, then you've already screwed up.
  - scarface_74 3y ago
    And then it gets back to my other argument. Are you going to pay someone the same that doesn’t fit your technical needs as you would someone who does? If you pay them less, are your raise policies going to allow you to get them to market value once they do have the skillset or are they going to end up job hopping?
    - sanderjd 3y ago
      Personally, I would not take this into consideration when deciding how much to pay people. I recognize that there are a lot of different niches in our industry, and presumably in some of those niches this narrow focus on what technology is being used makes sense, but that hasn't been my experience. In my experience, you want people who are both pragmatic and flexible about learning, evaluating, choosing, and teaching others new tools. I do recognize this may be a somewhat privileged view. I think I've been fortunate to spend my career in organizations where software is the profit center rather than a cost center supporting the rest of the business. My experience is that these companies have focused their hiring, compensation, and performance expectations on fundamentals and figure-it-out-itude rather than any specific technology stack.
- demarq 3y ago
  Clearly you read my response and felt some doubt

by demarq 3y ago

scarface_74 3y ago

So could you be a productive iOS/Android developer in a week with no previous experience?

ChrisMarshallNY 3y ago
My experience is that learning a new language -at a basic level- can be done quickly (like a couple of weeks, not days). But learning it at an advanced level, is a whole different matter. I've been writing Swift since, literally, a few hours after it was announced, in 2014. I write Swift every day (like, seven days a week), and have been, since that first day. I feel as if I have only had "mastery" of the language for the last couple of years. There's still plenty for me to learn, and they keep adding more stuff. But the language isn't the big deal. The deal for me, is the fundamental SDK/API/Framework. That has been an ongoing project since 1986. As soon as I learn one API, they change it up (and sometimes, the entire OS). During that time, I've written in 68K ASM, Pascal, Object Pascal, C, C+- (the weird THINK C variant), C++. ObjC, and Swift. I've worked with MacApp, OpenDoc(!), Think Libraries (Pascal and C), PowerPlant, and Cocoa (and its expression in iOS, WatchOS, AppKit, and TVOS). I've always considered hiring folks to be an investment. As a manager, I always looked for folks that had the fundamentals down, and assumed that I could train them into what we need. Most of the work we did, was way beyond anything you'd find in textbooks. I was under no illusion that I could hire folks that would be able to start on it right away. That was why my team was always one that I wanted to keep whole and cohesive, over many years. I can't even imagine today's 18-month engineer lifetime. I kept my engineers for many years, and that wasn't easy.
- scarface_74 3y ago
  I just said something similar in another reply https://news.ycombinator.com/item?id=37099395 https://news.ycombinator.com/item?id=37099395 But as far as employees being an “investment” let’s look at things from the employee side. For context: these numbers I’m about to cite are correct to within a first approximation on the “enterprise dev” side where most of the 2.7 million developers work and in most major cities in the US that are not on the west coast or in NYC Let’s say you hire a Junior/mid level developer and offer them $100K which is fair knowing they are going to do “negative work” for the first few months as an investment. Two years later, they have experience and now can apply for companies that are looking for experienced iOS developers. Their market rate shot up to $135k. Because of salary compression and inversion, you’re not going to be able to pay them 35% more in two years because of HR policies. Yet you can bring in new experienced iOS developers at market rate. If he’s smart your employee is going to jump ship, wasting a lot of your “investment”. As a hiring manager, knowing that statistically I’m only going to get two years out of an employee, why wouldn’t I just poach the person you just trained and pay them the $135K you couldn’t? Another scenario is that now that developer has been reading r/cscareerquestions and decided to “grind leetcode and work for a FAANG”. Now he’s looking at $200K+ as a mid level developer adding yet more bloat to the Facebook app. You couldn’t compete with that if you wanted to.
  - ChrisMarshallNY 3y ago
    > You couldn’t compete with that if you wanted to. Unfortunately, I was forced to. My company was one that paid “competitive” salaries. That’s code for “below average.” This filtered out 90% of applicants, right there. So the ones that applied, did so, out of genuine interest in the company and the technology (we were a “marquee” company). I was forced to look for “diamonds in the rough,” and became fairly good at evaluating whether or not someone could handle the tech and the learning. I kept them, by being a really good manager. I treated them with respect, didn’t burn them out, and shielded them from a lot of the corporate BS. They appreciated that, and stayed. When our team was finally rolled up, after just short of 27 years, the employee with the least tenure had ten years. These were seasoned C++ image processing professionals.
doix 3y ago
Not iOS, but I'm fairly confident I could be productive in an Android codebase in a week. The only reason I don't think I could do iOS is because I'd need to use a OSX, and I think it would take me longer to become productive in OSX. It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating new features? Sure. I did a trial week before joining my current gig full-time. I had pretty much no typescript experience, came into a large TS react/nodejs app and had a pull request on the 2nd day for a new feature. I wouldn't try to work on a Haskell or OCaml codebase, they are different enough that I'm not confident I could pick them up quickly. But most mainstream languages are similar enough that it really shouldn't be that hard to pick them up and be productive.
- scarface_74 3y ago
  > It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating new features? Sure. As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”? And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap.
  - doix 3y ago
    > As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”? I dislike the whole Agile stories/points/sprints thing, so probably not those jobs. But if you're asking if I'm applying to jobs where I write code, then yep! I love writing code and building things. > And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap. I don't know what other experience you have, but probably. At my previous job, I got a bunch of silicon production test engineers, that spend most of their day writing VBA, "productive" in React within a week. I setup the base of the application and sorted out the routing, state management and abstractions for dealing with our data. But they were writing views and features after a week pretty well. I had to point out some performance issues in code reviews but that was mainly it.
carstenhag 3y ago
During Covid I had a colleague, mainly web/js/angular dev, join the Android team. It was a new project to him, so he had 0 idea of the business problems, flows, etc. In a timeframe of 1-2 weeks he was making PRs. It needed quite some reviews from me, usually because he didn't know about "how it should behave" on Android, or what the best practices were in terms of using Kotlin or following our architecture. After 2-3 months he was as proficient coding as I basically (but we all know, coding is 50%).
em-bee 3y ago
i did this with php and python in two different jobs. i had very little php experience and never worked with any php framework before, but the team i was in consisted mostly of junior developers, so i ended up writing better code than any of them except the team lead. laravel was also very easy to understand. at another job i started with only some rudimentary python experience. they had an inhouse framework, so being deeply familiar with python frameworks and libraries would not have even helped me. they knew i had experience in other languages and it worked out pretty well. most recently i had an interview where it was very clear that i haven't done any work on go before. at least during the interview that was not an issue. after the interview they wanted me to send them code examples of previous work. i didn't get the job, but i don't think lack of go experience was the problem.
sanderjd 3y ago
I think all the "a few days" and "a week" stuff that generates these kinds of debate is a total red herring. Yes, it's hyperbole. But it's also true that people with experience successfully applying a bunch of different technologies are great hires onto a team using a technology they don't yet know. It's just a process measured in months rather than days. But if you need to hire someone because you have something that needs to get done this week, then you've already screwed up.
- scarface_74 3y ago
  And then it gets back to my other argument. Are you going to pay someone the same that doesn’t fit your technical needs as you would someone who does? If you pay them less, are your raise policies going to allow you to get them to market value once they do have the skillset or are they going to end up job hopping?
  - sanderjd 3y ago
    Personally, I would not take this into consideration when deciding how much to pay people. I recognize that there are a lot of different niches in our industry, and presumably in some of those niches this narrow focus on what technology is being used makes sense, but that hasn't been my experience. In my experience, you want people who are both pragmatic and flexible about learning, evaluating, choosing, and teaching others new tools. I do recognize this may be a somewhat privileged view. I think I've been fortunate to spend my career in organizations where software is the profit center rather than a cost center supporting the rest of the business. My experience is that these companies have focused their hiring, compensation, and performance expectations on fundamentals and figure-it-out-itude rather than any specific technology stack.
demarq 3y ago
Clearly you read my response and felt some doubt