Work challenges
Sep. 9th, 2016 09:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mtbcAt Aetion I had enviable freedom of action. I could write grant proposals for what I thought should be done and I could often largely lead the work on the funded ones. I got to choose technical approaches and details. I enjoyed talking with the funders, customers, partners, collaborators, figuring out what would work best and delivering it.
At Vecna it was quite the opposite but relatively simple: I was paid to work only on clearly defined tasks coming down from management. I would submit written design documents for both technical approach (the product lead in particular would consider that) and functional design (which would help quality assurance to design their testing). The technologies were fairly narrow: there were dozens of developers working within quite a standard J2EE technology stack from the RDMS up to jQuery by way of Hibernate, Spring and JSP.
I had quite a good workday today. I had the go-ahead to work on a modest task on code with which I already have some familiarity. The aspects that had highest technical risk went relatively smoothly. With luck I'll have finished off this next step early next week. What I will be doing in a week's time though, I don't know.
With my work in Dundee I have a couple of new issues to manage. One is that I have some idea what users want, albeit partly indirectly via those more engaged in outreach. However, I am not having to sell and run projects. So, I can propose things that make sense based on what I know, but from my vantage point I have but a partial view which makes me poor at guessing what I will actually be asked to do. It's not that matters are secret so much as that I want to use working time well and in my role it would be inefficient for me to closely follow the larger picture when a management team already do that. So, I postpone some tasks: maybe clarifying decisions must be made about them, perhaps they are not what is currently funded, or partners more urgently require something else. It is often interesting for me to survey the tasks that I think of as being on my plate to see which are now unblocked; sometimes none seem so and I try to poke them along and pick up a couple of smaller bug tickets in the meantime. There are surprise interruptions too that make planning uncertain: for example, this week I was fixing some unexpected long-standing errors in PL/pgSQL functions.
The other issue is that we have a lot of technologies under our belt. The team isn't enormous and the most knowledgeable of course tend to be the busiest in management, interaction with funders and partners, etc. We have C++, Java, Python, Django, MATLAB, Docker, OpenStack, Jenkins, React.js, OpenLayers, XML and XSLT, all kinds of things going on atop a number of code repositories and build systems that include steps involving Python code underlying some code generation, ZeroC's Slice for some, Apache's Velocity for other, along with both Ant and Maven driving builds. I wrote some Java code that generates Sphinx code for documentation. If somebody works on some part of the project then it can be difficult to find others with both the time and expertise to properly peer-review it; we do our best but it takes some effort. Similarly I know I could make use of others' work in my own but it tends to be a moving target and I haven't yet made the time to, say, understand our Ansible playbooks.
In short, I sometimes feel a bit at sea, both in terms of my work and others'. I am sure that people would listen if I had ideas about how to improve that but my sense is that there are no easy answers: it may be inevitable given that we try to do a lot in a fast-moving field with limited resources.
At Vecna it was quite the opposite but relatively simple: I was paid to work only on clearly defined tasks coming down from management. I would submit written design documents for both technical approach (the product lead in particular would consider that) and functional design (which would help quality assurance to design their testing). The technologies were fairly narrow: there were dozens of developers working within quite a standard J2EE technology stack from the RDMS up to jQuery by way of Hibernate, Spring and JSP.
I had quite a good workday today. I had the go-ahead to work on a modest task on code with which I already have some familiarity. The aspects that had highest technical risk went relatively smoothly. With luck I'll have finished off this next step early next week. What I will be doing in a week's time though, I don't know.
With my work in Dundee I have a couple of new issues to manage. One is that I have some idea what users want, albeit partly indirectly via those more engaged in outreach. However, I am not having to sell and run projects. So, I can propose things that make sense based on what I know, but from my vantage point I have but a partial view which makes me poor at guessing what I will actually be asked to do. It's not that matters are secret so much as that I want to use working time well and in my role it would be inefficient for me to closely follow the larger picture when a management team already do that. So, I postpone some tasks: maybe clarifying decisions must be made about them, perhaps they are not what is currently funded, or partners more urgently require something else. It is often interesting for me to survey the tasks that I think of as being on my plate to see which are now unblocked; sometimes none seem so and I try to poke them along and pick up a couple of smaller bug tickets in the meantime. There are surprise interruptions too that make planning uncertain: for example, this week I was fixing some unexpected long-standing errors in PL/pgSQL functions.
The other issue is that we have a lot of technologies under our belt. The team isn't enormous and the most knowledgeable of course tend to be the busiest in management, interaction with funders and partners, etc. We have C++, Java, Python, Django, MATLAB, Docker, OpenStack, Jenkins, React.js, OpenLayers, XML and XSLT, all kinds of things going on atop a number of code repositories and build systems that include steps involving Python code underlying some code generation, ZeroC's Slice for some, Apache's Velocity for other, along with both Ant and Maven driving builds. I wrote some Java code that generates Sphinx code for documentation. If somebody works on some part of the project then it can be difficult to find others with both the time and expertise to properly peer-review it; we do our best but it takes some effort. Similarly I know I could make use of others' work in my own but it tends to be a moving target and I haven't yet made the time to, say, understand our Ansible playbooks.
In short, I sometimes feel a bit at sea, both in terms of my work and others'. I am sure that people would listen if I had ideas about how to improve that but my sense is that there are no easy answers: it may be inevitable given that we try to do a lot in a fast-moving field with limited resources.
