The Onboardee’s Checklist

ou’re starting a new job and you know nothing. It is a new company, with their own internal processes and culture. Plus your role may be different, from what you were doing before.

You have the information you obtained in the interview, however the realities of a position do not often match the theory of a job description. Even if the interviewer filled your role in the past, the day to day activities tend to be glossed over in favour of less frequent but more memorable events.

Your own checklist

So the first thing you need is a plan. But how do you make a plan when you know nothing, every company is different. While that is true, it is not the whole truth. You have previous experience that can be used here. You would have noticed reoccurring patterns, especially if this is not your first job. 

If you lack knowledge the first step is identifying the needed knowledge and the initial steps in obtaining it. Remember you do not need to know everything all at once, you just need to know the next step.

Take your previous experiences as a new hire or learning a new activity or joining a new organisation and distill the commonalities down to a checklist. It is better to create your own, but on the off chance that it has something of value I will share my own.

My checklist

The following may seem obvious, but listing it out can help calm yourself and give you confidence. You have a way forward.

Remember your weakness is that you know nothing and your strength is that you know nothing. You can look at things with a fresh perspective.

Don’t be afraid to ask questions. If you have problems framing a question, note down an area where you are uncertain and after they have finished their explanation, ask for elaboration.

First steps

List the answers and / or the first steps in obtaining the answers to the below questions somewhere prominent.

• What do you need to know?
• Who can you go to for help?
• What are the resources you can call on?
• What can go wrong? What are the triggers for escalation and what are the first steps in response.
• What are the preferred communication channels?
• Is there any awkwardness or pain points in the processes? The existing team may be so used to working around problems that they put off changing the existing process.
• Is there a missing skill or responsibility that is not being covered by the existing team? Teams have a tendency to avoid essential tasks if there is a skills gap or a responsibility gap.

Onboarding and Tutorials

Document your onboarding experience, especially missing or incorrect information. Your successors will thank you.

• Evaluate step by step tutorials. Most people hate creating tutorials and are not trained in writing them so unless there is a dedicated team of technical writers they are often bad or completely missing. Even when a company employs technical writers, those writers need to communicate and coordinate with the relevant subject matter experts and this can be a failure point.
• There is almost always too many steps in these tutorials. This can be fixed by streamlining processes and creating defaults for the most common use cases. This is usually easy if your new role owns the process, a little harder but doable if no one owns it and if someone else owns it then some lobbying may be needed.
• A common failing in these tutorials is due to the curse of knowledge. Many tutorials explain from the point of view of the creator, emphasising implementation details and listing every possible function of the system. 
• It is better to explain things from the users point of view, emphasising the intent of the system and breaking things down by common use cases rather than by internal structure.

Communication 

• Create filters for your email that sort email into folders. In some companies, you will have 10s or 100s of emails a day, many of them automated notifications. It is easy to lose the signal for the noise.
• Don’t blindly accept meeting invitations. Know why you are in the meeting. Meetings are necessary for coordination, but they are costly. The more people in the meeting and the longer they run the more expensive they are.
• Frequent retrospectives are key to continuous improvement and the most important product of retros are the action items. Track the action items.
• Communicate using the teams preferred method.

First suggestions

You probably won’t volunteer suggestions until you have a feel for the lay of the land. However don’t wait too long as you can lose momentum.

Are their any gaps or pain points?

• Gaps
• Some of my greatest career successes have been from tackling problems that the other team members were avoiding, despite the fact that I had no previous experience with those problems. If the existing solution is either missing or extremely bad, then it matters less that you know nothing, the bar is low and it is amazing how far you can go with a little persistence, a fresh outlook and a willingness to learn. It is also easier to make changes if it is no ones responsibility as you are not stepping on anyones toes.
• Pain points
• If the existing process is painful then you will face less resistance to change and more impact on efficiency and effectiveness if you manage to streamline it.

Never Ask for Feedback You are Not Willing to Listen to

hen asking for feedback, make sure than the feedback giver feels listened too. Make sure that you make a good faith attempt to address their concerns. If you cannot then humbly and regretfully explain why you cannot comply.

Some people will be tempted to dismiss this as too touchy feely. Don't. If you get this wrong, things can get bad. Really bad.

One example of an attempt to gain feedback gone horribly wrong stands out in my memory.

