I feel like I have reached a happy point of productivity where I am doing the work expected of me, and at times even exceeding, but not breaking my metaphorical back. The truth is that most companies won't pay for the extra productivity that you create for yourself, but they will happily take it for free.
Fantastic way of putting it. Know this is a low-effort comment, but that's a great way to describe why over-extending yourself outside of the context of the overall mission isn't a good thing to do.
I almost only work in small companies, and in and near the agile world.
What I've learned is that while architecture is very important, it's best done after the code is written. It's hard to convince anyone of this who hasn't experienced it :)
$productivity = amount scammed out of customers - developer cost
I wish I could find the leaked document.
[1] https://www.vox.com/technology/2023/6/21/23768370/cancel-ama...
That's like conflating a practising doctor with a medical student.
And it skips past so much of the raw joy & auto-enrichment loops that happens when there's time allotted to discovering and improving the system as you go. DIYers have such amazing enrichment loops, making systems work better for themselves all the time. Not just the much vaunted fast delivery now, but the ability to keep iterating & expanding & delivering without your constructs starting to clash & thrash.
I love love Fogus's 100:10:1, on having many tangible places outlined where one might do something. Still dedicating yourself to something, but also giving yourself permission to hop around. Follow what feels good. https://blog.fogus.me/2015/11/04/the-100101-method-my-approa...
[Ed: s/yolk/yoke/, thanks for the fix folks!]
"Sprints" have given agile a bad name (to the extent it has a bad name, as in gp's complaint). The point is to optimize for changes, as they're inevitable, by: 1. Keep the code in a 'clean' (testable, free from cruft, etc) state continuously 2. Release continuously 3. Embrace YAGNI
If short, regular sprints help with those things, use them. But sometimes they don't
EDIT: but also and more importantly, your point is Excellent! 100% agreed - the ongoing process of discovery and continuous improvement of a codebase are signs of the best kinds of ownership / attachment, and sadly represents a huge blind spot and missed opportunity for the majority of "dayjob" projects.
This work needs to be done but it doesn’t leave me much time to get into coding things and thus I would score very low on that productivity measure because I’m hardly ever in the inner loop.
Bit of a tangent, but I'm just curious if that's that some staffs (but not all) and above are leads, or if it's that engineering & management tracks are orthogonal but not mutually exclusive?
I was attempted to idly discuss/suggest the latter was a possibility recently (not in a position to effect it), and I'm not sure I made my point very effectively or coherently. If that is the case where you work, are you aware of any sort of name for that or keyword? Hard sort of thing to search for otherwise.
So to that extent, I think there's quite a lot in common between engineering and management tracks after a certain point, both because there's a genuine need for that, and because direct code contributions just don't scale in the same way that helping others does.
Sometimes it means plowing into code and implementing stuff, because that's the main thrust at the time and where the most effort needs to be focused. Sometimes it means backing away and researching problems at a high level to save others from having to get out of focus.
Whether that's team leading or engineering or managering is a moot point to me.
https://staffeng.com/guides/what-do-staff-engineers-actually...
https://staffeng.com/guides/staff-archetypes/
I think it all depends on who you are and what your team needs.
In my experience, lead ==> doing stuff to keep everyone else in "flow" or "not going off-piste".
Sounds like you're doing a decent job of it :+1:
Some of the issue, in my own admittedly limited experience, is that some "important" folks often want the flashy ideas; they want someone to tell them there's a quick fix or a framework to solve the problem in 3x workshops over two weeks. It's unfortunately human nature to want the easiest solution. edit -- plus i think a lot comes down to fear (no control), which is also a thing.
Managers also like metrics. It makes their end of month presentations look good. Which is important otherwise the team gets looked down on compared to all the other managers with amazing metrics.
But, I could totally see something like this working well at smaller companies where stuff like that isn't a thing.
A dev's thoughts on developer productivity - https://news.ycombinator.com/item?id=31414681 - May 2022 (88 comments)
When working on a team, splitting up work across modules/contexts/domains works well. I’ll give you an API you tell me what works well, what you still need from it, what errors there are; I’ll address them.
Nothing works better than trust and autonomy. I don’t tell you how to do your job, you don’t tell me how to do mine. You want me on the team because of my expertise and some of my values overlap with everyone else’s.
When working alongside non-technical folks, communication and trust is key.
Trying to quantify developer productivity and sell a system is what the snake-oil hucksters have been selling since the 90s. Management consultants, process engineers, whatever you want to call them. They’re selling something.
We’re knowledge workers. We’re not manufacturing cars or widgets. We learn. We design. We think. Our output is knowledge, not widgets.
> Communication and trust is key.
> We learn. We design. We think. Our output is knowledge, not widgets.
That's a manifesto I would sign! But let's not make it into one, because back then the originally-similarly-spirited Agile Manifesto couldn't immunize itself against "adoption" by — management consultants, process engineers, whatever you want to call them =)
Automate and shift left.
