mablopoule

That "Features included" selection is golden, the "Every file is called index to turn your code editor into a fun maze for the entire family to enjoy." item actually made me laugh out loud.

This is the big one for me. In any big enough or unfamiliar frontend project, my go-to way to explore the codebase is to launch the front-end, and use the inspector to check the elements, and then search-back in the codebase the relevant classes to see what page/component display that, and how does it fetches the data.

If there is only an alphabet soup, I no longer have a simple set of classes I can grep the codebase with to quickly find the relevant components.

In general I would agree, but this project managed to avoid the main gotcha of AngularJS (the performance issues & the possibly messy data-flow), so it was holding out suprisingly strong, even pas the maintenance date of AngularJS.

The lack of pre-processing steps, combined with good CSS and a well-formed DOM made it one of the rare project in my work history that didn't create any rewrite-envy.

AngularJS or not, the main point is that avoiding piling layers of tooling that might force you to an upgrade for purely technical reasons was a nice experience.

This.

In one of my previous job, the main product was 100% pure Javascript (using AngularJS), with a few (vendored) third-party scripts, and it was very nice to work on it.

No package.json, no dependency issues, and above else, the workload we had was always related to business, and almost never related to external technical constraint such as a depreciated dependency.

Then you might really like the book I've first learn the world from, "Intelligence Emerging"[1] by Keith L. Downing. It's a very dense book about self-organizing processes, and emergence in general, and it drives me a bit crazy because it's one of my favorite book, but I never heard anyone mention it.

[1] https://mitpress.mit.edu/9780262536844/intelligence-emerging...

> Surely we can agree that distributing shared libraries via a package manager is a good practice, no?

At one point, long ago, you could just download a file, reference it in your index.html, and use it without ever having to worry about updating this package. It had its flaws, but it also had many advantages compared to having an external dependency that might conflict with your version of Typescript, or being highjacked by bad actors.

I don't diss the concept of package managers at all, but there are lots of case where vendoring an external package is preferable than adding it as a dependency.

Agree, and the most maddening thing is that the platform is honestly better than ever. Doing your layout in CSS is so much easier now than it was 10 years ago, thanks to CSS variable, containers queries, and widely supported flexbox & grid.

It's the NPM ecosystem above that's being stupid, and believe that adding more tools and more processing is a good thing.

While this case makes for a pretty fun story, there's other case of 'fake' event posted on social media with more sinister reasons behind it, like when russian troll farm used social media to try to organize protest that were bound to devolve into riots [1].

[1] https://edition.cnn.com/2018/06/26/us/russian-trolls-exploit...

This article is a joke, but a joke cruelly missed by it's own author.

Point in case: holding 'enterprise programming' as a paragon of software craftsmanship.

A realization I've had, seeing true 'enterprise programming' at work, is that most of the time processes acts like pass-band filters for quality: on the lower side some sort of garbage is avoided by adherence to processes, and on the upper side true software excellence is made impossible, or at least way harder than it ought to be.

A few examples:

- A simple CRUD app got a less-than-ideal data-flow, with routing and data-passing between pages were treated as an afterthought. The reason? The (Scrum) process-heavy organization understood work solely as defined through JIRA tickets, and they naturally created 1 JIRA ticket per page and per component, and of course heavily parallelized the work between many coders. As a result, each page matched the specs, but the overall data architecture fell through the cracks.

- We had one member of a previous team who alternated between 'okay' to '-1x coder'. His main issue is that he didn't really thought about the impact of his code, he just kinda appeased the gods of linting until they were quiets. The issue is that it was often just breaking stuff, or straight up putting deceitful typing in a way that would have spread in the applications. Automatic checks were all in the green, but everything was subtly wrong.

- Over-engineered types in Typescript. Some (usually junior) ambitious programmers see the power of types, and dream of creating types so perfect that the whole program will be created just by pressing 'tab' at the end. It sometimes work, but it also often create ungodly monstrosity where a KISS approach would have been less painful. We've all went through this stage, but some people just saw "The sorcerer's apprentice" section of the 1940 Disney movie 'Fantasia' and then stopped midway, too busy automating everything.

- Over-reliance on outside library, and a organizational incapability of creating anything remotely custom. Yes you should avoid reinventing the wheels, but if your job is also to make wheels, and none of the ready-made wheels fits the situation, then you better be making wheels sometimes.

- Over-reliance on fads and marketing. Process-heavy environments penalize individual initiatives. As a result, the "way everybody do something" becomes the only possible way, and this is very susceptible to fads and content marketing. And your soul dies a little when you cannot stop the "Sure, Redux seems very heavy for the needs of this project, but Redux is very powerful! That's why it's in every project!".

