My couple of thoughts, just based on my own experiences, are that: there is typically at least one architect above me(currently two, don't ask me why) that is responsible in doing the higher level solutioning. While I am free to give feedback on things, and that feedback is taken seriously, it is a far cry from developing my own architecture. On a big enough project, there simply isn't enough time to gather requirements, architect the solution, and then build it out(for one person). By the time I am assigned the feature ticket, it is a morsel of the overall thing.
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.
> 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.
Funny. I've programmed professionally since 1984, and have never really had an "architect" in the organization.
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 :)
I haven't had the pleasure in 20 years to work with an architect that added much of value, corporate structure and putting people in boxes is such a strange thing to me in software, if you work with senior people they should be able to drive and decide most anything with maybe a thin layer of general direction on top.
This from Beyang Liu, Sourcegraph CTO, who plays up his stint as a Google intern to represent himself as a "former google engineer", and wrote this blog referencing Google 55x in a short article to associate sourcegraph with Google-quality tooling: https://sourcegraph.com/blog/ex-googler-guide-dev-tools
Devs I think are somewhat withdrawn, as a result of being under the yoke of ticket delivery. Being given the trust respect & capacity to roam & improve as we wander about systems is rare; we're judged on how quickly the task at hand is done. This is such Luddite, chained-to-the-machine endpoint that we are at.
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...
That is why I promote FaF - fix anything Friday and try to fight off sprint load inflation, where it would be expected from team to do more and more. Then also promote “dev alignment” where devs come together to discuss architecture improvements or pick approaches.
yolk (yellow part of egg) -> yoke (harness for beasts of burden)
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.
As a staff engineer with team lead responsibilities I would love to be able to attain that kind of flow. Unfortunately, a lot of my job is liaising with product managers and making sure the team is focused on the right things or writing and reviewing documents.
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.
This really resonates and tracks with my experience. Really like the vector sum concept, as most metrics for productivity tend to be pretty naff (not good).
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.
The only thing that works well for me is: thinking hard (ie: writing some definitions, asking questions, editing, repeat) and then writing some code. Then repeat.
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.
> 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 =)
mym1990|1 year ago
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.
necrotic_comp|1 year ago
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.
BurningFrog|1 year ago
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 :)
johanneskanybal|1 year ago
casper14|1 year ago
golly_ned|1 year ago
itsdrewmiller|1 year ago
jauntywundrkind|1 year ago
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!]
ozim|1 year ago
chrisweekly|1 year ago
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.
elevatedastalt|1 year ago
badgersnake|1 year ago
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.
OJFord|1 year ago
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.
dijksterhuis|1 year ago
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:
dijksterhuis|1 year ago
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.
m0llusk|1 year ago
dang|1 year ago
A dev's thoughts on developer productivity - https://news.ycombinator.com/item?id=31414681 - May 2022 (88 comments)
itsdrewmiller|1 year ago
agentultra|1 year ago
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.
dualogy|1 year ago
> 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 =)
from-nibly|1 year ago
Automate and shift left.
matt3210|1 year ago
unknown|1 year ago
[deleted]