I said in another post that I hated all the ceremonies, including standup. And it goes without saying that means long standups.
But, one team I was one, we had long ass standup and it was perfect. It was very dev-driven, we were facing hard problems, and that was our time of the day to really nerd out. The PM would get bored after about 15-20 minutes and then we'd be working out how to deal with the issues that faced us. Sure, it could have happened at any point of the day, but that was our designated time where we were all in the office (this was pre-pandemic)
That seems unproductive. You end up having a room full of people discussing problems that should be solved by one or two people outside of the standup. That's contrary to what a stand up meeting should be. Don't do that.
That's the issue where the PM has so much power. In our company the engineering team dictates their process. They can do however they like as long as they ship the products on time.
Because in real world people play with the hand they are dealt with. Team hasn't quit because there are no better jobs with empowered developers are waiting.
The real question is why is the team putting up with this? They should be complaining about the PM and wasted time every chance they get, at the "retro", team meetings, and 1:1's... Complain, complain, complain.
> Honest question - why still use Google at all? Whenever DDG became good enough (seven? ten? years ago?) I used it exclusively. Lately I use a mix and have moved on from DDG, but I still never went back to Google and don't understand how people can tolerate it; I find the results really bad.
To me, DDG's results seem relevant-ish, while Google clearly knows my profile and what I'm looking for. I get more relevant results with Google than I do with DDG. That of course comes with the price of my search history and other behaviour online, but I'm okay with that.
Google also comes with some features that is convenient, when searching. Doing a "take away [town]" I get a minimap with pins, so I can see the take away places near me, the menu's are easily available as well as information about opening hours. DDG just gives me an (apparently) unordered list of restaurants in the town I put in, and with my sample search, the two first results doesn't actually provide take away.
Google to me is a convenient choice. I like convenience.
Odd. I don’t get relevant results using Google at all. Sometimes I get results that are in the same topic, but I can’t remember the last time a Google result gave me a result on the first page without a VERY specific query.
Kagi knows what I want (and don’t want) because I get to tell it. My preferences are what I tell it, not what it surmises from my activity.
PHP kind of stagnated in terms of development with PHP 5.5 in 2013. It kind of went quiet. Along with an overshared article[0] on how bad and why PHP 5.4 was bad (which the community in all fairness overall agreed with, with some exceptions) PHP got a real bad reputation.
PHP 7.0 landed after key persons picked up the development of PHP again, and while progress was slow it really took off from here.
It seems like the biggest pain for the entire community is the lack of generics. There's a lengthy explanation as to why it's so difficult to achieve in PHP, but overall the features since 7.0 added has really added some modern value compared to peer languages.
A lengthy list of additions is easiest generated by some GPT provider. But the community painpoint is generics.
I've been working with Laravel since '13 and PHP since '99.
Both just keeps becoming better and better to me. Recent years of needed improvement and feature development of PHP, keeps me happily invested in continuing with PHP as well.
I tried NodeJS/Typescript for a couple of years, between '21 and '23 - I never learned to like it and leaving the community was the best decision for my mental health in a software development context.
> I tried NodeJS/Typescript for a couple of years, between '21 and '23 - I never learned to like it and leaving the community was the best decision for my mental health in a software development context.
That's an interesting statement, as it heavily contrasts with my personal experience.
From the start, TypeScript felt as a breath of fresh air and the whole experience was very enjoyable.
The only (and major) drawback was having to deal with JavaScript frameworks which required tsconfig.json/webpack voodoo to work at all, let alone with TypeScript, but once the project was sorted out everything was a pleasure.
Can you point out the single most egregious thing you experienced with TypeScript?
> That's an interesting statement, as it heavily contrasts with my personal experience.
The key take here is that it's a personal experience - for the both of us. I'm confident that it works for some, the same way as PHP doesn't work for everybody.
> The only (and major) drawback was having to deal with JavaScript frameworks which required tsconfig.json/webpack voodoo to work at all, let alone with TypeScript, but once the project was sorted out everything was a pleasure.
I guess this is a great transition to your question...
> Can you point out the single most egregious thing you experienced with TypeScript?
The _most_ egregious thing? I would definitely say the community behind it. While I've worked with other languages as well (Kotlin, Dart, Python), the community behind NodeJS/TypeScript is the single most fragmented and toxic environment I've ever experienced.
It seems to have no common direction whether it comes to dependency managers, coding styles, transpilers, bundlers or much about any other “best practice” paradigms. And this also something that is pestering packages and the maintainers. Often, it looks more like a contest on who can make the most complex solution to simple problems as well. I don’t experience this vast amount of fragmentation in PHP, Python, Kotlin or Dart. Whenever you reach out to the community, you’re rarely met with more opinions than you have fingers and toes; sure - not all agree on everything, but there’s more often than not, a sense of consensus on what a common approach to any given problem could be.
> Whenever you reach out to the community, you’re rarely met with more opinions than you have fingers
One looks like a large and fast-progressing area, the other like a smaller and more cohesive area. JS/TS ecosystems made a lot of breathtaking progress in the last 15 years. It has a price: trying all the new approaches to find a better path means a huge breadth and fragmentation of the mindshare.
Not that Python hasn't made a lot of progress in the same 15 years, but, frankly, it's not as varied and novel, even with the advent of gradual typing and async support in the language.
Stability may sound and even feel good, but being stuck with targeting IE6 or C89 is also stability. Both stability and progress have upsides and downsides, there's no absolute winner, and you have (and, importantly, can) choose the balance you're more comfortable with.
It's constant churn in that ecosystem to keep the build system working in any medium/large project, way more so than in any other backend runtime/package managers I've used.
It's hard to quantify, maybe, but it just feels like constant stress. I've worked in bad Java shops where you wonder if the build will compile today. The average Node places are much worse in terms of the tooling and build system not working for whatever fancy reason on <insert day>.
Recent example: Did someone at Google decide to merge a PR to a library two dependencies down? Because now shit won't compile, the compiler OOMs. Just what I wanted to figure out today, a crashing compiler on a minor library version change that nobody asked for.
It’s a challenge, but it’s not that bad. All the package managers have lock files, so no dependencies change daily until you update them. You could even have auto-update via dependabot or renovate and the smallest amount of CI would stop the breaking update from getting through. I’ve worked in a lot of node projects and never worried about whether they’ll compile today. Lock files have been standard/default practice for a long time.
The hard part is actually doing the updates. So many breaking changes, so many new (often better) approaches, so many different tools that interact with each other in weird ways…
It happens regularly to the point that it becomes the happy path.
The trick is that you should pin all dependencies and not just let auto-updates happen, and instead treat even patch updates as if they could be major-version bumps.
> It's hard to quantify, maybe, but it just feels like constant stress.
I agree, but the key factor is auto-updates cause pain. Once you disable those you no longer experience any pain. For instance, no one needs to constantly upgrade dev dependencies, and even patch upgrades to TypeScript are hard to justify without full regression tests.
If you put off all updating doesn't that lead to a lot of technical debt down the road? I guess most of the stuff I work with has to work for a long time and putting off updates just makes for a worse pile to sort out later once you find something newish to integrate and now it won't work with the older existing stuff. For us, keeping up to date incrementally helps prevent that maintenance work from building up. I guess it depends on how long you'll be maintaining the code. If it's something that won't need to work for a long time and you have enough devs then you can probably skip keeping things up to date and just rewrite it when it needs updating.
> If you put off all updating doesn't that lead to a lot of technical debt down the road?
It depends on what you interpret as being technical debt.
For example, are you piling up technical debt if you skip a patch update to the typescript compiler? What about Jester? What if you skip a point release of React? Are you piling up technical debt if you are not on the bleeding edge?
In case this counts as technical debt, what's the productivity hit of staying on that treadmill? Are you actually gaining anything by systematically be on the latest and greatest?
> For us, keeping up to date incrementally helps prevent that maintenance work from building up.
In my experience with modern frontend frameworks, the vast majority of these incremental changes do not add any significant value and in fact amount to wasteful noise. Some patch releases introduce regressions that are ironed out in following releases, and automatically applying these updates only buys you problems.
Also, it's very hard to justify having to refresh your whole dependency tree at each commit, or risk experiencing problems because switching local development branches causes dependency issues. Installing dependendencies should be a rare occurrence.
I can't overstate the importance thay pinning all dependencies and lowering the frequency of how these dependencies are updated has on a team's development workflow. No one will get hurt if you upgrade Jest or TypeScript on a monthly basis instead of at each commit.
I think pinning dependencies helps, but I have literally never seen an organization do this with Node. At one job, the "architecture review board" decided that all services would always use "latest" for all dependencies...
I don't disagree, but there are other issues too. Namely the Node runtime is much harder to diagnose performance issues than with even async Java, and every time this comes up it's a huge resource sink for most teams I've seen.
I think Node is a great tool. Lots of FastComments is built with Node. I just don't advocate for building large systems or monoliths with it.
I think for my next project I'll be trying out using Laravel's prebuilt user auth/login system, then building the business APIs in Node+TS (interfacing with the same relational DB). Developing not-so-dynamic webpages is just quicker in Laravel/Rails/Adonis, and reusing a prebuilt auth system across small projects just seems logical.
There's a bit more coordination involved in this approach, but there's sufficient separation of auth logic from other logic to allow it to work efficiently. Might run into issues with performing auth-related tasks (like invalidate session) on the Node API side, but I think they won't be too difficult to work out.
Highly experienced Senior Engineering Manager adept at steering scalable tech organizations with a strong track record. Currently leading the offshore team for Joe & The Juice's critical mobile App and Backend, managing over a million users and driving significant revenue. Proven expertise in setting tech strategies, implementing PCI DSS compliant environments, and streamlining development processes through AWS DevOps strategies. Seeking an Engineering role to leverage skills in leadership, strategic decision-making, and technical innovation, contributing to organizational growth. Open to opportunities aligning with my passion for engineering excellence and continuous improvement.
> There’s a bit of religion happening in both directions. iOS has, objectively, fewer problems than Android in these regards and part of that are the policies.
When you say "objectively" I assume that this is something that has been measured and that there are reliable sources for this statement?
I would be really surprised. Anytime when I’ve searched for a feature (like DLNA sharing), and not for a specific app, I’ve got only very shitty spam apps in both stores. Even when I search for specific app, like GTA, the results deteriorate very quickly, in both stores.
I think it works well in both ways. I've been developing software professionally for the past ~20 years and there's no doubt that the combination of ChatGPT and CoPilot greatly reduces the amount of time I would usually spend on boilerplate code. Now I can more or less just review the suggestions, review tests and progress with my solutions a lot faster.
At the same time, I see my 9 year old girl using ChatGPT to create Minecraft extensions; she has no prerequisites for actually developing software, but she manages to make some small extensions and have them work either way.
Acknowledging that she doesn't actually learn much from this, I think one can assume that everything in between (e.g. using ChatGPT for pair learning) is definitely also possible.
But whatever AI is outputting, there's no way these qualified guesses can beat experience from a professional developer. I know that the output will never be better than the prompt, but sometimes the output - no matter how much effort you put into the prompt - is visibly just a qualified guess.
> How do people deal with Teams' vastly inferior chat after coming from Slack or Mattermost or anything else remotely modern?
I'm an engineering manager at a multinational company, which also have remote employees.
Half a year ago, we got a new Director of Engineering, who decided to move from Slack to Teams, due to compliance implementation.
No one in the engineering teams want to use Teams at all; they deal with it by secretly having a Slack Team that only they (as far as they know, at least) know about.
While the rest of the company is forced to use Teams, the engineers are using Slack as they've always been doing.
I've spent the last two years working with TypeScript solely. Coming from ~20 years with PHP and using Kotlin and Dart for some years as well, I feel that I'm doing something wrong.
I absolutely loathe working with TypeScript. The community is the most fragmented I've ever experienced, the silly amount of package managers, builders... TypeScript just doesn't fit with me.
You're describing issues with the underlying JS ecosystem. TS builds on that, and while it can paper over the language deficiencies, the libraries and frameworks are down to the larger community with its culture of constant churn.
Yeah — TypeScript is great in a vacuum, and if you’re working on an established project that’s got all the tooling configured perfectly it can be a pleasure… but if you’re starting from the ground up, it can be a god awful nightmare.
I think typescript is great but the heavy, heavy dependency on starter kits that come with a dozen build dependencies configured to within an inch of their life is a testimony to how much of TypeScript is voodoo.
Every dependency you add to a project requires new incantations and prayers and probably some sort of sacrifice.
Typescript itself is fine. But yes, if you are using 3rd party libraries and frameworks with typescript, you might wonder if it's too late to change career and become a monk.
It’s my impression GP doesn’t have a clear picture of where TypeScript ends and the rest of the tooling ecosystem begins. Which is totally understandable, especially given how pervasive TypeScript is and how it nearly totally overlaps with the rest. I think you and I have similar perspectives on the details, but you could be kinder expressing them.
I assumed repox prefers bluntness, due to their writing style. I was careful with the words and tone that I chose. Checking comment history, repox wrote that they are a Dane (which I didn't know). My experience of friends from other nearby countries is that their style of interaction can be seen as rude by many people. In particular my stereotype is that Americans often prefer a more gentle approach.
I think you are assuming I am not being respectful. However I believe that a blunt reply is definitely showing respect to them in this situation. I do need to be careful not to make comments that are personal attacks (or that could be mistaken for), which I certainly was not trying to do.
(To quote you: "you’re making the claim, you defend it. Otherwise the assumption is just, like, your opinion man." ;)
Hopefully repox can reply, although they don't often comment, so I would guess they are unlikely to check replies. Anyways, definitely off topic!
Hey, I mistake appropriateness of being blunt too. I’m autistic, so. I’m kind of impressed you dug through my recent comment history, even if the quote feels misplaced. Anyway feel free to be blunt with me, if you recognize me around.
But I’ll also be blunt when I notice a critique is probably misplaced.
To explain: I quickly scanned some of their recent comments to see if my assumptions could be wrong. When I noticed they were Danish, I then wondered if you were American, so I used hn.algolia.com to scan your comments for “American” as a keyword. You said you were, but at that point I luckily noticed the comment of yours that I quoted, which I just couldn’t resist cheekily passing back to you, because it fitted the discussion on comment quality at a meta level</smirk>.
I often write personal notes like this after the topic has dropped from the front page. If there are a lot of people still reading the comment threads, I try harder to not be a distraction to others and I try to keep on topic.
I really do appreciate your effort to keep my comment quality high - if we all do that for many comments (especially through voting) then the whole community benefits. I don’t realise when I get tone wrong. In this case I have been very slightly downvoted on both comments which is not usual for me - so your comment was an extra help.
FWIW I think “comment quality” is a weird self-policing cargo cult thing here that reflects moderation attitudes more than it reflects basic decency, and I appreciate your candor and openness to critique more than anything else in this discussion. I’m sure you’ll find if you look further through my comments that I think basic decency extends beyond the politeness expected here when they conflict. Regardless thank you for a fruitful conversation!
The developer experience must be evaluated holistically, because languages don't exist in a vacuum. The JS tooling, libraries and community absolutely impacts on how it feels like to be a Typescript developer.
The Kotlin situation isn't comparable because there is an established community that uses Kotlin in the backend, without using Android.
But perhaps you could compare with Swift: while Swift may technically run on non-Apple systems, that's not the experience of most developers. So it's totally valid to avoid Swift because you don't want to deal with Apple and Xcode.
> Please correctly blame the ecosystem that you dislike, instead of thoughtlessly using a language as a label for an ecosystem.
While I understand your point, I can't help but feel like the two are connected.
I _do_ have some beefs with the language itself, though. The export syntax concept is awful, the overly flexible type system to which I still haven't seen the point with and of course the whole thing needs to be transpiled to actually run.
Minor annoyances, sure. Easily to blame my abilities and capabilities as the reason for not understanding and enjoying TypeScript. But the ecosystem really hits the nail and by working with TypeScript on a daily basis, I'm forced to interact with it.
The developer community is so fragmented to anything else I’ve experienced. Granted, I don’t know every language and their respective communities, but the whole NodeJS/TypeScript community seems to have no common direction whether it comes to dependency managers, coding styles, transpilers, bundlers or much about any other “best practice” paradigms. And this also something that is pestering packages and the maintainers. I don’t experience this vast amount of fragmentation in PHP, Python, Kotlin or Dart. Whenever you reach out to the community, you’re rarely met with more opinions than you have fingers and toes; sure - not all agree on everything, but there’s more often than not, a sense of consensus on what a common approach to any given problem could be. While I of course could just have been very unlucky for the past two years, the community is the main (but not the only) reason I will not work with anything related to TypeScript or NodeJS ever again.
> I can't help but feel like the two are connected. I _do_ have some beefs with the language itself, though. The export syntax concept is awful, the overly flexible type system to which I still haven't seen the point with and of course the whole thing needs to be transpiled to actually run.
They are connected, but almost exclusively in the JS -> TS direction: typescript imports are javascript imports, the type system is messy because javascript is messy (whether complete compatibility with javascript was a good goal is another question...), etc.
> But the whole NodeJS/TypeScript community seems to have no common direction whether it comes to dependency managers, coding styles, transpilers, bundlers or much about any other “best practice” paradigms.
If it’s just the tooling that makes you dislike it, the tooling is just as frustrating if you write plain JS. If you don’t have specific gripes with the TypeScript syntax and type system as such, I’d suggest trying just using it without any additional tooling (typescript as a dev dependency, tsc as the only build step) in a project amenable to that. The biggest downside is slower iteration when tsc itself is slow. But you don’t actually need all of the tooling complexity if that’s what you don’t like.
With FrankenPHP, I can't imagine why I'd choose Bitnami anymore.