atom-ide (https://ide.atom.io) brings a lot of the great intellisense features over to Atom. It's most likely not completely on par, but as far as I can tell and based on my own usage, it's beyond good enough for most work.
> in exchange for paying this cost, you gain maintainability, developer efficiency, and (hopefully) better performance during runtime.
You also gain responsiveness to user interactions, a programmatic way to reason about your application/website & and some animation-sugar if you want. Don't throw the baby out with the bath water simply because people follow trends instead of good design practices.
And in my case, less Java I have to read or write on the back end :-)
I agree, though - it’s much easier to reason about the data integrity and security when there is a smaller code base on the back end, by virtue of splitting user interface concerns off to a front end code base.
I’ve been programming since the 80s, but I’d rather write FP code in JS than OOP code in Java - so long as I’m not doing anything to make the app work badly for people. So I’ve gravitated towards front end work the last 3 years or so.
The amount of colossal horror stories I've heard about that company has made sure I don't go near it with a 9 foot pole. Their platform is designed to obscure process in lieu of exploiting workers - all whilst advocating to "serve the client". Utterly toxic.
Co-workers who have a tendency to "shepherd" newbies are downright annoying. Other than the initial on-boarding, there is no reason to be involved in solving someone's "new comer experience".
Not in all the cases IMHO. Sometimes a newbie is lacking experience and be might not be aware of that. He might get overconfident and cause troubles for other and himself. This is where "shepherd" would have helped.
I had few mentors that just knew when to help out and what questions are on my mind and that helped a lot.
But this is exactly what the article talks about - and what I agree with - let them ask for help. To each his own, I agree that some people need that intervention, but for the rest of us, don't assume it.
I agree - but make sure you do let them know that it's okay to ask questions. Sometimes newbies might feel bad to ask for help.
I've had someone who recently graduated work in my team, who'd ask help and always apologize a ton of times for disturbing me whilst I had 'more important things to do'. Even though I made it clear quite frequently that I'd rather get disturbed rather than have him be stuck for hours on end.
Sometimes asking for help can make a new employee feel bad or judged and in my opinion, it is part of our responsibility to make sure this is not the case.
(Again, this does not mean to push your help, but just making it clear you are available in case they need you)
so treat the new employee the same as the employees who have been in the company for a few years and have written a lot of the systems and have internalised the business domain/company setup/system architecture & troubleshooting?
unless a company is rewriting the same 10 input form over & over again, I don't think that will work out great for anyone.
Why I recall one intern in a large intern in a very large company who blotted his copybook in a very very public way over 20 years ago.
That still has effects today as I was asked by an agent about a job at a company where he now has a senior role and I had to stifle a laugh and turn them down.
They could have done with some advice at the time.
TIL: "blot one's copybook":
to spoil one's reputation by making a mistake, offending against social customs, etc.
By the way I definitely wouldn't hold it against an intern 20 years later, so I'm surprised that you do. An intern by definition is going to make mistakes, even huge ones.
Hmmmm. It's hard for me to imagine a scenario that's so bad, but still the fault of the intern alone and not actually the company's fault for lacking proper controls, code review process, and backups and so on. i.e. an intern accidentally deletes the production database, or writes code so bad that it takes down critical software. Whoops. Pretty bad, but if it's a larger software company or larger IT team then they should've had processes against big mistakes.
This reminded me a lot of how DHH described their thinking (paraphrasing A LOT): other people don't have to have a bad product for yours to be successful. Good article!
