I worked at 2 companies since graduating. The first company had a DevOps guy that was strictly not programming (setting up AWS things, CI, etc). It was clear that programming wasn't his skill. Although he was able to learn it, he wasn't hired to write code. The second company I worked at, DevOps engineers were software engineers/computer science majors. They could immediately switch teams to a write-code-only team and be qualified.
Not exactly a listening device, but I was in an AirBnb once. Every time I would open the door, I could hear a notification being played in the upstairs unit. It wasn't the back door that caused the notification, but the actual door the apartment I was staying in. It was displeasing.
You might be able to speak colloquial phrases, but you will not be able to write correctly. For example, perhaps you will be able to order food from a restaurant, or say hello to a stranger.
Yeah; it’s actually pretty easy work. Interns have a lot of uncommitted time, and they’re going to leave soon so you don’t want to integrate them into the team too much. It’s also way easier to build to a well-defined spec (which an in-production endpoint would likely have).
So you let them rewrite something that already works. If what they build is good, you‘ve just knocked out a good chunk of technical debt and found someone you probably want to hire. If not, they don’t get an offer. Either way you probably didn’t pay them much to begin with so there’s a lot of upside and not much downside.
The question isn't whether or not the work is easy for the intern, it's whether or not it's appropriate. And this cuts both ways: a company that is doing serious core refactoring/redevelopment on the back of an underpaid "intern" is probably exploiting that labor in an unfair way. If it's in fact an unpaid internship, then they're straight up in violation of the Fair Labor Standards Act.
And, of course, a company that puts this kind of work on the back of a temporary worker is not treating its own codebase with the respect it deserves. This is rolling the dice with your expertise store -- you have to hope they did it well, because they aren't going to be around to answer questions if they didn't.
If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test.
The point is this was a well-specified, independent component with an existing functional implementation. This makes an ideal intern/temp/first project, because of those factors - it doesn't require deep knowledge of the organization or other services in the environment or business requirements. You build this, and if we like it, we use it and may give you a job offer.
Unless given other information, you can assume the company complied with the law with respect to paying the intern and the intern accepted the internship offer, and it sounds like he got a great experience out of it.
> If they didn't build it well, you throw it away, and you're only out what you paid the temporary worker and your code review/acceptance test.
Yeah, and that logic is almost inherently a violation of labor law. The whole idea behind allowing "internships" at all is that the intern is deriving value (education) from the relationship that isn't captured by wages alone. The test for whether it's legal involves how much they are supervised by the people who are supposed to be teaching them.
Handing out throwaway projects like you posit is an easy trip to a class action suit.
I think you may be mistaken about this. If it helps any, I wasn't one of your downvoters; I upvote comments that may be incorrect but lead to an interesting and informative discussion.
I live with an HR exec and read some of this thread to her while she was cutting rhubarb for something she's baking.
She said (paraphrased), "Are you kidding? This is a perfect project for a summer intern. They won't have to take three months to get up to speed with all your internal systems, and of course there is educational value - they will get to see how some talented developers tackled the problem in one language while they translate it to another."
There is immense value to the intern just for being around; the biggest things software dev interns learn isn’t how to code: it’s how to code as part of a team. So check-ins, CI/CD, automated testing, daily meeting cadence, architecture discussions, backlog grooming, code reviews... all things they don’t teach you in school, and all things that you need to know to develop software in the real world.
Most kids right out of school are honestly pretty decent coders. The internship is more about the professional skills than the technical ones.
> a company that is doing serious core refactoring/redevelopment on the back of an underpaid "intern" is probably exploiting that labor in an unfair way
> Handing out throwaway projects like you posit is an easy trip to a class action suit.
So if an intern shouldn't do work on the core product but also shouldn't do throwaway projects, what do you suggest an intern should do?
What do you consider an "underpaid" intern? Would you consider 75% salary of campus new hire as underpaid?
Most real internships pay under market rate, but not insanely low. A few years back, going rate for an undergrad CS internship was ~$25/hr or so.
If you’re recruiting on campus, you’re competing with other companies for the most promising candidates. If you come in with an unpaid internship, you’re going to get the leftovers.
Even ten years ago, I doubt it was an unpaid internship. They weren’t common in tech going all the way back to dotcom. And if it was a paid internship, labor law doesn’t care. As far as it’s concerned that’s a job like any other.
As far as I know, unpaid internships have not really been a thing in software development.
I was an intern back in 1995 and they paid us $10/hour ($16.88 inflation adjusted) and they provided housing on a college dorm. To put that in perspective, the $650 I made after taxes every two weeks was the cost of tuition every quarter at the state school I attended. I made enough that summer to cover my entire senior year including books.
No idea, but that seems like a reasonable choice in that case.
Yes the project was impactful, but there already was a reference implementation with a reference performance target. Worst case scenario, they would have been back to using the old implementation.
Depends on the intern, and the component. If the intern is talented, the component is well-tested and the mentor or supervisor can do an effective code-review - then why not?
This is slightly off topic. But PHP has a great devloper experience, in general, now with vscode, and autocomplate, find all references, etc. But the best framework out there is Laravel. It's great, but the maintainer doesn't seem reliable. Every single release has some type of backwards incompaitible change to it of which they don't document all the changes. So it's basically a blackbox if you are to upgrade your laravel/framework version.
I've heard this criticism of Laravel a couple times and never understood it. I've been using the framework for years and have never had an issue with upgrades. There is a clear and comprehensive upgrade guide with each release, as well as a third-party package called Laravel Shift that can inspect your code and perform automatic upgrades in many cases. I've found there are only one or two breaking changes per minor version release (which seems reasonable to me), and they are always well-documented.
Aside from that, I'm glad you've highlighted Laravel, which—despite being the most popular server-side Web framework on GitHub—gets virtually no attention from HN. It's typical to use Laravel in the old server-side rendered Rails paradigm (which is still probably best for some applications), but I've had success using it to develop APIs as well. Core features like the ORM, job queues, dependency injection, email templating, etc, are very solid, and the ecosystem of packages around it is phenomenal. I would recommend it to any Web developer.
Laravel also as a lightweight version called Lumen for simpler APIs and things. It includes a lot of the features of core Laravel but has a more stripped-down application structure.
Ok. I agree vert.x and quarkus.io really look promising! I was using the play framework which looked similar at first glance and then was horrible as java was just at the surface and one needed to use scala in the end. Learning scala with a java team under time preasure was not a good experience...
I did Play v2 with Scala... I can agree, it was not pleasant. (I had just gotten off a year-long Ruby on Rails/ JRuby on JVM stint though - so "pleasant" is a relative term)
How come it has a best developer experience? Even setting up xdebug and starting debugging is a pain. Most of the developers codes in php use `echo` for a long time.
PS: I haven't used php for 2 years, let me know if there is an update on debugging.
Yes I totally agree that setting up or rather understanding how the debugging cylcle works with php is not straight forward. It doesn't work out of the box and one has to dig into php internas. However, it pays off, as one can do remote debugging on e.g. a docker development machine or similar...
I am not sure how well such a feature is supported in javascript, ruby, java or what not out of the box...
