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.
I think that things like Agile are not an accurate model of problem solving and that making good software requires 'extending yourself outside', especially w agile or other modern management systems like many of us are working within. That is my experience. The actual effort is much more to make decent software that works and 'ticketing' makes it easy for devs to disown their own bad or incomplete work when it's convenient and can be disguised as working within scope. This bad work is then passed onto other devs (and the users) and/or converted to technical debt (oh look at all these bug tickets!)... When arguably the real and complete problem at hand was ignored because it was 'out of scope'. There is a 'shadow world' of work that exists outside of ticketing but is required to actually build the software. If you're not involved in that shadow work, then you may be a part of the problem. Problem solving is fluid and technical requirements and matters of approach aren't always readily available at 'groom time'. Work as a group, get uncomfortable if required, and don't go disappear with your ticket for two weeks and half solve a problem and bake the e2e tests. Most development work truly comes to a conclusion in a war room after the ticket is closed and with none of the original devs -- too much of the time these days. Reward devs for taking on more and owning parts of the codebase. AI threatens dev jobs because devs and scrum masters water down work and the system encourages shoddy, transactional work. Not really a criticism of the above comment ... But something I see a lot in enterprise software development. And I also do realize going outside of scope is risky and doesn't pay in the current management zeitgeist.
Another thing to mention is that if you find a way to do 8 hours of work in 4, almost no company will just let you take the other 4 for yourself, unless you do so quietly, so you have just created more work for yourself by becoming more productive.
Sure, but if you really did find a way to double your productivity, you can probably find a way to translate that into significantly higher income although probably not right away.
This is probably true, but if we are talking about climbing the corporate ladder here...that is primarily done through peacocking to management and networking well enough to get to the next rung, not through being very productive. If you are a 10x employee, why would a company want to elevate you out of that and into management?
But if you're going a different, more self-starter focused path, income opportunities should be increased, yes.
yep, companies thrive when they can steal as much surplus labor value as possible. you don't have to give them anything more that what you agreed to give them
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 :)
There have been no CTOs at the companies you have been working at? I would think that in small companies the architect duties fall to the CTO. Obviously things vary though...if you have never had an architect, I think you are the architect hehe. No one builds a house by feeling it out one step at a time.
I suspect software architects are useful when building user-hostile experiences like Amazon prime cancellation, aka Iliad flow [1]. Portioning out the work would keep as few people in the know as possible whilst reducing the risk of offending individual developer's morals.
$productivity = amount scammed out of customers - developer cost
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.
That is actually how Donald Knuth describes it in The Art of Computer Programming. The first program is merely written to understand the problem domain.
I feel like architecture has almost nothing to do with the low level task of coding, and more to do with organizing the order of operations which stem from the business level requirements, and identifying the services that will be used. Architecture is also useful for documenting how things work in a system, and then passing that understanding to anyone that is interested in the future.
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.
IMO it should be 'fix anything when you feel like it.'
"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
Problem is you want to have changes going through process. It has to go through other devs, it has to go through QA, if its user affecting it has to go through business. Yeah like we have linters and auto formatting so no one is arguing on that in my team. We don’t have superficial fix anything, people fix stuff that can affect users but as they work with system they notice improvements.
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.
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.
From my limited experience, Staff+ seems to have a lot of the same responsibilities as a manager, but without the direct reports—they're both “leadership” positions and focus on long(er)-term planning, business needs, cross-team communication, and enabling others rather than doing the work themselves. Though in lieu of people management, Staff+ engineers do get to spend some time coding, but it's pretty rarely the majority of their job.
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.
It depends on the team, the projects, the phase of the projects and the weather forecast. To me this "staff" stuff just means doing more of whatever it takes while making sure the other engineers learn and grow, not doing everything yourself just because you're able to.
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.
I think this from your second link is closest to what I'm getting at:
> 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.
Google has a title called TLM which is tech lead + manager which is meant to straddle the divide. In practice you have twice the expectations which are themselves conflicting with only the one salary. It is often used for ICs to try out management before making the decision which ladder to stay on. Most TLMs are at the staff level so kind of fits that staff engineer who is a junior manager that you describe.
Yeah I see that now on the site you linked, as well as in his book I think & Tanya Reilly's 'The SE Path' linked from its intro (that's all I can read before it arrives). Both seem helpful texts (I've ordered & have access to ebook resp.) so really appreciate the link, thanks.
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 =)
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.