My current mornings are pretty relaxed. I wake up an hour before I have to go to work, drink a glass of water, have a coffee while listening to some music and I might be browsing something on the internet. No socials though. Then I fill a water bottle and put it on my desk, take a shower and get dressed/etc. I work from home so that's nice but I do get ready as if I have to go out, i.e. I make effort to look smart and even put on some cologne. I do need to wake up relaxed though, I f*king hate waking up and having to rush.
When I was in between jobs, it was mostly similar but I got up an hour later than I would usually and wouldn't hit the shower until like 10 am. Maybe work on some project or watch something, eat lunch around 12 and then either go out for a walk or get groceries done. Only in the afternoon I would job search, call back people. Its only a few hours but I had to learn not to try to constantly job search, because there simply is no point and it would just make me feel like I was failing at it.
I'd say you're right to want some structure, but you're perfectly fine not having it all be productive.
> The reason React is particularly disparaged, imho, is because the framework fashionistas have moved on to chase the new shiny thing, and everyone else has always hated all these frameworks to begin with, so there's no one left to defend this particular hot mess.
I think you're projecting here. Its fine not to like trends in tech, but tech will change whether you like it or not. The people who jump on every new thing and stress about having to learn it all will keep doing it. That doesn't mean that anyone else hated it all to begin with. That's a pretty weird assumption to make. Even this thread is full of people who enjoy using React. Meanwhile, React is pretty stable and boring if you ask me. Your nightmarish decade will be extended. I'll light a candle for you.
Take notes as you go or by chapter. If a chapter has a summary at the end, read that first before going through the chapter. If there are code examples, write them out and play around with it. Get the important bits out that way.
Also, realistically you probably won't remember most of what you read. I suck at that as well, but you do build up a lot of peripheral knowledge. You may not remember how to do that one thing, but maybe you do remember that it exists, or that it was in a particular book. Just that type of knowledge has worked well for me.
We can't agree on your stance, because other people have different stances. You may have some reason why you want JS and cookies disabled, but many people don't. JS has been a part of the internet for as long as I've been alive. Sure, it's being used different and sometimes needlessly as with the blog you noted, but it's here and it's not going anywhere.
If you want the web to be cookieless and JS-less, you can disable them. But the web is not cookieless and JS-less. You get the experience you want. You can't expect everyone to want that experience.
Whatever happened to the notion that web pages should fail gracefully? That is, they should be able to function in the absence of JS and cookies. Perhaps not fully functional or as pretty, but they should work.
I've long considered websites that fail to do this to be poorly engineered.
I suppose that notion went away _because_ of JS and cookies.
Looking at it from a business perspective, it's also a matter of cost. How big a percentage of people have JS off (I searched a bit and everything suggests low single digits, 1-2%), versus how much time do I spend making sure the site is somewhat functional to serve these people. And does somewhat functional make sense? Can they see my site but they can't go into my sales funnel without me making HTML-equivalent pages? In that case why would I bother unless that percentage of users grows to where it becomes financially interesting to me?
Still, would be nice if most sites would at least render some plain HTML fallback with a bit of info, instead of a single line on a white page saying "this doesn't work".
> I suppose that notion went away _because_ of JS and cookies.
I don't understand what you mean here.
> Looking at it from a business perspective
Which, I suppose, is the underlying problem. In my opinion, the drive to turn websites into revenue generators has had a corrosive effect on the entire web. I suppose that I just have to accept that increasing portions of the web are going to be hostile and to be avoided. It just saddens me, as so much -- perhaps a majority -- of the web is already more of a security risk than I can bear.
> Still, would be nice if most sites would at least render some plain HTML fallback with a bit of info, instead of a single line on a white page saying "this doesn't work".
More info is better than less info, but either way, the page still won't work.
> the drive to turn websites into revenue generators has had a corrosive effect
While I agree, there is the other side of that. They are very very expensive. Even a simple site needs servers, and devs.
> More info is better.
For who? If I tell the 2% of people out there that I sell these awesome things and they attempt to purchase them, but they can't because they have JS off, who did that knowledge help?
Now if it cost me 10k to tell the 2% they're waisting their time here, I'm out 10k and they're no better off than when they got a blank page.
It went away when not having JS enabled stop being a regular thing ( what, 2010? At the latest!). Before that there were users with very old browsers, or asinine corporate "security" policies that didn't have JS; nowadays it's only luddites longing for HTML-only websites ( we must have lived in different times because those were just terrible to read, especially if you had a nonstandard (for the developer) screen size), aka a negligible amount of internet users. It's a pretty safe bet to not even test what happens when JS is enabled.
I politely disagree: today usage of js should be considered criminal not only because of privacy but because of IT {e,in}volution at a whole. In the past all desktop OSes are document-based and work in peer to peer networks (starting from Xerox workstations) since them we only have made crap to copycat those historical systems in buggy, limited and limiting ways just to avoid leaving end users any control of the system they use.
Such move is harmful for the society and must end before it's too late. We must came back to classic desktop computing and punishing all evolution that try to lock users. Modern web(cr)apps fall in this very category.
It's very asinine for instance forcing people's on crappy bloated banking portals instead of agree around a common and standard API (like SEPA OpenBank) leaving users using their favorite local app where all transactions are locally stored, digitally signed by the bank so source of truth in user hand, always available, with as many banks as users want under a common user-chosen UI. No need for crappy monsters WebVM, no need for gazillion of resources just to keep pushing around garbage mostly used for surveillance. The same apply to taxes and pretty anything else.
Personally I like reading post with Firefox reader just to avoid being distracted by the crap added to most websites, if a website does not render in Reader or without js I simply avoid it.
It walls an increasing amount of the web off from a really small and ever decreasing amount of people.
I'd actually say it's good engineering.
If I engineer a small gas can (for filling my lawn mower) I can build one that holds a gallon, or one that holds 5 gallons. Now 2% of the population that owns lawn mowers have massive yards and riding mowers. So which one do I engineer? Which do I build. I build for the 98%
Optimist says cup is half full
Pessimist says cup is half empty
Engineer says cup is twice the size it has to be.
The reality. Building for the 2% just isn't an effective use of resources.
-- Oh oh.. I got a better one..
-- How many bridges in your home town have allowance for horses. Are all the bridge builders bad engineers?
The way software development is generally practiced is not "software engineering" but "MVP development", which has nothing to do with anything but getting a piece of the pie. If a particular user doesn't fall into the biggest slice of that pie, the MVP developers don't care.
I've always felt that it's easier to handle older browsers with, if JS is an optional feature. Luddites must be the wrong word here, since it's mostly highly technical people that disable JS and cookies, old farts doesn't work either since there are more young people around me that does it.
I'm perfectly fine with using cookies and JS, in fact I use them daily in my webapps...
But please, please do render html _without_ requiring JS to do so... That's my main issue - getting blank white page on a simple text based html page like the one mentioned before...
Yeah that's very poor practice. I get why your site may require JS and have nothing for me if I turn it off, but do at least render some fallback with a bit of info so I know what I'm missing, how/where to contact and might be enticed to turn it on again.
No, we can't.
We can't agree on your stance, because other people have different stances. You may have some reason why you want the blink tag disabled, but many people don't. The blink tag has been a part of the internet for as long as I've been alive. Sure, it's being used different and sometimes needlessly as with the blog you noted, but it's here and it's not going anywhere.
If you want the web to be blink tag-less, you can disable it. But the web is not blink tag-less. You get the experience you want. You can't expect everyone to want that experience. /S
Well, we can. Some people here have even suggested just _how_ we can, so it's not that we can't. We're just not. You know, for reasons.
> We can't agree on your stance, because other people have different stances.
We can't agree on your stance on racism because other people have different stances.
To put my point less facetiously; opinions aren't the end of a discussion, they're the beginning. Presumably these stances you speak of are based on something. Well okay, this guys stance is based on something too. Discuss the merits of each and you can arrive at one stance that's more correct than the other. Unless of course one of you stops at some point in the discussion and says "Yeah, well, that's just like, your opinion, man".
> JS has been a part of the internet for as long as I've been alive.
I think it might be the cause of the problem some of us have with today's bloated Web. Sure, it wasn't ideal and definitely it wasn't pretty, but it was way more usable than today.
We used to share designers between teams at a company I worked for. It worked nicely, but the approach has its drawbacks as well, in that the person designing an extension to something might miss a lot of context that the previous person did. Especially if you constantly switch people around, you run into this.
Regardless, that doesn't address the plight of the junior. The junior shouldn't be put alone in a team and expected to effectively manage everything in that beach-ball graph, let alone be expected to come up with proper designs by themselves. That's a fault of the person putting the junior there, not a fault in the design of the whole team.
It usually works out fine when you do a `git pull --rebase`, but not everyone does this or has it setup so pulling might have some nasty effects. Generally helps to consider a feature branch as a private branch. Don't push to other people's features without asking, don't fuck up other people's work.
I suppose just the usual 'rebase vs. merge' - i.e. if there are conflicts to resolve they will be dealt with commit-by-commit in the usual way when rebasing, whereas without the option set they will be dealt with all at once 'merge-style'. I happen to think that's a feature, but I know some don't like it.
I think there's less argument in favour of merge than usual with pulls though - since it's much less like a semantic merge to begin with for git-merging to preserve a history of.
I'm certainly not aware of any objective downside/gotcha/'oh but it doesn't work when...', no.
Because git was written primarily for the Linux kernel and the defaults reflect that. The workflow of the Linux kernel is completely different from what most people outside of it do with git. "git pull" is used for opposite purposes in both worlds.
I think it's the usually public vs private branch issue.
If you're merging a public branch with another public branch, then if you a rebase, rather than a merge commit, then you mess up the history for anyone has pulled that branch.
The annoyance I'm describing is that when the commit message is 'merge branch master' (and especially if, as the label next to it shows, it is the master branch) this is crap and useless, and hiding the 'real' commits behind it that the committer had locally while behind the remote. If they had `git pull --rebase`d (or `git pull` with the config option set) the commit message would be that of the latest 'real' one.
I commit as clean as possible, each one should be a functioning feature or a part of it. I try to do small ones, so generally they'll just be part of a feature I have on my todo list for the entire feature. That actually helps me to mentally move on as well. If I need to rename some stuff I might squash commits, but no wip commits in the actual history.
End of day I usually commit a "temp" commit with a few comments to myself and push that to the remote branch, revert that the next day and force push over it for the next commit.
I have to apologise to the parent commenter, I laughed inappropriately hard at that.
Still, quite confronting to see how much time you have left statistically. For me it got me to change careers. I figured if I still had 30 work left before retirement, I might as well.
“But that’s very different from having the latitude to wake up and say, ‘You know, it’s raining. I don’t feel like going to work.’”
Pretty much sums up the CEOs thoughts in a single sentence. People that aren't in the office don't "feel" like going to work.
I don't "feel" like sitting in an office being unproductive, distracted and running from meeting room to meeting room anymore. If your culture is keeping people at the office for 70 hours per week and you're afraid that vanishes if suddenly those lazy people don't have to sit there anymore... then maybe your culture isn't worth much.
When I was in between jobs, it was mostly similar but I got up an hour later than I would usually and wouldn't hit the shower until like 10 am. Maybe work on some project or watch something, eat lunch around 12 and then either go out for a walk or get groceries done. Only in the afternoon I would job search, call back people. Its only a few hours but I had to learn not to try to constantly job search, because there simply is no point and it would just make me feel like I was failing at it.
I'd say you're right to want some structure, but you're perfectly fine not having it all be productive.