A previous company I worked in had an open plan office, full of cubicles with my team and team Marmalade sharing the same area.  Marmalade was an endless source of vicarious learning. I have learned more from them than any other team. They may have appeared once or twice in other blog posts.

Most managers when talking to their team about important and sensitive information, book one of the boardrooms to hold a meeting. They are quiet, private and usually free of interruptions. Team Marmalade's manager for reasons known only to him decided to hold an important meeting in the work area in the middle of the cubicles. I heard everything. The entire office heard everything and most unfortunately his team heard everything. The team hearing their manager is usually desired, however by the end of this particular meeting, the manager would end up wishing that everyone would forget that the meeting ever happened.

The manager started off by explaining that the teams process was not working. They were not achieving their goals. He said he understood that they had to change. He asked them for ideas on how the team could improve. So his team told him. They told him exactly what was wrong with how they did things. How they could fix things and how they could dramatically increase their productivity. They talked at length and in great detail and as each team member talked the manager became more and more uncomfortable. Finally he interrupted them. "I can't tell upper management any of this!" he said, "We are just going to have to stick with what we were doing."

Morale plummeted. Productivity plummeted. 

Then a few weeks later morale bounced back, thanks to the efforts of the team leader and no thanks to the manager. However some of the methods Marmalade's team leader used to restore morale were a little bit dubious. He might have gotten away with that if the team had been more productive. However while productivity had increased it was not back to pre-"feedback incident" levels and pre-"feedback incident" productivity levels were low to begin with. That was why the manager was talking about change in the first place. 

I felt conflicted. On one hand I was really impressed with how the Team Lead had turned around the team, on the other hand team Marmalade seamed to have reduced their commitment to their project. They seamed to have given up and there was an undercurrent of anger, frustration, and resentment simmering under the surface. Nothing had been forgiven or forgotten.

One day while the manager was offsite and the team leader got particularly inventive with his morale building activities, upper management stepped in to stop the fun. They loudly and very publicly told off team Marmalade for being unprofessional. Had all the managers in this company forgotten that we had meeting rooms?

Morale plummeted again. Productivity plummeted again.

This time it took a long time for team Marmalade to recover.

This is not the only time I have seen soliciting feedback backfire but it was definitely the worst.

If you are not respectful of the feedback you are given, the feedback givers can become cynical, resentful and apathetic. By the time you get serious about making changes your community may no longer be interested in listening to what you have to say. 

More Evidence Does Not Always Help, but Always Schedule Followup

y boss called me into his office. He asked me if I thought project Indigo could be completed on time. This was a strange thing to ask. My position on the feasibility of Indigo was well known, I'd had stated it clearly to my boss on more than one occasion. Indigo was due to start next business day. Was he having last minute doubts? or was he afraid I would make trouble either with his superiors or the new hires?

I had found myself in an Asch conformity experiment. I had estimated Indigo as taking 5 years for a team of 7 and both the other senior developer and the project manager estimated that it would take 9 months for a team of 5. Even the 5 year estimate was a product of the Anchoring effect, Yet, despite every skerrick of experience and expertise telling me that this was a multi-year long project, I was starting to doubt myself. Everyone else was supremely confident that it would only take 9 months.

Under the intense gaze of my boss I did something that I later regretted. I suggested a compromise. The project manager had a meticulous and detailed schedule laid out which stated the first module would be completed in a month. If we measured how much work was done during the first month we would have a good idea how long the whole project would take.

My first mistake was suggesting a compromise in the first place. The problem wasn't with there being enough evidence that I was right, after all this was a reboot of Indigo, it had already failed once. So there was plenty of evidence from the original project for how long it would take. The failure of the original project was why we had a project manager in the first place. He was there to rescue the project. 

One of the problems with Indigo was that the team was so focused on convincing higher management to green-light the project that they never stopped to consider whether they should do the project at all. Except maybe my boss was asking himself that question now. If so, I blew my best chance at killing the project. I guess I will never know whether being more assertive would have shifted my boss's position on Indigo. On the other hand, maybe he just wanted to know whether he could count on me to be a 'team player'. Sounds a bit paranoid, however the company was very internally competitive.  

My second mistake was not locking in a review meeting right there and then, with evaluation criteria. I probably didn't have the role authority or influence to swing something like that for project Indigo, but I could, and did, do something similar for later projects. It was an important lesson to learn. If you don't schedule it there and then, it is not going to happen. Later I came across many projects that needed either an architectural spike or a technological spike, and post spike reviews are useful. In one case the review resulted in a major pivot and other cases ended up triggering minor adjustments.

