January 2021 – Duke DataScience and Development blog

Easy to Read

Readability is a corner stone of good coding practice. Making things easy to read in any area is of importance and of value. The standard of what easy to read is somewhat dependent on the circumstances, but when allowing people to look at something and quickly understand exactly what it is saying is a pretty easy to read way of putting it.

Easy to read applies to so many areas in the field of computer science not just code, but comments, documentation are some of the primary areas. But what about project management, communication, and simple organization? The value of easy to read is that you can look at something and know what you need to know with out spending a significant amount of time just trying to understand the way it is written let alone the content.

Easy to read code is one thing and something I strive to do as I have been train for a long time, but when creating our team’s Trello board I found that I had to create a new definition of easy to read or maybe better said a new way of applying easy to read. Within the Trello board by simply adding a few bits of information to the titles of our cards. The amount of information that can be packed onto a single card is impressive but again it is a balancing act. This created an already easy to read board just a little bit easier so that way people did not have to dig into the card for relevant quick information.

All of this may be elementary but I found it to be a challenging thing and helped me to again see how CS basics apply to so much more than just Computer science. In communication making the main point easy to find and understand makes sure that people who only read a line or two have the opportunity to get the general message. Making information that you have to look at everyday or not easy to read will allow us to spend less time trying to find what we need and more time getting work done.

The KISS principle applies here keep it simple stupid and can help us to create easy to read information that will benefit not only other but also ourselves in the short and long run.

Flexibility

When working with other people, you will, without a doubt, have to make changes or adjustments based on these other people. People are complicated, and working with them is complicated. A key trait that is needed to work in any team or group setting is flexibility. Flexibility is not just beneficial when working with teams but also when working on projects for other people.
The idea that we will always get everything right is entirely wrong. The idea that other people are always going to get things right is also wrong. Unfortunately, people often make mistakes, and we will have to deal with them. The ability to change plans or have them changed for you and keep on going is crucial in almost every area of life.
Flexibility is a quality used to describe materials, people, plans, and it means bending easily without breaking. Simply you get tested or stretched, and you don’t break. Breaking during a project is never a good thing, and breaking and taking it out on other people is not good either. Other words that people use are resilience, mobility, openness, and versatility. Having these traits takes you from being stuck in your own ways or own forms of thinking and opens you to new concepts, which is exactly what learning looks like. Sometimes being flexible can mean that you have to do more work, but it makes you an easier person to work with and provides a better environment in general.
I like to think of myself as quite flexible when it comes to plans or projects, and my flexibility was put to the test recently in my capstone project meeting. We are now to the stage where we get to move onto the implementation of our project. My team and I were putting together designs and sketches of what our project will actually look like. We wanted to make sure we were all on the same page and get approval before implementing it from our project sponsors. Well, when we presented our layout to our project sponsor, he had some questions that we did not have the answer to and, after some digging, found out that there had been some miscommunication between what he wanted the process to be and what our design will look like. It was honestly very odd because we had been communicating about this the whole time, talking about what we wanted the process to be how things would be implemented but never before had he said that we were off base. Anyway, after a fair bit of discussion and lots of clarifying questions, we understood what it was that was different and now have a much better picture of what things will look like. Our implementation actually got a little easier and definitely more clear. All of this is helpful, but at that moment, I felt like I had completely missed something or we had not had all the information we needed. At that moment, if I was not flexible, that would not have been nearly as productive as it was. Flexibility has some stress built into it, but how you respond to that stress and pressure is what determines if you break or just bend a little.