5 ms·

If you just want to train your new hires: - prepare good documentation - be on a call with them when you have to explain stuff verbally - be available in tex

If you just want to train your new hires: - prepare good documentation - be on a call with them when you have to explain stuff verbally - be available in text chat to answer their questions No need to be always on call like this. I can only imagine this being used as yet another control tool for paranoic managers who want to make sure employees are always "working" at the desk.

ChuckNorris89 5y ago
>- prepare good documentation That's already out of the question in most companies I worked for that weren't established in a field like automotive, robotics, medical, aerospace. All web dev companies I know have their documentation in slack chats and in the heads of the senior devs with longer tenure who setup the greenfield, as their main incentive is to concentrate their efforts to ship-ship-ship to get features/sales/customers, not spend time writing docs that get outdated in a couple of sprints. Needless to say, being a junior in such a place is demoralizing AF as you don't understand anything and by the time you think you're there, the goalposts have moved again.
- Cthulhu_ 5y ago
  I've been in places like that, it's like you build a brand new front-end but in the background you know - or experience - that within five years it'll be replaced with something new and shiny. I came into the one company replacing a Flash application. We used BackboneJS first, then realized Angular was a better fit for larger applications, then a few years later when the whole company was basically using Angular, some guy came in from Google and Decided that they should be using Polymer instead. Once they nearly had everything ready for Polymer 2, Polymer 3 and lit-element came out which, of course, was completely different. I mean we spent time there fixing a performance issue because unlike real UI frameworks, Polymer had no real concept of routing; in effect it worked like tabbed web interfaces, leaving things open but hidden as the user navigates away. It was a multi-million embarrassment. I spent 2.5 years there in total in the Backbone and Angular project, and they decided fuck you, we'll do it different because we have a new UI style now so obviously every application has to be rebuilt from scratch.
matsemann 5y ago
I onboarded a new place during covid remotely. People did all those things well, but it still felt much worse than a normal in-person onboarding. Not saying OPs approach here is the right solution, but that just being "available" isn't good enough.
afarrell 5y ago
> prepare good documentation It is difficult enough to overcome the curse of knowledge when writing documentation that a better path is to open up a pair-programming setup and co-write your documentation with an intern or new-joiner.
- musingsole 5y ago
  I used to argue this too...but too many will use it as an argument to shirk documentation tasks onto people who quite literally can't do the job because the person with the relevant knowledge feels too important to bother teaching anyone.
  - afarrell 5y ago
    I have seen that failure mode as well. I cannot emphasise enough that it needs to be like pair-programming. Without the more senior person there, the more junior person will struggle to know how to get started and need to ask so many initially-ill-formed questions that it will be very slow going.

ChuckNorris89 5y ago

>- prepare good documentation That's already out of the question in most companies I worked for that weren't established in a field like automotive, robotics, medical, aerospace. All web dev companies I know have their documentation in slack chats and in the heads of the senior devs with longer tenure who setup the greenfield, as their main incentive is to concentrate their efforts to ship-ship-ship to get features/sales/customers, not spend time writing docs that get outdated in a couple of sprints. Needless to say, being a junior in such a place is demoralizing AF as you don't understand anything and by the time you think you're there, the goalposts have moved again.

Cthulhu_ 5y ago
I've been in places like that, it's like you build a brand new front-end but in the background you know - or experience - that within five years it'll be replaced with something new and shiny. I came into the one company replacing a Flash application. We used BackboneJS first, then realized Angular was a better fit for larger applications, then a few years later when the whole company was basically using Angular, some guy came in from Google and Decided that they should be using Polymer instead. Once they nearly had everything ready for Polymer 2, Polymer 3 and lit-element came out which, of course, was completely different. I mean we spent time there fixing a performance issue because unlike real UI frameworks, Polymer had no real concept of routing; in effect it worked like tabbed web interfaces, leaving things open but hidden as the user navigates away. It was a multi-million embarrassment. I spent 2.5 years there in total in the Backbone and Angular project, and they decided fuck you, we'll do it different because we have a new UI style now so obviously every application has to be rebuilt from scratch.

matsemann 5y ago

I onboarded a new place during covid remotely. People did all those things well, but it still felt much worse than a normal in-person onboarding. Not saying OPs approach here is the right solution, but that just being "available" isn't good enough.

afarrell 5y ago

> prepare good documentation It is difficult enough to overcome the curse of knowledge when writing documentation that a better path is to open up a pair-programming setup and co-write your documentation with an intern or new-joiner.

musingsole 5y ago
I used to argue this too...but too many will use it as an argument to shirk documentation tasks onto people who quite literally can't do the job because the person with the relevant knowledge feels too important to bother teaching anyone.
- afarrell 5y ago
  I have seen that failure mode as well. I cannot emphasise enough that it needs to be like pair-programming. Without the more senior person there, the more junior person will struggle to know how to get started and need to ask so many initially-ill-formed questions that it will be very slow going.