A dev's thoughts on developer productivity (2022)(sourcegraph.com) |
A dev's thoughts on developer productivity (2022)(sourcegraph.com) |
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.
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.
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:
Having that arbitrary deadline of a sprint helps to synchronize people. Because there will always be that one change that is released but not touched by QA or we need some business analyst to review feature on test server to make sure we did right thing.
Keeping code in testable state and somewhat clean state is easy like I mentioned linters, code formatting automatically. Keeping system changes as in frontend/ backend / third party services aligned is not because it is not something you can just write in one place in code.
But if you're going a different, more self-starter focused path, income opportunities should be increased, yes.
> Somewhat confusingly, some companies use Tech Lead as a title, and others use it as a role. In this list of archetypes, the Tech Lead is one approach to operating as a Staff engineer, but it's quite common to perform the Tech Lead role without having the impact expected of a Staff-level engineer.
My point is a bit 'bigger' than how do you operate in your position as staff engineer and what does the org need from you, what I'm getting at is about the structure of roles themselves - like it can be that your technical track/ladder (junior/mid/senior/staff/distinguished/principal/fellow/whatever) is IC that managers are completely separate, not the same people (junior/mid/senior/whatever managers). It can also be that people managers are separate, but technical management of projects is intertwined with the more senior roles.
What I was thinking about specifically, not knowing really whether anyone does this or not, was the possibility of people being on at least one of those tracks, i.e. maybe both, but that they're distinct roles. So you might be a staff engineer but a more junior manager. (And you might manage a different team than you work in, I suppose, but that would probably be inconvenient and anyway isn't really important one way or the other here.) But I suppose it also depends how or if you divide technical and people management anyway. I just don't really have the keywords to find much discussing it; your links are good though, thanks, I'll read some more on the site.
Once it's working, you know enormously more than when you started, and all you have to do is refactor the mediocre design you happened to build into something better, without breaking the functionality.
With good test suites and solid refactoring skills, that is actually both very doable and often a lot of fun!
Similarly, I always like to say you should plan to write (at least) two versions/iterations of everything. The first one bottom up, to discover what problem you're solving, and the second top down, once you know the problem.
Knuth continues to retroactively impress me!