I think koonsolo has a point, namely that you may start a business thinking “yeah my terms”, but pretty soon the business will determine the terms - and the times.
+1 for specialization, in my experience working on a fullstack team is significantly more painful than having a specialized role. Of course it’s partially because you have to learn a bunch of stuff, but I’ve also found that fullstack teams tend to have poor planning, e.g. it’s structured as fullstack to constantly fill gaps in a not well defined project / roadmap. Fullstack is good experience if you want to do your own projects / startup, but not a peaceful job.
Maybe underestimating how different people can ramp up in different parts of the stack, or underestimating the context switch, or the amount of glue between the different parts of the stack.
You're not wrong, but the root issue is that most of the time the team are not actually full stack devs or they are full stack devs that haven't worked in a team.
There should be no context switch if you're full stack.
The context is the feature you're implementing. It involves backend, frontend and ops, and assuming you're actually full stack there is no 'mental switch' between those, the feature is still the same.
Devs that aren't actually full stack are the ones that require a mental context switch between backend/frontend/ops and this is where the issue is.
My first question to a full stack dev is ask them to outline the steps involved for a feature that requires all of these. The way they will answer and describe the flow will give you all the information if they are actually full stack or a frontend dev with backend experience.
Full stack devs are rare, I'd say to become one requires at least 5 years experience working actual full stack, a position that usually only solo devs get to experience. Solo devs lack the team experience and that's the other part of the problem.
Full stack devs that can work in a team are holy grail territory.
Which is why the most important thing after you find a true full stack dev is to focus on teaching them on how to work in a team.
> There should be no context switch if you're full stack.
I’ve always considered myself full stack but I’m currently struggling pretty hard with parts of the codebase written in OCaml. There are challenges that are unlike others, so I don’t think it’s a good idea to generalize.
Mac mini's without a monitor hooked up can only display at a certain aspect ratio while remote screen sharing. The typical solution is to use a dummy hdmi plug (~$10) plus an app like SwitchResX (~$20) to support custom screen resolutions.
If OP's app works as described, then this is a free software solution to a $30 problem.
Your presentation has presenter notes but your MacBook has only one display?
Create a dummy display for the full-screen presentation, share that into the remote meeting/projector, and preserve the primary display for presenter notes, logtails, chat, etc.
For those who don't know, in PowerPoint go to Setup Slide Show on the Slide Show tab and select "Browsed by an individual (window)" and then share that window. Great for Zoom et al.
I use OBS to handle the screen sharing because it is easily to misclick the wrong window that are not for public view. In OBS, it is binded to specific window titles and it is easily to edit out the black bar on the top of the PowerPoint that appeared in Zoom directly (without OBS). I have a few scenes set up this away and quicker to switch than doing it through Zoom itself.
This doesn't sound like the core use case though based on the README - it sounds like it's used for enabling HiDPI (aka not-blurry) scaling on less-than-4K monitors. So, using native resolution but not necessarily 1:1 DPI.
Hi, I tested the Screen Sharing scenario with BetterDummy running on an Intel headless Mac Mini 2018 running Big Sur. Works splendidly, all resolutions are available and resolution change works on-the fly through Screen Sharing!
If you connect a Mac (mini, MacBook pro, air) to an external monitor, AND this monitor is not recognized as "retina" (eg. Apple $4599 XDR) AND you are not running at the monitor's highest resolution, the screen will be blurry.
There are a lot of "ands" in the above sentence, but it's actually quite common situation. Retina monitors are expensive. For non-retina monitors, native highest resolution still renders objects too small for many people.
On MacBook Pro/Air the solution is to mirror the screens. The MacOS thinks that it renders to the retina screen and sends appropriate re-scaling to the external monitor. But mirroring has its problems. For example, expect ratio will be the same as MacBook's internal screen. This may result in black bars on the monitor, depending on its aspect ratio.
Also, in M1 MacBook Pro 2021, the aspect ratio is variable, due to the 72 pixels menu bar up top, going in and out. I am not sure what will happen when you mirror the screens there.
Has Microsoft been particularly litigious of late? Pearl clutching over Microsoft’s use of telemetry (which Google never uses, by contrast) has turned into full-blown Slashdot-style insanity.
What you call insanity, I call keeping check on power abusers, and MS has decades of track record of that. The fact they started to play nicer the last few years doesn't magically erase lying, cheating, corrupting and trolling for 20 years. Also google gets it fair share of criticism.
In fact, I think we don't make enough noise given the few people outside of our bubble that knows about it.
It's as evil as you think the centralized authority is now or will be in the future. Some will also argue any entity having complete power over your life is inherently evil.