How the meeting with my boss played out, was possibly not the best outcome, however because I hadn't completely caved, the other senior developer as well as the project manager were put in charge of Indigo while I was left in charge of project Teal, the project that Indigo was supposed to replace. It was also not the worst outcome; I could have been put in charge of Indigo. Teal was the ideal position. Close enough to the disaster to learn from it, but far enough away to escape the flames.

After a month I checked the work tracking application; the Indigo team had not completed any stories. I asked the project manager whether Indigo was still on track to be finished by the deadline. He said it was on track. I pointed out that the team hadn't finished anything. He told me they had partially completed many of the stories. I asked how he could say they were on target to meet the deadline when assessing progress on partially completed work was notoriously hard. He said that his years of experience and expertise as a project manager allowed him to know that they would make the deadline. I talked to my boss and brought up our previous discussion and pointed out that the project was not going well. He said is was early days and he had confidence in the project manager. 

After a year the Indigo still had not gotten QA to approve a single story. There were tasks the that had passed QA, but that was a whole other problem. Tasks are not suppose to be tested by themselves, they are suppose to be tested as part of the story they are a part of.

Indigo was experiencing the classic signs of having stories that were too big. Most of Indigo's problems I have seen to a lesser extent in other projects. However the words "lesser extent" are doing a whole lot of work in the previous sentence. There was one difference that was a difference of kind rather than a difference of scale, one mistake that doomed Indigo from the very start. A mistake that caused many of the other problems, and that mistake was in how the estimation was done. There were other projects were I was pressured to reduce my estimates, as if re-estimating would change the real completion time. There was only one project that I have ever been on where I was given the estimate I was supposed to come up with before hand.   

As a consequence the stories were like epics and the tasks where like stories. So I used the completed tasks to estimate progress. This was less than ideal, as the tasks were not comprehensive. There were lots of gaps. I came up with a pretty graph that showed that Indigo would be finished in eight years. Again I was making the mistake of thinking that I needed more evidence. More evidence wasn't going to help. 

I showed the graph to my boss. He said that they had learnt a lot from the first year, and they would do better this year. Also he did not think that it would take eight years. I asked how long he thought it would take. He didn't answer.

At this stage cancelling the project would cause too much embarrassment. I do not think that anyone involved actually ever intended to meet the deadline. They thought that it would slip its deadline by a few months and upper management wouldn't be too upset by a small delay. It ended up overrunning its deadline by more than a few months.

The second year the real scope was reduced as low priority functionality was jettisoned, while on paper the estimated scope expanded, as hidden functionality was discovered, new stories were added. Stories were split into small stories and management became alarmed by the aggressive scope creep. 

No more new stories, and no more story splitting, management ruled. This did not help. The stories became bigger and bigger with more and more tasks, their estimated size kept increasing. The scope creep continued.

The third year management decided that the team should split the stories into smaller chunks and re-estimate to the "real" values. The backlog was greatly improved, however the stories were still too big, they still had trouble getting stories through QA and the number of stories kept increasing.

The project manager was starting to panic, he was flying in from interstate every two weeks and the project seemed like it was never going to end. His reputation for bringing in projects on time was starting to suffer. He was complaining to anyone that would listen. Most of the initial team except for him were long gone.

I left for greener pastures. A few years later I met the final team leader of Indigo for coffee and he gave me the low down on what happened next.

After five years, a prototype was given to beta customers. The customers hated it and gave the team a long list of things that needed to be fixed.

After six years the project was cancelled and the developers where laid off.

I agree with my former boss. There was a lot to be learned from the trials and tribulations of project Indigo and the learning did not stop with the first year.

Learning Plans for 2023

urrent Focus Topics

Focus	People	Tasks
Abstract	Communication, Coaching &             Leadership	Category Theory, Abstract Algebra &  Lambda Calculus
Concrete	Reducing Stress & Refocusing the Mind	Swift

Changes for 2023

I am currently spreading myself to thin between to many study topics. For the upcoming year I intend to slowly finish up many of the topics and narrow my focus.

Category Theory

I feel that am pretty much done with Category Theory, Abstract Algebra  &  Lambda Calculus. I will experiment  more with practical applications of the theory, and some of the functional swift libraries then close the topic off in March with some final revision. I have been building up an Anki flash card deck which I will share. I won't replace this topic with another. I will leave that quadrant blank for now.

