Every single discussion around UI is now laden with "this isn't 100% optimized for user interaction" like there's some rulebook dictating exactly what you have to do for your website to be useable.
There's benefits to this, but the main con is that now everyone wants everything to look the same and the fun of the internet disappeared. Everything's a product, nothing's an experience.
I see what you're getting at, but I'd disagree. I think accepting who you are also comes with commitment to pursue the things you're interested in, because non-acceptance would be "ignoring this part of me I wanted to pursue but didn't think I should".
Nah, you definitely don't get it. Some people are here enjoying the act of programming, and Cursor Tab is acting like an improvement on IntelliSense/autocomplete that actually knows what it's doing. Not all of us want to spend half an hour going back and forth with a robot about what it didn't do quite right when we can be in the actual code, tweak a couple lines, and press tab for it to replicate the change in the next 50 now it knows.
Agentic coding is fine, definitely helps me a lot with setup and boilerplate, but finer business logic details and UX changes are now it's strong suit especially if you know WHAT you want but not HOW to explain it in a clear enough format that it can do it without additional prompting.
Even with frameworks, I don't see any joy in making something that just looks and feels the same as any other site. I understand it from a business point of view, but if you're trying to just showcase yourself or your work having flavor makes more sense even if it's not the most optimal thing for SEO or retention.
Really hate how modern website building sites moved towards structured, samey sites. I miss the days of Geocities and Freewebs, the unreadable text against cluttered background images, the auto playing music, the trailing cursors, the spinning skeletons in front of crappy looking flames.
Yeah I agree, someone saying they don't want to talk anymore because they've already written about something stops it being a discussion and makes it into some sort of lecture but without the notes. If you're insisting on telling someone you wrote about the current topic of conversation, you can just mention it and carry on with it. Like authors who go on podcasts, they'll say "Like I wrote in chapter X, I think that..." - the conversation shouldn't be killed off. Comes off as a bit arrogant.
Every person I've spoken to who's told me they're interested in crypto literally only care about it to make money, and have no interest in learning how it works. They all treat every last crypto-based use as investment like stocks, and not as a normal economic choice (e.g. "I want $3000 worth of bitcoin to buy a car" is not something people are doing, instead it's all "I want $3000 worth of bitcoin because the internet told me it'll be 3 million in a year").
NFTs also annoy me because it's literally the worst part of art industry - "buying" the "rights" to a piece of art so you can turn it for more cash later on, and not as an appreciation of the work. Bored Apes might be one of the few exceptions where people are doing it for "bragging rights", which is infinitely better because you're buying it to say you own it, much closer to normal art purchases.
Setting times is fine, but my approach is I have a list of 4-5 things to do written the night before, and knowing how much time I have in the morning, midday and afternoon as well as the energy I still have left at different parts of the day I say whether they’re done before work, at lunch, or after work.
I’m really not sure on the distinction people are using between to-do lists and these other approaches - they all seem like to-do lists just formatted differently because people work differently.
Programming books are generally technical documentation, or close enough - of course they're boring to read. There's so much detail to programming you could spend the rest of your life reading documentation and feel like you barely scratched the surface.
The article suggests identifying the reason you want to read it. In your case, you should identify what kind of problem you're trying to solve (even if not in an actual project and just in your head, something like "how DOES a cloud server work?") and then get that specific knowledge out of the book, as deep as you want to go.
Programming books can be expensive though, so you should generally google overviews of what you're looking for before committing to a whole book.
If you're having to read the thing for work, I guess identify what the problem at work/school you're trying to solve (or what project you'd be applying it to) and regularly relate back what you're reading to what you would do with it practically.
The universe is a system. We a part of that system. So any traits we have are inherently traits that the universe has, even if parts of it don't share it. A human has a hand, the hand is part of the human, but the rest of the human is not necessarily a hand.
I'd argue that's the worst kind of best practice, because in order to get an entire team to work on it they now have no reason other than "their manager said so". It's one thing to skim over what you know your project manager won't understand (mine doesn't understand programming at all so really they just take our word on the implementation side of things), but to try and push it to the rest of the team and just hope they remember a long list of do's and don'ts without justification other than a book said to do it is stifling their personal development.
Even worse, if one were to go off and read up on what you've told the team to do on their own behalf, find that they don't agree with it, you've now got to handle:
- a discussion that should have happened earlier
- possible backtracking of recent work to try and reverse the pattern
- OR a backlogged ticket to reverse it while the system now has multiple different patterns sitting around with no push for consistency in either direction due to lack of priority
Obviously becomes much more of an issue the larger the system is, but in general you shouldn't be following (or asking others to follow) best practices without knowing the benefits behind them versus what you're doing now.
Used to have to argue with my dev team manager about this, he was a big fan of reading about some new-ish concept that we weren't using yet and then trying to tell the team he needs to spend a couple weeks changing everything over to it. I'd be the only one trying to force him to give us a list of "pros" for it over what we currently do and he wouldn't be able to answer, then go off and half-implement it across the system without telling anyone, causing the degradation of our ability to maintain the system (since it's now less consistently written) and wasting his own time.
People need to take best practices with a pinch of salt, and actually think through whether they'll provide any benefit to them in practice for whatever software they're working on.
If he knew one of their suspects names and decided to fuck with them and throw them off the trail, yes, he would use someone else's name. Your leap to judgement of "it must be Gary" is just as much of a leap as "it might not be" - both rely on "knowing" the Zodiac's motives, which no one does, because he's not been identified.
I could have sworn there was something I read when I was young that way more than that goes extinct every year.
Is it really that big a problem? Extinction happens all the time, even before humans came around. It's just what happens when environments go through change.
Oh, and a mention on 'saying no' - it's very hard to convince an employer to start saying no to customer demands even when they agree with all the reasons set out in front of them, especially when they've had a decade of doing nothing but bespoke work for them. It's taken a year but we're finally at the point we can firmly stand our ground as a dev team and say "no we're not working on that", or "push to Q4", and ignore the "we need this done TODAY" type of demands that have plagued us for years.
There's a balance needed with smaller companies. I, for a long time, chose not to care about the company's goals and just hit the daily tasks, and for a while it worked and I did very well. But eventually the management had a build up of stress, realising that THEIR choices of assigned tasks were not taking us properly to the goals, and let out the stress on the development team to a point where a few of us quit.
This isn't an objection to "not caring about employer's goals", far from it, it's clearly an issue with management teething problems as they try to expand a relatively small company and don't know how to do it. But I've found that caring a little bit about the goals, trying to see what they're aiming for and having that inside view of why we aren't getting there, allows me to bridge that gap, offer better advice to management and help the entire team have a less stress filled day, at the expense of some of my own peace of mind.
It'd be easy for me to say "well that's managements issue" but I can't ignore that management issues trickle down to the rest of us, which is much more obvious in smaller companies.
>Back in the 90s it was virus checking (Do you trust the AV company? What if they were bribed by the content companies?), full device indexing and search (Do you trust the OS vendor? What if they're in league with the government?)
These are examples of companies choosing to do something as a selling point of their software as a benefit to the end user, and people worrying that it could aid the government down the line if they change their mind.
Apple's content review change is explicitly FOR reporting people to police in a way that can be expanded beyond it's currently set purpose (child porn) later.
>I'm very surprised this didn't blow up when Apple implemented ubiquitous image text recognition.
I'm personally not a fan of that stuff anyway, but personally if it's only my local device I don't tend to care about image recognition, it's only when it involves communicating information from MY hardware to THEIR servers that I get antsy.
Yeah I think their analogies are a bit mixed, but the general idea of ‘learned reaction’ is still there, even if the examples the author used didn’t mesh well together.
Everyone’s different. You can read a hundred different ways to get around the resistance, but doing them 100% the way they’re described likely WON’T work for you. You have to find the things you do like about it, and discard the parts you don’t, and continue to refine your personal routine over the course of a lifetime.
The most important part of that process is continually (once a week or a couple times a month, in my opinion) taking a step back and assessing what is and isn’t working for you, then taking the time to find a way around it.
There's benefits to this, but the main con is that now everyone wants everything to look the same and the fun of the internet disappeared. Everything's a product, nothing's an experience.