engineerDave

I mock languages because they've caused me enormous pain at some point, not "offhandedly". Their scorn is deserved.

I don't know if this helps or hurts but I took up Elixir a few years ago and was liking it, the way the FP simplifies the scope you have to operate within and the general stability of the API that Jose has stated, i.e. it's feature complete for the foreseeable future, changes now are mostly optimizations such as pushing more into the erlang layer.

Then they introduced releases which can package everything into a tar file that has all the CSS, JS, HTML, erlang VM, etc. in it and runs as a binary via systemd and proxied through your .

Then they introduced LiveView and it was the first time I really had a "wow" moment since first learning Rails many many years ago. I can do nearly everything I want in real-time with it + JS hooks.

I really do think this addresses a lot of the frustration I keep experiencing w/r/t complexity in web development. I can just write Elixir code and get about 90% of the features of a JS framework like React.

The only real knock on it is it's strongly typed not static typed (they're working on a solution) but with code analysis tools like dialyzer and credo a lot of that worry is addressed. It's not for everyone but FWIW it has been a breath of fresh air to me a 10+ year web developer.

he just came up with a whataboutism that fits his narrative. commuting/recreation it doesn't matter. The bike inconveniences the motorists for a short time where as the car can end the cyclists life.

once per employer

Depending on where you live, e.g. proximity to the equator, you will probably never recoup the initial investment or if you do the panels will probably be at their end of life when you do. So you'll never really "make money". But you will insulate yourself from demand spikes and give you an emergency backup.

There is a truth here. A lot of companies build their first system in php. IME no one hires developers to build their second system or third in php, except maybe Facebook.

developers are lazy

I would argue Excel is the ultimate example of sunk cost fallacy but w/e if people like it, you do you.

All this talk about "I need Office to be Office" and no one mentions o365 online? Which works just fine on Linux. Also label printing seems a common issue but no mention of support of old old old legacy hardware that still works perfectly fine. For instance, my scanner which still works perfectly fine but won't work on Windows or Mac anymore works just fine on Linux because of the legacy driver support.

Not a business owner. Programmer who was a sysadmin in a former life and is familiar with all three O/S and a few others, e.g. embedded firware, etc.

In every organization, there is usually one app that ties a particular user to a non Linux OS, e.g. usually it's Adobe products, sometimes active directory, sometimes it's because "we have Access and it does everything we need it to and no we don't know what it does anymore", we need X software for X platform because skillsets and training.

A lot of lawyers would still (and some still are) be on WordPerfect if they could be, some accountants are probably still on FoxPro somewhere out there, but IME most users just need a Chromebook and a subscription to o365. Maybe ChromeOS Flex is an option for them?

If they have custom needs then they IME don't need much more than a CSV file and a simple ruby script that can import their label addresses from a CSV and spit them out to the printer a la ruby's Prawn.

The argument for training loses weight when each version of Windows and macOS changes fairly drastically you have to relearn with each major upgrade. Usually forcing hardware upgrades too well before the machine has stopped being viable. Whereas learning Linux once and that being all you have to know forever and can blast onto any machine, copy your files over, run your setup flat files or whatever you use to bootstrap your setup and IMO the training argument should push more to Linux but it never will for one simple reason. Support. If the manager can't offload a user needing help to support then all bets are off.

It is possible to move fast and NOT break things.

Breaking things is bad. Despite what Mark says. When you break things companies lose customers, they lose money, they lose market share, and people get fired or die.

TBH the OP post seems to be highlighting that "when we forget history, we're doomed to repeat it."

Not trying to be ageist but a younger dev wouldn't have context on a time when the industry had timestamps as versions and the core reason why SemVer became preferred, as you describe above.

Also achievable with elixir (via erlang)

Agreed. Kube makes the scaling out easier not the bootstrapping. An important difference.

apparently people haven't read the Mythical Man Month papers

Yup. Let's birth that baby by throwing more mothers at it.

The one thing I consistently see CS programs omit which drives me nuts with new hires. Zero knowledge of version control. Do yourself a favor and learn git now so you don't suffer later. It will help you all throughout your college classes too. TBH I'm not sure why this is such a glaring omission in CS degrees, I guess they just want to teach theory, not practical application but I've seen it consistently missing from new CS grads.

The only thing I've found that is as simple or as complex as you want it, and that I have stuck with for over 10 years is Workflowy

https://workflowy.com/

