[enraged_camel]

I don't see this as subjective, because dealing with computers and technology is a fundamentally different type of activity, and requires a totally different set of skills, than dealing with people. If you're the type of person who enjoys the former, I think it's safe to say you won't enjoy the latter much, at least not at first.

[mandelbrotwurst]

> dealing with computers and technology is a fundamentally different type of activity, and requires a totally different set of skills, than dealing with people.

Sure.

> If you're the type of person who enjoys the former, I think it's safe to say you won't enjoy the latter much

This seems like a bit of a leap. People can be good at and enjoy things that are very different.

[vi-mode]

Yes but the context here is coder transforms to manager. And coders got coders because they like short feedback-loops.

[mettamage]

Nope, I became a coder because I want to be able to create apps that I have in my head. I hated coding for the first 6 months (I'm on year 8 now). Now I like it, but I'm still not passionate about it.

My passion is about digital creation.

I think I'd like being a manager, depending on the context. Since I like to talk and listen to people their ideas and get energy from talking and listening.

I don't get energy from coding. I do get energy from creating something awesome (either myself or with a team).

[vi-mode]

Nice that you told us the story why you got into coding. I just tried to find an abstraction for the sake of simplicity. Of course we had all our triggers why we got into coding. And of course we had some specific end goal like you had but the actual activity of coding is about short feedback loops. Something which many professions lack. If you didn't like short feedback-loops you wouldn't code for 8 years.

[com2kid]

> If you're the type of person who enjoys the former, I think it's safe to say you won't enjoy the latter much, at least not at first.

I disagree, I volunteered (edit: to step up and take on) for a manager role and discovered I loved it. I really enjoy helping built teams and team culture, helping people learn and grow in their career and abilities, and working to coordinate work across multiple teams to get work done at a scale that I never could have as an IC.

Saying that people who enjoy coding don't like dealing with people is like saying people who enjoy painting won't like programming, it is a stereotype that is easily dis-proven by the existence of people who, in both cases, do enjoy both!

[vi-mode]

Managing people != dealing with people

This is the biggest misconception most have you have never led seriously. I like people, I like meeting people for a beer, for pair-programming, to date. Managing people is not about being with people.

[com2kid]

> This is the biggest misconception most have you have never led seriously.

As a manager, I managed my team, and dealt with a lot of other teams!

I was spending a good % of my time coordinating, organizing, and paving the way for my team to do good work. Ranging from ensuring the UI specs that got to them had been well vetted, to negotiating release schedules with other teams.

This extends even to engineering decisions. As an example, there were ways my team could implement a feature that'd save us time, but be harder for an upstream team to integrate with, or we could take more time implementing something to their requests at a cost to our schedule.

Balancing decisions like that is just as much talking to people in hallways between meetings as it is attending those meetings. It is forming relationships across an organization so that even when schedules get tight and times are tense, things don't get ugly.

[vi-mode]

Tbh, this sounds you like are heavily micromanaging your people because you don't have any task yourself. Did you ever got into 360 feedback? How was the outcome?

[com2kid]

I wasn't micro-managing my people, I was managing interactions with other teams.

For reference, we had software running on the cloud, mobile, and devices, with multiple teams at each tier.

API changes were a mess of coordination. It wasn't "send JSON" it was "round trip this in a way that can be consumed by a device with 256KB of RAM." Multiple transforms of data across multiple mobile platforms meant just locking down on field orders could be problematic if someone didn't take proper notes[1], or if a Java programmer on Android didn't understand how to properly consume an unsigned 8bit int.

Early on in the project, we had a design team that hadn't yet been trained on what 96mhz CPU could do in terms of UI. I was doing careful reviews of UI designs, and eventually was just sitting in design meetings, to ensure that by the time specs got to my team the spec was physically doable.

Another example, when it comes to performance. I was going over EE schematics to ensure there was sufficient bandwidth to push pixels how the UX team wanted. Part of my job was working as a go-between for EE and UX and explaining the other teams POV to people with very different backgrounds.

Then there is the more soft-skill stuff. Seeing months ahead of time that another team would be having problems in the future, and suggesting to one of my senior engineers that making some friends over there and getting up to speed on their code base ahead of time might be useful, so that in a few months when help is asked for he can jump in and assist.

Letting senior management down gently that their favorite feature is going to be cut.

Prioritizing what features we need to implement to show "progress" to upper management so that we can all stay employed. This often required guessing far ahead of time what we'd eventually be told to demo "next week", and having work start on it way ahead of time. These were very much "do or die" demos.

The feature work? The team sat in a pod and discussed technical implementations with each other. I trusted the people I had hired to do good work, that is why I had hired them. I had the huge benefit of having personally hired every member on the team, which is one of the things that made any of the above possible.

Then there is the actual team management stuff. Inviting engineers to the right meeting so that they had visibility, giving them a chance to speak up in front of senior leadership so that their name was known. Taking someone who I saw leadership potential in and helping them see it, and giving them opportunities to grow that potential.

Rotating user facing features around between engineers so that they all had something they could point to and say "I made that shiny thing!" Good for both morale and career visibility.

Preventing burn-out. Telling PMs that work was going to be delayed because the engineer best suited to doing it was going to be working 6 hour days on light duty because they just went through a 2 month crunch.

Ensuring senior leadership heard the name of the engineer(s) responsible when something went right, and only heard my name if something went wrong.

Managing is a lot of work, but I think your judgements about it are unfair. Managing engineering projects is a blend of technical and people skills, and there is no law of the universe that says someone can't enjoy both.

[1] Or ignored the spec sent out. Or wasn't aware there was a spec. Or we were told we had to have this working in a matter of days so there was no spec. Or there was a bug in the deserializer that ended up swapping two fields. That last one took awhile to figure out.