41–50 of 133 posts
Not really. It's more that the balance between breadth and depth has shifted. Applications are so much more complex and do so much more than they did 20 years ago. You definitely need to build a web version, and probably at least two mobile platforms too. Depending on what it is, maybe one or more desktop apps too.
In fact as a 1-person team it's usually necessary to interface much more often with other non-technical people. In larger (scrum) teams that is usually centralized through a PO or PM. Which is in the long-run usually a good thing, pressure can be extreme for 1-person teams since people call the programmer directly. I used to work at places where sometimes for a time frame of 1 hour a day someone tries to make me listen to his or her ideas. Such a waste of time.
This is just wrong. Imaginary computing (based on language models) and blockchain or other source of truth is the future. As hermit programmers we can rely on AI to make a prediction as to when a task will be done, generate documentation for us, generate tests https://mullikine.github.io/posts/imaginary-reflection/ , generate, etc. Any deployment system that doesn't use language models will be fragile as the time to…
The text seems to imply that people on the "technical track" (only programming) are doing so because of some flaw in their personality. That is absolutely not the case! This is not a good way to launch "hermit programmer" as a new term. The term is not defined and mentioned only three times in the entire text (once in the title). I suppose most readers have different assumptions on its meaning. I know a few "hermits"…
There's a part of the article at the bottom that defines a Hermit programmer more precisely: * they don’t plan how they're going to finish a task * they don’t document * they don’t test * they don’t refactor * they don’t know anything about production infrastructure * they don’t have good communication skills * they don’t try to diversify their skills I'd agree with the article that this kind of programmer is "dead".…
You sub-tier hermit blub code monkey piece of shit how could you forget to document and test well and refactor and stay on top of a 100 tech trends while churning out tickets all day, firefighting production issues, mentoring other programmers and working from home during a pandemic while friends and family around you are getting sick or dying? All of these things are doable if we had 5x more time and training and sane work cultures but we don't.
Fuck off, blame management.
> no-code movement will continue its expansion
One of the many examples of false opposites.
A good programmer / software engineer / whatever you name it, is characterized by his ability to move smoothly between very different layers of abstraction vertically as well as the ability to adopt different points of view, technical caused ones and others. This requires different levels of mastery of all of these things. Not always at the same time, but ultimately no one can be avoided.
Regarding the example from above: Dealing with a real programming language becomes unavoidable with certainty at some point. And this isn't simply "glue code", a pretty derogatory term often used by people who just can't program. It is part of real quality.
To me, this is simply a rant against technical qualification - more bluntly, an excuse of the own inproficiency. Something whose significant increase as a trait of software development in this age is in my opinion undeniable. And this is a problem. > no-code movement will continue its expansion One of the many examples of false opposites. A good programmer / software engineer / whatever you name it, is characterized…
One of the many examples of false opposites.
Absolutely. As a developer who works a lot in a no-code environment, the way I approach a problem is no different there than if I was developing the same solution by typing text in an editor. I see every day that people who are "good" programmers produce solutions in those environments way beyond what non-programmers produce.
In summary, hermit programmers who only write code for themselves are dead because: As they don’t plan, you never know when (or if) they are going to finish a task. As they don’t document, their code is not reusable because nobody knows how it works. As they don’t test, chances are the code they write is full of bugs. As they don’t refactor, the software cannot evolve. As they don’t handle infrastructure, their code…
He might even get hired because managers love this kind of incoherent drivel. He is still wrong though.