Two Years of Reflection

September 30, 2020

One of the things I learned about during my time as a learning assistant at Rutgers University assisting in classes and teaching in classes is the term metacognition. A page on Vanderbilt University’s website describes metacognition as

the processes used to plan, monitor, and assess one’s understanding and performance¹

This was one of the crucial ideas that we were taught to consider and understand when guiding our peers through the vast web of knowledge in each class. From what I remember being told, those students who succeeded in classes were usually better at thinking about their thinking. Or, in a sense, reflecting on what they’ve learned, and how to integrate it into their current understanding of the their respective subjects. By engaging in metacognition students can help improve recall, fix misconceptions, and improve the speed at which they can solve problems in the specific domain. It also helps identify strengths and weaknesses in the subject matter which can drive the areas a student may study or practice.

Having just recently finished two years in the workforce, and about to enter a PhD program where I will most likely be conducting a whole lot of learning, I think now is a good time to begin to reflect on what has been accomplished over the last few years. It is also where I could look back on where I could have made better judgement and improved on the products that I delivered. Also, I want to reflect on my time in my company as a whole, and where I think the company made missteps and where it earned my respect. Hopefully, trying to acknowledge these parts will enable me to find areas where I can improve as an engineer as well as help me identify organizations and aspects of which that I should look for when seeking work in the future; skills that I’m sure will be integral in helping me reach the end of this degree program and beyond.

For the rest of this post, I’m going to highlight some of the areas I feel that I struggle with, and then research and write about things I can do to improve myself in those areas, along with some plans of action that I can take

Design and Deliverables

One area where I struggled before, and still struggle is clearly communicating technical design verbally to others. I tend to rely heavily on depictions and diagrams to get my points across to others. I find that during explanations, I find myself moving from one point to another somewhat erratically. Unfortunately, I felt that there wasn’t many opportunities to improve on this over the last few years as there were only a few projects that required a thorough design which needed to be communicated and approved before implementing.

Personally, I feel it’s okay to lean on diagrams to help explain technical concepts, but in the future I need to find a better way to make sure my explanations logically flow from one point to the next, using the diagram more as a guide, rather than leaning on it to do the explaining. This is one skill that surely applies across a multitude of areas such as technical interviews, research presentations, and engineer.

Searching around the internet, I found a few places where some say that diagrams (or whiteboards) are fine for communicating technical information². I think whiteboards and meetings are fine for conveying architecture and communication - but I feel they are best used for fleshing out early ideas when collaborating with co-workers. Final designs should be able to be described in technical documentation that can be accessed and read by others with less context, and not require someone else present to explain points in the document. Apparently, there is a standard - IEEE 1471³ which describes how to communicate and document software architecture. Reading further on the IEEE website, this document has actually been superseded by IEEE 42010-2011⁴. Both documents I’m sure provide valuable guidelines for communicating system architectures, so I will be sure to read them to hopefully apply them to my practice.

Project Management

After experiencing the last few years, I think its crucial that companies, especially startups, justify the work they are doing by having a clear GTM (go-to market) strategy⁵ for their products. Having a clear strategy not only helps make it clear to the investors of a company how the product will succeed, but also the employees as well. Small startup companies are inherently risky - every employee of the company is usually putting something down on the line and will want to know how their work contributes to the company’s success.

To some extent, you should always listen your direct manager’s directions. They should be able to justify why or how the work you are doing fits in to the bigger picture. If the company has a clear GTM strategy, then your manager should be able to give you a straightforward answer to what company goals your work is contributing to. If they aren’t able to do that, then there’s probably an issue with your manager, or the company. I think personally, I could have done a better job asking the right question as to where some of my work would fit in and how it would be used by customers.

Now, for small tasks (1-4 days of time) I would argue that it’s probably not as necessary to understand the motivation behind each task. However, if you know you’re going to be involved on a project for an extended period of time (1 -3 months or more), then I think you should be able to hold your manager accountable for being able to explain where the project fits into the bigger picture. If they aren’t able to do so, then maybe it is time to start re-evaluating your current position, team, or even company. Management should at minimum be able to justify their decisions for the direction and assignment of projects.

To be clear, startups pivot for a vast number of reasons, and sometimes the management might not have the clearest picture about what the next steps are for the company. However, if the company tries to hide the fact that it is struggling, or feeds lies about progress, then I think that’s a clear warning sign when things are bad. If your manager(s) are at least honest about what is happening, then you should be able to trust in them to do the right thing. In the future, I’m going to try to do a better job asking the right questions about my assignments, as well as team direction.

Summary

There are surely a multitude of other areas that I could have performed better in. The two that discussed today are things that stuck out starkly to me a couple of times over the last few years. I want to be able to make permanent improvements to my ability to work in an industry setting that will help me improve as an engineer and as an employee. Singling out and writing about them along with giving myself concrete actions to take to improve I hope will improve my prospects for the future.