What if I were to name the top skills/discoveries I made during my 6-month internship?
A big doubt I had in my newly formed Tech career was whether I had enough coding experience 🙂Even though I had a fairly OK GPA, I was nowhere near some of my peers in terms of coding knowledge or project experience. This was what lead me to apply for an internship at 99x as a Full Stack Trainee Software Engineer.
1. From console.log → debugging tools
Back in uni even though the concept of debugging was known (try, catch, etc.) by textbook definition, for almost all projects, my go-to was console.log:
onOrderItemDelete(e: any) {
console.log(e);
this.currentPackage.items.splice(e.currentIndex, 1);
console.log(this.currentPackage.items);
this.getPackageTotalWeight();
console.log(this.totalWeight); //ugly right?
this.packageForm.patchValue({
totalWeight: this.totalWeight,
});
}which would also result in the console getting flooded with junk.
However, the sharing of my screen when debugging with teammates is when I learned there are always debugging tools (Ctrl + Shift + I on Google Chrome).
Since most modern browsers (and even IDEs) have built-in debugging tools, Using Chrome I discovered that the content of the DTOs and the call stack (Sequence of function execution) are observable from line to line.
onOrderItemDelete(e: any) {
this.currentPackage.items.splice(e.currentIndex, 1);
this.getPackageTotalWeight();
debugger; //the magic word
this.packageForm.patchValue({
totalWeight: this.totalWeight,
});
}This shows the content of variables, and how it changes from line to line along with the sequence of nested executions in the call stack.
Now, it takes only around 5 minutes to debug which took me around 30 minutes to debug earlier.
2. From if-else, loops → map, reduce, filter
When I was assigned a task to map a certain DTO to a presentable format in the front-end, The 1st choice then was to use if-else, loops and transform them. It took both a huge amount of time and many lines in my initial code and was considered efficient.
The mediocre if’s and For loops (1):
let orderChannelIds!:string;
for (let f in response) {
orderChannelIds.push(f.orderChannelId);
}let orderChannelGroup!: orderChannel[];
for (let fi in response) {
if(fi.orderChannelId === ocId){
orderChannelGroup.data.push(fi)
}
}
After a friendly chat with one of my fellow senior developers, I was enlightened with the concept of map, reduce, and filter. Some built-in functions of JS and TypeScript. Finally not only did the code look simple but was also executing faster with fewer side effects.
Chad map, filter (2):
const orderChannelIds = [...new Set(response.map((f) => f.orderChannelId))];
const treeStructure = {
data: orderChannelIds.map((ocId) => {
const orderChannelGroup = response.filter(
(fi) => fi.orderChannelId === ocId
);
}
}Afterward, I was able to reduce a previous function of mere 20–30 lines to just 3 or 4.
Chad reduce:
const calculatedWeight = orderPackage.items
.filter((x: OrderPackageItem) => x.itemQuantity > 0)
.reduce((sum: number, item: OrderPackageItem) => {
// calculation logicreturn .....
}
At present, it has become a habit of mine to almost not use if’s or for’s 😅
3. From ‘Thinking for 10 minutes and coding for 3 hours (and still failing)’ → ‘Thinking for 2 hours and coding for 10 minutes’
This is what my normal coding life cycle looked like before. Trying to do everything only using the programming languages and frameworks I knew already, I never was the one to get out of my comfort zone in terms of new technology👶.
But this soon had to be changed, For a task to consider the state management aspects of a component I was constructing. Nothing seems to be working. After asking one of my senior developers again, what they did seemed to surprise me.
Instead of checking any of the lines of code I have written, he quickly seemed to Google the problem and come across an already existing state management library RxJS. He read the document for almost 2 hours that day and before the DSM the next day the entire state management process was simplified to a few lines of code with everything smooth-flowing (maybe 20 mins).
So always...ALWAYS instead of deep-diving into the code, it’s better to invest your time to find the right tool for the right job.
4. From Ctrl+C, Ctrl+V of code blocks→ Shared Components and imports.
Let’s admit it, most of our undergrad code had massive boilerplate and if you searched a selected block across other files, chances were it was repeated over many other parts of the program. In terms of data, replication can sometimes be a hidden advantage 😕, but for code, I discovered it isn’t.
The practice for this was to modularize the code and implement shared functionalities and components.
For example, for the few pages I had to develop for our web-based OMS, the same package editing component was repeated but with minor changes (Mainly parent-child component connections and role-based restrictions). The solution was, shared components in the directory. With the rest of the functions separately.
The frequently used constants could be then exported. So if changed, only one place will need to be edited.
constants.ts:
export const Constants = {STANDARD_WEIGHT_UNITS: ['kg', 'g'],
STANDARD_LENGTH_UNITS: ['cm', 'm'],
DEFAULT_CURRENCY_CODE: 'USD',
//and so on ...
feature.ts:
import {Constants,DEFAULT_COUNTRY_CODE} from '..app/shared/constants/constants';
.
.
.
findSelectedCountry(countryISO: string): ICountry | undefined {
if (!countryISO) {
return (this.countryList.find((country) =>
country.isoCode === NORWAY_COUNTRY_CODE));
}
}5. From ‘Δεν μπορώ να καταλάβω’ → ‘Hey I know this!’
The 1st thing I told my intern-mate when we first saw the first code was ‘I can’t understand any of this 😂 Both of us had never done C# before and even the file structure along with new keywords seemed absolute Greek for us. So our Team Lead took a call and did one of the best things for us.
Instead of explaining the entire structure or code, he descriptively explained only 1 aspect of the entire codebase and guided us just with some resources. So with only around 10% of the map explored, the rest was up to us, and boy did we discover wonders.
Soon with much Googling and documentation raiding, The ‘Greek letters’ slowly started to turn to simple English (Understandable code actually😝). And WE HAD BEEN KNOWING THEM ALL THE TIME! Below is a sample method of how to understand tech terms and code I grasped within the period that has never failed me up to now 🧐
Also one of the best quotes by one of my team leads:
“The moment you should be happy is not when your code runs correctly on the 1st time… But when it gives a different error each time you correct the problem.”
Even the complex design patterns and architecture were graspable afterwards thanks to component-by-component understanding.
6. From ‘Software Engineering is just coding’ → ‘What isn’t Software Engineering?’
Before 99x, I was in torment thinking my future job would just be tapping at a keyboard 8 hours on black terminal screens, Boy was I proved wrong.
Almost all IT industry jobs (As of my noob experience after 6 months) are a separate way of practice!
- During the 1st few weeks, there was the planning phase and configuration setup for our project. In addition to the formal-friendly DSM meetings and Dev-Sync meetings, We also had the experience of seeing how the senior developers and tech leads chose which technology over which (sometimes debating 👨🎓) with clear justifications (Why CosmosDb over SQL for this solution, Why RxJs over NGXS, etc.) along with the requirement s of the clients. The senior developers did most of the configuration settings (billing, partitioning, Partition keys for Dbs, etc.)
- The whole meetings with the clients were very informal. IT didn’t matter if a team member was an intern, an Analyst, or even a Tech Lead, etc. Everyone was considered equal and everyone’s opinion mattered towards the end product of the project.
- Another huge phase we got exposed to was the whole planning aspect (sprints, Work allocation, priorities, etc.). Just after a few weeks, we got the hang of our planner, we were constantly asked to update the status of our allocated tasks and the estimated hours of working. then we realized, the projected forecasting and estimation of delivery, productivity, and all aspects were measured here just like any other construction, Business project 😵. The Project Management side is also part of a developer.
- Even with coding, it wasn’t just tapping on the keyboard.. Code review was a vital part of any developer’s life and I am still thankful for our lead who *forcefully* made us review every other’s code even if they were waay experienced than us 🙏. This was one of the key reasons my code became cleaner throughout.
- Finally, the non-office hours! These were the stress-release hours of discussing stuff with the teammates, coffee breaks. Any developer would agree that this is also the moment where you miraculously find the solution to the bug in line 1432 of the controller class🥴.
- And the community sessions with other teammates from different projects. From a learning point of view, this is where “strength through diversity” came in. The ability to understand how interns just like us managed other tech stacks and projects of different domains, their best practices, etc.
There I said it, the mini-story of how the internship made me from zero → hero 🦸♂️. Special thanks to Team 99x, for the wonderful intern experience, my team lead Janitha Tennakoon , Anura aiya, Ashan Fernando for the guidance, my intern-mate Harshana Edirisinghe ,fellow UCSC interns, teammates, interns and everyone who helped to make this a great experience for my Career 🤩 🥳
