If architects had to work like programmers (1995)
gksoft.com
gksoft.com
You will be left to execute these tasks as you see fit, but you must report progress on them daily in a one-hour meeting along with every other architect working on entirely unrelated work. You may be asked to repeat this same oral update in other meetings. These meetings may be time consuming, but you will still be expected to meet your time estimates.
During this project to design my house, there may be periods of time when I may require you to assist with architectural emergencies, such as stabilizing the Leaning Tower of Pisa. These emergencies supersede your work and may come at any hour of the day or night, but should not impact your time estimates.
If you are still around by this time. Your equity is worthless.
Generally, the optimal strategy for a construction company/contractor is to go in with a low fixed price bid and screw them on the extras that your specialists have identified will be necessary, but the general contractor/engineers have missed.
Source: I used to price construction jobs back in the day, and heard a lot of horror/joy stories. I think my college education was partially funded by these kinds of mess-ups, as my dad worked in construction.
I.e. you know what is broken and roughly how to fix it and in everyone's view it absolutely is your responsibility to "git'erdone", but you can't since you either don't have access or resources to do what needs doing and you won't get the access or the resources due to office politics or some other equally unfixable issue.
That's a fun little stress-biscuit to eat.
For example you see are responsible for fixing problem X, so you go to do it, and are told that X isn't on the planning board this month (because problem X hadn't occurred yet when planning happened at the start of the month) therefore you aren't allowed to work on it. But in other meetings, it's your fault it's not fixed, X is your job after all.
Ah! The good old recipe for burnout.
It is pain to work in such an environment.
Funny thing, that's basically the job description of a Product Manager, although HN loves to roast them, some of the hilarity comes from the fact you're accountable for outcomes and responsible for a process to get to those outcomes, but have no budget, have no reports, and you're trying to convince completely different management structures in completely different parts of the company that the thing you're working on is the thing they should prioritize or it all falls apart. Getting any significant new feature or new product to launch in any large company is basically a miracle, even if it arrives to launch hollowed out on the inside. This is mostly not a consequence of how well you do your job, it's a consequence of how dysfunctional the organization is, and I'll let you in on a secret.. /all/ large companies are deeply dysfunctional.
They are all from Blue Pants, so won't work the same time shifts as you
To them, maximizing their ability to make choices about the way work will be done means they have more ability to take the good decisions that will lead the project to a successful end.
People are spending too much time sharpening their pencils, besides a good pencil sharpener is expensive. The solution is to get a sharpener person to move the sharpener about to save everyone time.
However they are expensive to employ so we are going to outsource it because sharpening pencils are not our core business.
It always starts as cheaping out on the free soda.
Unless, as was also mentioned, someone is a project/product manager without actually understanding the business.
It might even be that there's seemingly a lot of long term goals/objectives/focus. If it's mostly strategic level plans/talks/etc, while day to day things are still planned, executed and evaluated on half-year and even just quarterly period - it seemingly ends same as not having longer term plans.
Putting salespeople in between engineers and clients, and giving them perverse incentives to say "yes" to everything the client asks, and no incentive at all to try to understand what it takes to actually get any of that stuff accomplished. It produces clients that live in fantasyland.
Someone spends hours torturing numbers in a spreadsheet until they give up and yield the desired answer. Pivot tables are created and used to make a slide deck using Microsoft Power Point. A decision is made, another round of golf played, and someone checks on the value of their non-salary compensation.
That the spreadsheet does not reflect your experienced reality is of little consequence because at that level, the spreadsheet is the reality. If your number doesn't reflect what's in Excel, you can be easily replaced with another number.
This nails an entire culture, from healthcare, to education, to policing...
But we cannot blame software itself, right? Something went deeply, horribly wrong in our own societal script. Something way beyond Max Weber or Franz Kafka's takes on bureaucracy. SOmething that made us bow down before computers as new gods.
I'm becoming a techo-athiest.
Complexity is neither an immanent feature nor inevitability. Behind unruly complexity is our failure to manage it. And indeed, a love of complexity, a fetish for it that seduces us into ever more.
To defeat complexity we have to embrace, and engage with it. We have to see what parts of technology that got us to where we are, must now be justifiably rejected.
All I see right now, especially with regards to "AI" and the new wave of techno-populism, is a retreat from complexity and more embrace of "magic".
He worked his way up middling-high in the management structure. High school diploma only.
The company got bought at some point. He says nearly all the management up to the C-suite had done actual work at the company, at some point. They promoted from within.
After the acquisition, a bunch of MBAs who’d never done actual railroad work took over. Says everything became endless, pointless meetings, a lot involving travel. Impossible to get any actual work done. The old-timers had to keep stopping them from doing dumb shit that couldn’t work.
The old timers got “encouraged” to take early retirement. And that was the end of that.
The take-over by professional managers and finance bros, rather than having professional (at the thing you actually do) managers running things, is behind it. The easy quips about MBAs ruining everything are more or less correct.
Yesterday there was this post [0] on Ivy League's wanting to separate ideology from teaching. As if that were possible.
We can read plenty regarding the decline of academia under leftist ideology. The long march of postmodernism is supposed to have corroded everything, decolonising curricula, celebrating diversity etc, etc.
Sure. That may well be true.
But equally true, through ferociously ignored is the parallel march of the ideological right in universities.
Just as there are some liberal arts degrees that teach Marxist feminism, Foucault and Derrida we have MBA's, which are equally ideological. They're steeped in the values of the Thatcher-Reagan era and right-wing economic theories. Their totems - Hayek, Strauss, Schmitt, Mises, Friedman are less well known than those on the left.
Nonetheless these often discredited ideologies are presented with the rigour of Maxwell's equations.
Off they confidently stride into the world, to run amok doing harm every bit as egregious as their left-leaning counterparts.
I've taught some of these kids in a business school, and honestly by year 3 they are utterly lost - all the hallmarks of cult-like brainwashing are fully in effect. Where the sceptics win over the strident zealots, is at least with the lefties there remains chink of openness to new ideas. An MBA is an MBA for life.
"Curtis argues that computers have failed to liberate humanity, and instead have 'distorted and simplified our view of the world around us.'"
https://en.wikipedia.org/wiki/All_Watched_Over_by_Machines_o...
If we can blame easy access to guns for the rise in mass shootings then we absolutely can and should blame easy access to Excel for the rise in MBA's completely fucking up companies.
It's just common sense.
Someone must have made a new spreadsheet because they insisted I owed them for one extra day of rent. I pulled out my copy of the contract, which required one check per month of exactly the same amount.
They said my contract was "wrong" and I entered full WTF mode. Offered them an advance of one day's rent that I'd deduct from the final rent check. Eventually they tired of me and "credited" me the amount in question instead of fixing their spreadsheet.
At this point I'm thinking that it has seeped into the very nature of the world - like Morgoth's Ring.
I am done with it.
For the next job I take, I will demand to be present in the daily meeting to see how it looks like. Ideally, there isn't one.
Based on a 2 line description from a product manager, so you actually have no clue on the scope of the task until you start working on it.
This is how at my last company, my team got every estimate wrong and engineers got fired.
Yes the salt is real.
And then, you will be held accountable for that number, even if (supposedly), doesn't represent time and even if the interpretation of your estimate must use the unit that the person holding you acciuntable.
Wow as I re-read this statement, it's completely insane
However, do not build the first floor yet, because I am still waiting for some important decisions to be made.
I’ll add another shocker: sometimes blueprints are poorly specified and/or incorrect. And yet, people build the houses. That’s the job!
Conversely if programmers had to work like Architects they'd be paid a fraction, not get promoted to run serious projects until they are 50+, work copious unpaid overtime, not be allowed to work from home, be held legally liable for their work, spend most of their days focussing on compliance rather than outcomes, be more client focussed than they have ever considered regardless of above, etc.
Said junior usually only does this for a maximum of 10 years and graduates to owning their own business. However 85% of them graduate to running a drafter business which just draws plans.
Uh, based?
I've always been amazed that in software, you can call yourself an 'architect', 'engineer', or 'contractor' without any legal accountability. But I'm from the brick-and-mortar side of the fence.
(I 100% believe that if an architect read this article, their takeaway would be that programmers have it too easy)
A family member bought a plot, some blueprints for a two-story house from an architect firm and hired someone to build it.
Well into the construction, the builders asked if he would like them to raise the roof of the building by one meter, as it would be a negligible increase in cost.
He was going to reject the offer but changed his mind and accepted.
Once completed he realized that if he had rejected the offer, he wouldn't be able to use the second floor at all. The house had a Gable-style roof[1], and the stairs a U shape along one of the outer walls. Had he not raised the roof, one couldn't have walked up the stairs due to the roof being so low along the outer walls. Even after raising the roof, tall people would still need to tilt their heads going up.
The guy did get the drawings independently checked BTW, they were indeed drawn with the roof too low.
I only ever did one big renovation and built one house, but I've seen builders fixing mistakes from engineers and architects sooo many times.
Not sure if there's a type of architect that has to think about the wholistic picture including function, usability and general ergonomics. They probably cost more too.
Uh, yes it is? It's in most building codes, as well as in the IBC (International Building Code).
Architects don't deal with structural soundness; that's a misconception. That's the domain of the structural engineer. The architect IS the generalist.
Pretty much every architect I ever had to work with was like that.
Most of developers jobs are “here is Jira ticket build what is written there”.
You get product owners, business analysts, scrum masters that should take away 90% of BS.
But still it is not the case and a lot of those business roles seem like they are just useless and I would do much better job directly talking to the customer.
In SW they are the PM's. Without a good PM to shield you from the customers insanities you are lost. In architecture or other engineering professions it's the same. As architect you have a special man to deal with politicians and special clients, and in many other professions even with the press, who has no idea either.
Never talk directly to the customer. Or if so, you are not allowed to make promises.
You should talk to the customer to understand the problems they have, and work with them to figure out the smallest thing that might help them solve their biggest problem. Build and deliver that small thing fast, then iterate.
It's amusing but sad to see that Agile rent-seekers have managed to creep into the process once again.
And developers have bought it.
Nice but now there isn't anyone to shield us from the insanity and micromanagement of PMs.
Especially the ones who "dabble in programming every weekend".
My current company has been run into the ground because we had a salesperson in charge of product map making wild promises to customers. What they wound up settling on was a PDF report that costs us $5-$20 to make and we sell for $1!!! Utter insanity. We'll be pivoting out of necessity but we could have saved 6 months by putting someone technically competent in the role.
- you aren't allowed to do any programming yourself, you just write a specification
- the majority of the people doing the programming are incapable of reading the specification
- many of those who can will deliberately ignore it to save money
- nevertheless, it's your fault if it's realised incorrectly
According to my brother who work in construction, architects are often clueless on how to build stuff and existing material limitation, especially with the money he's given.
Architectes are not engineers they are designers and visionaries.
You can check this video for more info:
Structural Engineer vs Architect - Design Meeting https://youtu.be/29-xtjX8rAk?si=7dupEMwy3DEbs_Yi
But anyway, no, if the house is built incorrectly, the builders are liable, not the architect.
Shouting “that’s the job!” when it is ostensibly not the job (whatever your experience of the “reality” of it may be) is really an implied assertion that you must make concessions in your work arrangement regardless of the explicit agreement you make with your employer when accepting a job.
The desperation to communicate this comes across, to me, as a cry for help with asserting yourself in the workplace. In my experience this is a result of a power imbalance in the employment relationship. Unfortunately the reasons for this imbalance are often extremely complex but some generic, potentially not helpful, advice for anyone in common scenarios I’ve seen would be:
1. Improve your skillset. It will help your (implied) negotiating power when they start adding more meetings or pulling you off task
2. Learn how to politely assert yourself in a work environment. We’re all playing games of imperfect information and light assertiveness and confidence can put an adversary in a position where they can’t afford to assume you’re wrong (in the moment)
3. Know what you’re signing up for and be candid about what you’re bringing to the table. If you’ve spent the last four years in intensive study of algorithms and data structures, be candid about the fact that you’re taking the job to solve computational problems. Let them know ahead of time that you’re not another head to count or butt to fill a seat.
The thing with the construction industry is that the user can "see" the frontend before, it would be like if you build the frontend and when the user accepts you build the backend.
Yes and I would like it.
- programming is way easier because you get instantaneous feedback[1]. When he has an idea it will take sometimes tens of years for it to be realised. (if ever)
- the rules they operate under are not deterministic. They might design a building which is totally fine under one interpretation of the regulations and fails under an other. Sometimes what actually changed is not even the interpretation of the rules, but things outside of their control such as the political favours of the investors behind the building. If plan reviewers want to find some problem with your thing they will.
- builders replace materials and techniques often, sometimes even without discussing it with the architects. In programming you don't have to worry that your compiler cheapens out and replaces the doubles you declared with single floats.
- With programming if you don't like what you made you just rewrite it[1]. With his line of work once you know know that something is wrong it is way too late to change anything. Heaps of money has been spent and years are passed. Because of reputational and liability reasons this leads to a mindset where you are unlikely to accept that there was ever anything wrong with your idea thus architects become solidly set in their thinking.
- Everything he thinks is mediated through layers and layers of other people. If something goes wrong he can always blame the builder, or the owner or the occupier. This leads to even less honest self-reflection.
1: A common theme in all of this is that what he has experience with is very small scale coding. He knows that a compiler provides instant feedback on syntax errors and he thinks that is all there to software development. We who work in the industry know that feedback loops are not always that fast in Software Engineering , but those parts of the work were not experienced by him.
Very much on point with this post above
Scale it up! It's already built, so I expect it on the lot tomorrow.
The house must be rebuild in the same location while I'm using it and the transition to the new house must be seamless. The garage must be rebuild with the car in it, the kitchen floor and counter top must be replaced while the dishwasher and the oven are running, I must be able to shower and stay in my tub during the bath room replacement, you must rebuild the bedroom discreetly while I'm having sex, toilets must be rebuild while in use.
Also architects often need to adjust design while building is under construction.
Deploying code is not comparable to what you have described.
The restaurant business is so low margin, most restaurants simply can't renovate -- even if you can afford the actual cost of renovation, unless you are already wildly successful you'll never make up the money lost for being closed for weeks, you have to fire and rehire your entire staff, and you'll piss off customers by being closed when they expect you to be open. It makes more sense to simply close the restaurant after a few years and open a new one.
Rich people who want custom homes often want to design it themselves, and then get extremely annoyed when confronted with the reality of basic design principles, usability, materials, structural integrity, etc. And then like to change their plans last minute once they actually start to see it framed in (assuming they don't freak out because they've never seen framing before and don't realize it isn't done yet). Or perhaps one of their rich friends made a glib comment or a jab while being shown the foundation and now the customer wants both their kids to have their own recital hall, because one isn't enough.
Another stellar example: someone wanted a garage put above their kitchen because they wanted to park their ferrari next to their bedroom on the second floor. Damn the exhaust fumes.
You mean this guy?
The next morning, after they sobered up, more like this guy: https://youtu.be/fqgrOl1q9p8?t=5
A lot of models had to be built. But this is common. Hitler as another rich nightmare customer was famous for adoring Speer's models, and changing his mind constantly. He always knew better.
Fix, Developer asks landscape architects to draw a pool deck on the podium of a tower under construction. Landscape asks engineers about floor thickness and load numbers and are told that the podium, as completed, cannot carry a pool. Apartments have already been sold, with brochures showing pictures of a pool deck. Nobody told engineering that they had to spec for a pool let alone where on the podium.
Another story I’ve heard: core of residential tower has been completed to 20 out of 40 stories when developer gets a bright idea and approach an architectural firm to design a rooftop pool, as if that’s not something that required planning in terms of foundation, structure or where to put maintenance equipment.
For example, in construction you have:
* Architect (designs the building)
* Designer (prepares the technical drawings)
* Engineer (signs off the drawings)
* Manufacturing (makes building parts to the drawings)
* Surveyors (make sure the land can be built on)
* Builders (build the building)
* Roofers (put the roof on)
* Site managers (make sure the builders build the building)
* Building Control (government sign-off on the built building)
* Sparkies (put wires in)
* Plumbers (put the pipes in)
* Plasterers (put the plaster on the walls)
* Painters/decorators (finish the walls)
* Fitters (put everything else in)
All of these are separate businesses and I'm sure I've missed some things, or misnamed others. And, despite a number of people being legally liable for shoddy work, we still see things like Grenfell happen.
Software engineering, by contrast:
* Product manager (figures out what to make)
* Designer (figures out how it should work/look)
* Software engineer (writes the code)
* Auditor (compliance with relevant standards e.g. PCI DSS or SOC2)
There's also a bunch of stuff supporting that but I left them out because I'd add 5x more on the construction side.
My point isn't to say who has it harder, or which field is "better," just to point out that the fields aren't comparable at all.
> My point isn't to say who has it harder, or which field is "better," just to point out that the fields aren't comparable at all.
Is this industry jargon, a translation, something else I'm not aware of? I'd think this was "electricians".
I thought it was:
* Managers (they manage)
* More managers (they also manage)
* Even more managers (probably also manage, not sure though)
* One full-stack developer assigned 20% to this project (has meetings with managers, writes the specification, writes the code, tests the application, deploys the application, provides 24/7 on-call support)
https://www.stilldrinking.org/programming-sucks - Second section
But thanks for sharing, it's quite fun
Also, many commenters saying this is in bad taste, badmouthing architects or assuming a victimized 'hurr programming is so hard' stance. I read it differently, as a critique of the software industry itself, about how we're utterly unable to get our clients to understand the realities of our work.
Noone in their right mind would ask for a house with 2-to-42 bedrooms. Yet the average IT worker somehow accepts this as normal in their software work. It would behoove us to get our clients to understand this, and not delegate that task to the scrumlords... who generally only make things more confusing and complex.
Also, make sure only authorized people can enter or see what’s happening inside and keep everyone very safe from fires, physical harm or other people. Unfortunately, the safety must be accomplished without additional cost or restrictions in use.
In some places the new house is being built for folk who are happy with the old house. And if the users don't want to change they can sabotage the project away. It's worth finding out, before any money is spent, just how devoted to thd project the owner is.
As in, if push comes to shove, who gets fired, the architect or the monther-in-law?
Its usually: "our product needs X, get it done". You can listen to that manager for hours or days, use your psychiatrist hat to extract more useful info, renegotiate requrements etc, but that doesn't save you from probably weeks or months of just hard work.
I would understand if one is a contact person for some account. And then you listen to your client as best you can, write up a doc/ticket/whatever for someone else to deal with that.
A janitor who listens most of the time isn't really a good janitor so this is much less universal than it sounds.
Architects and software engineers are both part of the product design phase, software engineers deliver the first version of a product that can be tested (that can include multiple iteration, and new versions of an already finished version of the product).
Product manufacturing in IT mostly consists of getting a copy of the product to the end user, either by creating an actual copy, or by allowing all users to have access to the final version created by product design.
Software engineering is part of design, you’re part of getting the requirements and design final, don’t expect just to manufacture according to finalized designs.
Architect simply look at the bigger picture design, components and interfaces, whereas engineers have a smaller focus. Architect are usually just engineers with more experience so they have more experience with the bigger picture design.
I don't think that is true at all. These are distinct fields.
Same with any craftsmanship. If they botch something they have to start all over again, sometimes they can't.
Compared to that being a programmer is easy.
If we're talking about building, you'll know the estimates of adding a sink on a specific room / floor vs adding another floor on the roof. Both need to be reviewed by the blueprints and whether the foundation support another floor if we're talking the later.
In software it should be similar, however most of the time management isn't aware of the software architecture and the challenge to make the change. Adding a button to change some value may take either hours to days depending on the architecture, same with adding a sink may take days to months depending on the plumbing blueprint.
Which is why in software, sometimes management ask you to add 50 floors to an existing 100 floors building and simultaneously change all the electricity placements on all floors, in under 3 months.
Some changes are trivial, others are like moving to a new standard for railroad widths.
The biggest difference though probably is, that the architect who creates the blue prints - will not be involved in the actual construction work. Therefore the blue-print (which the customer signed off on) has to be ground truth.
But with a good chance of not being paid.
And with direct personal liability that cannot be shielded with a corporate entity;
and professional license requirements;
and building codes enforced by governments…
And of course if you fuck up, people may die.
The article captures another aspect of architecture as well: ordinary people assume living in a house and using buildings gives them informed opinions on architectural matters. But that’s just people.
No clue how that works in the US, but here most of the calculations are being done by an engineer with a different education than an architect.
If's fun little article, but is a bit short-sighted. Probably because otherwise it would not work.
Programming has a lot more in common with portrait painting or sculpting than building something physical like a house.
It is very hard and expensive to change physical things, software is relatively easily comparatively to change. Because software is changeable and pliable, it is practical to not make all decisions in advance.
I'm not saying there aren't positives to doing things that way, but it's got a lot to do with why the satire of this article rings true.
Programming is a profession that, with the exception of a few early decades, practically started in the corporate world. Modern day development is what you can expect when companies have unchecked autonomy over a whole professional field.
That's why an abomination like scrum exists where you are guilty tripped everyday in dailys having to report what you have done even though management and your colleagues have access to your tickets with your logged hours and the code you have commited to the repository.
I love programming but the only thing that keeps me in the field today is the pay, the moment I start to earn less I leave the field and go to work in something else.
Thanksfully, I could tame my SW clients, but heard enough stories of totally incapable PM's who accept such clients. But we also had similar "Bauherren", esp. in politics. German politicians are famous for demanding the "eierlegendewollmilchsau" in construction.
I even had specialized jobs to deal with such clients, such as e.g. in stage design. There was a whole SW VR project to be able to show the client his absurdities beforehand.
To me these "what it's like in comparison to x" post just try to exaggerate and overblow the Programmers life whilst downplaying an Architects.
Almost all of these points just illustrate that every project based profession has similar pain points.
It's also ignorant to assume you know what it's like to be an architect or what another profession is like for that matter unless you have worked in both fields.
For example: start by marking the position of the front door on the property and lay out the living room with sticks and wire so you can decide where you want to look at while sitting on your couch.
And I believe he was right. Building lean can be done but does not fit in the 'architectual way'.
The insight here is that people expect things not based on reality but on desire. With architecture there is a process to give the architect leverage to say no to ridiculous requests, architects need to be licensed, which is hard to get.
We have no such leverage in IT so we get threatened with "do it or I will find someone that will" and businesses are always trying to find that cheaper someone or group of people that will do the work they have in their head on time, for a cheap budget, and without asking a lot of questions like "why do you think I would know something you didn't say or write down".
A lot of people are saying "construction and software are very different". This is fair, but this is not how I read it. The point being conveyed is not that the methods used in software don't make sense in construction, or that we're using the wrong method in software because construction does it differently, but to outline the outlandishness of certain expectations in software and of software devs (extreme flexibility, ridiculous cost, taking in the needs of the planet, doing all the jobs) that, dare I say, didn't change much in the 29y since this was written.
That these are bytes and those are bricks don't change that thise expectations are unrealistic, and that post makes that point in a funny way.
The premise of micro-services where lost in complexity, the whole point always was "you should be able to select the tools you like".
To put it another way, there's a reason Toyota has an order of magnitude more employees but a comparable networth to Adobe and it's not because doing things in the real world is easier.
I'm incredibly grateful that I work on cattle not pets, or humans.
PPPS. House will might be sent to the moon or Mariana trench. Make sure it can sustain these pressures.
PPPPS. This goes for trailer as well. Additionally we need a plan to deploy it on a neutron star.
“bah! you don't need no plans or design! I’m an agile™ architect and will lay brick using microbrickservices™ and the runnyconcreteframework™ and see where we go from there”
The fact people are taking this so seriously is concerning, though not surprising.
Building software lends itself to change and iteration more readily than building in the physical world. As an industry or discipline, it is also vastly younger (and therefore immature) compared with eg. our shared knowledge of how to do construction projects that has developed over thousands of years. The realm of what is possible and impossible is also much different. A laypersons understanding of what goes into building a home versus building a web application are much different.
This made me chuckle. Captures the mentality perfectly.
But the sad reality is that programming mispractices have spread like a plague to other engineering discliplines.
Even total BS like agile have been forced on other poor engineers in totally different sectors.
So programming didn't evolve into an engineering discipline, we brought everyone else down with us!
The royal we, as in The Man, by the way. I did nothing wrong. Leave me alone. :)
But if you think about it, an architectural drawing for a building is essentially an executable recipe for building a house that the construction team uses to build it. I.e. it's actually very similar to a program. It tells the team of builders all they need to know to build the building.
In the software world, the blue prints actually are executable. That's the whole point. The job of programming is essentially just creating a very detailed blueprint in some language. The compiler/interpreter then generates the executable from this blue print. The only difference here is that we replaced the team of construction workers with another program the construction process is automated and does not involve any people.
This wasn't always the case, the word compiling refers to people stacking together punch cards in the right order. The first computers were humans flipping switches, doing calculations, and messing around with cables, punch cards and what not. The word debugging refers to removing actual live (or dead) bugs from circuitry. Writing a program used to mean creating a plan to task these people to do all these things. Having a plan for that is kind of crucial. Exactly like having an architecture blue print for a building is important. That's what a program is: a blueprint for creating/generating instructions that a computer can work with. Ada Lovelace, widely recognized as the first programmer, never even had access to a computer. She was designing software for a machine that did not yet exist. But she was a programmer and not an architect.
Having a separate program for producing the program just isn't a thing (well except for meta programming of course). Just like having a blue print for a blue print for a bridge or a building is not really a thing. There's just the blueprint. And just like programmers have to do a lot of problem solving while they create their blue prints (programs), architects have to do a lot of problem solving while they are creating their blueprints. It's this problem solving that make their jobs hard and unpredictable. Once you have the blueprint, things get relatively straightforward and predictable.
But before that, buildings are just as risky and unpredictable as software programs are. You have to deal with requirements, budgets, regulations, flaky customers, etc. This can get really complicated and risky. That's why large engineering projects run over budget so often. And ironically, agile engineering is actually a thing too now. E.g. SpaceX iterates on their rockets rather than designing them years in advance: real world engineering is learning from software engineering.
What? You can't do that? My husband/ son/ nephew/ gardener knows how to draw with pencils, I can have them do it if you won't see reason!
The problem is nobody cares about that style because although people die when a building falls, nobody dies when a program crashes.
At least most of the time, nobody dies.