4 ms·

> I wouldn't mind to work long hours if that would mean purely coding. But no, employers prefer to throw bunch of non-coding tasks at engineers You can’t have

> I wouldn't mind to work long hours if that would mean purely coding. But no, employers prefer to throw bunch of non-coding tasks at engineers You can’t have it both ways. If you want to just code, call yourself a coder or programmer. An “engineer” is of a profession devoted to “the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people.” Making your work useful to people involves communication and research beyond coding. Maybe it ain’t jira tickets but it also ain’t “purely coding.”

slt2021 3y ago
It is not even engineering. A lot of software devs have become slaves on the alter of Agile software development. A senseless machine that only cares about the number of your JIRA tickets, and making sure your agile shibboleths like standups, retros, sprints and etc are conducted. You can look at gogle - the company that has never produced any useful product beyond a few of search/ads, youtube, gmail, and maybe google docs. Thats it. Nothing more. and gogle is considered very efficient in its engineering processes, that entire industry copies it. meanwhile the most disruptive innovation comes from small teams that dont care about formalized rituals and jsut focused on execution and coding, they dont need PM, TPM, and Agile Coach, and Engineering manager to deliver value
- eduction 3y ago
  Ya I think you make a fair point that a lot of non coding work these days probably doesn’t actually improve the product/make it work better for the end user. I see that as simply bad management, and there is indeed a ton of it. Keep in mind that agile began as a reaction to “waterfall” and was intended to reduce bureaucratic overhead and planning. But the reaction became worse than what it was reacting to. I think throwing out all process will just lead us back to bad process. Better to have a good process - some sort of planning and system for improvement is good and necessary IMO. Especially if you’re building an organization or iteratively improving product. v1 can arguably be done seat of the pants but what about subsequent versions.
XorNot 3y ago
John Carmack's experience of engineering isn't a bunch of meetings, customer-alignment sessions, or anything else though. Apocryphal stories of him measuring everytime he was interrupted are the antithesis of that: they imply he wasn't available to staff, wasn't coordinating with anyone - he was in fact, just coding. How many people have jobs where "just coding" is actually adequate to do the job? The early years of game development are perhaps the only time this was relevant, and even then it only applies if you work for yourself and not salary. When 16 hours a day of coding will pop out a game engine a little faster, which gets it to market faster, which gets money into your bank account faster - sure, go nuts. The monetary value of your output is potentially highly disproportionate to the hours input and you the only stakeholder is you. Of course, if you're spending a stupid number of hours a day coding and disregarding leading your art department, or guiding your other developers, or negotiating with your publishers for funding or deadlines...then you're probably not actually doing your job.

slt2021 3y ago

It is not even engineering. A lot of software devs have become slaves on the alter of Agile software development. A senseless machine that only cares about the number of your JIRA tickets, and making sure your agile shibboleths like standups, retros, sprints and etc are conducted. You can look at gogle - the company that has never produced any useful product beyond a few of search/ads, youtube, gmail, and maybe google docs. Thats it. Nothing more. and gogle is considered very efficient in its engineering processes, that entire industry copies it. meanwhile the most disruptive innovation comes from small teams that dont care about formalized rituals and jsut focused on execution and coding, they dont need PM, TPM, and Agile Coach, and Engineering manager to deliver value

eduction 3y ago
Ya I think you make a fair point that a lot of non coding work these days probably doesn’t actually improve the product/make it work better for the end user. I see that as simply bad management, and there is indeed a ton of it. Keep in mind that agile began as a reaction to “waterfall” and was intended to reduce bureaucratic overhead and planning. But the reaction became worse than what it was reacting to. I think throwing out all process will just lead us back to bad process. Better to have a good process - some sort of planning and system for improvement is good and necessary IMO. Especially if you’re building an organization or iteratively improving product. v1 can arguably be done seat of the pants but what about subsequent versions.

XorNot 3y ago

John Carmack's experience of engineering isn't a bunch of meetings, customer-alignment sessions, or anything else though. Apocryphal stories of him measuring everytime he was interrupted are the antithesis of that: they imply he wasn't available to staff, wasn't coordinating with anyone - he was in fact, just coding. How many people have jobs where "just coding" is actually adequate to do the job? The early years of game development are perhaps the only time this was relevant, and even then it only applies if you work for yourself and not salary. When 16 hours a day of coding will pop out a game engine a little faster, which gets it to market faster, which gets money into your bank account faster - sure, go nuts. The monetary value of your output is potentially highly disproportionate to the hours input and you the only stakeholder is you. Of course, if you're spending a stupid number of hours a day coding and disregarding leading your art department, or guiding your other developers, or negotiating with your publishers for funding or deadlines...then you're probably not actually doing your job.