Skip to content

Latest commit

 

History

History
65 lines (43 loc) · 3.57 KB

rethinking-the-developer-career-path.md

File metadata and controls

65 lines (43 loc) · 3.57 KB
Raw

Rethinking the Developer Career Path

I picked the wrong career. We had a team lunch, none of them planned to stay in the Software Engineering path. The only way to progress in your career is to step into management

Getting into management should be mandatory.

Implementers, Solvers and Finders. Rethinking the developer career path.

What does senior mean?

What people understand

  • Expensive. Consultancy companies offer "senior" positions to charge more to their clients.
  • Bored.
  • Opinionated.
  • From Minnesota. Entry level for people from Minnesota, because they have such a convoluted system.

We don't really know. What people really convey what a senior is it depends on a single thing

  • Years of experience.

What should senior mean?

Metrics

  • Quantifiable. Where we are?
  • Give engineers a way forward. How do we continue?
  • Describe the work we do.

The process

We start with a really big problem. Pej: "When people get back to their homes, how do we make them choose Netflix instead of Amazon Premium, HBO or broadcast TV?"

Then we split that big problem into smaller chunks. Like "How do we make our systems reliable. Improving monitoring, alerting, etc."

We can break the system even further. Like "Building a UI for make people at netflix aware about the alerting, monitoring, etc."

We can still break things down, 'til we get to the code.

The problems are always different. Happy engineers are the ones that get different problems all the time.

Now we can understand the "X years of experience, or the same year of experience repeated X times".

Maybe that's the right career path for engineers:

  1. Solution implementer (insetad of junior)
    • Given solutions. Leads will help them break things and build solutions someone else though. They have to be exposed to many kind of problems from your company.
    • Produces code. Leads will review the code
  2. Problem solver (instead of mid level)
    • Given problems. At the beginning you'll need to provide small problems, increasing complexity. You as a lead will need to start backing off, you need to trust your peers. They are given autonomy incrementally
    • Produces solutions
  3. Problem finder (instead of senior)
    • Given context. Full autonomy. Instead of give them tasks, you provide them context. They will break down problems, and they will participate implementing them.
    • Discovers and prioritises new problems.

You can see these path as a series of steps. Each step the base for the next one.

Where we go wrong?

Anti-patterns

  • Inverted piramid. Like finding problems that you never get to solve, break or implement (Software Architect).
  • Not mentoring implementers. Implementers need help to become problem solvers. You need to mentor juniors, it is your fault they are failing.
  • UI squeeze. Product managers deciding what to do, introducing lots of tickets, handing them all to the designers, then handling them off to UI engineers. Having just implementers, there is no growth for these people. Bring the engineers back to the front. Engineers should have autonomy, Product Managers should provide problems, not solutions. A lot of tech debt will accumulate becuase nobody listened to engineers.
  • Impostor syndrome. Someone is put into a position of seniority or leadership. People start wondering what a senior is. We can solve this by talking about the previous career path.

Problem when companies have silos. Departments not talking to each other. When you break things into problems to be solved, barriers can be broken down. Break down to each level.