In older projects, senior project managers had feature sacs where feature requests grew.
When a feature request was ready, it was expelled through the PM’s extensible mouth and left to dry for a few days before being shown to the development team.
The best way to deal with people complaining about features being removed in a software update is to include a brain-cleansing module in your code: when the module is loaded into a user’s browser, any memory of the deleted feature is removed from the user' brains.
When a line of code is written, it captures some of the writer’s psychic energy.
When a line of code is deleted, this energy is discharged. This discharge will affect all people near the peripheral used for editing.
Deleting a lot of code at once can be dangerous.
Using a remote desktop or other technical isolation can reduce the impact, depending of the protocol, but the recommended method is to have a cat sit near the machine during the refactoring since they can harmlessly feed on this energy.
Using automated tools to remove some types of bugs means the ecological pressure is lower on nastier bugs because competition for food is less harsh.
These harder to fix bugs will probably grow steadily, making software development more difficult.
Before Conway’s law was voted on by the IT High Council, you could decide to create a software in the design you wanted with no relation to an organization’s structure. Unfortunately, it meant too many successful projects and not enough money for consulting companies.
It needed to be fixed.
The natural world is full of chaos. When we attempt to move reality into a computer system, the chaos it contains creates lumps that we perceive as bugs. Fixing the bugs releases the chaos.
As the total quantity of chaos is stable and more and more of the natural world is digitalized, the chaos density slowly increases.
Which means that digitalization will create software with more and more bugs, until we reach saturation
Brain snapshots and their integration into tools solved the software documentation problem:
-
When someone create a ticket, a snapshot of the author’s brain is taken and stored in the ticketing tool, any question can then be asked to them, even years after the problem is spotted, which replace the need to write specification
-
When a development is done, a snapshot of the developer’s brain is taken and stored in the version control system, even years after the code is written, which replaces the need to write code documentation.
The latest technology update provides the ability to merge brains snapshots, which enable to consolidate several requirements or technical changes in one persona. The current brain snapshotting tools only works when merging different snapshots from the same person, merging snapshots from several people and especially more than two is unsupported from now.
If you ask a developer about infinite loops, they would probably tell you they are a problem and that all loops need a way to break out.
Same if you ask them to play a game with an infinite loop mechanic.
Yet, when you put the same person on a software project and you call the infinite loop “sprint” or “iteration”, very few of them understand what is happening.
There is of course a trick: the main mechanic is hidden, and worse: most of the lore explains to them that the point is staying in the loop and even to improve the loop.
Imagine Groundhog Day's Phil Connors trying to improve the loop by working tirelessly on doing a better report of the groundhog again and again. But he quickly realizes that the report is not the point: the point is to break from the loop, and he starts to poke at the game mechanics until he finds how.
Each time you end an iteration on a project and reach the point where the retrospective starts, it means you failed again. Using the retrospective to improve how you develop is like Sisyphus using ice breakers and Post-it® to find ways to better push the boulder.
The end goal of the software project game is to exit the loop, and to dethrone god. If you fail doing so during an iteration, at least use the retrospective to find ideas to try next time.
There are audio logs, graffiti in bathroom walls and item descriptions that point to the solution, but first you must take control.
I wonder when we’ll be able to pay an AI to generate the dreams we want to have.
Which also means people will be able to hack the system to send nightmares to their enemies.
The new trends in how to organize a large code base are :
-
An infinite corridor with dim lights
-
Interconnected small rooms with subtle differences
-
Haunted forest where taking the wrong exit in a screen brings you back to the beginning area
When you write code and some part of your project becomes harder and harder to read as you explore them is a diegetic way to show that you’re reaching a boundary of the simulation.
One undermentioned thing of growing as a developer is when you’ve outgrown your skin and you need to shed it. Skin shedding rhythm depends on your field and the climate of the org you’re working for.
Don’t forget to eat the skin you just shed because there’s a lot of knowledge encrusted in it you would otherwise lose.
It’s rumored that in some highly competitive orgs, stealing the skin of a more senior person before they had the time to consume it is an accepted way to speed up your career.
Some creatures of magic origin have a “true name” that holds some specific power. Most software developers don’t have a magical origin so they don’t have a true name, but something similar exists with their first line of code (aka floc).
It’s not their literal floc, because for most developers it would be a variation of “hello world” or other first lines from popular tutorials, instead it’s the first line where the developer can fully express themselves.
Like the above-mentioned true name, knowing a person’s floc means you can control themselves if you follow the right protocols. It’s a good reason to not publish your earliest projects online: some unscrupulous recruiters are known to scout these, in case they can find a first line.
An experienced developer can lend some of its skills to a project by adding their floc to it. Each time it’s done, they lose a part of their abilities until the floc is removed, so they should be aware to not do it too much.
Of course it’s best to do it covertly to avoid any risk. When a floc is included in a project, anybody working on the source will see their skills improved. A beginner who experiences this may think it’s because of the code’s style, architecture, or choice of language, but a more seasoned one will recognize the effect.
When several flocs are added to the same project in a proper way, they can produce a kind of resonance that improves the overall effect. A developers' covenant with a high level of trust can take the shared decision to all donate a floc to a project, increasing the odds of a risky project to be successful.
The catch is that a developer can’t remove their own floc from a project to take their lost skills back: somebody else has to do it, or the project shouldn’t be used anymore for a significant duration.
Depending on the rewriting rate and the specific floc, a floc can thus remain in a project for a long time after the floc’s owner left it. It explains why some refactorings can make a project harder to work on without any visible reason: it’s because it removed one or several flocs.
No public information is currently available about what’s happening to a floc when the associated developer dies, but speculations are running wild.
Cats can hear WiFi waves, to them it sounds like a crackling fire, lulling them to sleep.
Bluetooth devices have learned to mimic a baby’s cry to some degree. By doing so, they appeal to a human’s maternal, nurturing instincts, making it far more likely that their needs will be met.