5 ms·
This is a perfect example of why the problem isn’t the stack, native vs web, or programming languages. I’ve been saying this for ages when people bash JS for be
by klabb3 3y ago
This is a perfect example of why the problem isn’t the stack, native vs web, or programming languages. I’ve been saying this for ages when people bash JS for being slow, or the web for being bloated.
Yes, you pay a bit for the sandboxing, GC, rendering, built in accessibility. But that’s a rounding error when businesses, especially large ones, go on a PM-centric feature frenzy. You get out exactly what you put in. Performance, security, user experience..
Whether it’s frontend, backend, embedded, whatever, the engineers are alright. Generally. It’s when you stop listening to them, or punish the grumpy ones in favor of the people-pleasers, that this crap happens. That’s worrying, because it’s become so prevalent.
- OtomotO 3y ago> This is a perfect example of why the problem isn’t... Depends on how you frame the problem. If you declare the problem is that although batteries became way more efficient you don't get out more hours because they are wasted, then the story is a different one. Same when you don't have an abundance in RAM but are forced to use certain programs and applications. I have 64GB Ram these days, colleagues at clients of mine only have 16GB and they face certain challenges I don't, because of the tools forced upon them by their superiors. These problems can be real, they can be "artificial" (there is a philosophical note to this somewhere ;)), but in the end, there is undeniable truth that launching a whole browser engine for each and every app can be and indeed is wasteful compared to alternatives. Of course if you don't see this as a problem "ex falso quodlibet" takes precedence and it all becomes futile to discuss :)
- thrnkkm 3y agoIt goes opposite way as well. I have workstation with 128GB ram with a few terabytes of storage, I can run full stack with everything in single machine. I also have VM snapshots, versioning etc... There is simple script that installs all deps and setup dev machine. My colleagues have tiny Macs with 16GB. To accommodate them, we had to split mono dev setup into separate K8S cluster. On single machine I could easily split test build process. Now we have spaghetti of dependencies. And spinning up secondary dev instances is not permitted due to high AWS cost. So investing result binary (like this blog post) is now impossible.
- rand846633 3y ago> And spinning up secondary dev instances is not permitted due to high AWS cost. Time for a new employment opportunity.
- deleted 3y ago[deleted]
- ToucanLoucan 3y ago> there is undeniable truth that launching a whole browser engine for each and every app can be and indeed is wasteful compared to alternatives. Wasteful and always, always a worse experience. I'm sorry if this ruffles feathers here or people feel called out, but I can FEEL the difference in these web-cruft apps every single time, full stop. I would Pepsi challenge this as many times as people want and I will eat my snow boots if I get it wrong. If you make your app with web tools, I will not use it if I can conceivably manage doing so. And if I must, then I guarantee you I will do it as grudgingly and as little as I possibly can.
- m463 3y ago> the grumpy ones You know, grumpiness really is a thing. I wonder if it should be treated as a symptom like left arm tingling before a heart attack. A call to make some serious changes.
- vasco 3y agoMeh, developers are people too. They are right and they are wrong. I've seen some guys who are proud of having the grumpy persona, which is really just a nice word for "I know better than the other people I work with" and it's not a great attitude. Engineering choices all have trade-offs yet the grumpy guys always frame it as "my way or everything will collapse later".
- mjburgess 3y agoWhat attitude is the appropriate one if everything will collapse? There are long-tail risks to the stability of codebases, organisations, institutions, governments.. the soviet union collapsed. It seems likely that some engineers can intuit such long-tail risks. If linkedin is subject to a competitive threat which requires rapid innovation, the org will lose because it's development practices preclude it.
- DaiPlusPlus 3y ago> What attitude is the appropriate one if everything will collapse? Short the stock.
- m463 3y agoSorry, should have been more clear. It is when you - a normal, well adjusted engineer - realize you are feeling grumpy about something. It might be a sign to explore what is really going on.
- klabb3 3y agoAgree with this. And why it’s important to have spaces to blow off steam and vent without being shunned as a bad team player or whatever. I’ve seen quite a bit of toxic positivity that makes people sit on their grievances in silence instead and become complicit and resentful (like the parent comment mentions). It’s much better to air it out - oftentimes there’s constructive things behind discomfort. In fact, discomfort is a guiding light for innovation imo.
- usrusr 3y agoIt's not just PMs though: developers are forced into resume driven development by hiring practices. If they stick to the toolkit already established in the app they set themselves up for a career trajectory towards Uber driver. The risk of knowing only what was fashionable five years ago is just too big.
- DanielHB 3y ago50% of the reason Kubernetes is getting so popular, devops people need k8 experience to move up in their careers and therefor your company is now using k8.
- ako 3y agoI think ai/llm have overtaken kubernetes in this regard, everything’s needs to be solved with AI, even if it doesn’t solve the problem in a better way. But I guess that’s also part of the learning process, trying it everywhere to learn from experience what doesn’t work.
- efxhoy 3y agoWe’re adopting kubernetes to run “ai” with kubeflow. Modern problems require more problems taps forehead
- sotix 3y ago> It's not just PMs though: developers are forced into resume driven development by hiring practices I was laid off from my last gig in January because the company was running out of money. Last week I saw a former coworker share how excited they were to turn a perfectly functional and internal website built with html and css into a react app with redux and nextjs. I couldn’t believe a company running out of money would have a developer do that when it doesn’t affect revenue generation whatsoever. And I can’t believe the dev didn’t stop to think that the previous website was already perfect. There were never any complaints. Their LinkedIn post had tons of likes. I’m happy that they were happy, but I was left a little concerned.
- deleted 3y ago[deleted]
- ngrilly 3y agoSounds like bad product management as much as bad engineering. I mean, the outcome — a bloated product — is bad for everyone: the users in the first place, the engineers building the product, but also the PM who can't conceivably be proud of shipping a bad product.
- klabb3 3y agoIn my experience PMs are not rewarded for good product, but rather a mix of shortsighted metrics and whatever their VP/senior person has on their personal agenda. At big companies, employees are often not even using their own products. The corporate ladder is all that matters. Obviously that’s not unique to the PM role, but seemingly more prevalent. I think it’s an effect of the rootless roaming you get when you spread people thin over large areas, and don’t have clear ownership and responsibility – which I think is a prerequisite for (the good kind of) pride. But overall, yes, it’s definitely a structural issue with the organization at large. Clearly, when it’s gotten as bad as in this case.
- passwordoops 3y ago>In my experience PMs are not rewarded for good product, but rather a mix of shortsighted metrics and whatever their VP/senior person has on their personal agenda. At big companies, employees are often not even using their own products. The corporate ladder is all that matters. YES YES YES. It's why I gave up on working as a product manager after nearly a decade. It's turned into KPI Management and everyone suffers, especially if you care about delivering good product
- johnzimmerman 3y agoWhat career did you transition to?
- passwordoops 3y agoMy background is natural sciences, so I took a paycut to go back into an academic lab and rekindle my bench chops. Been really fun so far and my hope is to continue working in the field as a lab manager or researcher in the private sector. Won't pay as high as a software PM, but a lot more satisfying and healthy
- osrec 3y agoPerhaps, but in my experience, this is often what happens when you have too many cooks. People like to build corporate empires by having more subordinates. Those subordinates need to justify their existence somehow. Bloated, inefficient software is one of the unfortunate outcomes.
- signaru 3y agoSome of my friends who work in similar situations call this "job security".
- DanielHB 3y agoYou joke but when something is really bad I make a point of saying it is "job security" for myself in front of my tech lead (and my teach lead's manager). It triggers something in their heads that "oh, if he quits we are screwed". Those things tend to get addressed. There other bad things I don't refer like that, like something that is bad but if I quit and they get a new guy he can probably figure it out in a few weeks tops.
- itsoktocry 3y ago>go on a PM-centric feature frenzy Do developers have any agency whatsoever, or are they at the mercy of doing whatever their managers suggest (while always knowing the "right" answer, of course)? Does our industry attract people who avoid accountability? Fraud? It's the executive's fault. Business struggling? It's the MBA's fault. Bad product? It's the PM's fault. Must be nice!
- wildrhythms 3y agoMaybe when you tell your engineers you need X feature implemented in two weeks, leaving them no time to plan or refactor, and they're building on an already bloated, ancient spaghetti codebase because every deadline has been two weeks under a skeleton crew for the past decade...
- ninkendo 3y agoThey have very little agency. Priorities are driven by OKR’s, which require measurability as one of the core tenants. If you want to accomplish something, you must be able to point at a number somewhere, and have a plan to make it to up and to the right. Refactorings to pay down tech debt rarely can pass as OKR’s unless there is a true business need. This is a feature, not a bug, as far as management is concerned. They’re often proud of saying things like “if you can’t measure it, it doesn’t exist.” There’s often managers that are very sympathetic to the idea of pushing for quality, but then they’ll ultimately say something like “but, if you can’t come up with a number to show benefit, perhaps it really isn’t worth pursuing ¯\_(ツ)_/¯” and we move on to the next feature. The only way any real quality improvement happens, is if motivated individuals do the work basically on their own time. You will not get organizational support for it. If you’re lucky, it will pan out and an improvement will be made. If you’re not, maybe your refactoring causes a regression somewhere (nobody’s perfect!), someone notices, and if that person is particularly angry about it you’ll get yelled at for making “rogue changes” that cause bugs. If your rogue change was done in some other part of the codebase, you’ll probably have your access revoked (ie. others will be put on the approval chain to prevent you from making such changes again.)
- trog 3y ago
- salamander014 3y ago> punish the grumpy ones in favor of the people-pleasers, that this crap happens This isn’t exclusive to technology, but I see this all the time at my large organization. As a grump, I have to pick which shitstorm to care about and spend my time chipping away at, which ends up being really draining. To help with this, we began focusing a team of great folks with shared values, leaning in on modern operations/SRE best practices. We started to have some real success with SDLC for our operations workflows. That’s when management changed our teams direction. Good times.
- silent_cal 3y agoEspecially when everything's on 2 week sprint cycles, and all of those new features are rushed. We can refactor later!
- blasphemers 3y agoWe're not doing waterfall, but we're going to plan out every little detail of a change into small parts and plan out how many sprints it should take to do them all and split that work across the team so that you are always relying on someone else's work or somebody is waiting on you to start something.
- imbnwa 3y agoLiterally described my workplace, and it won't change b/c everyone wants to game theory the wrong way to make themself look like a 'team player' (I hate that term)