6 ms·

To be fair, unless you're building some low level infrastructural systems, coding is the easiest part, and code is cheap. Drop any senior dev into coding duty,

To be fair, unless you're building some low level infrastructural systems, coding is the easiest part, and code is cheap. Drop any senior dev into coding duty, and their skills return after one to two weeks. On the other hand, asking a junior dev to implement a new system that integrates with 3 other departments, and you'll have to wait two quarters for them just to figure out who to talk to and how to get consensus.

bombolo 3y ago
[flagged]
- MattPalmer1086 3y ago
  Then you have quite limited experience (or you're just going for some snark). Over my career I've seen all kinds of people leave coding. Some of them were poor coders and some of them were excellent. Some of them were good or bad communicators or architects. Out of interest, just who do you think should be doing the high level architecture?
  - bombolo 3y ago
    > Out of interest, just who do you think should be doing the high level architecture? People who will maintain it have more interest in keeping it maintainable, rather than architects that won't actually do any of the work to maintain it, and will not learn from their mistakes.
    - MattPalmer1086 3y ago
      I often see the argument that people who write the code should do the architecture as well. Maybe on a small development effort it can give better alignment. When things scale up and in bigger orgs though, it doesn't work nearly so well. There are so many different business and technical requirements and strategies to take into account and signed off. This is a full time job. It may lead to really annoying things being imposed on the developers that they would never have chosen. However, this does not mean that the architects are idiots, although that is of course possible!
    - piva00 3y ago
      At the company I work for, senior engineers are usually responsible for writing RFCs and getting the involved/dependent parties in the discussion, staff engineers chime in with architectural details the seniors might have missed due to a hyper-localised view of the issue/proposal. This feeds back into seniors understanding of the whole/higher-level architecture, which it's then used to adapt the proposals with the architectural decisions/requirements/constraints. High-level architecture at scale demands a level of knowledge that engineers from a specific team might not have, not due to incompetence but because the scope of the team is bounded and the context is very local, at large enough orgs it's not possible even for senior engineers to keep track of all the weird interactions systems have at a higher level, you need someone whose job is to look at a higher level and validate cohesiveness, someone that knows about other similar work being done across other orgs to see points of cross-pollination, etc. Honestly I can't see how I could depend only on myself and other senior engineers in my team to validate architectures that span cross-org, it'd be exhausting to shift my context all the way up and down architectural layers for every single RFC I write.
  - uztrax 3y ago
    Domain experts, financial or business specialists. I've never seen a competent software architect. They make wild statements, draw some trivial diagrams with impressive sounding words. Then some diligent programmer discovers that none of it works, silently creates the real architecture. Then the "architect" takes credit for the result. The days of Internet RFCs that are carefully written are over. We are in the age of agile self-promotion and B.S. (this also applies to foreign policy, with the same results).
- maeln 3y ago
  Ad hominem. Having senior dev / "architect" focusing on higher level / abstract design and working with junior dev to code it and get it up and running is a very common pattern in big company (especially not tech-first company). And it does work.
  - uztrax 3y ago
    [dead]
  - bombolo 3y ago
    > Ad hominem. No? It applies to anyone having the same opinion.
    - maeln 3y ago
      In truth, it is more a ad personam argument. You are not contributing anything substantial to the debate, you are just attacking dumpster_fire with no other argument than "in my experience".
      - bombolo 3y ago
        I believe that actual experience is superior to logical reasoning with little or no data to support it.
        maeln 3y ago
        The only data you provide is "your experience" which is of little value here considering we don't know the extent of it nor its relevance. If anything, the way you express your opinion so strongly, one would hesitate to think that you have any experience in a big corporation with several teams working on different product and/or part of the same product. The context in which having senior dev focus less on coding and more on reviews, documentation and design is common place.
        bombolo 3y ago
- dumpster_fire 3y ago
  There's a misunderstanding here due to context. Someone working in a startup (been there) will find it difficult to understand just now much communications are required to get anything done in a large MNC. Out of necessity, people who have pushed enough code to understand the systems have to step up to do the comms instead of being siloed. I had many a time freaked out some other team because the phrasing of my email made them think we're going to dump more work on them. This is the actual difficult part about engineering at scale: Getting everyone on the right page. You can opt to keep coding, but it won't get you far in your career. Does this mean the communications have more value than actual implementation? It depends. Again, this value differs at different company sizes. I just got the chance to code again last month, and I've already completed 5 features (code reviewed) that the juniors couldn't complete in a year. I won't say they are worse at coding, but more that I am more familiar with how dependencies work because I've already done the same thing when I was a junior. Also, knowing who to ask for help also helps a lot. I stand by my statement. Code is easy and code is cheap. One day you'll understand.
  - bombolo 3y ago
    > I stand by my statement. Code is easy and code is cheap. One day you'll understand. You don't have people under you that can complete in a year what you can complete in a month, and you're still insisting that anyone and their cat can code? I guess they can code… but evidently not as good?
    - FemmeAndroid 3y ago
      I think you’re overlooking this: > I won't say they are worse at coding, but more that I am more familiar with how dependencies work because I've already done the same thing when I was a junior. Also, knowing who to ask for help also helps a lot. I might phrase this a bit differently, but I think it’s getting at my thoughts as well. I work with developers who would destroy me in a race to implement various search algorithms, or whatever discrete metric of coding prowess you want. What they struggle with is: - Efficiently getting other teams to answer their blocking questions in a way that makes the other team happy to work with them. - Understanding the existing features of our fairly complex stack. - Judging when to ask for help, and who to go to about a particular problem. - Identifying dead ends quickly, and pivoting to alternative solutions at the first sign of trouble. - Incorrect assumptions about the company’s priorities, and how the priorities can help shape the request. I end up in a lot of meetings, but I also occasionally (a couple times a year on average,) take a few weeks and implement a business goal that a team has been stuck at for months/years.
- dang 3y ago
  Please don't cross into personal attack, regardless of how wrong another comment is or you feel it is. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
Donckele 3y ago
[flagged]
- bombolo 3y ago
  > “coding is the easiest part, and code is cheap” Let me translate: "My work is difficult and important. What other people do is easy and a 3yrs old could do it". I'm ready to bet his architecture is bad and the coders deviate all the time to make it work.
  - diegoperini 3y ago
    That's a really bad faith take of that comment. I'd translate it as "in a place where most people are experienced programmers, communication becomes the main bottleneck."
    - dumpster_fire 3y ago
      Clearly I have much more to improve on because you put it way better than I did. My communication skills are terrible.
      - diegoperini 3y ago
        We all have our own battle scars :)
    - bombolo 3y ago
      I'm reading what's written. You're extrapolating. Unfortunately I don't possess long range telepathic abilities, like you seem to have. Ironically, it seems that even if your interpretation (or mind reading) is correct… we have someone that should be facilitating communication that is clearly not good at communicating what they are thinking.
      - diegoperini 3y ago
        I was just guessing but OP provided confirmation to my interpretation.
