Habits by definition are your daily routines in life. It could be either good or bad. Habits can come in a form of survival such as needing to eat food for 3 times a day. There are also habits that are healthy such as working out for 3–4 times a week. There are some bad habits that damages your body such as smoking and drinking alcohol everyday.
And lastly, there are habits that will make you excel in whatever career you’re in right now. Habits are the ones that created experts, geniuses, and gained proficiency in what they’re doing right now. It is not done overnight, but it’s possible. Most productive and smart people will say that habits were the ones that made them successful. I couldn’t agree more than that.
It took me a while before I start developing some habits that made me a better Software Engineer. Through working with different clients and different industries, I start to develop some internal habits that I find hard to stop it now because in most cases it allowed me to be better each day.
In case you’re wondering, here are some of the habits I formed along the way that made me successful in which you can do as well:
Architect every software application
I almost never code any application without having to architect it properly first. Most of the time, I used best practices like keeping in mind when to use Design Patterns, separating code responsibilities using SOLID principles and Domain-Driven Design(DDD) approach. Maybe I’m a little bit perfectionist when it comes to cleanliness of the code because I believe it will save me a lot of time in the future and will further minimize the frequency of spaghetti codes that increases Software Entropy over time.
I believe in every software you make, there needs to be a better architecture. You’re most likely to be productive when you’re trying to make the code as separate and clean as possible. When I learned how to better separate my repository and my service layer into the application, I was able to improve my coding speed at an incredible pace. Not only that, I was also able to insert some Unit Tests into the mix thanks to better separation of concerns.
Software Architecture was more obvious when I moved to MVC paradigm and throw DDD into the mix. It just showed how important is the concept of Separation of Concerns (SoC) in developing apps, more so when developing large-scale, enterprise applications. It was the most productive moments of my life as a Software Engineer.
The only exception of this is when I’m coding some sample code snippets or demo apps I need to test for the demonstration. Or some experiment software app for testing.
Always write tests
Another thing I’m practicing in my job as a Software Engineer is to always write tests. Test-Driven Development (TDD) in my personal opinion is very important discipline to implement when writing your Unit Tests.
The idea behind this approach is to let the test drive the design of your functions and predict its output before you even write implementations for it. At first this might sound confusing and not making any sense. But when you start practicing it, you will realize its uses and its benefits that outweighs the cons of using this approach.
What’s more, TDD allows you to write cleaner code and architecture that prevents your code into becoming unmanageable (spaghetti code anyone?) in the long run through implementing Interfaces and SOLID principles. If done properly, you can use stubs as a dummy replacement for concrete implementations of your services.
It is also worthy to take note that you cannot create every test in all scenarios. This is where most developers got mistaken and taint TDD for what it’s worth. You might need to know what are the scenarios which are testable and which are not before doing so.
An example of this is creating a function for Add(). You will know for certain that you can create a test for this and apply TDD methodology. Now how about when you’re creating a test for just displaying the information in ViewModel? Sure you can. But is that even necessary?
Overall, this habit of creating tests allows me to be better at refactoring my Software Application and Architecture. It also allows me to ship the features I’m making with great confidence with little to no setbacks.
Write Blogs/Articles for what you’ve learned
I think some people neglect the idea of writing your realizations/findings down on a piece of paper like a scientist. Or create a blog article for it.
As I understand it, writing articles for the things you have just realized in programming will in fact make you a better one. Especially when you write it down and share it with programmers around the world.
Not only that you were able to share your ideas and help programmers in their problems globally, but you were also able to express your uniqueness and quirks.
Another benefit of writing articles is you increase the retention of that information into your brain. Research has shown that the more you write the information, the better you will retain and process the information better. So based from that information, I’m using blog or article writing as an outlet to better retain and process that information better, ready to be seen by the public around the world.
An added bonus for this is you allow yourself to communicate with programmers and you’re showing that you’re open for criticisms. This way, you’ll improve and learn from their advices. Or correct them. This opens a conversation so that either of you can benefit.
You might have noticed that good software engineers write blogs. This is what they’re probably aiming for aside from showcasing their skills and marketing themselves as a personal brand.
And you’re probably better off practicing the discipline called “The Feynman Technique” as well. /shrug
Use version control systems like git
I’m not entirely sure why most developers in my city still don’t know how to do this as a norm in their day to day as a software developer. To me, using git was the most important discovery I explored in my entire life as a Software Engineer. It saved me a lot of headaches.
Because of version controls such as git, I can create branches that relates to specific features you need to work on. In this case, there’s no need for you to rollback because chances are, you won’t merge your feature branch to your master branch until you tested it perfectly and is working fine. If things didn’t go your way, you can leave that branch and you don’t merge it with your master branch.
Version controls are powerful. It’s the one that actually makes remote work very successful till now. Imagine working with developers in different timezones and you don’t have that version control that will log/monitor your changes and just simply copy/paste your projects in the cloud storage. That will be disastrous!
As a bonus, when you expose your open-source projects in github especially if it’s useful, chances are there will be lots of people who will collaborate with your project and improve it.
Use kanban board
When I’m serious in the project or idea I’m building, I’m using kanban board apps like trello to jut down all my ideas/bugs/issues I encounter when currently building my MVP. In teams, I usually see developers uses trello as their usual practice to jut down those ideas and features that needs to be delivered.
In kanban boards, you’ll usually see To-do, In Progress, Done in the board depending on the current status of the task you’re working on. You could also expand it depending on your needs. Some teams I’ve worked with have something like “For discussion” columns in their trello board before they put it in “to-do” and ready for the developers to take once they’re done discussing the feature.
As an individual user who has several personal projects to make (whether it’s my own personal app, a startup app or so), it saved me a lot of headache. It was easier to understand where I’m currently heading, and what ideas have already been implemented.
I can’t imagine my life as a Software Engineer without having to use trello. It saved me a lot of time while keeping the projects more organized than saving all those things in note-taking apps like OneNote.
Solve problems at a different angle
You could say I’m a little bit obsessed with solving problems at a different angle. Especially with optimization, I was constantly asking myself if how can I still optimize the query even though it’s already optimized.
There are also some scenarios wherein queries really needed to be optimized such as displaying more than 100 records or so. Samples such as these needs a lot of thought as the implementation might be a little too far-fetched or impractical when the user actually uses the feature. In this case, it’s better for you to discuss the feature with your client and solve it at a different angle.
I also try to analyze the algorithm speed behind the scenes of the code I’m making using Big O Notation.
Making this as a habit made me better at solving problems, even with problems which might be a little bit impossible to solve as that is our duty as Software Engineers. It also allowed me to produce better output with little to no bugs.
Exercise / Hitting the gym
I usually go to gym to workout for around 3–4 times a week. This is to ensure that I’m making my brain healthier which allows me to think better and solve complex problems for my clients.
Scientists discovered that exercising or workout can actually make you smart. According to the study, endurance exercise that improves cognition and protects the brain against degeneration.
Overall I love working out as a whole aside from its benefits that I can reap. We don’t have to work and tire ourselves out 24/7 in front of the computer screen. We also need to work out and be healthy as a whole.
Remember without healthy body, we cannot be efficient in our work. This is one of the few ways I can optimize myself, not just optimizing the code all the time.
Avoiding procrastination in today’s world seem like a challenging thing to do especially if you have no bigger reasons to do so. One of the keys to further eliminate or minimize procrastination is to have a bigger reason why you want to succeed or improve so far.
I told one of my friends who were working in other city that if you could just minimize using social medias like facebook, you are doing your future self a favor for improving.
Let’s do a simple math of procrastinating your time towards using facebook: you browse facebook for 2 hours/day. You habitually do that for 30 days/month. Now multiply 2 hours in 30 days. It equates to 60 hours right? It’s equivalent to almost 3 days. It might not sound a waste of time enough. So let’s just make it into a year.
Now, assume that you waste your time 3 days in using facebook/month. Multiply that by 12. Now you have wasted your 36 days simply by using facebook.
Imagine if you could simply minimize using your facebook and simply work on improving yourself. To the things that really matters. You can improve yourself quickly rather than wasting time in browsing meaningless stories on facebook.
Deactivating my facebook account allowed me to improve my skills as a Software Engineer and use that 36 days of my life for self-improvement. It was a life-changing realization.
Lastly, this is the habit I used to hate the most. Reading books. Now I appreciate it. I read books everyday.
Reading books allow you to learn new information you can relate or connect with your current skills and solve problems more efficiently than anyone who is not reading books at all.
For the kinds of books I read, it’s usually non-fiction. Mostly self-help books, business books, and Software Engineering books or any books that I can link in my career.
It made me a better thinker, and better Software Engineer as a whole.
I couldn’t have been a better and successful Software Engineer without these daily habits in my life right now.
What about you? What’s your habit that made you a better Software Engineer now? Write your habits in the comment section below!