Introduction
Before the module I felt like I had a good understanding of how to code in Python. I started teaching myself to code in April 2020, following some online courses and YouTube training materials, and embarked on this Masters in early 2021. Earlier this year, I came across a post on Reddit discussing the pros and cons of coding bootcamps where one of the users posted:“Teaching yourself to write code and expecting to be a software engineer is like teaching yourself how to type and expecting to be an author” (Anonymous Reddit User, 2022)
At the time, I thought she was overstating the case. This module has changed my perspective and helped me realise there is much more to software engineering than just writing functioning code.
Secure Coding Principles
As early as the forum discussion in unit 1, when reading Alberto’s post about Cross Site Request Forgery, I started to become aware of the gaps in my knowledge, specifically around security vulnerabilities and their mitigation. When following tutorials and courses for beginners, security was either completely ignored, or briefly discussed as an after-thought. Well, they say the first part in solving a problem is realising that you have one to start with.Discovering the 10 OWASP proactive controls was one of the most practical and useful pieces of learning I have gained on this whole Masters (OWASP, n.d.). They are clearly written and specify how to build security into software projects rather than bolt it on to a completed project. Ian, my team mate in the group work, decided early on that we should use these measures to drive our development assignment and, looking back, I think that was a great decision. They gave us a clear path of action to develop securely and ensured that we considered aspects of security that we may not have done otherwise, like encrypting data at rest.
I will definitely be using these controls going forwards in my personal projects and in my professional career. In fact, I am currently designing a workshop for Associate Engineers at my workplace on how to use the OWASP proactive controls to build security into our codebase, which I will be delivering in mid-June.
Teamwork
I’ve always considered myself to be a good teammate. I build good working relationships with others, communicate freely and openly, respond well to feedback and have a sense of responsibility and fairness when dividing tasks. One aspect of teamwork that I have struggled with throughout my life is how to deal with those who do not pull their weight. Previously, when this has happened, I have tended to lose my own motivation to make the team succeed and often settled for doing just enough. I am proud that this did not occur during this module. Reflecting on why this is the case, I think that myself and Ian felt like we had a point to prove, that we could do it without help. “The smallest team with the biggest ambition” was our motto. I want to carry this into my life outside university and continue to do the best I can even when hampered by absent teammates. I finally realised that I can’t control what the absentees do or do not do.One of the drivers of success in our team was our regular communication. We used Slack for this, and this was a major improvement on my group work in previous modules when I had used Discord. It was difficult to have conversations with one of our team, Kaoru, as she was in a far-removed timezone. Subsequent reading about issues within global agile development teams has led me to realise that this was not an issue specific to our team. It is listed as one of the most commonly identified risks to the success of development teams across diverse geographies (Verner et al., 2014). Some of the mitigations suggested include the use of asynchronous chat tools, like Slack, and regular meetings. We tried both of these, but to no avail.
Another aspect of our success was the method in which we divided the work. We based the divisions on the team members’ likes, interests and strengths. For example, Ian really likes working on backend code, and so he took this responsibility. I enjoy writing tests and getting good coverage, so I took this task. In previous groups I have been a part of, we were more concerned with splitting the work evening than with catering to each other’s strengths. Going forwards in the degree, and also in my professional life, I am likely to put more weight on an individual’s preferences than on any misguided attempts to be ‘fair’. This seemed to work well for us, and liking what we were doing was one of the motivational factors than kept us going when the workload was heavy.
Development Practices
One of the aspects of our assignment delivery that I felt could have been improved upon was the setting and following of guidelines and rules for development. We initially agreed that nobody should be able to merge into the main branch without a PR reviewer, but we soon discarded this, and each of us merged when we thought we had good functioning code. This led to our main branch being broken on a couple of occasions. Code reviews are good for a number of reasons, one of which is that sometimes a developer not directly connected to the code change can spot something that somebody working on it may have overlooked. My workplace disables merges until the PR has at least 2 reviewers. On future team projects, I’d like to set up rules on Git to make it impossible for merges without reviewers.
Conclusion
This feels like the module where I have made most progress - spotting gaps in my knowledge, learning to use some good new tools (sonarqube, git actions, Kafka), improving my teamwork skills, and generally moving towards being a better, more complete software engineer.
References
OWASP (n.d.) OWASP Proactive Controls. Available from: https://owasp.org/www-project-proactive-controls/ [Accessed 14/2/22].Verner, J., Brereton, O., Kitchenham, B., Turner, M. Niazi, M. (2014) Risks and risk mitigation in global software development: A tertiary study, Information and Software Technology, Volume 56, Issue 1, Pages 54-78, https://0-doi-org.serlib0.essex.ac.uk/10.1016/j.infsof.2013.06.005.
