3 ms·

> I think there is something uniquely magical about software, and part of that magic might stem from this tension in how we define it. Well, yes, but I'd phras

> I think there is something uniquely magical about software, and part of that magic might stem from this tension in how we define it. Well, yes, but I'd phrase this differently. To me, there is something uniquely unprofessional about software, and part of this unprofessionalism stems from our lack of understanding. If you do get a computer science degree, congratulations! You have more knowledge than 90% of the people I've worked with in my 20-year career. But even then you only have the "book knowledge"; you still lack the real-world knowledge that comes from practicing a profession. Tradespeople are required to have both the book knowledge, and the practical knowledge (from working under a master). This solves a lot of problems by filling in the gaps that books leave out or haven't updated to yet. Software feels like magic because there's so much to know. Even for experts, knowing "how to do something right" isn't totally clear. I think the cause of the uncertainty is software engineering's lack of standardization. Not long ago, the world had no standard units for making buildings. Nails, bolts, wooden beams, sizes of walls, framing layout, roof design, etc varied widely. Making a building strong enough not to fall over, be blown over, shaken apart, or burn down in 10 minutes, required over-building it, because you didn't actually know how to figure out if it would fall over or not. But now the component parts of a building are made to a set minimum standard. Building codes lay out exactly how you can construct a building so that it's safe to use. It's still not easy to construct a building, but at least we know exactly how to do it, and we can check that it was done correctly. In this way, an expert can know exactly how to build a building the right way. Because of this, construction isn't magic. In fact, it's often derided as a job for people who aren't smart, yet you have to be fairly skilled to do any part of it well! Software engineering still lacks the certainty that physical engineering figured out long ago. Apparently software isn't important enough for people to need to quantify it yet. As is usual with humans, it takes a busload of kids getting creamed by someone speeding through an intersection for us to finally put stop signs in place. I expect after the next world war, when our society is brought to its knees by a simple computer virus, security will become standardized and required, with liability for the "engineers" who don't follow the protocol. ....none of this has to do with organizations, though. Nothing magic about organizing software engineers. Successful management strategies that work at other companies, also work in software companies. There are additional management strategies that can help the lowest level of work become more efficient (https://www.atlassian.com/agile https://www.atlassian.com/agile), but those things require the boring, old, "normal" management to be done correctly first. This has been written about to death by people who've studied it all their lives. But software people stick to their software people blogs, and software people management strategies, and never branch out to see how the wider world works. Then they wonder why it all seems like magic.

Nevermark 1y ago
> Software engineering still lacks the certainty that physical engineering figured out long ago. Apparently software isn't important enough I think it is widely viewed as important enough, and every serious attempt at a new language or many software tools involve massive efforts (when their ecosystems are considered). But one challenge is, we can't really measure a new language until its been put to use by a lot people, encouraging an ecosystem of libraries and tools, in a virtuous circle. By the time that virtuous circle confirms that yes, A B and C are great improvements, its very difficult to take the next step and add D, E, and F that worked so well in another language. It happens, but it tends to happen slowly and paid for with complexity that a new language with A, B, C, D, E and F at the start would not have had to pay. But getting a new language and ecosystem revved up is much harder than adding complexity. Until someone else with a great deal of passion and time takes another big gamble and succeeds. Meanwhile, all that code in all those languages doesn't go away. C++ complexity is where every language that never gives up, never surrenders, maintains backward compatibility, and continues folding in more good ideas, is slowly heading toward. Its like trying to improve standards while building an "organically growing mountain terrain" type city, where the city has three main ground levels, covering vast areas of land, with smaller 2nd level areas on top of each, then smaller 3rd levels on all those 2nd level regions, etc. The different innovations happening in particular towers are very difficult for other towers built with other standards to adopt. But all the towers need to keep growing. Someone says, lets start over with a new city, and it may be a much better city in many ways, but not all, and if enough people help they get a good enough first level up so more people start building there. But the same problem accrues.
- 0xbadcafebee 1y ago
  > we can't really measure a new language until its been put to use by a lot people, encouraging an ecosystem of libraries and tools Programming languages are just a raw material, like wood, or an alloy, or chemical. They have to be applied in a specific way to have a specific result. A "language" on its own doesn't matter. I could write you the same application in 5 different programming languages, just like I could build you the same building with 5 different raw materials. Once you decide to use wood, you have to figure out how you're going to build with wood. Again, in the olden days, this was a bespoke process, like it is today with programming. Are you going to timber-frame? Stick-frame? How tall will it be? Will you use wood joinery or metal fasteners? How will you reinforce it? How heavy will it be? Will you need special equipment or teams of people to move materials? Then you have to get your materials prepared; your beams cut to size, your metal fasteners of the right length, your mortises and tenons cut. Then finally you can assemble it all. Compare that to programming. Again, you have to figure out how you're going to use the language. What modules you will use, what libraries, what software architecture, what APIs, what protocols, etc. Then you collect your materials and fit it all together. The difference is this: with modern buildings, most of how you put the pieces together is already specified. An architect still needs to draw the plans up, but building it is pre-determined - not by the builders, but by the building code. You know for a wall plate you're going to need 10d nails. You know your floor joists must be 12, 16, or 24 inches on center, and you know how thick your subfloor needs to be for each. You do not deviate. For a given material, in a given place, for a given application, somebody has already determined how you will build it. Another big problem with software is the lack of specialization. Most often I see teams of random software developers doing all kinds of things they're unqualified for. People who're clueless about system architecture, defining the architecture of the software. People building the applications without knowing what they will end up looking like. This is insane! Imagine if you just sent some random DIYers to build a house, with no plans, with no building code. The result would be an absolute mess. Of course they would need to stay employed for years, constantly fixing and bolting-on things to cover up their mess. The "software world" has been an asylum run by the inmates for far too long. We don't need to constantly change languages. They're all about the same anyway! Rewrite an application from one language to another, and it just has a different set of bugs. The only reason it's done this way is we allow software developers unnecessary free reign, because we have no other choice, because it's just a guild of craftspeople building things however they want. Standardization should force a set of materials and a way of building, regardless of the personal whims of the programmers. The result may not be "fun" (which seems to be the primary priority of all programmers, over anything else), but it will result in lower cost, faster building, and more reliable results.

Nevermark 1y ago

> Software engineering still lacks the certainty that physical engineering figured out long ago. Apparently software isn't important enough I think it is widely viewed as important enough, and every serious attempt at a new language or many software tools involve massive efforts (when their ecosystems are considered). But one challenge is, we can't really measure a new language until its been put to use by a lot people, encouraging an ecosystem of libraries and tools, in a virtuous circle. By the time that virtuous circle confirms that yes, A B and C are great improvements, its very difficult to take the next step and add D, E, and F that worked so well in another language. It happens, but it tends to happen slowly and paid for with complexity that a new language with A, B, C, D, E and F at the start would not have had to pay. But getting a new language and ecosystem revved up is much harder than adding complexity. Until someone else with a great deal of passion and time takes another big gamble and succeeds. Meanwhile, all that code in all those languages doesn't go away. C++ complexity is where every language that never gives up, never surrenders, maintains backward compatibility, and continues folding in more good ideas, is slowly heading toward. Its like trying to improve standards while building an "organically growing mountain terrain" type city, where the city has three main ground levels, covering vast areas of land, with smaller 2nd level areas on top of each, then smaller 3rd levels on all those 2nd level regions, etc. The different innovations happening in particular towers are very difficult for other towers built with other standards to adopt. But all the towers need to keep growing. Someone says, lets start over with a new city, and it may be a much better city in many ways, but not all, and if enough people help they get a good enough first level up so more people start building there. But the same problem accrues.

0xbadcafebee 1y ago
> we can't really measure a new language until its been put to use by a lot people, encouraging an ecosystem of libraries and tools Programming languages are just a raw material, like wood, or an alloy, or chemical. They have to be applied in a specific way to have a specific result. A "language" on its own doesn't matter. I could write you the same application in 5 different programming languages, just like I could build you the same building with 5 different raw materials. Once you decide to use wood, you have to figure out how you're going to build with wood. Again, in the olden days, this was a bespoke process, like it is today with programming. Are you going to timber-frame? Stick-frame? How tall will it be? Will you use wood joinery or metal fasteners? How will you reinforce it? How heavy will it be? Will you need special equipment or teams of people to move materials? Then you have to get your materials prepared; your beams cut to size, your metal fasteners of the right length, your mortises and tenons cut. Then finally you can assemble it all. Compare that to programming. Again, you have to figure out how you're going to use the language. What modules you will use, what libraries, what software architecture, what APIs, what protocols, etc. Then you collect your materials and fit it all together. The difference is this: with modern buildings, most of how you put the pieces together is already specified. An architect still needs to draw the plans up, but building it is pre-determined - not by the builders, but by the building code. You know for a wall plate you're going to need 10d nails. You know your floor joists must be 12, 16, or 24 inches on center, and you know how thick your subfloor needs to be for each. You do not deviate. For a given material, in a given place, for a given application, somebody has already determined how you will build it. Another big problem with software is the lack of specialization. Most often I see teams of random software developers doing all kinds of things they're unqualified for. People who're clueless about system architecture, defining the architecture of the software. People building the applications without knowing what they will end up looking like. This is insane! Imagine if you just sent some random DIYers to build a house, with no plans, with no building code. The result would be an absolute mess. Of course they would need to stay employed for years, constantly fixing and bolting-on things to cover up their mess. The "software world" has been an asylum run by the inmates for far too long. We don't need to constantly change languages. They're all about the same anyway! Rewrite an application from one language to another, and it just has a different set of bugs. The only reason it's done this way is we allow software developers unnecessary free reign, because we have no other choice, because it's just a guild of craftspeople building things however they want. Standardization should force a set of materials and a way of building, regardless of the personal whims of the programmers. The result may not be "fun" (which seems to be the primary priority of all programmers, over anything else), but it will result in lower cost, faster building, and more reliable results.