What I’ve Learned Working as a Professional Developer so Far
--
I started learning how to code back in 2018 when I first started on FreeCodeCamp.
Back then, I wanted to find a good use of my time and thought coding would be a great way to do. I remember my first project, a simple calculator, and my excitement with setting it up for the first time, especially when everything clicked together for the first time. I never got really serious with it however, until I entered university about a year later.
Soon after, I found myself thrown into a trial by fire when I took on my first Internship at Daloopa sometime later. Now, I’m working as a software engineer at Holmusk over the summer and I’ve learnt so much over the past few months. I thought I’d write this article in short to do a reflection on some of the lessons I’ve learnt the hard way.
Keep It Simple Stupid (KISS)
I heard this mantra thrown around a lot when I first started reading programming articles but never really got the hang of it. It wasn’t until I was working in a professional environment and had my code scrutinised that I realised the importance of keeping your code simple and precise.
I personally feel that there are two main reasons for doing so.
- Your code will be built upon in the future. People will be reading it and working to extend the functionality of it. You might have saved 100 lines of code by making your code more general but if it comes at the cost of specificity and verbosity, it makes future functionality difficult to add on. Instead, consider writing code first and abstracting later on
- When you make Pull Requests or ask people to read your code, you are taking valuable time out of their day. Senior Engineers/Your peers aren’t waiting around all day with an unlimited amount of time and patience. Each Pull Request you ask to be reviewed drains them of time and mental capacity, potentially delaying their own work and the project
Some simple workarounds I’ve found for this have been to just write code that is cleaner and more functional. Let’s take an example where we want to
- Filter out all the items that have a display property of true
- Add a new property of newProp of abc to these items
//Sample Input
input = [{…,item:{display:true}},{…,item:{display:false}},{…,item:{display:true}}]//Sample OutputDesired Output = [{…item,{display:true},newProp:abc},{…item,{display:true},newProp:abc},{…item,{display:true},newProp:abc}…]
and we have the existing code that we’ve written.
//A little bad Code
x = []
for (let i = 0 ;i < something.length;i++){
const item = items[i]
const item_trueness = item['display']
if(item_trueness!==true){x.push(item)}
else{pass}
}new_items = []for(let j = 0 ; j < x.length; x++ ){
let new_object = x[j]
new_object[newProp] = "abc"
new_items.push(new_object)}
It’s not bad code per se. It’s just a bit verbose for its purposes and would take someone an unnecessarily long time to understand it. Instead, let’s apply some destructuring, remove unnecessary control flow and make use of the spread operator.
x = []
for (let i = 0 ;i < items.length;i++){
const {display} = item
if(display){x.push(item)}
}new_items = []for(let j = 0 ; j < x.length; x++ ){
new_items.push({...x[j],newProp:"abc"}
}
We can even go one step further by using purer functions such as filter and map in this case. I won’t go over what these functions do in this post. Not everyone is familiar with them but if your team is comfortable using them, I highly recommend giving them a shot.
return items.filter(item=>item['display']).map(item=>{...item,newProp:"abc"})Asking Questions
When I first started asking questions, I would ask really bad ones. What made them bad was their lack of specificity.
For instance, I would ask How do I make X happen ?
This isn’t a good question not only because it places the onus on the person you’re asking it to but also it fails to let them highlight the problems in your thought proccess. Instead, consider rephrasing your questions in these formats.
Sample 1
Hi there, I’ve tried doing Y to get X to happen. My understanding of Y is that it does Z and in turn allows for X to happen. I’ve also tried implementing H as an alternative measure but found that it didn’t work. What is the problem with my approach.
Sample 2
Hi there, I’ve encountered some difficulties when doing X. The error seems to occur when I do Y and I’ve also found problems when testing for A. I think this could be a bit problematic down the line when we implement BC. Is this an intentional design feature or a bug I should wait for a fix for?
By doing so, you force yourself to structure your question in such a way that you proactively seek solutions. Not only so, once you present this to the person you are asking this to, you will also be able to get a much more specific answer!
As a pro-tip, don’t feel bad about asking questions! I still struggle with this at the end of the day and I think its better to ask and confirm than to assume something and have to fix it down the line.
Plan
The importance of planning cannot be understated, although you also cannot over plan. The key lies in finding a nice balance in-between.
Here’s my current planning process.
- Sketch out rough requirements in the form of a to-do list
- Make a wireframe of the UX in BLACK AND WHITE AND GRAY. NO COLORS ALLOWED HERE
- Demarcate all the rough components allowed
- Think about the least complex way to do what needs to be done
- Smash something together.
- Reiterate and clean up code.
Ok, I’d be lying if I said 6 happens all the time. I’m no stranger to technical debt to be very very honest. But I’ve found that sticking to this lean planning process forces me to think ahead of problems I might face and to proactive find solutions to them.
Not only do you make life much easier for yourself, but you also expedite your coding because you have a much better mental framework in mind to deal with what needs to be done.
Have Fun and take a break
I think this is probably the most important part of coding or programming jobs we do. At our very core, every programmer is a tinkerer. He or she plays around with code using a conceptual mental model to make something happen.
And it is fun that drives this, I hope, for you! I personally enjoy playing around with a lot of different technologies in my spare time and have found a lot of joy in them. Not only have these side projects brought me a lot of joy but have also allowed me to work better at my job.
A lot of them start with the question “What if ….. ? “ and before you know it, we’re building something. I love programming and I can’t imagine doing anything else on the best days and I hope you do so too!
