When coding there are a lot of factors to consider, the time complexity of your algorithms, the space complexity as well, and even power efficiency can all affect the decisions you make and the flow of your program. It’s a complicated task and with constant distractions in our ever-growing busier and busier lives the need to make the coding process as quick and easy as possible is constantly present (of course it almost never is quick and easy).

One way that we can optimize our time effectiveness is clean code. What is clean code? As Thiraphat Phutson puts it in his blog, “The Art of Clean Code: Writing Code that Lasts“, it’s code that’s easy to understand, maintain, and extend.

There are plenty of aspects to writing clean code such as using good naming schemes for variables and functions, proper spacing, consistent indentation and bracket use, the list goes on and on. And just like there’s many aspects of clean code there’s plenty more attributed to “messy” coding.

So how does clean code apply to me? As a major in computer science the ability to code is almost the entire point of my degree. Learning how to keep my code clean and organized, making it easier for myself to understand if I ever need to come back to it as well as fellow team members and coworkers is incredibly important.

As I’ve mentioned my honors project in my past few posts, I’ll mention it again here. Although as I’m writing this my project has been submitted and is officially done in terms of what my professor will see for now, I’m not done with it. In fact, I’ve barely begun. Most of my honors project was geared around performing my own sprint for a product I’ve chosen to create. In the first sprint I completed almost no coding got done, most of it was setting up to be able to start programming the project.

This is where I can take the clean code skills I’ve acquired, and make sure that as I’m coding what I can only imagine is going to be a very complex project I’m keeping it organized and efficient. As Phutson mentions, clean code allows for maintainability, scalability, and efficiency, all things I’ll need for my project. He also mentions collaboration which is another fantastic aspect of writing clean code, but it doesn’t apply as much to my case with me being the only developer.

Clean code is an incredibly important skill to have in the computer science world and I’m grateful to have had not only an introduction to it but some practice with it as well. I will be sure to keep it ever-present in my mind as I code not just my current project but any project in the future.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

A sprint retrospective is an event that occurs at the end of a sprint where the team meets to discuss improvement for the next sprint. This is to say, the team gets together and looks back at the sprint completed and looks for areas of improvement that they can adjust for the next sprint.

Following the theme of my last few blog posts, I will be manning a one-man scrum team (which is an odd sentence). How exactly will a sprint retrospective look for me and by extension how would it look for someone following a similar journey through scrum?

A great place to start is knowing what’re the right questions to ask, thankfully Rodrigo Ribeiro has provided us with these questions is his blog, “How to Run a Sprint Retrospective 101: The Essential Guide”. Now, this blog was written with an entire scrum team in mind so let’s take a look at the four major questions he poses for a retrospective and look at them in our scenario.

“What did you like in the sprint?”

This is a simple question, but it may have more significance to our situation than you would think. As Ribeiro notes this section is mainly for giving credit where credit is due to your team members and making sure to thank them for their efforts. Well for us we are our team members, but that doesn’t mean we don’t deserve credit or appreciation for our effort. Taking a moment to pat yourself on the back for completing your sprint and telling yourself you did a good job can really improve your attitude and confidence when looking towards the next sprint.

“What is puzzling you right now?”

This question is an opportunity for your team to ask for clarification about roles in the team, as well as technical and functional purposes. For us, roles are not relevant as we are assigned all of them. As for technical and functional purposes, as the product owner we already know what the purpose of our product is, both technical and functional as we’ve designed the backlog. With this being said, maybe this question is better omitted from out one person retrospective.

“What didn’t work so well?”

This is the time for the team to express their feelings about the project. In our instance, this is the perfect opportunity to be fully honest with ourselves about our current feelings towards the project as well as our feelings about that last sprint. Were there issues with backlog items? Did we move the project towards completion in the same direction we set out product goal? These are very important questions to ask ourselves and to be fully honest about as we’re the only input.

“What are your improvement ideas?”

This is the section where you, of course, should ask your team for solutions to issues you’ve been having as well as general ideas for project improvement. So how does this relate to us? After the end of our previous sprint, with certain backlog items finished and maybe even some scrapped, some adjusted, and some still alluding a solution, we can take a minute to reassess our current situation and decide our next steps. Were some of the completed backlog items not completed to our standard, or in the direction we wanted to move our project? Are some backlog items unable to be completed now irrelevant or should a new way of looking at them be implemented. Without the input of others during a sprint it can be hard not to be one track minded and tunnel visioned so this is a great opportunity to take a breather, relax, and try to search for a new angle. Maybe write down some solutions, think them through, and try again with new tasks and backlog items for the next sprint.

It’s important as a one-man scrum team to be incredibly flexible, and getting held up on one backlog item can really stagnate progress and burn out a single developer. Asking these questions in the middle of the sprint will only lead to complicating something that’s already complicated navigating as one person. It’s better to do what you can during the sprint and assess and reevaluate with yourself after. From there you can make changes and move forward in the direction of your choosing.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.