21–30 of 221 posts
Just this morning I've spent an hour trying to get a well-known Http library to work in my project, cos the developers keep completely refactoring all the classes and methods. Stop it!!
The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready
The first thing that came to mind when I read the opening paragraphs regarding churn is developing mobile applications. I find myself losing a day or two just to get my apps to compile if I ever go a month or two without spending any time on them. It's brutal how quickly things can break and dependencies need to be updated. Is it possible to do modern mobile dev without churn (coming from a situation where my clients…
The piece reads like a Unix pastor's pulpit preaching "Great nutritious technologies to use: Make, Emacs, Lisp, CLI" "Bad unwholesome technologies to use: JavaScript, Ruby, IDEs, Graphical User Interfaces" I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years. And is it candy or an olive that I like VSCode and not Emacs (not that I've ever tried Emacs, I just don't…
Unfortunately doing this tends to lead to being unemployable because too many people associate being immersed in churn as "productivity." This spreads philosophically and suddenly people doing the hiring want these kinds of people who can "solve" these kinds of "problems." At the same time, finding something that works and sticking with it perpetually sounds wonderful - perfect, even. But breaking things and doing ha…
Totally agree. Sticking to things that work can hurt your job prospects seriously. You are quickly an “outdated dinosaur”.
Like all industries we can't just stay still. Curiosity and creativity are important. The "olives" are a fruit of some sort of older technology that has matured. Maybe this technology was the "shiny new some some time back then" Some people try to fix the the shortcommings from yesterday's technology with their own ideas and view of things and nobody can prevents this. This is just basic, human creativity at work. Ma…
The reality is that there is very little actual innovation happening in programming. Most of the ideas in use today have been discovered decades ago. The big reason for churn is that people don't bother learning about what's been done before, and keep reinventing the wheel. You don't see in other disciplines such as physics or chemistry where people spend years learning about existing research before actually startin…
Earlier quoted context omitted.
The reality is that there is very little actual innovation happening in programming. Most of the ideas in use today have been discovered decades ago. The big reason for churn is that people don't bother learning about what's been done before, and keep reinventing the wheel. You don't see in other disciplines such as physics or chemistry where people spend years learning about existing research before actually startin…
> Most of the ideas in use today have been discovered decades ago. The big reason for churn is that people don't bother learning about what's been done before, and keep reinventing the wheel. But on the other side of the coin, do you really want to be locked into a decades-old solution to a "solved problem" forever? Or are there still improvements that can be made to reduce friction and human error? "Machine/human re…
People don't discuss solutions in a vacuum. Ideally they'd think about what the potential fallbacks of using XML alternatives are before jumping into a new tech. Which they will, unless they're really really new
The piece reads like a Unix pastor's pulpit preaching "Great nutritious technologies to use: Make, Emacs, Lisp, CLI" "Bad unwholesome technologies to use: JavaScript, Ruby, IDEs, Graphical User Interfaces" I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years. And is it candy or an olive that I like VSCode and not Emacs (not that I've ever tried Emacs, I just don't…
I’d be interested in hearing about the problems Make has caused you— Whenever I’ve needed to write or edit a makefile, it’s been a pain looking up the relevant details in the manual, but nothing as severe as what you seem to be implying. Have I just been lucky, working with less complicated projects, or something else?
Earlier quoted context omitted.
The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready
Until your CI pipeline causes churn because something doesn’t work anymore....
The piece reads like a Unix pastor's pulpit preaching "Great nutritious technologies to use: Make, Emacs, Lisp, CLI" "Bad unwholesome technologies to use: JavaScript, Ruby, IDEs, Graphical User Interfaces" I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years. And is it candy or an olive that I like VSCode and not Emacs (not that I've ever tried Emacs, I just don't…
>I personally hate Make, it's burned me too many times. I’d be interested in hearing about the problems Make has caused you— Whenever I’ve needed to write or edit a makefile, it’s been a pain looking up the relevant details in the manual, but nothing as severe as what you seem to be implying. Have I just been lucky, working with less complicated projects, or something else?
AS_SRC = main.S util.s
OBJ = $(AS_SRC: .S=.o)
[...]
clean:
rm -f $(OBJ)Earlier quoted context omitted.
> Most of the ideas in use today have been discovered decades ago. The big reason for churn is that people don't bother learning about what's been done before, and keep reinventing the wheel. But on the other side of the coin, do you really want to be locked into a decades-old solution to a "solved problem" forever? Or are there still improvements that can be made to reduce friction and human error? "Machine/human re…
Your contrived example falls flat because JSON is flat out better for most use-cases and anyone having a discussion about it will probably fit into those use-cases. People don't discuss solutions in a vacuum. Ideally they'd think about what the potential fallbacks of using XML alternatives are before jumping into a new tech. Which they will, unless they're really really new
Easy to say with hindsight now that it is massively popular and has a huge ecosystem of parsers for every conceivable language. At the time it was invented though, it was yet another data exchange format and I'm sure there were a lot of grey beards pooh-poohing it.