[ChrisMarshallNY]

Good management advice. I was a first-line manager for a Japanese company (hard estimates, with lots of international frowny-faces, if the estimate was missed). That was pretty much what I did.

We usually came relatively close to our estimates, but would sometimes encounter anomalous situations that would force us to re-evaluate. I found that my managers were pretty good at accepting these, as long as they were not too frequent, and as long as I didn't do the "Lucy in the Chocolate Factory" thing. They set hard plans, and we were not to deviate from them.

But our customers often did not like the software that we delivered on-time, and to-spec. Since we were a hardware company, it was considered OK, but we hated it.

So we delivered yesterday's technology; tomorrow. :(

But I also ran a small team of really high-functioning C++ engineers. They stayed with me for decades, and I got to know them quite well.

I can't even imagine running one of these shops with half a million inexperienced engineers that flow in and out like guppies in a pond. My management experience would be worthless for that environment.

Since leaving, I have taken a very different tack with the software that I write.

I assume that my estimates are basically fiction. I am going to make big changes, to suit changes in the deployment environment, customer expectations, competitive landscape, platform tech, etc.

I tend to write very flexible software, in layers and modules. It allows me to react to these changes fairly quickly, and to maintain my very high quality standards, throughout.

I often toss out huge gobs of code, when I hit one of these challenges. That actually makes me happy. The code I don't write, is the best code of all.

Flexible software is a very double-edged sword. Most quality processes advise against it; for good reason.

But I tend to know what I'm doing. I've been at this a long time, and have been very humbled by many, many mistakes. I would probably have a difficult time trusting developers with lesser experience to take the kinds of chances that I take.

So my personal process depends heavily on me being me. I know myself, fairly well; warts and all. This means that I can trust the Principal engineer on my projects.

I manage scope. My projects are small-batch, artisanal, projects. I don't bite off more than I can chew. That said, my "small batches" are bigger than a lot of folks' personal projects. I often spend months, writing my code, so change comes almost invariably, during my projects.

Works for me. YMMV.

[xcambar]

Honest question: how do you function in a team?

I know a bunch of very self-aware devs, but they almost all have a very double-edged relationship with team work: theylove to learn and share yet see other people as impediments or risks on their way to delivery.

How to improve on these situations?

[ChrisMarshallNY]

Very well. You don’t last long in a Japanese company, if you don’t “team” well.

I lasted for almost 27 years.

I’m working on a team, now. I am doing the native app development, and I was the original author of a couple of the servers, but there’s a relatively young chap, working on another server (we’re up to 3 servers). He has some experience, but nowhere near mine. I’ve learned to work with a light touch, in these circumstances. I demand a lot, from myself, and expect his work to meet my bar -but only at the API level. I stay out of his kitchen. I make sure that he has no problem, asking me any questions, or for help.

When he asks for help, I immediately provide it, with no judgment. In turn, he has introduced me to a couple of new tools and techniques that I have adopted.

Here's an example:

Before this project, I'd never used Postman. I used much simpler REST explorers. You'd probably laugh at the primitive tools I used, when developing my servers.

I suspect that you wouldn't laugh at the results, though.

He asked if I could use Postman to give him examples of using the API for one of the servers that I wrote.

I could have been a dick, and said "RTFM" (It's a very well-documented API). Instead, I learned Postman. Didn't take long. He's thrilled at the results. Our exchanges seldom take more than a couple of Slack messages and a Postman query example.

I now have experience using Postman, and will have a new tool at my disposal, for working with others. It probably won't be a regular part of my solo work (Insisting on using team tools for solo work can be a bit problematic), but it's nice for teams.

I am encouraging him to learn Charles Proxy. He's not really following up on that. It's not the end of the world, but he's missing out on some really awesome inspection capabilities by ignoring the tool (and it means that I have to be a bit more creative with my Postman examples). It may cause problems down the road, and I'll deal with them, if they crop up. I will do so in a non-judgmental way. Our relationship is valuable, and needs to be treated with respect. I treat him with respect, and he does the same for me.

In my world, that’s how we team.