4 ms·
Yes, I resonate with this and the article above. I think 80% of a SWE's job is to communicate with the XFN partners (either gathering requirements, pushing bac
by gosolozero 2mo ago
Yes, I resonate with this and the article above.
I think 80% of a SWE's job is to communicate with the XFN partners (either gathering requirements, pushing back, managing up, collaborations, etc) and then plan out the actual coding (gather code pointers, look at past code, plan architecture, talk to the team). The last 10% is the coding. And then the other 10% is the maintenance of that and past code (which honestly should be a lot more but incentives are not aligned well).
It's hard for people to understand jobs they don't do. They imagine we spend 8 hours a day clacking at the keyboard.
- pjio 2mo ago> They imagine we spend 8 hours a day clacking at the keyboard. I do, but the order of the keys makes a difference somewhat.
- avilay 2mo agoThe percentages are different for different types of SWEs, not all SWEs spend 80% of their time on XFN comms. I agree with your larger point that a non-trivial amount of a SWE's time is spent on XFN comms and team alignment. My argument is that if an individual contributor is not spending a majority of their time on problem solving and implementation (including maintenance of legacy code), they are not maximizing their potential. If they are spending 80% of their time on non-coding activity they are better suited for an Manager role (Engineering or Product). At the end of the day, coding is not hard only if you are a good coder to begin with. If you are a good EM/PM then people issues will not be hard (which coders often complain about).
- gosolozero 2mo agoI'm talking from the perspective of working in big tech. Working in a fast paced startup, percentages are definitely different. But alignment/deciding where to spend resources is more important than coding especially the higher you go, the more resources at your disposal (staff+ eng). Junior eng again different percentages.
- mupuff1234 2mo agoI feel like almost every standout product in the world was a result of someone with good instincts and not the results of XFN communication. Unfortunately it is still the job...
- lelanthran 2mo ago> I think 80% of a SWE's job is to communicate with the XFN partners (either gathering requirements, pushing back, managing up, collaborations, etc) and then plan out the actual coding (gather code pointers, look at past code, plan architecture, talk to the team). The last 10% is the coding. And then the other 10% is the maintenance of that and past code (which honestly should be a lot more but incentives are not aligned well). That last 10% is the value-add. If you aren't doing that, the other 90% can be done by pretty much anyone, and they won't be "SWE", they'd be minimum-paid white-collar workers. A lot of people miss this in their haste to rationalise their evaporating value - "I'm still useful, because AI is only doing that 10%, I am still needed for the other 90%", not realising that if they aren't needed for that last 10%, they are interchangeable with the office receptionist :-/
- snowe2010 2mo agoThis logic makes no sense. If 90% of a software engineers job is not coding, then the valuable part of their job isn’t coding. It’s the other things. Else junior devs or interns would be doing all that work. So no, they aren’t interchangeable with the office receptionist, else the office receptionist would already be doing that job.
- menaerus 2mo agoI have been writing code professionally for almost 20 years, hard or at least non trivial problems what many would consider, and my job description does not resemble the tiniest of what you're describing. Coding _is_ difficult and dedicating only 10% of your time for that task will leave you very quickly without the job. Most of the time not only that you spend close to 100% of the time doing the coding part but even more than 100%. Some problems and domains are just difficult and not trivial to the part you can automate them. With the age of AI this may be changing though.