soj.ooO
BETA
The social discussion platform
Home
Pochas
Channels
Videos
Log in
Sign up
Sign up
Home
Pochas
Channels
Videos
Log in
Sign up
Parent Post: How to "exit" software development
·
In Reply To
gaby
·
10/1/2026, 6:28:42 PM
·
permalink
It's great to hear it makes no sense. Let me try clarify... In any job you have your basic tasks. As you do them many times you develop all kinds of small insights, use a different or extra tool, different resources or materials, change the order of the tasks. You develop a feel for things. Besides the basic tasks there are irregularities or exceptions that happen infrequent or rarely. If you've seen those before they also get easier to deal with. Some of the tasks require documenting them, some require looking things up. You can make an app that for example just dumps all open tasks into the viewport. One can certainly scroll to the right task click on it, fill out the start date and time, your full name and employee number, the number of other employees on it, more names and numbers. etc If you've done the job 1000 times you know which task to start with. As an employee in a big company you can ask for that task to be put at the top of the list. You get a discussion about how necessary it is to have it at the top. It probably wont happen. You've wasted everyones time? If it is your own shop, after opening the task, you could fill out the date and time automatically, as you are using the app it is safe to assume you are the one doing the task and we know your employee number too, that leaves the info about the other employees but you should have some work schedule that already has that information. But wait! We have geolocation too! The app can know when you arrive and send a notification asking you to press start. In a larger company this would require 1000 hours of discussion where everyone questions your sanity for proposing all those expensive little things we don't really need. The conclusion might be that they don't want to spend time keeping track of individual tasks. In contrast, if done well it takes no time at all and you can chose to track smaller tasks. The big company might have scheduling software that makes it really hard to import the number of people working on that location on that day. The software might not know the location at all. If you are going to write everything from scratch you can structure the data so that it wont be a complicated thing to implement. Examples are bad as they are easily confused for the subject but say you got a job washing cars. The app can tell you which materials to put in the car, have you count how many bottles or brushes are left. It can show you a map where to drive to. Describe what to do on location. (Say, ask for water) Complete the unpacking task. Instruct you what tool to use and how to assemble it with pictures and/or videos. Warn what absolutely not to do. Then when done you pack everything back in the car, hit "depart" and the itemized invoice is send. A long story short, the MBA will do everything in excell and do lots of busy work. The programmer can make it so that when the software is finished all work that remains is washing cars. Your head can be filled entirely washing cars. You don't even have to train anyone. All time is accounted for. Then when you've perfected the software for your proverbial breakfast restaurant you take it to other restaurants and show it to them, live in action. Not some demo. The real thing.
Save
Cancel
7
bumps
Share
S
saarnok
·
10/1/2026, 9:19:24 PM
·
permalink
I'll attempt to summarize what I imagine is an understanding. Organizations have organization priorities. Not production priorities. Individuals (should) have production priorities. Not organizational priorities. Individuals solely are responsible to produce. Organizations exist solely to organize individuals. The protocols of organization are accumulated, not engineered and trend toward entropy, with protocols that do not get updated or deleted, but added to as standard. Eventually the organizational protocols will overwhelm the productive protocols until the organization is forced to hire contractors outside the organizational structure to aquire productivity. My mistake was in trying to identify with a coding problem where none existed. Notes: Self motivated individuals aquire skills like a velcro ball under a bed aquires fuzz. It's just what happens. Non or un-motivated individuals aquire familiarity with protocols. Which enables them to survive within a non-productive organizational structure. Documentation in the real sense is vanishingly rare, and reconstructing a chain of "why" is largely forensic in nature and frequently more productive to start over from scratch. As an independant coder you can satisfy sufficient protocols to gain acceptance while not being mired in the mud of entropied protocols. Am I even close?
Save
Cancel
5
bumps
Share
gaby
·
10/9/2026, 4:56:58 AM
·
permalink
Thats a wonderful perspective. The coding problem is the solution. Because it takes effort to write the bureaucracy (code) into software (code) you are highly motivated to get rid of the dead code and you can add lots of easy new code that doesn't require people monitoring other people and people monitoring them where you constantly have to wonder if it is worth the money (it usually isn't) Someone who doesn't write software doesn't know which part is easy or hard.
Save
Cancel
3
bumps
Share
S
saarnok
·
10/9/2026, 10:27:10 PM
·
permalink
I'll just have to admit I don't have the experience to really understand what you're saying. I think perhaps it's a tiny bit like something I can understand, but you'd have to know what I would understand in order to make a better analogy. Unfortunately I can only grope in the dark to apprehend your meaning, where you could only tune your analogy if you had a better sense of my experiences. But, truly, thanks for the effort.
Save
Cancel
1
bump
Share
Signature
Loading…
Verify locally
Close