spacebanana7 3y ago
This depends on the organisation. If an enterprise has well defined interfaces for teams to interact with one another and effective escalation points for conflicts in priorities then communication might be the cheap & easy part. Conversely, small modifications to a messy codebase can be extremely time consuming. Imagine being asked to fix an animation bug on an in house date picker in a large Angular app that hadn't been updated in 5 years.
- deleted 3y ago
  [deleted]

bombolo 3y ago

[flagged]

MattPalmer1086 3y ago
Then you have quite limited experience (or you're just going for some snark). Over my career I've seen all kinds of people leave coding. Some of them were poor coders and some of them were excellent. Some of them were good or bad communicators or architects. Out of interest, just who do you think should be doing the high level architecture?
- bombolo 3y ago
  > Out of interest, just who do you think should be doing the high level architecture? People who will maintain it have more interest in keeping it maintainable, rather than architects that won't actually do any of the work to maintain it, and will not learn from their mistakes.
  - MattPalmer1086 3y ago
    I often see the argument that people who write the code should do the architecture as well. Maybe on a small development effort it can give better alignment. When things scale up and in bigger orgs though, it doesn't work nearly so well. There are so many different business and technical requirements and strategies to take into account and signed off. This is a full time job. It may lead to really annoying things being imposed on the developers that they would never have chosen. However, this does not mean that the architects are idiots, although that is of course possible!
  - piva00 3y ago
    At the company I work for, senior engineers are usually responsible for writing RFCs and getting the involved/dependent parties in the discussion, staff engineers chime in with architectural details the seniors might have missed due to a hyper-localised view of the issue/proposal. This feeds back into seniors understanding of the whole/higher-level architecture, which it's then used to adapt the proposals with the architectural decisions/requirements/constraints. High-level architecture at scale demands a level of knowledge that engineers from a specific team might not have, not due to incompetence but because the scope of the team is bounded and the context is very local, at large enough orgs it's not possible even for senior engineers to keep track of all the weird interactions systems have at a higher level, you need someone whose job is to look at a higher level and validate cohesiveness, someone that knows about other similar work being done across other orgs to see points of cross-pollination, etc. Honestly I can't see how I could depend only on myself and other senior engineers in my team to validate architectures that span cross-org, it'd be exhausting to shift my context all the way up and down architectural layers for every single RFC I write.
- uztrax 3y ago
  Domain experts, financial or business specialists. I've never seen a competent software architect. They make wild statements, draw some trivial diagrams with impressive sounding words. Then some diligent programmer discovers that none of it works, silently creates the real architecture. Then the "architect" takes credit for the result. The days of Internet RFCs that are carefully written are over. We are in the age of agile self-promotion and B.S. (this also applies to foreign policy, with the same results).
maeln 3y ago
Ad hominem. Having senior dev / "architect" focusing on higher level / abstract design and working with junior dev to code it and get it up and running is a very common pattern in big company (especially not tech-first company). And it does work.
- uztrax 3y ago
  [dead]
- bombolo 3y ago
  > Ad hominem. No? It applies to anyone having the same opinion.
  - maeln 3y ago
    In truth, it is more a ad personam argument. You are not contributing anything substantial to the debate, you are just attacking dumpster_fire with no other argument than "in my experience".
    - bombolo 3y ago
      I believe that actual experience is superior to logical reasoning with little or no data to support it.
      - maeln 3y ago
        The only data you provide is "your experience" which is of little value here considering we don't know the extent of it nor its relevance. If anything, the way you express your opinion so strongly, one would hesitate to think that you have any experience in a big corporation with several teams working on different product and/or part of the same product. The context in which having senior dev focus less on coding and more on reviews, documentation and design is common place.
        bombolo 3y ago
dumpster_fire 3y ago
There's a misunderstanding here due to context. Someone working in a startup (been there) will find it difficult to understand just now much communications are required to get anything done in a large MNC. Out of necessity, people who have pushed enough code to understand the systems have to step up to do the comms instead of being siloed. I had many a time freaked out some other team because the phrasing of my email made them think we're going to dump more work on them. This is the actual difficult part about engineering at scale: Getting everyone on the right page. You can opt to keep coding, but it won't get you far in your career. Does this mean the communications have more value than actual implementation? It depends. Again, this value differs at different company sizes. I just got the chance to code again last month, and I've already completed 5 features (code reviewed) that the juniors couldn't complete in a year. I won't say they are worse at coding, but more that I am more familiar with how dependencies work because I've already done the same thing when I was a junior. Also, knowing who to ask for help also helps a lot. I stand by my statement. Code is easy and code is cheap. One day you'll understand.
- bombolo 3y ago
  > I stand by my statement. Code is easy and code is cheap. One day you'll understand. You don't have people under you that can complete in a year what you can complete in a month, and you're still insisting that anyone and their cat can code? I guess they can code… but evidently not as good?
  - FemmeAndroid 3y ago
    I think you’re overlooking this: > I won't say they are worse at coding, but more that I am more familiar with how dependencies work because I've already done the same thing when I was a junior. Also, knowing who to ask for help also helps a lot. I might phrase this a bit differently, but I think it’s getting at my thoughts as well. I work with developers who would destroy me in a race to implement various search algorithms, or whatever discrete metric of coding prowess you want. What they struggle with is: - Efficiently getting other teams to answer their blocking questions in a way that makes the other team happy to work with them. - Understanding the existing features of our fairly complex stack. - Judging when to ask for help, and who to go to about a particular problem. - Identifying dead ends quickly, and pivoting to alternative solutions at the first sign of trouble. - Incorrect assumptions about the company’s priorities, and how the priorities can help shape the request. I end up in a lot of meetings, but I also occasionally (a couple times a year on average,) take a few weeks and implement a business goal that a team has been stuck at for months/years.
dang 3y ago
Please don't cross into personal attack, regardless of how wrong another comment is or you feel it is. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

Donckele 3y ago

[flagged]

bombolo 3y ago
> “coding is the easiest part, and code is cheap” Let me translate: "My work is difficult and important. What other people do is easy and a 3yrs old could do it". I'm ready to bet his architecture is bad and the coders deviate all the time to make it work.
- diegoperini 3y ago
  That's a really bad faith take of that comment. I'd translate it as "in a place where most people are experienced programmers, communication becomes the main bottleneck."
  - dumpster_fire 3y ago
    Clearly I have much more to improve on because you put it way better than I did. My communication skills are terrible.
    - diegoperini 3y ago
      We all have our own battle scars :)
  - bombolo 3y ago
    I'm reading what's written. You're extrapolating. Unfortunately I don't possess long range telepathic abilities, like you seem to have. Ironically, it seems that even if your interpretation (or mind reading) is correct… we have someone that should be facilitating communication that is clearly not good at communicating what they are thinking.
    - diegoperini 3y ago
      I was just guessing but OP provided confirmation to my interpretation.

spacebanana7 3y ago

This depends on the organisation. If an enterprise has well defined interfaces for teams to interact with one another and effective escalation points for conflicts in priorities then communication might be the cheap & easy part. Conversely, small modifications to a messy codebase can be extremely time consuming. Imagine being asked to fix an animation bug on an in house date picker in a large Angular app that hadn't been updated in 5 years.

deleted 3y ago
[deleted]