With only a proportion of developers classified as key workers (where their responsibilities perhaps included the operations-side of keeping mission-critical and life-critical systems up and online), the majority of programmers will have been forced to work remotely, often in solitude.
So how have the fallout effects of this played out?
This post is written by Paul Dubs, drawing on his 15+ years of experience as a software engineer. Based in Germany, he is responsible for heading up the software division of Skymind, an open source enterprise deep learning software company that cals itself a dedicated AI ecosystem builder.
Dubs writes as follows
We are building AI solutions for business use. This includes our open source products Deeplearning4J and Konduit Serving, as well as commercial products and professional services.
In many ways, things havent changed that much due to the pandemic. The company has always been a remote-first company. The team has consisted of people distributed over many different time zones. The biggest change has been that we cant come together as easily as we used to. Previously it was possible for key people to meet in-person at least once per quarter. Often, we met at conferences or for workshops.
In terms of what types of application development we think have actually flourished under the constraints of lockdown vs. what types of development have suffered things that are clearly defined. Where you know exactly what needs to be built and no communication or planning is needed, things can be done very well under lockdown conditions. When you can just set yourself as offline and work heads down until you are done.
But anything that benefits from a free communication flow is somewhat hindered: brainstorming and whiteboarding; planning and figuring out what to build in the first place.
Unfortunately, most of the online meeting solutions weve tried so far end up being a very distant second compared to an in-person meeting. The latency results in people starting to talk over each other; the noise reduction algorithms remove too much and make it hard to understand some people; sudden technical problems always result in lost time.
Dubs: tough times, but teamwork has still shined through.
Thinking about our staff numbers, headcount has grown quite a bit during the last year, despite the pandemic.
Training these people has been a challenge we have had to overcome. Whereas we could organise a workshop and come together previously, we now have to find different ways to share our knowledge. One of the ways we are doing it is through regular knowledge sharing sessions over Zoom. We record them, to allow people who were not able to attend to watch them at a later time, and make that learning more asynchronous in general.
Thinking about methods waterfall development as we know it has always been a strawman. Even the paper that introduced it, used it as an example of what not to do. So, I dont think that we as an industry are likely to fall back to it.Agile development methodologies have always been about being adaptable, about being able to deal with the uncertainties of business life. With uncertainties at an all-time high, it seems unlikely that anyone would consider moving away from agile methods. It makes sense, however, that the actual details change.
How that change looks obviously depends on the situation. For example, there is no point of a standup in the morning, if there is no morning that is consistent for all of the team members as we are working at different hours and time zone.s
A more asynchronous approach, where you have a kind of continuous standup in a Slack channel, for example, can work better in that case.
I have been working in a remote position for a few years now. When the pandemic hit, this meant that I was well prepared and essentially nothing about my day-to-day work had to change.
In contrast to many people who were used to going to an office building to do their work and now have to work from their bedroom, living room or kitchen, I had a properly set up home office already. More importantly, I was already used to working in an environment that is abundant with distractions.
For many people, it was the first time where they had to do the majority or all of their work from home and while they knew how to deal with distractions in their office environment, they werent equipped yet to deal with them at home. When you have to work from your kitchen, your mind might wander to what you will be cooking today or you start to suddenly notice all the little spots that may need a little bit of cleaning. When working from the living room, the TV may be a constant reminder that you might be also watching your favorite show right now.
It really is no moral failing of their own, as those activities are strongly associated with those rooms. For the brain, the work might as well be the distraction.Finding your own rhythm that will work in your home environment takes some time and practice.
For myself, Im following the same schedule as Ive used before the pandemic. I get up sometime between 6 and 7 in the morning, get a light workout in, revisit my plan for the day that Ive set up the evening before, and read a bit. Then I get some breakfast and get to work. Sometime around noon or early afternoon I have lunch and a short break and then get back to work. When Im done for the day, I sketch out a new plan for the next day. The plan helps to stay on track, or get back on track when something unexpected needs to be handled.
One particular thing that really helps me to stay focused, is to ignore all and any news until the evening. During interesting times, as we are currently experiencing, the trickling stream of news can heavily sap attention from the things that really matter.
Link:
Programming in the pandemic - Skymind: Thoughts from the AI ecosystem - ComputerWeekly.com