Burn out

Burn-Out...

You read about it on LinkedIn and Forbes but those articles never prepare you for when it actually happens. To be totally honest, I've come within a gnat's whisker of burn out twice within the last six months and it is most certainly not good.

In this blog post, I want to go through some common symptoms, but crucially to put down for each item, what it felt like and how I ensured my boss knew that despite burn-out issues I was still willing to put the effort into the project. All I can say at the moment is that I'm glad I have caught it, and hope that with the end of the project in sight (Nov 16), I can kick it well into touch.

So burn-out, what is it and why as an academic, should I care for a staple buzzword on LinkedIn?

Symptoms:

1) Anger:

- I found that I was becoming more irritable at work, particularly when it became evident that I needed to take the initiative and move more of the team's work onto my own task list. I became really quite angry at the asymmetry that was becoming evident over the course of months of project planning documents. No doubt this contributed to my lack of holiday and weekend time over the last year as quite simply I was the only individual with either the skill set or dedication to get various blocks finished.

2) Performance:

- I found that on particularly hard days, my productivity was somewhere down near the floor, along with the discards of the many coffee cups. I found that weekends, even those that were quite relaxing, no longer brought my productivity back to where it needed to be. The issue here is that it added to the issues of project slip and scope creep, in that my task list kept on growing as I took other's tasks to completion and grew at a faster rate than tasks were being completed.

3) Insomnia and Sleep Deprivation:

- I found this to be a big one, not being able to sleep until gone midnight, early mornings to get into work early despite a 40min commute, coupled with broken sleep due to our pets.

- I found myself relying more and more on coffee and sugar as Becky's work patterns changed from rotation to rotation

4) Chronic Fatigue:

- Trudging to work, a pain in the chest, limbs that are complaining as you walk, and a headache that lasts until lunchtime all seemed to become a regular occurrence. Coffee did fix this but it became harder and harder to last until lunch, and I found my lunchtimes shifted closer to 11.30am or 11.00am. I started needing coffee in the afternoons just to keep the day at least reasonably productive and I started to require music more often to keep the tempo of work at a steady pace.

- Weekends for a long time have been more about catching up on sleep than social activities.

- What can you do if you need to get your head down into some code, but your too tired to do so? Coffee, sugar? The number of mistakes in simple code syntax increases and adds to the annoyance.

Causes:

1) For me the simplest cause was probably not saying "no" when asked to take on another work package. This is always a fine line as we all want to look productive, trustworthy and ready to get into the job, to our employer. Ultimately though the issue came down to skill sets, in that I was the only one on the team that had the skill set required for work package A, B and C, in addition to work packaged 1, 2 and 3. When that is the case you simply cannot say "no", but your task list begins to grow outwith your control.

2) A second issue with our current project was others on the team not pulling their weight or not bringing themselves up the learning curve for a complex task coming up in the next few weeks. The classic case of this on this project was the Embedded C required on each digitization and signal processing Hub on the FLITES tomography ring. If no one else on the full time staff of the project, the only option is to bring in temporary staff. Having done this with an extra PhD student on the team, Embedded C was developed at an initial fast pace, but once they went back to their main project, the same issue arises, in that the entire Embedded C project falls onto one man.

3) Scope creep is perhaps an issue that was endemic as part of the issue with a team member not pulling their weight. I found that natural item or block precedence forced blocks to be reallocated to me in order to get them done before the block I was supposed to do. Likewise if the complexity of a block is only illuminated once work on the blocks begins then scope creek becomes rapid. For the FLITES project a representative example of this would be the custom Intellectual Property Interface (IPIF) required between the main experimental data FIFOs and the embedded micro-processors heap/stack memory. It was quite easy to identify we needed a bridge between the FIFOs and the Direct Memory Access (DMA) engine that performed word-wise data movement, but the complexity of the internal state machine was not evident. My final version of this block needed loop-back functionality, differing states depending on which FIFO (processed data or RAW ADC data) and required compatibility with the AXI protocol without in-house ability to simulate this bus.

To Close:

The FLITES project comes to a close at the end of November, while my contract is renewed on a platform grant on 1st October. Luckily while it looks like there will still be project pressure, I can now do these remaining blocks and tests without the issues of poor team members. While this does mean the remaining tasks are fully my tasks, this is a weight off my shoulders and I'm actually much more happy with the next month's work packages. No doubt I'll need to severely edit the work of this particular team member, but at least I can do this with the headphones on, a good cup of coffee and with the knowledge that I'll be able to spend some quality time with my family on the weekends ahead.

I'll keep you posted...

Ed

UPDATE: (E.F - 7th Nov 2016 10:00):

So despite now being on a new grant, which should re-balance the books towards at least having the time to write papers. It seems that is not to be. In the course of 3 years I've had 3 direct ideas of 'Lets start writing this paper' some of which were for invite to submit special issues (which we all know are easier to get into), totally Veto'ed. Now sure I understand we need to get the development work done, but at this point of the project, we also need to get the content we have out there, and to do so ASAP.

To go back to the above closing paragraph, the work of this poor team member was entirely sloppy, minimal if not zero testing and so poorly commented that I was forced to spend an entire day simply getting it to be commented, with an appropriate header, revision history and to make sure its version history is in-line with what it should be.

