No youre managing a team of software engineers, one skill they have is writing.
The product isnt the text. The product is the entire system designed to keep the text alive, functional, reasonably error free all in a relatively unpredictable environment.
We definitely need to keep considering how other professions manage the unpredictable nature of their work so we can learn. Im just not sure this narrative suits that goal.
The uncomfortable fact is other professions treat their employees like cogs (hiring booms then mass layoffs), or their customers like crap (ever wait an hour for your set time appointment at the doctor?). The determining factor is really the price of the professional.
Software development is in a real interesting situation as its transitioning from a low status job to a high status one. As this progresses you'll see more and more "the customer is always wrong" style blog posts. They are already pretty common already.
I would liken any status in software to superstardom in sports. If you're in demand for exactly the right thing, all the doors open. But if your real calling is something with no extant "pro league", you are viewed as a hobbyist without relevant skills.
Knowing 6502 assembly was a pretty sweet skillset, back in the day.
I'm not sure I've had any job in the last twenty years where I met all the listed requirements.
My impression is that employers want some skill that it's sometimes possible to puzzle together from (but is rarely directly stated in any reasonable way) on the requirements list, then they want you to pass a poorly done faux IQ test.
Then there's a bunch of social stuff, which I don't really understand well enough to treat as anything but random noise. I mean, I can see that it's there and that it's not random, but I can't really see how to change it to my advantage.
Hiring is hard, and nobody, as far as I can tell, is any good at it. But being too specific about what skills they want is not a problem I've personally seen. (Not in the last 20 years in silicon valley, anyhow)
The way I see it, the lowest point may have been the 60s, then it briefly rose in the 80s to "wizards", continued to rise 'till the early 2000s, and now is in sharp decline, as everyone and their dog is now a software developer.
Software developers were never the hero’s of the story. It was always the prettier people egging them on for the greater good while they talked about how smart they were.
That’s changed lately. With the need for ever more developers the average skill has gone down but that is orthogonal to status in society.
Softward development is a very inconsistent status and status depends upon what is aimed for greatly. Outsourcing to cheap labor was considered a cost cutting panacea until it backfired horribly.
Apparently Japan considers programmers low prestige still for one.
I can get an appointment with my doctor, quicker than I can get a programmer assigned to a task at my workplace. I go through fewer gatekeepers at the doctor's.
Because you're the client. You seeing your doctor will always make the doc more money.
To carry this metaphor a step further, you asking for help on a ticket is more like going to the emergency room. If your ticket is a tummy ache you're going to wait. If it's a gunshot wound to the chest you're going to have all the best staff on hand immediately to put out the fire.
Is it? I mean, practicing medicine on other people is illegal in the US, as I understand it; and you can't obtain certain drugs. But I think everything else the doctor does, you can do to yourself without fear of legal penalty?
In my experience it massively elevated my status 15 years ago thru now, where it seems to have no effect and perhaps anchor me away from higher level jobs given the value of the output and scarcity of 10x engineers.
I’m happy enough as a simple IC if they pay and treat me well, but that’s not been the case in 5+ years which has me in retirement from the field.
Status normally follows money (with enough gestation time). For the simple reason to get money you need to convince someone who already has it to give it to you.
The inverse is also true, while a Noble title will get you a good spot at a traditional restaurant in London - for the most part nobody cares now that they don't employ half the village.
It seems to be reversed or less related in software. As programmers went from curiosity to wizards (high-status), their salaries went up, but these days coders are dime a dozen, but the salaries are still high due to what seems to be a combination of adtech boom and demand still outpacing supply.
Anecdotal, but the way I sampled the status question is this: 15 years ago, when I told someone I can code, I was seen as some sort of genius. Fast-forward couple of years, and the exchange started to go like this:
You and I take the same situation and see it very differently.
My impression is that most people don't see intelligence as a good thing; not socially, at least.
15 or 20 years ago, if I said I was a programmer outside of my chosen peer group, people were more likely to respond like I was someone not worth associating with socially.
Now, people almost treat it like any other high earning professional. My impression was that then, it was only a job you went into if you didn't have opportunities in business or law or whatever. Now? it's on the standard path to both of those, and catching up (but still not there) on renumeration.
My impression is that a lot of the people who came into the industry after me were the sorts who would have gone into business or law in the '90s. This makes me seem a lot more socially normal than I was when I was younger.
> No youre managing a team of software engineers, one skill they have is writing. ... The product isnt the text. The product is the entire system designed to keep the text alive, functional, reasonably error free all in a relatively unpredictable environment.
So, are writers just people that produce text? I think of them as people that produce systems that are explained and interacted with through text. The product of an author isn't text, it's a a story. The product of a technical writer isn't text, it's distilled knowledge. Text is the medium. I see a lot of parallels with software development.
> A well written story can be open to many interpretations, well written software... not so much.
Well written tools can be reinterpreted for use in many different ways. Is your favorite text editor something you use to write code, or write term papers, or to express your thoughts in diary form, even if it's eventually published online?
Our relationship to the software we use changes over time, even if the software is mostly static. In that respect, maybe software is often like poetry. A lot of the benefit is us finding your own interpretation of usefulness from it. Certain software resonates with some of us while others see little use in it. You'll have to pry Vim from my cold, dead hands, but I don't begrudge anyone their Emacs, or Sublime Text, or whatever they find works well for them.
It's a rosy, romantic view, but I pity the software engineer (or amateur code-monkey, however you identify) that doesn't feel this to at least some degree. The road is long, you might as well find some friends along the way.
Niven's First Law of Writing: Writers who write for other writers should write letters. - Larry Niven, science fiction author (1989)
The writer is that person who, embarking upon her task, does not know what to do. - Donald Barthelme
Summary of advice from writers: Advice from writers is useful, and not only about naming. Writers have been at it for centuries; programming is merely decades old. Also, their advice is better written. And funnier. - Peter Hilton
Author: Yesterday I worked on a few paragraphs where the antagonist was just about ready to reveal to the protagonist his knowledge of the protagonist's long lost brother. But I'm blocked on the historical research about Vietnam POW camps. Hopefully, if my research assistant can run that down soon I can move that paragraph from the unblocked column back to in progress. In the mean time I'm pulling in the foot chase scene "story" but at this time I think both these "stories" will carry over to next sprint.
Publisher: Hmmm, that's going to negatively affect your velocity.
Managers shouldn't be writing code or architecting at all. A manager's job is to manage people or a product. If it's people, she should be completely focused on unblocking the engineers and keeping them out of meetings. If it's the product, she should be completely focused on gathering the requirements and constraints and communicating with the customer and getting estimates from the engineers.
The architecture and implementation is a hidden detail for a manager. Either the team lead, architect, or team as a whole should design and move on the code.
The problem is the architecture is intertwined with the product is intertwined with the people. Believing that these things can easily be broken apart is an illusion. It’s how product believes one thing and engineers believe another, resulting in quick hacks, missed deadlines, and a mediocre product, if it’s released at all. Meanwhile the manager is a “people person”.
Teams need leadership, not three leaders. Dev managers should be able to understand the architecture, and the product, and the team. Product advises on the direction. Tech leads argue for the implementation. But the dev manager needs to bring these things together and provide direction. Otherwise all three people will just point fingers when the results suck—diffusion of responsibility. Teams need leaders and leaders need to be accountable for results.
> Believing that these things can easily be broken apart is an illusion.
It works really well were I work. It's led to an extremely bottom up culture were engineers want to stay forever, because they feel like management isn't getting in their way or compromising technical decisions.
> Teams need leadership, not three leaders.
I'm not advocating for shared responsibility. What I'm advocating for is separating responsibility such that each person knows exactly what they are expected to deliver. The manager is expected to help his team perform and be happy. The TPM is responsible for delivering the product the users want. The tech team is responsibility for delivering a product as quickly as possible that is maintainable and bug free and meets the requirements set by the TPM.
In your model, managers argue with the tech team, which causes people on the tech team to quit or become frustrated because the managers can't understand all of the details and still fulfill all their managerial duties.
> It’s how product believes one thing and engineers believe another
The role of the TPM is to make sure the tech team is building what the user wants. the TPM should be synchronizing with the user and the tech team, making sure this doesn't happen. It's their responsibility.
> Teams need leaders and leaders need to be accountable for results.
Agreed, teams need leaders who are focused on doing one thing, and one thing well. They should not be backseat architecting or leading the technical direction, unless they are the tech lead.
I'm sure it works well in terms of making the engineers happy because it sounds like the inmates are running the asylum. You're right that managers should be dictating the what and not the how, but that doesn't mean they shouldn't understand the "how" their report has chosen.
I agree with everything you say but what bugs the living hell out of me is this profession's infatuation the new shiny. That along with the almost universal absence of any objective evidence that the new shiny will positively effect the project's bottom line.
In former times, what we consider the trades were also romanticized. The masons and all that. I expect software to follow the same path and at an accelerated rate but that still gives us a while before we‘re fully normalized.
I do wonder how a TV show runner of some experience would handle a software production. There are a lot of moving parts that are not unlike what they deal with.
There is no technical debt in TV production. That alone changes many things. You don't need to care how you arrived at the result or how "maintainable" it is.
I thought that "the ship that made the Kessel Run in less than 12 parsecs." was the very definition of tehnical debt - which took 40 years to finally resolve.
The Stargate SG-1 writers regretted the "3 shots from a zat-gun disintegrates" thing, and had zat guns only ever hit stuff twice for the rest of the show after they realized the mistake they'd made.
The problem was introduced to solve a plot issue in one episode - they needed a way for the team to get rid of the bodies they were leaving behind on a spaceship in one episode.
I'm not sure that quite right. You do need to make sure it is maintainable because (at least in the US), they needed multiple seasons to reach a mark that would allow syndication.
I think 21 is talking about the technical side of production e.g. hacking some weird sound effect - doesn't necessarily matter if it was hard, once it's recorded and produced, it's done. If you had to have someone holding up a part of the set, as long as it worked, it doesn't need to be maintained.
What you are talking about is maintenance of the storyline, which in some ways is probably more consistent with what us Devs talk about with technical debt. That said, there are plenty of plot holes in many TV shows and I still watch them!
There is in production you start out with x pages of script and have 7 days to shoot it.
Listen to and commentary with directors and actors they will often refer to getting the day done i.e. they shot the required number of pages and having to cut stuff or not be able to do some cool shot they wanted.
This article is a great example of the biggest problem with software development management: they often fundamentally do not understand what software engineering entails.
You can tell that he has caught on to a few aspects in terms of requiring editing and creativity and not being able to plan everything ahead. But really he doesn't understand the full extent of what programming involves. If he did he would definitely not carry the writer metaphor so far.
A writer's output is natural language. Natural languages and programming languages are extremely different things. Prose does not have strong and brittle constraints on syntax and semantics that computer code does. Prose does not create real systems with many moving parts that must align and synchronize precisely.
If you could get a creative writer to sit down and just design a new type of spacecraft engine by using his creative powers like a science fiction exercise, then the metaphor would work. But engineers have to make systems that are completely detailed, exacting, follow the laws of physics and harness them in intricate ways. Software engineers are often essentially doing research on new systems or new ways to combine systems.
If at all possible, get an experienced programmer to act as a manager for programmers. A programmer would not describe it as simply writing.
That metaphor seemed like it was trying to show equivalent complexity, not that the jobs were interchangeable.
Engineers on a spacecraft needing to know that at a certain temperature a material contracts which changes the friction coefficient it has and increases the heat generated until two moving parts melt, seems to have the same equivalence as knowing that at a certain rate of incoming messages your cache technology starts hitting a race condition where messages are double sent and now the downstream work is duplicated but not able to be correlated.
All of this is different from ambiguous wording in natural language, where the ambiguity might even be the intent.
Thermal contraction would typically not change a particular part/material’s coefficient of friction but rather would potentially decreasing acting normal force. Friction is reduced because contact decreases not because some material characteristic changes.
Pedantic maybe, but it does reiterate the point that a software dev couldn’t design a spacecraft.
I think you may be missing the point. I was trying to give an example of complexity, not trying to prove that a software engineer could casually walk up and design a spaceship.
The OP's point was that both types of engineering are of similar complexity when contrasted to writing in a natural language
But that has nothing to do with what I was saying. I was saying that engineering is different from writing. There is no reasonable interpretation of what I wrote that is saying that different types of engineers could do each other's jobs.
I have found that a lot of the skills to do with writing effectively, professionally and reliably also apply to writing (and maintaining) software. It's not to say they're the same discipline, but they're closer than - say - electronics engineering.
But then a lot of disciplines are also assisted by having more writing skills as well.
The product isnt the text. The product is the entire system designed to keep the text alive, functional, reasonably error free all in a relatively unpredictable environment.
We definitely need to keep considering how other professions manage the unpredictable nature of their work so we can learn. Im just not sure this narrative suits that goal.