4 ms·

Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? Is it constant ag

Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? Is it constant agile crunch to smash as many story points as possible into the current sprint?

pjmlp 4y ago
Unless it can be made billable it is usually frowned upon.
pacifika 4y ago
In an agency setting anyways the percentage of billable time is usually a kpi
loup-vaillant 4y ago
In some places, such as the one I'm working in right now, explicitly discourage working on anything but what you've been assigned. I've even been scolded from taking items from the next sprint when I was done with the current (and in no position to really help my colleagues).
dusted 4y ago
In my experience, pretty close to constantly working on whatever has been prioritized from above and needing actively to push back and have exceptionally good arguments for improving things that are not in scope.
Manuel_D 4y ago
> Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? A valid point, but that just kicks the same question down the road: why was no engineer assigned to investigate loading times? That might be indicative of a culture that is biased towards projects with an outcome decided a priori. A lot of managers don't want to assign tasks where the definition of "done" is ambiguous.
michaelt 4y ago
Almost every developer can fit a bit of discretionary work into their existing stories. You can polish up the performance when you first code it. Almost every employer also has a bunch of things they'd like you to do outside of your stories - mentoring junior developers, recruiting, planning, team building, professional development. Some employers have SOC2 compliance policies that all changes should be traceable to a documented requirement, so fixes after the change is complete can be a bit more bureaucratic. If the project is behind schedule, the bosses might want you to work on something else instead. Many developers are given pretty high-spec machines, so they can compile quickly and run weighty IDEs and so on - meaning an issue that's painful for users with 2GB of RAM and 2 CPU cores might be barely noticeable to users with 32GB of RAM and 8 cores. And of course, some workplace cultures would say if you've 'got your work done' you can do discretionary performance work or you can leave early - and who'd choose performance work over spending time with their loved ones?
- galangalalgol 4y ago
  A programmer? The gp talked about promotion as an incentive. 15 or maybe 20 years ago people didn't go into programming as a profession so much as they got paid to do what they would have done anyway. That was after the first dotcom bust, so maybe some people before that were in it for the money. But the number of times I have had to apologize to the wife because I got lost in a problem and was late getting home is large. Heck on /. they would have questioned that I actually had a wife, because programmers don't date. The motivation of the people doing the job has changed now that it pays well. But also, the culture of "if you aren't working your backlog item you aren't working" is new. The scrum kanban thing is somewhat to blame. Waterfall was terrible, but everyone on a good team knew that and just did what made sense, which is kind of what the agile manifesto was about.
  - IggleSniggle 4y ago
    Omg I’m a younger gen it sounds like, but I’m constantly getting in trouble with my wife for getting too lost in a problem. She hates, too, that I can continue to be lost in it even as I’m eating dinner or walking with her in the park or whatever. As for where that energy goes…when an employer tells me that in order to do XYZ I need to open tickets and write stories and and and, even though I agree those are the right things to do, my brain is more likely to the attack the problems where all that distracting bullshit is unnecessary.
menaerus 4y ago
(others) YMMV but I usually don't. It's the complexity of the problems which I need to tackle and for which I have no playbook to follow and it will mostly involve deep understanding of HW, operating systems and algorithmic design. There're also compilers and programming languages which do require a non-trivial amount of time to understand but also keeping the pace with it because they're constantly evolving. Pick any of those to study and I guarantee that you can spend your lifetime doing so without having a single second to spare. However, to provide an actual business value to your company, you obviously cannot keep running through this rabbit hole on and on but by the end of the day you have to learn how to pick the right balance. In the end, I'd say that the problem space is simply too huge and I personally haven't found myself idling in my 10+ year career other than in the moments when I became too frustrated with the problem at hand. That's also one of the reasons I am reconsidering what I want to do in next 5-10 years :)

pjmlp 4y ago

Unless it can be made billable it is usually frowned upon.

pacifika 4y ago

In an agency setting anyways the percentage of billable time is usually a kpi

loup-vaillant 4y ago

In some places, such as the one I'm working in right now, explicitly discourage working on anything but what you've been assigned. I've even been scolded from taking items from the next sprint when I was done with the current (and in no position to really help my colleagues).

dusted 4y ago

In my experience, pretty close to constantly working on whatever has been prioritized from above and needing actively to push back and have exceptionally good arguments for improving things that are not in scope.

Manuel_D 4y ago

> Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? A valid point, but that just kicks the same question down the road: why was no engineer assigned to investigate loading times? That might be indicative of a culture that is biased towards projects with an outcome decided a priori. A lot of managers don't want to assign tasks where the definition of "done" is ambiguous.

michaelt 4y ago

Almost every developer can fit a bit of discretionary work into their existing stories. You can polish up the performance when you first code it. Almost every employer also has a bunch of things they'd like you to do outside of your stories - mentoring junior developers, recruiting, planning, team building, professional development. Some employers have SOC2 compliance policies that all changes should be traceable to a documented requirement, so fixes after the change is complete can be a bit more bureaucratic. If the project is behind schedule, the bosses might want you to work on something else instead. Many developers are given pretty high-spec machines, so they can compile quickly and run weighty IDEs and so on - meaning an issue that's painful for users with 2GB of RAM and 2 CPU cores might be barely noticeable to users with 32GB of RAM and 8 cores. And of course, some workplace cultures would say if you've 'got your work done' you can do discretionary performance work or you can leave early - and who'd choose performance work over spending time with their loved ones?

galangalalgol 4y ago
A programmer? The gp talked about promotion as an incentive. 15 or maybe 20 years ago people didn't go into programming as a profession so much as they got paid to do what they would have done anyway. That was after the first dotcom bust, so maybe some people before that were in it for the money. But the number of times I have had to apologize to the wife because I got lost in a problem and was late getting home is large. Heck on /. they would have questioned that I actually had a wife, because programmers don't date. The motivation of the people doing the job has changed now that it pays well. But also, the culture of "if you aren't working your backlog item you aren't working" is new. The scrum kanban thing is somewhat to blame. Waterfall was terrible, but everyone on a good team knew that and just did what made sense, which is kind of what the agile manifesto was about.
- IggleSniggle 4y ago
  Omg I’m a younger gen it sounds like, but I’m constantly getting in trouble with my wife for getting too lost in a problem. She hates, too, that I can continue to be lost in it even as I’m eating dinner or walking with her in the park or whatever. As for where that energy goes…when an employer tells me that in order to do XYZ I need to open tickets and write stories and and and, even though I agree those are the right things to do, my brain is more likely to the attack the problems where all that distracting bullshit is unnecessary.

menaerus 4y ago

(others) YMMV but I usually don't. It's the complexity of the problems which I need to tackle and for which I have no playbook to follow and it will mostly involve deep understanding of HW, operating systems and algorithmic design. There're also compilers and programming languages which do require a non-trivial amount of time to understand but also keeping the pace with it because they're constantly evolving. Pick any of those to study and I guarantee that you can spend your lifetime doing so without having a single second to spare. However, to provide an actual business value to your company, you obviously cannot keep running through this rabbit hole on and on but by the end of the day you have to learn how to pick the right balance. In the end, I'd say that the problem space is simply too huge and I personally haven't found myself idling in my 10+ year career other than in the moments when I became too frustrated with the problem at hand. That's also one of the reasons I am reconsidering what I want to do in next 5-10 years :)