Furness College Work Experience
Day 1:
My week placement from Furness College at 3SL started with an introduction to the company’s employees, courtesy of Jan. She briefly addressed their roles and explained the layout of the office, before showing me to my desk. There was a laptop set up ready, and it was on this I’d be working for the rest of the week.
The first task given to me was to work through Cradle’s comprehensive tutorial, so I could learn its functionality through experience. This knowledge, albeit gradually gained, would serve me well over the following days.
Day 2:
My second day began with one of 3SL’s Support Engineers, Cam, explaining how to operate their development database. It was very intuitive, being another instance of the Cradle software. If anything demonstrates a company has confidence in its product; it’s the fact that they use it themselves.
On here, the company had prepared a series of tests for me to perform across many of Cradle’s various facets. These helped to expand my understanding of Cradle’s applications, and gave me a valuable insight into the procedures involved in testing a software product.
Day 3:
The third day, I was taught again by Cam on how to navigate and utilise the support call database, where the company logs any exchanges they have with their customers. One feature of this particular service is said database’s external accessibility – which, if they’re so inclined, allows Cradle users to see how their call is progressing.
Some calls may reveal flaws in the software; either by exposing bugs overlooked during testing, or by bringing to light new issues.
Customers may also call to investigate whether Cradle provides a certain feature they’ve found themselves needing. If it doesn’t, the suggested feature is filed into a list of those potentially included in the future. As this list is weighted by demand, periodic reviews are held to consider Cradle’s direction with these requests in mind.
I also learned about the internal testing, performed by the support department prior to software release.
Day 4:
On day four, I had the opportunity to meet the company’s programmers. They provided me with a document of both requirements and background information to their current project; then asked me to consider how I would approach the same problem. I was told to consider how elements of the software already present could be reused to accomplish a different objective – one of the key skills for any developer to have. This is because modularised code is not only far more versatile; but far more stable too.
De-constructing, the method by which a goal is achieved into componential steps (allocating a minimalistic concern per element) allows one to maintain track of all the necessary inputs and outputs at each. With these in isolation, another programmer – or even the selfsame at a later date – need not know exactly how a particular element of the broader system works in order to utilise it effectively; as they know what to feed into it and what it will produce in return.
I also learned one of the reasons bugs can appear only on the user’s version of the program, is that the optimisation processes of the IDE-external compiler can make alterations to the finalised code. Whilst this is typically a positive thing, there are instances whereby the structural changes may interfere with the core functionality of the software.
Day 5:
My final day of work experience at 3SL consisted of: watching a pair of videos explaining software as a service; being given a tour of the company’s social media, including some of the behind-the-scenes on how posts are produced; and writing this blog post to record everything I’ve learned this week.
L Anderson Work Experience Oct 2019