Aside: Get this, he sent it to be as "FILE_V2_0", it should have been version 1.9, but in the revision history that I'd put in in a previous version, it was v0.01! O wait what's that, v0.01 was the created date, some 6 months ago!!!

So, this post-doc is quickly turning sour in that I've picked up the pieces of significant non-novel development work for too long, so long in fact that I've not been able to get into the lab to do any experiments and therefore the number of publications is now going to present a serious issue for my career!!!

How do we ratify workloads then in academia. In the last 3 years I've:

- Developed the FLITES PCB (Single-Handedly) - No novelty there!

- Developed the Firmware (leading the team, but as mentioned ending up taking back tens of tasks elongating my own development timeline) - No novelty there!

- Implemented UDP Ethernet with a custom packet structure from the ground up (Single Handedly). Lets put it this way 100MB/s Ethernet was ratified by the IEEE in 1995, hardly novel...

- Developed the Embedded software, again we are not implementing anything novel, but of course being at the back of a jet engine we need these functionalities before we can do any science.

- Testing has been laborious and again pretty much single handedly.

- Documentation seems to be beyond the poorly performing student on this project, so I guess that's up to me too.

- On top of that I need to go out to the Madrid testing site, with an expectation from the PIs that IU can fix what is turning out to be a huge signal path in the field. I'm sorry but if this student doesn't implement loop-back tests for each block in the chain (as I did), then how can one identify, debug and correct an issue! Is is the PCB? Is it the SerDes? Is it SerDes clocking? Is it the non-novel, poorly written code of the digital lock-in amplifiers? Is it the experiment synchronisation block? Is it the main data FIFOs.

- Of course "muggins" here spent the time so that blocks for the back-end all have self tests, loop backs and on-initialisation notifications to the user of an issue. If the direct memory access fails then I know, if the custom written IPIF falls into an error state then it outputs known codes for various error conditions, if the embedded micro-processor fails to set a configuration register then it flags that to the user.

The role of a post-doc is complex, but we are also expected to perform novel research and to publish that research. In the first few years I was OK with doing development work only, as the end application was novel, however as other people's work became increasingly sloppy, as I became expected to take their allocated tasks back, I've ended up not being in a position to publish, not even when I have 80% of the material!

Let me put it this way, if we were to add pie charts into our documentation that showed engineer work allocations, I'd be the poor sap that has been allocated 96-97% of the work! Quite simply with a team of two engineers, if one under-performs, does not have the required skillset (despite training and the expectation that a Ph.D is "self-directed learning"), then yes, the project time scales will become skewed. No longer can you say #weeks/#people for it becomes #weeks/1. There is a reason why the combined PCB/firmware/software/test flow has taken two and a half years. On top of that, perhaps the entire reason why I've hit burn out, what feels like for the third time this year, is that I've been underutilising my holiday entitlement. 7 days from a possible 32 days. O wow, great. Perhaps the very fact that when the project came under pressure, I stepped up to the mark and worked extended hours during the week and weekends, while under-performing student team member was not prepared to work the hours required nor could be be bothered to do any tests.

As another aside I'll demonstrate how poor this student is. Fine, the is a learning curve so I respect when people's code is poorly documented, I understand the idea of getting it working rather than the supposed extra effort in correct version control and commenting. However that is at the start of a learning curve, not after 3 years of self-directed learning, being passed tutorials, going to training courses, attending the undergraduate courses and having a development board on ones desk for 3 years. Should I be the one that has to check that variables have been declared? Should I be the one to ensure the high-speed clock stays on the clock tree (rather than a clock gate removing it from the clock tree and thus not passing timing closure)?

The student's project is a digital lock-in filter producing in-phase and quadrature outputs. Quite surprisingly, despite having a computer controlled signal generator on his desk he STILL has not measured the frequency domain behaviour! ITS A FILTER! Its digital but has he done tests with different sampling rates, different numbers of bits? NO. He looked at the temporal domain, ok sure, but is it stable if you give it a step or impulse? It implements a bog standard unitary co-efficient rectangular in time (sinc in frequency) filter, but what about other filter coefficients? What about longer or shorter integration times? What about the FWHM of the band-pass in the frequency domain? What about the rejection ratio or fall off into out of band? What about side lobes? What about noise, perhaps clock phase noise/jitter, or the quantisation noise? The fact these haven't been investigated demonstrates something, and I'll let you decide what that is.

UPDATE: (E.F - 7th Nov 2016 : 11:15):

To be honest, I was recommended to apply for a job with Xilinx ASIC development team, so I have. It would be a shame to leave the university as I have a number of opportunities (papers, grant proposal, small fellowship, book chapter) that are still open ended. But at the same time, the recruiter is putting me forward with a salary expectation a full £7-8k higher than my current.

On top of that I suspect Xilinx will be a little more reasonable when it comes to CPD, I'm tired of being told there is no money for the advanced courses, but some of the cheaper 'introductory' courses are financial. In my opinion, there is a reason why those courses are cheep, and its because they are not meant for engineers that have already dragged themselves up the learning curve of some technique.

I'll see how I progress in the application for that Xilinx role, but ultimatly I need to prevent burn out from effecting my family, which it seems to be doing already!!!