- There is a lack of respect for the history of programming. IMO it has caused the industry to be stuck in a perpetual cycle of half-baked rediscovery.
- Similarly, a type of "FAANG-syndrome" exists and allows sub-par ideas to take over mind share of the industry. Once a technology picks up enough momentum, it will snowball and we're stuck working with legacy trash almost immediately. Developers legitimately seem to believe each trend is good.
- Our industry's shared vocabulary is too weakly defined. Phrases like "The right tool for the job" are ubiquitous but essentially meaningless and used as a form of shorthand "I currently feel this is correct". If we had a real professional lexicon, the first thing juniors would learn would be to enumerate reasoning to a precise degree. IME most "senior" devs can barely do it.
From my perspective "our" job is to deliver solutions to specific problems our end-users have. How people accomplish that varies a lot by their position/seniority.
To get into the weeds: When I first stared worst case scenario, I could waste my own time with poor or overengineered solutions. Now I can waste half a dozen programmer's time by not doing enough due-diligence and or planning.
But it's not always the best tool. Even as an IC, I've done far more with emails and meetings than just writing code without thinking, whether that's discussing UX implementation details with the designer or pushing back on some half-baked over-engineered solution from management or fighting some evil advertising and tracking scheme from marketing. We don't just write code but also gatekeep it with some level of professional judgment and ethical discretion. (Or at least should.)
I think the orgs that don't give you any autonomy or agency beyond "code monkey" are the more problematic ones. Not only will you burn out having to repeatedly implement things you have no input into, you'll also be the easiest to replace if all you do is code.
Doesn't this describe every job on Earth?
This issue is particularly prevalent in the Javascript world, where it isn't uncommon that when you hit build/run, half a dozen process need to occur. This is partly why I wish they'd just put native TypeScript in the browser, simplify the build pipeline by removing several steps (and, yes, TS would evolve slower/more conservatively which I also consider a positive).
WebAssembly is the apex of this issue. Super fragile to build and impossible to debug. It is what I call "prayer based development," because you "pray" it works or troubleshooting becomes a nightmare.
* WebSockets are superior to all revisions of HTTP except that HTTP is sessionless. Typically when developers argue against WebSockets it’s because they cannot program.
* Your software isn’t fast. Not ever, unless you have numbers for comparison.
* Things like jquery, React, Spring, Rails, and so forth do not exist to create superior software. They exist to help businesses hire unqualified developers.
* If you want to be a 10x developer just don’t repeat the mistakes other people commonly repeat. Programming mastery is not required and follows from your 10x solutions.
* I find it dreadfully hypocritical that people complain about AI in the interview process and simultaneously dismiss the idea of requiring licensing for professional software practice.
What did you mean by this? Were you suggesting that interactive web apps should maintain a persistent and stateful connection to the server and use that to send interaction events and receive the outputs back, like a video game would, rather than using stateless HTTP calls and cookies and such? Why is that superior?
And sorry if I misunderstood!
That is how I design all my web facing applications now. The idea is that with WebSockets all messaging is fire and forget and that is independently true from both sides of the wire. That means everything is event oriented on each side separately and nothing waits on round trips, polling, or other complexity. In my largest application when I converted everything from HTTP to WebSocket messaging I gained an instant 8x performance boost and dramatically lower the architectural complexity of the application.
No one is using my project, and I'm not exactly learning a lot from them, except in the first half of each one because whatever afterwards is just polishing (e.g. I did an interpreter project on a Python subset a year ago, and TBH the whole concept was pretty straightforward once my brain got it in the first few weeks). It's more of an obsession and that probably explains why I got burned out after 2-3 months and COMPLETELY lost interests in it. Looking at my GitHub commit history, it is always 2-3 months of almost daily commits compensated by 3 months of absolutely non-activity.
I don't think this is the right path for me if I want to leverage my side projects to get a job in low-level programming. Either I figure out how to drill deeper into each of my projects, or I need to figure out how to remove the burnout every 2-3 months. If the market is good I'd go straight to apply for system programming jobs but right now it's even tough to keep my own job.
So this is my unpopular opinions about side project programming -- if you are like me, maybe it's time to rethink the strategy. We only have one life, and I'm already 42. Gosh! Maybe I (we) should just find another hobby.
To me algorithms and solving problems in the abstract sense are the actual interesting part of the job
If discussing language/framework choices is the most interesting part of the job, it means I have a boring job/project/domain
- Cache invalidation is relatively easy; it's choosing the right strategy that is hard.
- You hate SPAs because you conflate them with running javascript, and you hate running javascript because you conflate it with predatory advertising strategies. You should hate predatory advertising strategies.
- IP clauses in job contracts contribute to the formation of monopolies and monocultures; they should be collectively fought harder than they are.
- Teaching juniors should be < 10% of a developer's job. If you want an instructor, hire an instructor.
In an alternate timeline, Microsoft might've won out with single vendor .NET everywhere. The DX would be better but everything would be way more closed.
On the iphone, only BASIC. :-)
"Just Run, Baby."
I'm not a 'programmer' like you all are, at best I can hack together code to get things done. I use git maybe once a year. I'm a biotech person that likes to hang out because y'all are mostly smart and the community is great here.
But man alive, this is not that difficult. Yes, it's hard to wrap your head around some nested dependancies. But it's a lot easier than any chain of protein/gene/neuron interactions. This stuff makes sense and you can edit it. My field can't really do that most of the time and it really doesn't make sense for decades (at best).
Like, I'm trying to follow along here and am mostly lost. But the few times I do know something about the code y'all are talking about, it's made out to be a lot more complicated than it needs to be.
I mean, yeah, keep that up though. Makes your bosses pay you more and lord knows those suits should be doing that and not spending the cash on rockets and shitty pick-ups.
But for real, y'all are making this out to be a lot harder than it is.
[0] this is supposed to an unpopular opinion, right?
It doesn't get as much mindshare as the problems with typing and frameworks and fashion trends and such, but my god, I've never seen a major, popular language with such poor support for basic time zone manipulation and storage. It is really really bad and won't be fixed until the Temporal API is stable and widely available: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
There is a relevant xkcd: https://xkcd.com/1987/
