[mym1990]

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.

[necrotic_comp]

> 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.

[tobestobestobes]

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.

[axus]

Over-extending yourself can lead to burnout. Pacing yourself and not becoming a problem is good for both the employer and employee.

[mym1990]

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.

[hollerith]

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.

[nsvd]

Realistically, whoever manages you will take credit for the additional productivity and leverage it to get more money for themselves.

[mym1990]

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.

[hsavit1]

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

[BurningFrog]

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 :)

[mym1990]

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.

[willtemperley]

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

I wish I could find the leaked document.

[1] https://www.vox.com/technology/2023/6/21/23768370/cancel-ama...

[willtemperley]

Downvotes without comment, how brave you are

[arresin]

Isn’t after too late though?

[BurningFrog]

It's really hard to design code before it exists!

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!

[reverius42]

Wish I could upvote more.

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.

[qohen]

Or, as Fred Brooks wrote in "The Mythical Man Month" (1976): "plan to throw one away; you will, anyhow."[0]

[0] https://en.wikiquote.org/wiki/Fred_Brooks

[1] https://wiki.c2.com/?PlanToThrowOneAway

[arresin]

That’s great if you have the time for it but a bit impractical to write, architect, then refactor.

[katze77]

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.

[BurningFrog]

How have I never heard that?

Knuth continues to retroactively impress me!

[mym1990]

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.

[johanneskanybal]

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.

[casper14]

Ive had the luck of recently having effort rewarded with fair raises. But can see how most companies won't do that