u/Swami218 wrote (the comment Michael replied to):
Ah, I see. I think an important distinction is the scope of the work vs the level of the individual components. Certainly even a junior developer writing those test cases should write them well, but it would be defined and guided by their seniors. I believe Codesmith’s view is s
u/michaelnovati replied · · edited ★ FEATURED
+1, agree on a lot here.
I do actually agree that the scope of the products could be mid-level and senior, the only missing piece is the SCALE - building a product for a larger number of actual users is important in being a mid-level and senior. Building a tool that solves a vague problem is an important part - actually working through benign day to day problems actual users have and prioritizing and making judgement calls along the way is a missing piece that's just hard to get anywhere. Even the most successful and long running OSPs don't have any real usage I can find (e.g. ReacType is a headliner that as far as I can tell no one uses, and no one seems to care about the security issue I reported that lets anyone wipe out their marketplace thing, and clearly no one is using that feature anyways)
But yeah agreed on scope actually haha.
"storytelling" to me is where the strategy part goes off track - people I have interviewed come across that they spent more time practicing how to talk about the unit tests they added than they actually spent adding the unit tests Quite frankly, this is a good strategy for quickly getting a job, but it actively slows down the process of actually getting the experience needed to be mid-level day to day.
I commented separately but I THINK it comes down to Will's views on capabilities vs skills. If you are 100% you COULD do something, then you don't need to demonstrate you can do it. And I'm built from the Meta philosophy of you have to frickin prove, not just demonstrate, you can do something for 6 months BEFORE getting promoted to that level on paper.