Week 2: Junior to Intermediate Dev

What is this series?

I've been a developer for 2 years but my learning lacked focus. With this series, I want to look back at what I've done for 6 months to move towards being an intermediate developer.

TLDR

1. reflecting on week Friday afternoon was really helpful. I read through my conversations in Slack to see how inefficient I was at owning a project
2. TODOs before next week. Use github as a metric for how much code I'm pushing.

Reflection on owning my last project

Owning the project

1. Get stakeholders on a call to understand the impact of the project. Throw out all assumptions and start from scratch.
2. Find Subject Matter Experts (SMEs)
3. Check-in with Product Manager for prioritization
4. Get metrics to justify the project

For step 1, I didn't realize that the stakeholders hadn't made much effort to address the issue on their own. They said the project was valuable but their actions said otherwise.

Designing a solution

1. writing a design doc revealed gaps in my high level understanding of the issue
2. brainstorm with a group
3. again "start from scratch" mentality
4. TLDRs are welcome in any documentation

Mental frameworks

Starters | Finishers | Optimizers

1. Starters get dopamine hits from new ideas, finding problems to solve.
2. Finishers get dopamine hits from well defined to-do lists.
3. Optimizers get dopamine hits from dragging projects beyond scope to "perfection"

Evaluate which one you are. Try to use it to your advantage when you can (ie - starters can help product managers find meaningful work for a team). Keep the framework top of mind to notice when you'd benefit from playing another role.

Skill development isn't linear

Skill development is logarithmic. To motivate ourselves, we can use small tasks to make the learning curve feel steep in the short term. However in the long term, I'd imagine its wise to notice when you're in the tail end of your learning curve so that you can jump to an entirely new skill.

First heard of this in James Clear's newsletter but I found it again here

I don't agree with the faster growth in this diagram, but I agree you can disguise a large logarithmic curve as many small wins. The inaccuracy in the diagram comes from the steepness of the smaller growths when time is large. Smaller tasks don't give much growth to an expert in comparison to their total knowledge, hence why this is a logarithmic growth curve in the first place.