DEV Community

loading...

Discussion on: Anarchitecture

risavkarna profile image
Risav Author • Edited

The goal of a good manager is to "remove" the need of themselves through training independent, productive and powerful team members.

Amen to that. Even a good developer should aim to make oneself obsolete although you may only get asymptotically closer to that goal currently.

I often cite the example of the movie Armageddon where they chose to train miners into becoming astronauts rather than choosing to train astronauts to learn the parts of mining necessary for their asteroid problem. I would love to see the industry shift towards training developers to be managers instead of certifying managers for technical project management.

I am still chuckling as my friend just shared his piece of misery to me after reading this article:

Developer: "This is out of the scope for this sprint. It will take extra resources. We cannot manage it now."

Project Manager: "I just feel like I should learn how to program and just show you; you can do it over night."

This was overheard at a prestigious company that my former roommate quit after 6 months so as to not let his PhD go to waste.

Thread Thread
diakula profile image
diakula • Edited

Good move, that guy, he apparently knows where his career needs to go, commendable on not taking shit too long!

What is funny, is that both roles can be right, from my personal experience on both sides of the trenches.

The project manager comes off as disrespectful in the end.

The developer is probably OK.

Having mentioned academic background, there is one note I want to make.

It is very demotivating to live as a developer knowing that you always have to make compromises with designs to make money and meet project timelines.

There is a positive way to rephrase this that is very very powerful:

  • "Find the right problem definition!"

A good developer with an academic background knows what is the BEST possible theoretical solution 90% of the time. This is what they are solving. Subconsciously, everything they solve is measured by that, and hence the satisfaction level is correlated by the size of compromise.

This is not good way to live.

What is important to understand when in business, is that the realistic problem rarely is academic. You can be in business with a half baked awkward and expensive to run legacy monster service for 20 yrs. But it is beautifully reigning in money, until the competition comes.

Therefore, the developer requires a lot of respect, but also training in pragmatic problem description. A dev has to wire up their internal reward system to always giving 100% to what is necessary for the problem at hand.

Identifying the right problem to be 100% no compromise on the spot is the art form.

Some call it scope, but there is psychology behind it too which if not aligned, is massively demotivating.

Thread Thread
risavkarna profile image
Risav Author

Well said regarding problem definition. I happen to have a similar but a bit of an extreme opinion on this, pieced together here:

"Businesses, [also clients or managers] can still partner with software teams in an agile way to properly define the problems and agree upon the desired features for any possible solution that may emerge in the solution space after enough iterations [but nothing more...]
Otherwise we would be in the business of building the fabled horse carriages of customer's dreams when we could be building them cars or even star ships that the customers do not yet know about."

Thread Thread
diakula profile image
diakula

Indeed! Building a team that draws motivation and satisfaction of delivering iterativelly is the challenge. It is the essence of realizing what developer profession means.