engineerDave

If you have a good framework behind your project, e.g. Rails, Phoenix. You probably don't need it. I'm a primarily a ruby/Rails developer who is slowly switching to Elixir/Phoenix, and I find myself reaching for React when I need to do very complex User Interface components, mostly Rails. Most of my Phoenix apps so far haven't had big UI components. Outside of that Rails' or Phoenix's built in unobtrusive JS, the new hotwire stuff, or Phoenix's live view is more than sufficient IME. If you're doing a JS based single page app then perhaps but it's pretty complicated and there are probably easier options.

Greenfield coding projects are very rare, except in consultancy, but even there you'll have to maintain what you build. Refactoring however can be the same type of thing. IMO use this opportunity to write tests and learn to refactor. Most developer jobs will be exactly like this, learn to embrace the suck and find the joy in the refactoring. Eventually you'll get the skills to get a better job or start a consultancy. You might also prefer being a business systems analyst where you spec projects instead of build them. IME BSAs work on a lot of the stuff you mention you like and developers just slog through the coding parts.

internet 1.0, post AOL, pre dot com crash. You had to roll everything and could even run a server with little fanfare from your home because ISPs allowed you to run your own servers. Now most prohibit or outright block it without a higher tier plan. There were problems with this approach though, spam, malware, etc.

It's only with Web 2 that we became addicted to offloading everything to central providers. Their siren call was too much to resist and now they have all our data. It wasn't designed to be like this, we can just go back but a lot lack the skills to roll the full stack now sans AWS/Google Cloud.

I would bet the angle is that programmers in their 20s are less likely to push back against things like on working conditions and demands on their time. Basically get them while they’re young and dumb

All banks AFAIk not just EU banks.

The problem as I've experienced it is they hire you based on the code example from the interview and then the actual job requires you to know all the orchestration components (puppet, chef, kubernetes, package manager and system settings, etc) to bootstrap the virtual machine OS or cloud component that then will require you to know the particular OS distro CLI or cloud API to then run the code upon.

In my experience, I spend 80% of my time just figuring out how to get the code to run safely and properly and then chugging through the "stack" part of the full stack programmer before I'm even able to run my code at scale. The actual code itself tends to be simple. Sometimes already existing in a very fleshed out and optimized library, sometimes even core to the language itself.

It's really more endemic of more the prevalent problem that what HR thinks programming tends to not be what programmers actually do.

They're his words not mine. Go fight with him if you think otherwise https://www.youtube.com/watch?v=Of1phFsC4ZI&t=3290s

When I say copy I don't mean implementation but inspiration. They may not have copied it exactly in implementation, it is FP vs OO, but stimulus.js was a direct response to LiveView. I don't think there is anything wrong with that however I welcome any advancement that requires less JS.

Not a knock on you but maybe you're too new to Rails too.

I've been using Rails for 10+ years now and setting up a phoenix app is very intuitive. A lot of "oh this is like X in Rails". IME most of the complexity was around JavaScript and that's changed with esbuild.

However it sets up with very similar patterns to Rails. Something I'd expect as it's creators came from Rails. Usually the differences are specific to FP vs OO.

Admittedly coming in from another language especially with an OO background would be harder as it's a smaller community than Rails and doesn't have 10 years of documentation sitting out there. That said documenting elixir code is much easier IMO, so that is sure to change. Also the scope of FP languages requires significantly less documentation IME.

The only thing vs Rails that I have found somewhat needing more attention in Phoenix is SSO integration but it's there and progressing especially with the Phoenix 1.6 changes.

This is the correct answer.

Elixir Phoenix. It’s what rails copied for the Hotwire stuff. With distillery you can compile all of it, css, js, images, html, down to one tarball that you unpack and run as a service placed behind a forward proxy for complex setups or standalone if desired. Plus it’ll blow the doors off a Rails app performance wise, measured in micro not milli seconds, and will deploy on a fraction of the resources. Plus the community is filled with ex rails devs who left ruby for elixir so it has a very familiar feel if you come from Rails.

Not trolling. Since others have handled the H1-B visa stuff, I'll just say your first sentence tells you the exact problem.

> I'm a 20 y/o bootcamp grad with no college degree and 6 months of professional experience

Six months experience out of a bootcamp isn't even enough experience to know what you don't know. I don't care what they told you in the bootcamp. IMO it's one of the main problems with bootcamp programs, they're a sort of ponzi scheme for becoming a programmer. It's like learning to swing a hammer and calling yourself a carpenter.

