Oh man! You know how to kill it with these conversations.
No! I don't want to be promoted. I don't want the added responsibility of watching others code. However, I did not get this opportunity. I got the promotion. Guess what? It made me grow, and it made me realize that I don't want to be a lead of a team.
I just want to write code. I want to architect systems. I want to write tests.
But then again, I want to share my knowledge with others and help them. So shit. What am I to do?
A Front-End Developer with a passion for learning how people work, the efficacy of good design, and a growing interest in the complexities of functional programming.
A Front-End Developer with a passion for learning how people work, the efficacy of good design, and a growing interest in the complexities of functional programming.
Courage can't exist without a little fear. And I'm sure there's tons of conferences or MeetUp groups with shorter timeframes. Don't need to host an hour off the bat.
Or you could find a way to create a hackathon (especially for students) and offer your expertise to get them through issues.
You're a developer, it means you like solving problems. I'm sure you'll reach those goals and plenty you haven't yet thought about.
You don't architect systems. You architect teams. If you are writing code by yourself, then you don't need that much architecture.
The real need of architecture comes when you have a codebase shared among tens or hundreds of people, and you don't want them to convert the system into a massive blob of chaos as they add features to it.
So, when you are architecting, what you are defining is how the teams will interact with each other.
Because of that, an engineering lead needs to have people skills as well.
You do architect the system. You put forth the standards that others on the team need to follow.
While I do agree with you that you need to have people skills, the system absolutely needs to be architected. There needs to be someone at the head approving and disapproving. This ensures congruence across the entire application.
I am not saying that you have to be a dick to be an architect. You just have to know how to make one hell of an application. You have to ensure its consistency or its ultimate demise.
What I mean is that any software architecture needs to be humans-first rather than technology-first.
Some programmers choose architectures because they look cool from a technology point of view, and they fail to understand the human component this technology is trying to solve.
The first thing that needs to be architected is always your teams and, then, find the best technological solution that fits those teams.
But that means that, as an architect, you need to be managing other people.
I agree whole heartedly. There are always two sides to every coin. I think that in the long run you will always have the human element to deal with.
This is not a bad thing. Like I said my teammates are amazing and I love them. I just don't want the responsibility of being in charge of them. There are amazing people out there who do just that. I don't think that I am one of them.
At my last company there were two advancement routes for engineers, one leading to CTO and the other to Enterprise Architect. The CTO was a people manager. The EA was a programmer on critical systems who didn't have to do any people managing, but people often went to him for advice on big important questions. Sounds like the perfect role for you.
That's 90% me ❤️. Except the part that I don't mind watching other people code. Maybe it's the places I've worked for but managerial position always had too much bureaucracy
So I don't mind watching others code. The thing that I don't want to do is babysit others as they code. I want to be able to do a solid code review, know that what they added is tested, add my comments and be on my way.
I really like watching other people code, I learn a hell of a lot by doing so.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Oh man! You know how to kill it with these conversations.
No! I don't want to be promoted. I don't want the added responsibility of watching others code. However, I did not get this opportunity. I got the promotion. Guess what? It made me grow, and it made me realize that I don't want to be a lead of a team.
I just want to write code. I want to architect systems. I want to write tests.
But then again, I want to share my knowledge with others and help them. So shit. What am I to do?
Technical specialist?
I'm down.
Present at conferences?
That requires courage! And a whole lot more knowledge than I possess!
Love the idea though. Career goals.
Courage can't exist without a little fear. And I'm sure there's tons of conferences or MeetUp groups with shorter timeframes. Don't need to host an hour off the bat.
Or you could find a way to create a hackathon (especially for students) and offer your expertise to get them through issues.
You're a developer, it means you like solving problems. I'm sure you'll reach those goals and plenty you haven't yet thought about.
You don't architect systems. You architect teams. If you are writing code by yourself, then you don't need that much architecture.
The real need of architecture comes when you have a codebase shared among tens or hundreds of people, and you don't want them to convert the system into a massive blob of chaos as they add features to it.
So, when you are architecting, what you are defining is how the teams will interact with each other.
Because of that, an engineering lead needs to have people skills as well.
You do architect the system. You put forth the standards that others on the team need to follow.
While I do agree with you that you need to have people skills, the system absolutely needs to be architected. There needs to be someone at the head approving and disapproving. This ensures congruence across the entire application.
I am not saying that you have to be a dick to be an architect. You just have to know how to make one hell of an application. You have to ensure its consistency or its ultimate demise.
I didn't explain myself well in my last comment.
What I mean is that any software architecture needs to be humans-first rather than technology-first.
Some programmers choose architectures because they look cool from a technology point of view, and they fail to understand the human component this technology is trying to solve.
The first thing that needs to be architected is always your teams and, then, find the best technological solution that fits those teams.
But that means that, as an architect, you need to be managing other people.
Great points!
I agree whole heartedly. There are always two sides to every coin. I think that in the long run you will always have the human element to deal with.
This is not a bad thing. Like I said my teammates are amazing and I love them. I just don't want the responsibility of being in charge of them. There are amazing people out there who do just that. I don't think that I am one of them.
At my last company there were two advancement routes for engineers, one leading to CTO and the other to Enterprise Architect. The CTO was a people manager. The EA was a programmer on critical systems who didn't have to do any people managing, but people often went to him for advice on big important questions. Sounds like the perfect role for you.
Enterprise Architect sounds right up my alley. I have a whole lot to learn to get to that point, but thank you for pointing out a viable direction!
That's 90% me ❤️. Except the part that I don't mind watching other people code. Maybe it's the places I've worked for but managerial position always had too much bureaucracy
So I don't mind watching others code. The thing that I don't want to do is babysit others as they code. I want to be able to do a solid code review, know that what they added is tested, add my comments and be on my way.
I really like watching other people code, I learn a hell of a lot by doing so.