northofnormal/gist:3156b3255ed55e9b3f6690a8bfad6ca5

## gistfile1.txt

Q1: "Releasing the suck" requires confidence and belief in yourself. How can we start speaking and acting with confidence...when we don't have that confidence yet?

* There’s a grey zone to “release the suck.” It needs to start as you a junior, easing your way in. Organizations need to allow space for juniors to do that and show that growth.
* “Fake it ‘till you make it” is a thing, to just start pretending you can do it until other people believe it, and then you believe it
* Requires you to show some vulnerability and get into the larger community
* Volunteer for new opportunities, get out of your comfort zone—even a little bit. Bonus if there’s a way to do that while maintaining some comfortability or “safety.”
* “I don’t WANT to, but I should, for the sake of my career”
* Junior devs are expected to fail. The difference between junior and mid-level devs is the level of support they will need.

Q2: "Driving Through Ohio" is tough--how can we recognize that progress is being made when we feel stuck? How can we tell the difference between being **actually** stuck (i.e. in a bad or unhealthy workplace) and slow but steady progress?
* Are you learning new things?
* Not just new technologies or new tools—are you communication skills improving, are your team skills growing as well?
* Check in with others—your team, your leads, your managers. What are they seeing from you?
* Set objectives that you can measure yourself against and have the conversation regularly about how you are doing against them.
* Team leads can keep an eye on team dynamics: who is asking questions, and who is answering them? How does that evolve? Do the question-askers become question-answerers?
* Keep a success log! And make time every week to update it with what you accomplished or are proud of this week.
* Have a “bragging Friday” session or slack/hipchat channel where you and your colleagues can brag about every small or large thing you are proud of this week!

Participant Question: Regarding “driving through Ohio”, does what and how we are measuring change from junior to mid-level?
* A junior needs to know the one way to write an `if` statement, and can advance relatively quickly.
* The process from mid-level to senior takes much longer.
* There’s stress associated with working in an Agile environment, in that nothing is ever “done”
* This is where the knowledge sharing and community leadership aspects of become more important
* The moving target nature of tech can be frustrating, there’s always new things to learn and it limits your ability to build a foundation
* Do we, as an industry, measuring the wrong things? Is it too much focus on technical knowledge (knowing all the frameworks) and not enough on team skills?

Q3: Can everyone be a "senior" developer? Should that always be the end goal of career growth?
* There’s a people route and a technology leadership route but both use the same problem-solving skills. How and why we do things, either in code or in process.
* Maybe your personality isn’t geared towards “tech lead”
* There’s a difference between “Engineering Manager” and “Tech Lead” but both move you away from touching code regularly
* Senior Developer-ness isn’t management, it’s good judgment and the ability to make technical decisions
* Is “senior developer” a universal state, or is it contextual? Can you be “senior” in one domain but not when you move into another? Is it a static state?
* Randall Koutnik’s talk on “Implementers, Solvers, and Finders” : [Rethinking the Developer Career Path – Randall Koutnik | The Lead Developer UK 2017 - YouTube](https://youtu.be/yIPbE7BssOs)
* In a new context, the problem finders will still find the problems
* [Price’s Law](https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price):  Half the work comes from a square root of all participants. Knowing where you are at in that distribution is indicative of your “level”
* Decouple your output from your seniority—focus on others, not on yourself
* As long as you are focusing on your own output, you are remaining a very good mid-level developer, not making it to senior status. Not everyone can get there.

	Q1: "Releasing the suck" requires confidence and belief in yourself. How can we start speaking and acting with confidence...when we don't have that confidence yet?

	* There’s a grey zone to “release the suck.” It needs to start as you a junior, easing your way in. Organizations need to allow space for juniors to do that and show that growth.
	* “Fake it ‘till you make it” is a thing, to just start pretending you can do it until other people believe it, and then you believe it
	* Requires you to show some vulnerability and get into the larger community
	* Volunteer for new opportunities, get out of your comfort zone—even a little bit. Bonus if there’s a way to do that while maintaining some comfortability or “safety.”
	* “I don’t WANT to, but I should, for the sake of my career”
	* Junior devs are expected to fail. The difference between junior and mid-level devs is the level of support they will need.

	Q2: "Driving Through Ohio" is tough--how can we recognize that progress is being made when we feel stuck? How can we tell the difference between being actually stuck (i.e. in a bad or unhealthy workplace) and slow but steady progress?
	* Are you learning new things?
	* Not just new technologies or new tools—are you communication skills improving, are your team skills growing as well?
	* Check in with others—your team, your leads, your managers. What are they seeing from you?
	* Set objectives that you can measure yourself against and have the conversation regularly about how you are doing against them.
	* Team leads can keep an eye on team dynamics: who is asking questions, and who is answering them? How does that evolve? Do the question-askers become question-answerers?
	* Keep a success log! And make time every week to update it with what you accomplished or are proud of this week.
	* Have a “bragging Friday” session or slack/hipchat channel where you and your colleagues can brag about every small or large thing you are proud of this week!

	Participant Question: Regarding “driving through Ohio”, does what and how we are measuring change from junior to mid-level?
	* A junior needs to know the one way to write an `if` statement, and can advance relatively quickly.
	* The process from mid-level to senior takes much longer.
	* There’s stress associated with working in an Agile environment, in that nothing is ever “done”
	* This is where the knowledge sharing and community leadership aspects of become more important
	* The moving target nature of tech can be frustrating, there’s always new things to learn and it limits your ability to build a foundation
	* Do we, as an industry, measuring the wrong things? Is it too much focus on technical knowledge (knowing all the frameworks) and not enough on team skills?

	Q3: Can everyone be a "senior" developer? Should that always be the end goal of career growth?
	* There’s a people route and a technology leadership route but both use the same problem-solving skills. How and why we do things, either in code or in process.
	* Maybe your personality isn’t geared towards “tech lead”
	* There’s a difference between “Engineering Manager” and “Tech Lead” but both move you away from touching code regularly
	* Senior Developer-ness isn’t management, it’s good judgment and the ability to make technical decisions
	* Is “senior developer” a universal state, or is it contextual? Can you be “senior” in one domain but not when you move into another? Is it a static state?
	* Randall Koutnik’s talk on “Implementers, Solvers, and Finders” : [Rethinking the Developer Career Path – Randall Koutnik \| The Lead Developer UK 2017 - YouTube](https://youtu.be/yIPbE7BssOs)
	* In a new context, the problem finders will still find the problems
	* [Price’s Law](https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price): Half the work comes from a square root of all participants. Knowing where you are at in that distribution is indicative of your “level”
	* Decouple your output from your seniority—focus on others, not on yourself
	* As long as you are focusing on your own output, you are remaining a very good mid-level developer, not making it to senior status. Not everyone can get there.