In general, processes and systems attracts 'system people'. They can be useful, but too much will just create a dogmatic, un-pragmatic work environment where business consideration are swept under the room.

As far as I understand it, the permission is allowed/denied by the end user.

It's the App Store reviewer that considered the permission prompt to be unclear, and thus rejected the app from the platform.

While I believe that the app store reviewer was being dense on purpose, I agree that this is a better prompt.

There's strict, and there's kafkaian. It's not as if the reason why a camera app would require the camera is pretty obscure, especially if neither the app nor the permission text changed that much between reviews.

But it's a camera app. Of course it needs the camera.

It's not overreaching app permission, it's been rejected because the text "The camera will be used to take photographs" wasn't considered a good enough explanation for the permission.

Same. I felt that the article generally got his point across, and kept a good balance between "straight to the point" and flavor text.

And while I don't want profanity present in all the articles I want to read, I find this kind of tone way more appealing than the dry, PR-approved blog posts where the only kind of levity found are "2010 internet humor" cat pictures, and "Corporate Memphis" illustrations.

Thank you for putting this so eloquently.

While not a wrong response in itself, the onboarding cost argument tend to be a bit exaggerated most of the time, because unless you plan on hiring people for a week at most, you're usually better served by avoiding sources of complexity.

The argument is to avoid going all-in on Redux by default if you're doing a React project, not telling you to hand-roll your own Redux.

If you're doing a mostly-static site with a few bells and whistles, then HTML and plain old JS will probably do.

> “The merchants of complexity will try to convince you that you can’t do anything yourself these days,” wrote David Heinemeier Hansson (DHH), the creator of Ruby on Rails. “You can’t do auth, you can’t do scale, you can’t run a database, you can’t connect a computer to the internet. You’re a helpless peon who should just buy their wares. No. Reject.”

Such a beautiful quote, and really describe well my experience. For the past few months I've been in a team that keeps trying to pull dependencies and library of components for the simplest of things, and trying to argue my point kinda in vain, to the point that I'm starting to get cranky and rant-y about the subject[1].

Need a header on top of our application? Let's use a Angular Material component, why would you code it yourself? Need to display stuff in a grid, oh we better should center our project around Ionic so we can use ion-grid.

More than 'merchant of complexity', I thing that a huge culprit is the need for content marketing, and so any new thing in a framework become the theme of multiple conference, and the obligatory Medium posts explaining the new stuff (in itself, not necessarily a bad thing), but which often tend to snowball into "Method X is obsolete, why you should all port your code using newfangled method Y".

And now, I have a colleague working in an Angular app that keeps on rewriting stuff and wrap everything with signals. Signals can be good sometime, I'm not against angular signals in itself, but he's just taking dead-simple code and making it more complicated because apparently now everything Angular should be about signal. At least I'm away from the part of the React ecosystem that keeps trying to re-invent the cascading part of CSS but with Typescript in the mix. shudders.

[1] https://news.ycombinator.com/item?id=40476275

JSDoc does not scale, but some projects are just better when they aren't scaled.

JSDoc is indeed fine on toy project, or in fact any project (even prod-ready ones) that doesn't warrant the trouble of adding NPM packages and transpilation steps.

Although they are rare, those type of small, feature-complete codebases do exists.

Respecting other professions.

By that, I mean getting over any mentality that accountant are simply bean counter, sales peoples are just talentless people riding on charisma, etc...

All those stupid tribal mentality will hinder the programmer's ability to think about the project holistically, and propose the right technical tradeoff.

I had the luck of working in a company that not only had very good dev team and CTO, but also a very smart CEO and non-tech teams. As a result the sales & business decision were done with technical possibilities (and limitations) in mind, while the technical choices were done with business problematic in mind. That was by far the best codebase I've seen, because there was a lot of smart, 'out-of-the-box thinking' kind of technical stuff in it where it mattered, and also lot of technical simplicity or even 'cowboy coding' when it also mattered.

I believe that there is a continuum where the most limiting thing you can do for your tech skills is to identify yourself with your technical stack. Don't be a 'Javascript programmer', or worse, a 'React programmer'. I fact try to not even think of yourself as a 'programmer', because that will push you into thinking that 'problem-solving' implies a programming exercise, of course only with your usual tools.

That's often the case, but the most elegant solution to a problem is to not even have a problem in the first place, and that requires programmers to think about the project and the objectives in a level possible only when thinking (or listening) in term of added value in the business, sales problematic, financing issues, legal issues, and so on. By working with those 'non-technical' teams, you can acquire by osmosis their way of thinking, and be able to argue technical issues way more efficiently, while also being able to cut corner when it makes sense.

