| The path as an SE has many roads. I love your post, and I wish I were lucky enough to have had any of that along the path I took. My first dev job came after mid-way through a PHP course in college. Prior to this, I had also completed courses in Java and C++. At $10/hr (boy was I desperate), I was hired on to replace the outgoing fullstack web dev (basically at an email advertisement spamming company). I was supposed to "get up to speed" with my replacement within a couple weeks of being hired. It was unwritten and unspoken, but basically I was to become the ad agency's sole fullstack web developer. At the time, I knew zero front-end and the PHP that I did know was murky (5.x) at best. I had no chance in learning enough to replace the then sole fullstack dev and quit because, I just wasn't ready at the time to absorb front-end web technologies in that short amount of time. Boss warned me that when I give a deadline for a project, it may as well be prophetic - however, I was scared sh1tless giving any kind of projection on any kind of project with me as the sole developer doing things I've never done before; it seemed to me to be absurd. Fast forward a few years, I just couldn't land any programming/web job because my experience didn't line up with what was requested - even when I thought I was around 70%+ qualified. After a while, I got fed up with the esoteric requirements, even for junior positions. It's exhausting reading through countless job listings trying to find something that may fit. So, to this day, I just code for fun - like a locally hosted movie server that I prefer over Plex. Sorry for the ramble. I'm estranged by the industry in regards to hiring for junior positions. |
I'm long past my junior days and this still bugs me. In case it helps anyone else, now I give my estimations with two [low, mid, high] qualifiers next to them:
1. Uncertainty: this is where I signal whether I think the task is well defined and we have the expertise to deal with it or not. The estimation gets a multiplier (however stupid I think the task is) when this is not low, and I make it clear that uncertainty can be reduced by either better defining the task or breaking it into an "exploratory" phase (where we try to come up with a tech-demo to get a better "feel" of that new thing) and then an execution phase that will turn it into a reality (which will be estimated _after_ the exploratory one is done).
2. Environmental risk: this signals how external factors can impact the task (e.g.: the client is complicated to work with, this necessitates collaboration from a third company that may or may not be fluid, we require key people from the team that is busy doing something else, etc.)
I've found that this both reduces my anxiety and tunes the client's expectations much better (it becomes much easier to explain after-the-fact why two tasks that had a similar estimation ended up taking wildly different efforts).