Hi, I work on web in London. The prestige of the company isn't as important as having proved you can work and learn. In fact you should probably ask that on interviews - what will you team be like and what kind of opportunities will you have to learn and grow as a dev? It's never good for a dev to work alone, but it's especially harmful for junior devs.
I don't know the market for Haskell. If you want to get into backend for web, you can't go wrong with Node.js. Agencies using those services usually prefer the backend written in Javascript or Typescript so more devs can, in principle, work on both ends. Moreover, you can get into cloud services like AWS and Azure easily if you know Node. I reckon it will be easier to start as generic "web developer" or "junior developer" and then gradually evolve into backend. Specialists tend to be mid to senior.
You should start sending applications on your last month. I don't think it will take you more than that to land a junior role in London (there are many more junior openings than internships). But you can create a Linkedin account today if you don't have one.
Sometimes framework peeps can get caught on complex stuff because it's more interesting. While talking about static analysis, HOCs, immutable thunks and so on is cool, I'm glad Sarah went down to planet Earth to speak to the mortals. There's a lot of market potential for Vue in legacy sites.
Learning to code is easy. Javascript is easy to work with. Especially nowadays with lots of great learning materials online. Those freelancers weren't born knowing Javascript. They trained. That's how you git gud at things.
Head over to freeCodeCamp and get coding. It doesn't matter if it's too easy at first. Race through it. The good thing about freeCodeCamp is that you have to make a full-fledged product, it's not just examples. Don't listen too much to the sales pitch and don't take seriously the important-sounding words like "become an engineer", etc. Just get coding and complete a project. It's very important that you make something from start to finish on your own. That's the whole point of this bit, really.
When you have finished a project, head over to egghead.io and get the two React courses by Kent C. Dodds. The introductory one is free. The advanced you'll have to buy. It's worth it.
You have three months to do this. You will be more employable -and confident- by May.
In real applications we need to use social login, share, google maps, shopify buy SDK, S3, Azure speech API and so on. The javascript tools to access all of that are plain old ES5 at best. How will we use them from another language?
Libraries, too. Are we going to find ourselves writing our own custom dropdowns and datepickers in C++? Not to mention our own view update and state management libraries.
This is the reason there are next to none real world examples of web apps made in Elm. No communication with planet Earth.
The rest are pretty common, I would not consider reduce() or passing an object to a function instead of separate arguments hipster hacks at all. "Options" objects are ubiquitous in corporate SDKs like AWS and Azure. They are the opposite of hipster.
I work at a small company. We have 6 javascript developers. All our web projects are node, typescript, and the front end stuff the client wants us to use (though we default to angular). We enforce types for communication with node, so at least you know the structure of all the json going through the network. On the node side we use loopback, which generates a nice site to call the API from outside the project.
We write no tests whatsoever. This is a business decision.
There's a test team of 2 people whose job is to go through our crap (i.e., the user stories) and write docs.
Management has to adapt to clients. Managers use the agile words, but the client's budgeting procedure has to take precedence. Regarding estimations, there's no analyst estimating features and tasks, the developers do it themselves. Developers also talk directly to clients often and go on-site.
Since we're so small (about 30 in total), things are personal. We know everyone personally and can make out who wrote a given piece of code. I think communication must be easier with fewer people. I can't imagine having 500 people committing into my project!
Is he right on composition? He seems to think it's about size ("small units of functionality"). Really composition vs inheritance is about dynamic versus static. Acquiring the functionality at runtime or at compile time. This is explained in the book he cites.
If you want tickets to fix, join a digital agency. Ask what kind of clients they nurture. Media is good. You want to work making NBC apps for Android. Things like that. You will reach millions.
Such a change might bring a different type of stress. The feeling that you're helping lobotomize a generation with mindless entertainment instead of helping cure cancer. Also, the tickets.
They're going to need something else. X11 and GNOME/KDE/etc will never be mainstream. Ubuntu made a mistake not contributing to Wayland but they were right to try Unity.
Ironically, Canonical is making money mainly with cloud services. Meaning servers - what Linux is good at.
Don't go down that rabbit hole. Linux is not for desktop despite many years of efforts. Even the distro with the greatest focus on UI (elementaryOS) looks like a toy. That Linux is hugely successful everywhere EXCEPT in the desktop should tell us something.
Just my honest opinion after 15 years of continuous use in university and work.
You don't. The todo app is a handy example because you have the CRUD operations and local state. It's meant to show you how to get to grips with a library so you can use it for a real project. The todo app itself is just an example.