16 ms·

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 r

by mym1990 2y ago

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 2y ago
> 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.
- axus 2y ago
  Over-extending yourself can lead to burnout. Pacing yourself and not becoming a problem is good for both the employer and employee.
- tobestobestobes 2y ago
  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.
- hsavit1 2y ago
  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
- mym1990 2y ago
  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 2y ago
    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 2y ago
      Realistically, whoever manages you will take credit for the additional productivity and leverage it to get more money for themselves.
    - mym1990 2y ago
      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.
casper14 2y ago
Ive had the luck of recently having effort rewarded with fair raises. But can see how most companies won't do that
johanneskanybal 2y ago
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.
BurningFrog 2y ago
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 :)
- arresin 2y ago
  Isn’t after too late though?
  - BurningFrog 2y ago
    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 2y ago
      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 2y ago
        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 https://en.wikiquote.org/wiki/Fred_Brooks [1] https://wiki.c2.com/?PlanToThrowOneAway https://wiki.c2.com/?PlanToThrowOneAway
      - arresin 2y ago
        That’s great if you have the time for it but a bit impractical to write, architect, then refactor.

necrotic_comp 2y ago

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

axus 2y ago
Over-extending yourself can lead to burnout. Pacing yourself and not becoming a problem is good for both the employer and employee.
tobestobestobes 2y ago
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.
hsavit1 2y ago
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
mym1990 2y ago
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 2y ago
  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 2y ago
    Realistically, whoever manages you will take credit for the additional productivity and leverage it to get more money for themselves.
  - mym1990 2y ago
    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.

casper14 2y ago

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

johanneskanybal 2y ago

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.

BurningFrog 2y ago

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

arresin 2y ago
Isn’t after too late though?
- BurningFrog 2y ago
  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 2y ago
    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 2y ago
      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 https://en.wikiquote.org/wiki/Fred_Brooks [1] https://wiki.c2.com/?PlanToThrowOneAway https://wiki.c2.com/?PlanToThrowOneAway
    - arresin 2y ago
      That’s great if you have the time for it but a bit impractical to write, architect, then refactor.