3 ms·

I've had two dev jobs in my career that wound up being very different than advertised, the best I can tell is that companies will say pretty much whatever you w

I've had two dev jobs in my career that wound up being very different than advertised, the best I can tell is that companies will say pretty much whatever you want to hear as a candidate, but when it comes time to solidify a product roadmap, you have to be flexible. In one case, I was hired as a back end services engineer and wound up working almost exclusively on a React SPA. In another case, I was also hired on as a back end services engineer and my team was asked to take over development of a native mobile app even though only one out of my four teammates had any iOS experience (I had none). It took our team two months to ship anything meaningful (a talented mobile team could've knocked it out in a sprint) and then it was immediately back to web work. In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies).

hysan 5y ago
> In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies). This is something I’m dealing with in my current job. I would love to hear how people have been successful at conveying this to leadership.
- thr0wawayf00 5y ago
  I started asking my boss to commit me to 6 months on a new stack if that's what they really needed me to do, making the argument that it takes at least a month to really become productive and several more to internalize the concepts. He understood and agreed that the constant context switching didn't make much sense because it slowed us down, but he couldn't make any promises. Things didn't change and I left a few months later when I got a better offer.
- rkeene2 5y ago
  In the past I've explained this as a comparison of Costs and Outcomes. The total cost of the plan, and the outcomes (mostly as benefits). In the GP's example it could have been, for example, the cost in time for the existing to develop the iOS application, the opportunity cost that's being given up by causing schedule slippages, and the discretionary effort of staff based on doing unfavorable work for the benefits of reducing management complexity, upskilling existing staff, and gaining a wider variety of experience within the team. Alternatives such as using a supplier to build the iOS have their own costs and outcomes. For example, cost in terms of capital dollars, a technical person still needs to invest time in finding the correct supplier, a technical person still needs to invest time into creating the specification to build upon (even if you find a supplier which can do agile and incremental delivery/iteration), and management overhead for managing the team and/or relationship with the supplier. Further, since the product is something that needs to be maintained (presumably), a maintenance plan of some sort will need to be put into place, and for the benefit of getting it done more quickly, a better product by developers interested and competent in the domain the total cost will likely be lower, and other projects will slip less. There's also the advantage that if management has to put in capital dollars then they are more likely to take the project seriously and fund its maintenance and reward those involved, especially if that's accounted for up front.
SkyPuncher 5y ago
There's another perspective that might be worth considering - management knew your team would deliver. Specific platform skills are learnable. The ability to ship something isn't always - especially at scale. I'd much rather give a team 3 months to ship something that I'm 99% confident will be delivered than to try it twice with two teams that have an 80% chance of delivery each.
- thr0wawayf00 5y ago
  The problem in that particular case was that the company did this so much with various teams that it caused incredible turnover. We had a great mobile team that slowly left the company because they were being asked to prioritize web work, and when they all left and the company realized that there was mobile work to be done, they started asking us web devs to prioritize mobile. They were getting lots of complaints across the org of never-ending context switching and they didn't really care. I'll ship stuff because it's my job, but I won't stick around for management that can't be bothered to keep their mobile and web teams happy enough to prevent these insane context switches.
Dave3of5 5y ago
> In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies). Interestingly I see this is a few ways: * Every small 15-30 minute call knocks me out for hours. I really need at least one full day a week with minimal meetings and that includes the daily stand-up. I honestly think the daily stand-up costs companies millions per year in productivity cost * Moving from project feature to feature is costly. So if you're working on feature X this sprint and then the PO moves to feature Y in the next sprint due to priorities it'll slow down dev. Doing this often (say every sprint) will kill velocity * Moving from project A to project B is also a big killer for productivity * Moving around tech stacks as you've said it happens occasionally in my experience but when it happens you're often flustered

hysan 5y ago

thr0wawayf00 5y ago
I started asking my boss to commit me to 6 months on a new stack if that's what they really needed me to do, making the argument that it takes at least a month to really become productive and several more to internalize the concepts. He understood and agreed that the constant context switching didn't make much sense because it slowed us down, but he couldn't make any promises. Things didn't change and I left a few months later when I got a better offer.
rkeene2 5y ago
In the past I've explained this as a comparison of Costs and Outcomes. The total cost of the plan, and the outcomes (mostly as benefits). In the GP's example it could have been, for example, the cost in time for the existing to develop the iOS application, the opportunity cost that's being given up by causing schedule slippages, and the discretionary effort of staff based on doing unfavorable work for the benefits of reducing management complexity, upskilling existing staff, and gaining a wider variety of experience within the team. Alternatives such as using a supplier to build the iOS have their own costs and outcomes. For example, cost in terms of capital dollars, a technical person still needs to invest time in finding the correct supplier, a technical person still needs to invest time into creating the specification to build upon (even if you find a supplier which can do agile and incremental delivery/iteration), and management overhead for managing the team and/or relationship with the supplier. Further, since the product is something that needs to be maintained (presumably), a maintenance plan of some sort will need to be put into place, and for the benefit of getting it done more quickly, a better product by developers interested and competent in the domain the total cost will likely be lower, and other projects will slip less. There's also the advantage that if management has to put in capital dollars then they are more likely to take the project seriously and fund its maintenance and reward those involved, especially if that's accounted for up front.

SkyPuncher 5y ago

There's another perspective that might be worth considering - management knew your team would deliver. Specific platform skills are learnable. The ability to ship something isn't always - especially at scale. I'd much rather give a team 3 months to ship something that I'm 99% confident will be delivered than to try it twice with two teams that have an 80% chance of delivery each.

thr0wawayf00 5y ago
The problem in that particular case was that the company did this so much with various teams that it caused incredible turnover. We had a great mobile team that slowly left the company because they were being asked to prioritize web work, and when they all left and the company realized that there was mobile work to be done, they started asking us web devs to prioritize mobile. They were getting lots of complaints across the org of never-ending context switching and they didn't really care. I'll ship stuff because it's my job, but I won't stick around for management that can't be bothered to keep their mobile and web teams happy enough to prevent these insane context switches.

Dave3of5 5y ago

> In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies). Interestingly I see this is a few ways: * Every small 15-30 minute call knocks me out for hours. I really need at least one full day a week with minimal meetings and that includes the daily stand-up. I honestly think the daily stand-up costs companies millions per year in productivity cost * Moving from project feature to feature is costly. So if you're working on feature X this sprint and then the PO moves to feature Y in the next sprint due to priorities it'll slow down dev. Doing this often (say every sprint) will kill velocity * Moving from project A to project B is also a big killer for productivity * Moving around tech stacks as you've said it happens occasionally in my experience but when it happens you're often flustered