Leadership

I worked my way though a large chunk the courses and books I had earmarked for these topics and I am also applying that knowledge. I am going to finish Communication & Leadership in June and Coaching in October.  I intend to study creative writing in 2024. 

Wellbeing 

I am going continue on with this. The only changes I am making from last year is to alternate my exercise routines and restart my music practise.

Swift

There is still a lot I want to do in this area, so this one will be keeping me busy.

Related Posts

• Learning Outcomes for 2022
  
• Learning Outcomes for 2021
  
• Learning Plans for 2021
• Goal Setting
  
• Learning by Doing
  
• Select the Right Skills to Improve

Learning Outcomes for 2022

ocus Topics for 2021

Focus	People	Tasks
Abstract	Learn to Learn	Category Theory &  Lambda Calculus
Concrete	Reducing Stress & Refocusing the Mind	JavaScript & Knockout

Changes for 2022

I changed jobs in the second half of 2021. My Javascript skills were less of a priority as my new role was focused on Swift. I felt as though I had mastered Learning to Learn, therefor I swapped it out for leadership and communication.

My wellness routines where an ongoing concern, so I kept that focus. I hadn't made much progress in category theory in 2021, so I rolled it over to 2022.

New Focus Topics for 2022

Focus	People	Tasks
Abstract	Communication, Coaching &             Leadership	Category Theory, Abstract Algebra &  Lambda Calculus
Concrete	Reducing Stress & Refocusing the Mind	Swift

Category Theory

In contrast to the previous year, I ended up over-investing in category theory in 2022. I was constantly running into a web of mathematical concepts that I was less than familiar with. I did manage to uplift my understanding from a vague shaky beginner level to a more solid intermediate grasp of the material. There were lots of diversions along the way. The consensus was that category theory was easier if you knew abstract algebra so I added it to the list.  Most of the programming examples that were used to illustrate category theory were in Haskell so that went on the list too.

I had a bit of trouble translating the theory into practise. I am mostly using Swift at the moment and while Swift uses lots of category theory's concepts, they tend to be obscured .e.g. although, concurrent contexts, throwing contexts, sequences and, optionals are all monads, in Swift they are each treated as their own separate thing, and you would only notice the similarities, if you already knew the theory. If a programmer wanted to tie those concepts together, e.g. using a Monad class they couldn't, because Swift does not support higher kinded types. 

There are libraries that help Swift be more category theory friendly, and one, Bow even simulates higher kinded types. Maybe I will experiment with those libraries in 2023.

Leadership

I managed to make some progress on this, even though it felt, as if category theory was stealing my focus. I even managed to translate my learning into activities at work. Although, most of these leadership activities, were extensions of things I have been doing for a long time, or started as a part of my Learning to Learn focus in 2021. 

Wellbeing 

I,  for the most part, continued with the wellbeing strategies I developed in 2021. However insomnia and stress started to creep back. This was probably due to my letting music practice lapse. Exercise and mindfulness meditation were not enough. Playing a instrument seems to be the most effective de-stressor for me.

Swift

There is always a lot to learn in Swift. Every year apple releases new versions of Swift, XCode, iOS, macOS, watchOS and tvOS. There is also the new Swift libraries and APIs. While I learnt a lot this year I feel I am barely scratching the surface. I am still working my way through last years WWDC videos.

Conclusion

All up I was less effective in converting my learning into day to day behaviour change in 2022 than I was in 2021. But I still made some good progress.

Related Posts

• Learning Outcomes for 2021
  
• Learning Plans for 2021
• Goal Setting
  
• Learning by Doing
  
• Select the Right Skills to Improve

Evaluate Learning Outcomes

t the half way point in my professional development plan for 2021 it is now a good time to review my progress . 

So far I have found the plan to be very helpful. Over the last six months I have studied a broad range of topics, some of those topics where within the plan and some where done in an ad hoc manner. Comparing topics studied within the plan to those studied without, the planned topics were studied in a more comprehensive and systematic way with more deliberate practice and social learning. This resulted in better learning outcomes with a more solid grasp of the subject.

Skills Learned

Learning to Learn

I completed my initial goals, finishing the practical, social and formal components with only bonus items outstanding on the progress tracker.