In SF, you'll be going up against BS in Comp Sci grads at minimum, that are probably from an Ivy League or "Public Ivy" type of school, who most likely also have a solid internship and references under their belt and were actively recruited by the FAANG company.

I think your expectations are a bit too lofty. You're gunning for FAANG and you simply don't have the qualifications. That's the harsh reality.

The good news is there are plenty of places around the world that need competent programmers. You should probably return to your home country and target a smaller company somewhere in the EU, that will give you the experience that sets a solid foundation. While you're doing that you'll need to build your online presence, e.g. open source code contributions, open source code repos, blog posts on seemly simple subjects where you pull the subject apart and lay it open for the reader. Basically you need to establish yourself so that when people search for your credentials, they exist and demonstrate clearly what you're capable of doing.

We've all been there. While it can be frustrating, it's not so much different than anything else in life. Hopefully you love to program and will find a joy in your growth as you learn new concepts and ways of applying the languages you utilize.

Best of luck!

this x1000. My main frustration with imperative programming has become the devops plumbing and defensive nature in code that was needed to get something done.

Switching to Elixir - learning what OTP brings to the table, e.g. observers, genservers - distillery compiled binaries per OS, negating the need for a lot of the devops complexity, e.g. docker, node, - the switch to esbuild and liveview for less JS cruft - FP transforming of immutable data to more immutable data vs managing state

TBH all of it has been a breath of fresh air.

I was being tongue in cheek on that one, sorry if it didn't come across that way. Although I've been a Rails dev for 6 years now, I've come to hate the TDD approach and am a convert of FP and types, & compilers a la Haskell. Because there really is no such thing as a massive change in FP IMO. Unfortunately I'm not competent enough in it yet so Rails still pays the bills.

true but even staying current across small SemVer changes can be a relatively large burden

I think your memory of the 2 -> 2.1 -> 2.2 -> 2.3 (if you were lucky to get bundler running) to 3 to almost immediate 3.1 with massive changes (asset pipeline) upgrade is a little fuzzy. It was the suck. A lot of companies I know of are still running Rails 2 because of this change.

Yes. Being forced to push changes to production with zero test coverage, and hence zero confidence in your code on a Friday night. (true story)

After that you always make sure test exist before even pondering a push of potentially breaking changes! :P

Fair points all. But the breaking changes I'm referring to are items like changing method names, most likely because OCD, and helper methods, etc. While good/great tests will catch this type of stuff in your code, it will still be a lot of chasing your tail refactoring code because someone didn't like the way something was named. I see this a lot in the ruby community. Its like some sort of crazy insanity that ruby devs exercise when changing publicly exposed API methods just because _____. smh

In cases like this when I ask why TDD isn't done the answer is usually some variant of "its working" to which I usually reply "how do you know?". :P

The main problem I see in the ruby community, in this regard, is the willingness to make breaking changes and justify it via Semantic Versioning. While on the surface this seems ok the underlying problem, as I see it, is the old version isn't maintained, so essentially the only maintained version now has breaking API changes.

There are few ways this could be addressed, e.g. separate branches for old gems, and some developers do actually do this but in the end I've noticed these legacy branches and gems just bitrot while the developer devotes their time to the new branch. So essentially to use the gem you have to make the SemVer API jump which then begins the dependency failure cascade dance you mention.

I'm close to starting another new Rails job and I'm not looking forward to the inevitable rails rescue work on legacy codebases, yet this is the reality of a modern Rails developer.

Also I think this upgrade work needs to be factored into "development time" and when you do I'm not convinced Rails is actually faster.

LOL using the root of the word you're looking up to define the word you're looking up, classic!

here is a podcast where they cite error handling stats of C++ vs Erlang.

http://mostlyerlang.com/2014/11/19/049-supervisors/

starting at 28:45 although you might want to listen to the whole podcast

We also don't have police helicopters here in Madison at least to the best of my knowledge

FWIW He wasn't really in the bush. He was in a suburb of Madison called Middletown where there are corn fields on the outskirts of residential neighborhoods and the weather was fairly mild last weekend. Low humidity and 80ish F.

When I read this I couldn't help but think it emphasizes the core problem with creation waste, meetings and communication lag, e.g. time between emails, IMs. I think we can all learn from that part.

That might be the best pro Scala (your "Why Scala?" blurb) statement I've heard yet. :)