Since finishing my studies in Computer Science at the University of Edinburgh, I have spent the last two years working at Adaptive. Here, I have progressed from the graduate program onto real projects. In this article, I will contrast my experience studying Computer Science and how it compared with my time at Adaptive.
Studying Computer Science: Learning to solve problems
I started my CS studies by asking the question: what is Computer Science? The internet provided an overview which gave me an idea of the courses I would study.
My courses ranged from highly theoretical, such as Theoretical Computer Science - which looked at problems of satisfiability - to Object-oriented programming. Yet, despite all of the courses, I often wondered about how I was going to apply linear algebra, or discrete math, for example.The knowledge imparted was extensive, but there was less time dedicated to practical work.
Most of the courses at university followed the same pattern: we covered some theoretical concepts, followed by one or two assignments to put the core materials of the course into practice.
As an example, in Computer Architecture, we looked at caches (memory and its history) and CPUs, and for the practical assignment, we had to implement some cache policies on a simulator and evaluate them, measuring time efficiency for data retrieval.
This pattern of teaching had a huge impact on my understanding of Computer Science. I began to see it as a study of problems and solutions in the technology space. The problems were often defined using formal language in the form of logic. Or they could be formulated as a question, such as: “Which cache policy is most efficient?”, or: “What are the pros and cons of different cache policies?”
Coming up with a solution would usually involve developing an application to help answer the question, and gather data for the conclusion.
I took this mindset of identifying problems and coming up with their solutions with me when I joined Adaptive, and here I was able to take it to a whole new level.
At Adaptive
Graduate Program
Like all new graduates, I underwent the same structure:
Reading materials => Build an Application => Work on real projects
With a mindset of problems and solutions, when I was first introduced to what a web application was: my first attempt was to define it. And the definition was something like this: a web application is an application that runs on the web. That can then lead one to theorise what an application is etc. and so on. The solution would have been something like running an application on the web using HTML, CSS along with Javascripts or any of the libraries such as React.
Information on React, or HTML etc.., are not defined formally, rather one gets an idea of how to use them when building an application. In our case, we made a stock tracker, see below:
In the process of building the “stock tracker”, I came to the realisation that back at university, the problems are often demonstrated in isolation. Take for example the cache problem, we never saw how the cache was connected to the CPU or how the operating system manages it, rather we investigated the pros and cons of different policies of cache on data retrieval.
But the stock tracker proved to be a very good exercise demonstrating how several problems were lumped together and a good way for us to work on our skills on combining several solutions to solve each problem. We looked at how we structure the file and code as well as making architectural decisions such as which libraries to use. This was under the supervision of some of the seniors such as Bhavesh, Frank and others.
In House Project (Reactive Trader)
Reactive Trader was my first real project at Adaptive. In contrast with the stock tracker which we had to build from scratch, Reactive Trader was a fully functioning application. Most of my tasks were therefore centred around extending Reactive Trader with new features or resolving existing bugs.
The dynamic here changed, as we were no longer in a group composed of graduates like in the stock tracker, but we had a project manager, a BA, and a UX designer. Not only was I learning more about the role of each of these people, but I also had to figure out who to turn to in case I had any questions regarding my tasks.
If I were in doubt about the layout of the application or design structure, I turned to the UX designer; if I got stuck and predicted that I would not finish the task in time, I spoke with the project manager; if functional requirements were less obvious, I asked the BA.
Here, I primarily faced the problem of identifying the flow of information within a scrum team. At this stage, I began understanding that clarity in communication is the key. As the software or application is evolving, identifying problems that halt communication between all these entities will enable things to run more smoothly. This will in turn mean that goals are met more quickly which leads to greater satisfaction within the team and among the stakeholders.
At this stage, I had a clear understanding of who to turn to for which problems, developing communication with my colleagues. Not everybody understands the complexity of logic language which I learned at university, so I had to think about how to effectively get my point across.
Client Projects
After initially working on in-house projects, I made the switch to working on client projects. The dynamic is different as the source of requirements come from the client. This makes client projects a great source to learn and encounter different types of problems.
With the current client project, the application we are building is very involved, with a complex structure. For example, we have a form with multiple entries, some of the entries can be expanded or collapsed. The different entries are often interrelated. If I select an option on entry A, and want to select some options in entry B, entry B options should be filtered based on entry A. Furthermore, requirements are quite fluid so they are regularly in flux.
I have greatly admired Leon and Francisco’s approach to dealing with constantly changing requirements as described above. We capture functional requirements first by creating the entries and disregarding the relationship between the entries. The remainder are captured as technical debt. In the future, as we have a clear understanding of the direction, we can then handle the technical debts. This is one of the key things I have learnt that generalizing solutions can often put one in a box. It is better to be open minded to changing situations and challenge one’s assumptions and approach.
Other aspects of things I have also been able to reflect and observe from my teammates is how to integrate the Adaptive culture into how I deal with the clients. At Adaptive, we have a cookie box, which gets refilled every now and then. First time we arrived at the client site, they did not have this. We bought cookies and invited the clients to our cookie party. This might seem minor, but it was instant hit with both the clients and ourselves and it also reminded us of the office.
Final thoughts
At Adaptive, I have had the opportunity to challenge my understanding of technology, on the problems and solutions mindset. The problems are not presented in isolation; rather they are multi-dimensional in nature. We deal with many different entities which all use different language jargon so being clear and concise in communication is key for a team that delivers.
I have also come to appreciate something which I am still trying to understand which is composition. Composition is a concept in programming which deals with creating complex pieces of code by combining simple ones. I see this concept fits very well with nature in general as most of the equations that describe nature are simple, but nature itself seemed to be very complex. Intuitively, I think complexity should be a composition of simple things.
This is an area I am currently investigating and I hope to write more about this in the future.
Thank you for reading.
Moise Lubwimi
Web Developer,
Adaptive Financial Consulting