I finished a second course in addition to the one I initially identified and I was happy with the way I was able to put my learning into practice.

JavaScript

I completed my initial practical and social goals with the formal component still unfinished. A bonus practical activity as two video courses are still outstanding on the progress tracker.

I am happy with the improvement in my JavaScript skills and have been able to put my new knowledge into practice. The modularity and reusability of my JavaScript has improved. I am looking forward to finishing the final modules in my courses.

Reduce Stress 

The activities that I chose to combat stress were very effective and the WOOP Matrix was helpful in keeping me on track.  However while it was easy to keep the schedule when I was stressed it became harder when I was merely preventing possible stress in the future. I fell off the wagon in March but rededicated my efforts in April.

Functional Programming

I still haven't yet identified practical and social activities for category theory and lambda calculus. I am hoping they will help me improve my functional programming which is a style I have been utilizing with increasing frequency over the last decade.

 

.

Self-Directed Learning

t the end of November 2020 I put together a professional development plan for 2021 with the help of Knowles (1975) Six Step Self-Directed Learning Model.

Diagnose Needs

First step in the Self-Directed Learning Model is to identify your needs. At the time three needs immediately came to mind.

• Encourage my team to take more ownership of their professional development.
• Learn to cope with the stress of my job in a more effective way.
• Increase my skill with JavaScript to the same level as my skill with C# and Swift.

The reason I was creating a development plan in the first place was to lead by example. It had the additional benefit of organizing my professional development in a more systematic and structured way.

In the last quarter of 2020 my sympathetic nervous system became over stimulated flooding my body with adrenaline and cortisol causing insomnia, stress and exhaustion. I needed to control my stress levels by engaging in activities that activated my parasympathetic nervous system. Fortunately I already had a good idea how to do this. Over most of 2020 I had been studying positive psychology and the science of wellbeing, so I had a wealth of both theory and practical advice to draw upon. It was just a matter of customizing that advice to my situation and putting it into practice. 

I have been using JavaScript for almost a decade, however I had learnt it in ad hoc manner and my understanding is not as thorough as most other technologies I used on a regular basis. My understanding of many JavaScript Frameworks was more comprehensive than vanilla JavaScript. This is the very situation I warn against when I mentor and coach other developers. Also my JavaScript code tends to be less structured or modular than my C# or Swift code. Therefore my skills in that area needed an upgrade. 

Formulate Goals 

After using focusing questions to narrow down the skills I wanted to target, I decided I wanted to balance my attention between people and technological skills and also between concrete and more abstract skills. I came up with a two by two matrix and filled it in.

Focus	People	Tasks
Abstract	Learn to Learn	Category Theory & Lambda Calculus
Concrete	Reducing Stress & Refocusing the Mind	JavaScript & Knockout

To help me make the most of my development plan I decided to study learning strategies as my abstract people skill. I decided that developing my intrapersonal skills to control my stress counted as my concrete people skill and JavaScript counted as my concrete technical skill. To fill in the remaining area I decided to concentrate on mathematical theories that would help me utilize functional programming in a more effective manner.

Identify Resources 

It was reasonable easy to find online resources to support my learning, there is a wealth of online courses that are freely available. I added them to my Self-Directed Learning Matrix 

Diagnose Needs	Formulate Goals	Identify Resources
Learning Strategies
	Learn to Learn	Professional Development Course Learn to Learn Course
Wellbeing
	Reducing Stress & Refocusing the Mind	sleep - 8hrs exercise - 30min meditation - 5min play music - 15min
	Happiness & Wellbeing	The Science of Well Being Course
JavaScript & Frameworks
	Generic JavaScript	Advanced JavaScript courses MDN Coursera courses JS for web devs JS, jQuery, JSON web programming
	KnockoutJS	https://knockoutjs.com/
Functional Programming
	Category Theory	Category Theory for Programmers Book
	Lambda Calculus	Lambda Calculus videos 1 & 2

You would think that meditation would be the most effective activity for reducing stress, but it turned out that for me, practicing and playing music was the most effective method. Not everyone can use music this way. However most people have some sort of activity that calms them and helps them focus their mind, whether that is drawing, golf, chess, music or some other hobby.

Choose Strategies 

For Learning Strategies and JavaScript I used the 70-20-10 rule. I filled in a Learning Action Matrix to divide my learning activities between deliberate practice, social learning and self study. 

