4 ms·

But in those few months, they were often trained intensively on exactly the tech stack you're looking for, and they built some things, in a team, that look a lo

But in those few months, they were often trained intensively on exactly the tech stack you're looking for, and they built some things, in a team, that look a lot like what's actually done day to day in many businesses. In an up to date way. That helps! We have only one boot camp graduate, who came from a completely different career. He's been productive from day 1, has carefully listened to all advice he's got since and is always working on figuring out better ways to do things, and he's just very good after two years.

josephg 4y ago
There are knowledge holes a mile wide with bootcamp curriculums though. The programs I’ve seen don’t teach: - Information security - Anything lower level than Python/Ruby - Unix (streams, files, processes and threads, syscalls, etc) - Debugging. (Except incedentally) Not knowing these things can be fine in a feature factory workplace. But having an engineer on your team who has no idea about infosec is an active danger. “I make a sql query from this string builder” / “we save the passwords in this database table” / “the AWS credential is here in the javascript code in the repository” / etc.
- torben-friis 4y ago
  I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process? Stronger point even: it is beneficial to have a person capable of messing up that way so you can check that your quality control is working.
  - josephg 4y ago
    A tiny minority of places I've worked do code review for every commit. Or have careful enough processes that they would catch every mistake made by incompetent engineers. Most companies simply trust their employees most of the time. Hardening a process against programmers you don't trust has a massive cost.
    - mavelikara 4y ago
      > A tiny minority of places I've worked do code review for every commit. In the past three jobs I have had, over 13 years, all changes were code reviewed before merge. I don't know the industry's general stance on this, but I wanted to describe my experience here which is very different from yours.
      - torben-friis 4y ago
        Same here.
  - nicoburns 4y ago
    > I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process? That's true, but issues getting into production isn't the things that might be problem. Junior devs requiring hours of review time for relatively simple tasks can also cause a lot of problems for an organisation, bringing productivity to a halt in extreme cases.
- scarface74 4y ago
  And most college courses also don’t teach that.
  - peanutcrisis 4y ago
    Can you substantiate this? It's incredibly hard to believe that the majority of universities offering a programme in computer science would not have a class on operating systems or information security, or anything more abstract or concrete about those topics.
    - turdprincess 4y ago
      At least at my school, the CS degree was open ended. You take a handful of required corses (intro to programming, algorithms, operating systems) but aside from that, it was up to you to pick the classes which interested you. If you were interested in security, or databases or mobile app development, you could take those classes, but they weren't required. The things I learned in college which were actually applicable to a software engineering job was: * A basic ability to program * Maybe some low level concepts about operating systems. But this is a big maybe, because my operating systems class was pretty early on and was long forgotten 3 years later when I went to apply for a real job. I learned nothing about version control, the typical client-server model, html/css/javascript, REST, servers, databases, doing a pull request, teamwork, etc. I think those classes may have been available, but I never took them and graduated just fine. I am not convinced this 4 year CS degree was any more useful than a bootcamp, which teaches you the actual useful things you need to be a junior dev. I think the difference between CS and a bootcamp is more of intent and followthrough. People often pick bootcamps because of promises of easy money, versus someone who does a 4 year CS degree is possibly more committed and won't give up as easily. But in terms of their actual preparation, I doubt one is better than the other.
      - nicoburns 4y ago
        The other difference is that one takes 4 years and the other 3 months. That’s 16 times longer, so if you spent only 5 hours a week working on or thinking about programming, then that would be an equivalent amount of time. Which is not mention that sometimes things take a while to sink in.
- turdprincess 4y ago
  I have a CS degree from a top university and I didn’t learn any of the above in college (except for perhaps debugging), including an internship. Actually 10 years later I’m a senior engineer at a FAANG (mobile specialty) and I still don’t know most of the things you listed. Except for debugging - I got that down!
nicoburns 4y ago
> he's just very good after two years Right, but a self-taught developer might well have years of non-commercial experience and be good in two months or even from the get-go.
- mavelikara 4y ago
  The word "might" is doing a lot of work in that assertion.

josephg 4y ago

There are knowledge holes a mile wide with bootcamp curriculums though. The programs I’ve seen don’t teach: - Information security - Anything lower level than Python/Ruby - Unix (streams, files, processes and threads, syscalls, etc) - Debugging. (Except incedentally) Not knowing these things can be fine in a feature factory workplace. But having an engineer on your team who has no idea about infosec is an active danger. “I make a sql query from this string builder” / “we save the passwords in this database table” / “the AWS credential is here in the javascript code in the repository” / etc.

torben-friis 4y ago
I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process? Stronger point even: it is beneficial to have a person capable of messing up that way so you can check that your quality control is working.
- josephg 4y ago
  A tiny minority of places I've worked do code review for every commit. Or have careful enough processes that they would catch every mistake made by incompetent engineers. Most companies simply trust their employees most of the time. Hardening a process against programmers you don't trust has a massive cost.
  - mavelikara 4y ago
    > A tiny minority of places I've worked do code review for every commit. In the past three jobs I have had, over 13 years, all changes were code reviewed before merge. I don't know the industry's general stance on this, but I wanted to describe my experience here which is very different from yours.
    - torben-friis 4y ago
      Same here.
- nicoburns 4y ago
  > I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process? That's true, but issues getting into production isn't the things that might be problem. Junior devs requiring hours of review time for relatively simple tasks can also cause a lot of problems for an organisation, bringing productivity to a halt in extreme cases.
scarface74 4y ago
And most college courses also don’t teach that.
- peanutcrisis 4y ago
  Can you substantiate this? It's incredibly hard to believe that the majority of universities offering a programme in computer science would not have a class on operating systems or information security, or anything more abstract or concrete about those topics.
  - turdprincess 4y ago
    At least at my school, the CS degree was open ended. You take a handful of required corses (intro to programming, algorithms, operating systems) but aside from that, it was up to you to pick the classes which interested you. If you were interested in security, or databases or mobile app development, you could take those classes, but they weren't required. The things I learned in college which were actually applicable to a software engineering job was: * A basic ability to program * Maybe some low level concepts about operating systems. But this is a big maybe, because my operating systems class was pretty early on and was long forgotten 3 years later when I went to apply for a real job. I learned nothing about version control, the typical client-server model, html/css/javascript, REST, servers, databases, doing a pull request, teamwork, etc. I think those classes may have been available, but I never took them and graduated just fine. I am not convinced this 4 year CS degree was any more useful than a bootcamp, which teaches you the actual useful things you need to be a junior dev. I think the difference between CS and a bootcamp is more of intent and followthrough. People often pick bootcamps because of promises of easy money, versus someone who does a 4 year CS degree is possibly more committed and won't give up as easily. But in terms of their actual preparation, I doubt one is better than the other.
    - nicoburns 4y ago
      The other difference is that one takes 4 years and the other 3 months. That’s 16 times longer, so if you spent only 5 hours a week working on or thinking about programming, then that would be an equivalent amount of time. Which is not mention that sometimes things take a while to sink in.
turdprincess 4y ago
I have a CS degree from a top university and I didn’t learn any of the above in college (except for perhaps debugging), including an internship. Actually 10 years later I’m a senior engineer at a FAANG (mobile specialty) and I still don’t know most of the things you listed. Except for debugging - I got that down!

nicoburns 4y ago

> he's just very good after two years Right, but a self-taught developer might well have years of non-commercial experience and be good in two months or even from the get-go.

mavelikara 4y ago
The word "might" is doing a lot of work in that assertion.