Much of that US developer advice I just boosted also applies to those of us in the UK. If I'd known this earlier I probably wouldn't be plotting my escape into DevOps/Sysadmin stuff!
A couple of points I'd add:
* Keep finding the joy in your work. It's easy to get buried in the "not code" stuff and think "this ain't what I signed up for!". This leads down a very dark path...
* Your time at work is valuable. Spend it wisely, and make sure what you say "yes" to is worthwhile
@bobstechsite Thanks for the boosts. I originally specified US developers because, while I've done some foreign travel (including a visit to the UK in 1998) I've only ever worked in the shithole country in which I was born and raised. Law and custom varies by country, and I didn't want to do unnecessary harm.
@jeffcliff I often find as a developer I'll be pulled into meetings I don't need to be in.
For cross-team stuff it probably makes sense for 1 person in a dev team to go and share notes later. For other stuff asking "does this need to be a meeting?" & "do we really need a dial-in for this?" can free up a lot of time
Similarly if people are asking you for paperwork, I can guarantee managers want their devs to prioritise code. If it's raised as an issue, the manager will fix it!
@bobstechsite The 6-9? managers that I had to report to (in 3-6? different companies) had differing ideas on what was important and how to fix it. Paperwork/meetings ratcheted up until it took much of my time. The managers generally prioritized paperwork because it made the other managers demands more transparent and besides; I was used as an example of 'well jeff can document what he's doing during the hours of time that he's at work so we can micromanage him, why can't you, other devs?'
@jeffcliff and I think that's your problem right there.
Corporates are waking up to the fact that "command and control" is not a good way of motivating people or achieving results.
It might be different where you are, but the two companies I've been a dev for (ones' a big ISP, the other's a consultancy) is the focus is on coaching people to make good decisions rather than telling them what to do and grading people based on how much time they waste & paperwork they generate.
@jeffcliff I have now been on several courses where the expectation is you tell people what the objective is, but not how to do it.
You can suggest options, but the idea is meant to be that people feel empowered to make sensible decisions.
That being said, there are limits. Corporate policies and budget approvals aren't going away any time soon! 🤦♂️
@jeffcliff plus, I've seen plenty of examples of people using point estimates as a stick to beat developers with when they don't match the previous sprint.
So, there's always going to be room for improvement.
I've yet to work anyway that does "true" agile. Usually it's a bastardised form of whatever methodology they used before, but with SCRUMs 😂