For controlling stress I used WOOP to help establish new habits. I filled in a WOOP Matrix to plan my approach.

For functional programming I delayed planning out my approach until the other topics where finished.

Implement Activity

I used a study tracking board to track my progress in learning JavaScript and track my progress in applying Learning Strategies.

I used a check list to track my adoption of stress relieving habits. If I missed an activity on one day I focus on achieving it on the next.

Evaluate Outcomes

The six month evaluation can be found in this blog post.

Conclusion

The Learning Action Matrix organized the development plan in a simple to understand structure.

Many of the learning strategies that I learnt came together to form a synergistic whole.

Books

• Self-Directed Learning: A Guide for Learners and Teachers by Malcolm Shepherd Knowles

The New Normal

t's been more than a year since COVID became a part of our lives and we have adapted. The world looks very different from what it did a year ago. Some things are better e.g. more telecommuting, some things are worse e.g. less social events. This is a look back on what it has meant for me and what it means going forward. My experience is hardly unique as most of us face similar problems.

Work

I started a new job in March 2020 and a few weeks into the new job everyone was transitioning to working from home. I was a little hesitant at first as the schools had closed and my apartment was full of noisy children. However the children were good about being quiet while I was running meetings. My team adjusted to video meetings and we were soon communicating far more frequently than when we were sharing an office. The company was committed to making remote work effective therefore the transition was well planned and the IT infrastructure put in place to support remote work.

We all adapted surprisingly quickly and everyone made allowances for the situation, if there were people passing in the background of a video or a bit of extra noise it was no big deal. 

Biggest requirement is to draw boundaries. When I first started working remotely I thought the problem would be that my personal life would bleed into my work life, however my family is good about not disturbing me while I am at work.  A bigger problem is my work life bleeding into my personal life. There is always the temptation to do one more thing. Also there are time zone differences so even when you're off work other members of the team are still working, and in this always connected world, there is the temptation to respond to queries. I have seen team members respond while they are on vacation or after hours or on the weekend and I must admit that I have done the same.

It is sometimes difficult to balance your needs with other people's needs. One of the attendees of my meetings asked to shift the time so that she could pick up her child from school. I was happy to ask the other attendees if they were okay with the new time then adjust the time. I had faced the exact same problem the previous month, but had made other arrangements rather than inconvenience my co-workers. I realize now that I should have done as she had and asked my attendees if they were okay with a new time. It is important to ask for what you need to succeed and thrive.

I am back to working one day a week in the city.  I prefer remote work and most of my co-workers feel the same. The company has gone from having a dedicated office to renting a co-working space. This also means they have gone from having dedicated on-premises servers to having everything in the cloud. 

Unfortunately the transition back has not been as well organized as the transition to remote. At the start of COVID there was a sense of urgency and a determination to get things right. Whereas with the transition first to partial on site work and then to a co-working space the attitude has been more laissez-faire.

My employer is not the only business to shift to co-working spaces and cities all over the world are dealing with a shift in tenancy patterns.  

Family 

You would think that being cooped up in the same apartment we would see a lot more of each other, but we actually see less of each other now. Part of it is that the girls are getting older and more independent, but part of it is lifestyle changes brought by COVID. We now have more than twice the number of devices in the apartment than we did before COVID. It used to be that the family would sit in front of the TV sharing a movie, but those days are long gone. Now the TV is only used for news and video games. The demise of the idiot box isn't exactly a tragedy, some would call it a boon. However everyone stays in their room, working on their devices or video calling their friends or watching media. Sometimes the only thing that breaks the illusion that I am alone in the apartment is when one of my daughters comes out of her room and asks me for help with her school work.

Thank the stars for card games. We played cards before COVID, I taught the girls when they were very young, and it has always been a fun shared activity but card games became a lot more important after COVID.  We still go walking around the park when the park is open and restrictions allow, but less frequently than we did. We also used to do a lot of improv games. Those have gotten a little less popular as the girls get older but are still fun.

We have to schedule time together now and make family time a priority, where before it just happened.

Exercise 

With the gym and pool shut down in the middle of the crisis I was reduced to running up and down the stairs. Thankfully things are back open again, but I still haven't fully gotten back into my old routine.

The girls had it worse with almost everything shut down. They are back doing most of their activities such as swimming lessons, gymnastics and dancing. However they still do less activities than they did before. I worry about the effect of spending so much time indoors has had on them.