Reading everything I've written above, you might be tempted to think that I see programming only as a mean to an end, and don't care about code quality. I do like "programming for programming sake", like reading SCIP, playing with data structures, looking up esolangs, or more pragmatically thinking deeply about the dataflow of an application and what are the most appropriate data structures.

What I don't like however, is when programming become self-masturbating in a way that are neither enlightening, nor impactful. I've once joined a company that was obsessive about linting, improving their CI/CD processes, and following 'best practices' in the most jarring way. Some devs even wanted to switch libraries for a newer one based on the number of Github stars. The business side of things was basically burning down due (in part) to a lack of appropriate features in the product, but it's wasn't really a problem as long as Typescript was configured to be as strict as possible, and linters too, that will surely means something about quality I guess. Somehow, the company folded 6 months after.

Honestly, you're either telling too much or too little.

Could tell what are the precise language / corporation / project, if you're comfortable with that of course?

Honestly, I'm a bit more regulation-friendly than you, I remember the whole 2000-2010 decade where you had one charger per phone, in a house with 4 people, some with work phone, all incompatible. The switch to one, maybe two kinds of charger was a clear improvement.

It's not false, but having "big tech company" isn't the only metric of success of a society.

Stuff like quality of life, workers rights, shared values are a bit more important, and that requires the ability to basically tell a company "Who the hell do you think you are?".

Well, you and Netrisca were together, while those thousands of enemies, they were alone.

> Spreading subtle ads through memes is probably still an under-explored area of marketing and it bypasses modern ad-blocking techniques.

In this vein, I encourage you to search about the 2016 russian interference, and the tactics of the IRA (Internet Research Agency, a russian troll farm). It's been eye-opening for me how was heavily in Twitter/Tumblr in those years about the quantity (and quality) of manipulated memes and astroturfed viral content in social networks.

> and the code debt is often worth it.

This is something that I like about the metaphor of 'code debt', and which tends to go over peoples head: debt can be a perfectly fine instrument, and just like a real debt, it can be a good thing when leveraged wisely. The issue is more when debt is treated as 'free money', and is used carelessly.

Assuming you're all of those, then one day you might meet someone younger than you who does all of these a bit better than you, and also is good at piano. And he or she will be nice and graceful about it, too, so you won't even be able to hate on them.

It's not a personal attack against you, it can happen to (almost) everyone :D.

My "favorite" example about this is the 2016 Pulse nightclub shooting, because it's so easy to jump to conclusions (especially when it seem to fit the ambiant discourse) and be completely wrong about the whole situation.

It's a gay nightclub in Orlando, Florida that was in 2016 the theater of a mass shooting (49 killed + 58 injured) during a "Latin night".

I still remember hearing about it on social media at the time, that it was another attack on LGBT, and especially an attack on minorities... turns out that the perpetrator didn't even knew it was a gay nightclub, he was an ISIS sympathizer whose ire was directed towards the US at large.

Of course, it doesn't diminish the tragedy of the event, or the fact that the LGBT community of Orlando was the most heavily hit, but it does illustrate that we should be mindful on when we are jumping to conclusions and assuming stuff without all the elements.

You just need to meet someone like that, they are rare but they exists. It doesn't means that they are good at everything, just that they are better than you in every way.

I had a colleague like that. She was super nice, super smart, very good looking, was well-balanced emotionally, and dated a professional athlete. The kind of person who has a very good career, and then train for the marathon on the weekend. Even her name sounded cool.

I know it sounds like jealousy, it isn't, I'm honestly happy for her, but it's just a reminder that sometime people can be more advanced than you, and that you shouldn't place your self-worth only by measuring yourself with others, cause people like John Urschel[1] do exists.

[1] An up-and-coming american football player who abandoned his career at the NFL to focus on his PhD in Mathematics at MIT.

I don't remember where I saw this quote, but... "It's okay to half-ass something, when all you need is half an ass".

EDIT: Totally agree about the 'important mindest for startup', I had a similar eye-opening experience, working in a startup with 'cowboy' code that was actually quite good, but I had to unlearn a bit of stuff I read as a junior/mid-level developper.

It was code that was well-architected, had well-concieved data structure, and had business value, but every "professional" coder would deem bad-quality, since it had no unit test, did some stuff unconventionally, and probably would have many linter warning.

I do agree with the grandparent, I was a bit surprised too in the last paragraphs that the article's solution to frontend overengineering is to unionize.

Though true, the articles doesn't go into 'capitalism = bad'.