Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)KE
Posts
4
Comments
26
Joined
3 yr. ago

  • Cloud, and really any vendor specific stuff, is tough to keep up with both in terms of learning and creating training materials. You're better off getting it straight from amazon, google or other practitioners. See if you can find some smaller conferences in your area, and if you can spend training budget on that.

    Obviously $200 isn't much, but coursera might be a better bang for your buck than some other systems. Learning core skills will help you level up, while a lot of Udemy and similar content will just keep you on the same track you would have been on.

  • All of these things are less serious problems if things move faster. QA review of the master branch is the only thing you're doing that has to be long running and synchronous.

    For your acknowledged problems:

    1. This is huge, and should be a focus for you.
    2. This isn't actually a big deal. Outside of fixing bad prod deploys, reversion causes more problems than it solves. If you get the devs out of QA, the need for this will decrease.
    3. If you freeze the code on tuesday and release on thursday, that sounds like a schedule!

    It sounds like the QA department is overwhelmed. You need more test automation in order get the turnaround for regression testing down. Many end to end test tools have recording functions - a senior QA or engineer in test could quickly get simple but brittle automation in place.

    Devs need to understand that QA stopping the line is a last resort, not a personal safety net. More unit and integration testing will keep more of the work on the devs until it actually is ready.

    What does your source control and CICD situation look like?

  • The overview is good, and the outline is good, but ultimately the problem is that the returns on big investments in DX are only really seen for companies at absolutely massive scale. There are far more companies that just burned through money getting a "nice" dev environment than there are companies that put a FTE or more into DX and saw worthwhile results.

    It's worth some time for teams to think critically about their own tooling, but the trend towards DX as an end in and of itself has been a drag on many teams.

  • This is it. From another angle, setting clear boundaries on your time, delegating and trusting your team, and managing expectations are all powerful skills that need to be developed from the senior level and up. Clearly knowing and articulating your limits can lead to working on more valuable and meaningful work within those limits.

  • Job hopping at a fixed time is silly. Don't leave a situation where you're growing, getting new opportunities and doing interesting work because generalized advice on the internet told you to. Leave when you're not happy, not growing, and not getting paid what you're worth.

    The timing right now isn't great either - the market is flooded with recent layoffs, and companies are trying to pick them up at a discount.