Live data from Hacker News

You’re Not Managing a Team of Software Engineers, You’re Managing Writers

medium.com

21–30 of 56 posts

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#21

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 i…

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.

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#22
post #5

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.

Interlacing is technical debt. It looks bad and there's no longer any need for it, but it's still included in currently supported standards.

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#23
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.

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#24

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…

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…

Similarly interested in the way you see status.

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.

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#25

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…

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…

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.

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#26

Earlier quoted context omitted.

What’s your basis for determing status? 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:

"What do you do?"

"I'm a software developer."

"Oh cool. Like my boyfriend and my brother."

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#27

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…

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…

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.

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#28
post #21

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 i…

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 man…

> 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.

Re: You’re Not Managing a Team of Software Engineers, You’re Managing Writers

#30
post #5

Earlier quoted context omitted.

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.

Plot debt? I could actually see that describing some shows...

But plenty of other franchises just ignore things in the past as though they never happened, even up to and including characters.
Post reply on HN