You’re Not Managing a Team of Software Engineers, You’re Managing Writers
medium.com
medium.com
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.
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.
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.
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.
Apparently Japan considers programmers low prestige still for one.
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.
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.
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.
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:
"What do you do?"
"I'm a software developer."
"Oh cool. Like my boyfriend and my brother."
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.
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.
However, I can see some similarities in the mechanics if I squint hard enough.
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.
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.
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.
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.
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.
Every carpentry job requires solving a lot of problems every day, and using a variety of skills.
But carpenters don't think of themselves as divas or creatives.
In most cases, it's not nearly so romantic.
There are objectives, roadmaps, client needs: it's just a job. Put on your hard hat, get your morning coffee and do it.
https://www.forbes.com/sites/jvchamary/2018/05/30/solo-star-...
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.
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!
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.
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.
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.
Pedantic maybe, but it does reiterate the point that a software dev couldn’t design a spacecraft.
The OP's point was that both types of engineering are of similar complexity when contrasted to writing in a natural language
So the entire thread is unreasonable.
But then a lot of disciplines are also assisted by having more writing skills as well.