By : Elliot Yesmunt, Software Engineering Intern
About half of my summer here at SEP has been spent developing a front-end for the new time-entry tool. As work for my team’s client-facing project came to a lull, we sought a way to learn the React JavaScript framework which has become very popular in the last few years. Since Adobe Flash will no longer be supported in 2020, our current time-entry tool was going to need an upgrade. It turned out to be a great way to learn React and Redux and also an opportunity for me to learn how a team can pick up a new language and create an awesome looking web-app in a matter of weeks!
There were a few things I walked away with from a practical teamwork standpoint that I hadn’t considered before this project.
- When knowledge of a language is scarce, pool the knowledge by mobbing in the initial stages.
- Once everyone has some degree of aptitude with the language and tasks are able to be worked on in parallel, pair programming can be beneficial to both the learning and production processes.
To elaborate, in the initial phase we were defining a lot of smaller design “habits”. We talked about the pros and cons of different designs, and everyone was conversing and getting on the same page. The mobbing also helps everybody get familiar with the syntax and general structure of the language. The first few days there was no room for doing any of the work in parallel since there were only a few files in the whole project. We would have been stepping on each other’s toes left and right. But once the project got big enough, tasks were broken out and we grouped together in pairs or triplets. I found the pairing stage very helpful in solidifying my understanding of React and how to use it. What made this difference between the effectiveness of pairing versus mobbing in this phase, was that I was more easily able to stay engaged in what we were accomplishing in our task, and I could “stop the train” and say, “Wait…why are we doing this?” or “what is this again?” without feeling like I was disrupting the flow of the whole team. Looking back it was a great experience on which I will use to improve future projects, both work related and pet-projects with friends.
On the technical side of things, there were a few key-points I want to remember for the rest of my coding in React or in any other domain.
- Readability and understandability do not always coincide with elegance in software.
- Try to write code that will be easy for anyone to learn and add to.
- When I refactor something, ask myself: – Is it easier to understand?
- Does it help decouple the code?
- Will it now be easier to add to or modify?
Something that I realized with programming in React was that abstraction is best when it is clear and understandable from the name. When a class has a concise name and functionality that follows its name, it is a clear abstraction and grouping of logic. But if this is not possible, it may be best to leave it where it is even if it makes a function or class a little bit larger. Because this way, when a new person looks at this larger piece of logic they don’t have to go hunting down what ambigiousFunctionName is actually doing. All of the logic is presented right up front, and they can take it all in at once.
I really appreciated the opportunity I had to see a team of professional, seasoned software engineers start a project in a totally new domain. I was surprised how quickly everyone was able to adapt, learn and construct a sharp looking, almost completely functional, web application in under two months. It was another fun and interesting summer internship with SEP.