FYI the roots of this approach come from traditional typography, which obviously predates the web. IME the web stuff more or less copies the standards established in typesetting or ends up just reinventing it. You could easily spend a career studying and learning it. I find it best to use a CSS framework like TailwindCSS where there are built in classes for dealing with it.

https://en.wikipedia.org/wiki/Column_(typography) https://tailwindcss.com/docs/typography-plugin

I never have had a project fail due to it's tech. In my experience, projects rarely fail due to the tech, they fail due to the team and management.

If you get to the point you're referring to, e.g. Twitter having fail whale issues because they built entirely on mostly vanilla Rails, is a good problem to have and one you'll be able to get resources to fix once you get there.

Maybe it's just me but IMO your time would be better spent reading something like Predictably Irrational by Dan Ariely or brushing up on your psych 101 concepts. Learn to deal with the irrationality of your team, your customers, and your boss and your life will be a lot less stressful.

Good luck!

As a ruby dev this completely makes sense to me based on the Java developers I have worked with. I'm willing to bet he also never even considered jRuby as a happy compromise, also basing this on my experiences with the Java developers I have worked with

I haven't really seen anyone mention this one but if you run Docker heavily, you're going to want Linux. Mac and windows both run Docker via Hypervisor and it's quite a bit slower, at least for building. Short of that just get a mac. Although TBH this isn't a huge enough reason if you're only incidentally running docker as you can still shift your context to a linux machine on your network for a performant context.

The main reason isn't build quality or anything like that, although IME it's good on the Apple side. It's because mac is the shim between enterprise OS and open source OS. Things like MS Office, MS Outlook might not seem like much until you have to have them. Granted O365 has made some nice strides in making them moot but the web versions can still be limiting. Also if you go into development for anything mac or iOS you'll need to be on macOS for XCode, and you still have the option of installing the Adobe suite of products, as much as I hate using them.

w/r/t the tiling. You should check out this app for the tiling/snapping stuff

https://rectangleapp.com/

Although not as natively customizable as Linux. I've found everything I need that I miss from other OSes on mac. There are a lot of highly motivated developers that come up with some really nice apps/extenstions/etc.

FWIW I've been using macOS/Windows/Linux for over 12 years. Every OS has it's warts. I'm still kind of baffled that Windows doesn't have native Explorer tabs.

If the thought is you work fewer hours so now I can cut your pay, then I think realistic the answer is hell no. Unless I'm already checked out from stock options or something, a senior engineer's pay is more related to their knowledge than for their time. A senior engineer can save you way more money just by keeping you from doing things than you'll make from a more junior dev working more hours in their place. I'd bet for most senior programmers, if you just cut their meetings out of the equation, you're going to find out they are already working part time.

A lot of this discussion has devolved into the management side of choosing a language and strayed from the realistic side. But insofar as to why people would choose Haskell...

Haskell is fast, compiled, type safe, memory optimized, allows concurrency and parallelism. The use cases where you'll see using Haskell will generally be companies like financial sector where very fast and error free execution directly translates to making more money, e.g. dark pool front running trading algorithms. Generally you don't hear it extolled because of who is using it and the secrecy around what it's being used for, e.g. competitive advantage.

Outside of that you'll probably only see it in academia because of a lot of the reasons listed in the replies. In my opinion its a harder language to learn because it really is just lambda calculus translated to a programming language.

Bonus points if you utilize their websocket login. Will teach you websockets, genserver, pattern matching, and how to lose your hair in 10 days because of all the hidden shit you have to figure out because they're not documented for websocket connections, e.g. return message shapes!

I think the argument for Teams falls apart when Slack, not IRC, is factored into the equation. The only argument that is justifiable for Teams is if you're on O365 is slots into your organization easily, outside of that Teams is pretty bad. It's main selling point seems to be "you already have it". It's as if MS execs pointed at Slack and said "engineers make us that" and gave them a weekend to do it. The UX on Slack is almost unusable. It's some of what Slack does but with about 5 more clicks needed per operation, assuming you can even do the operation.

The main reason Teams sucks has nothing to do with tech. It's the fundamental design vs Slack.

Slack is organic free flowing conversation, like a chat, that you can thread out of for expansion of a particular though via threading.

Teams is forced threading on each thought and then constrained followup with no ability to thread because you're already in the thread.

I can deal with the tech limitations it's the fundamental UX that makes it a huge garbage pile that is being forced on people because "we already pay for it and all our employees are in it. Also hard to build custom bots for if your organization limits admins.

The simple answer is to ensure that Ukraine never joins NATO. Secondary answer is to secure more seaports.

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.