By Nitish Deshpande
!!Programmer, Developer, and Software Engineer!!
Below are the commonly associated definitions with the terms Programmer, Developer, and Software Engineer.
1. Programmers turn clearly defined solutions into the code, and all beginners start out with the aim to become a programmer. As the saying goes: everyone can become a programmer.
2. Developers take this further – they can code and design solutions and mostly focus on solving real-world problems. All developers are programmers, but not all programmers are developers.
3. Software engineers, on the other hand, see the big picture and have a deep understanding of how code and programming languages work, so they specialise in designing good solutions that are scalable. Suffice to say, all software engineers are developers, but not all developers are software engineers.
Keep a habit of scribbling out the algorithm/pseudo-code before you actually convert the solution into code. Writing by hand can also help you plan your code before you move it to the computer. You can save a lot of time if you write out which functions and classes you will need, as well as how they will interact. Although more time consuming, this restriction will mold you into a more fundamentally sound developer.
When you are implementing a feature, its always good to split the bigger tasks into smaller and clearer tasks which are individual logical units and can be tested individually. Keep a list of such small achievable tasks and keep ticking against them once you complete it. This will give you a boost and motivate you to keep ticking more boxes. The checklist can be either in a book or in any software (like Google Keep).
Follow a proper version control strategy by creating develop, feature, master branches and having proper access policies set-up. Discuss this with your mentors if this has not been set-up. Whenever you start coding make sure you pull the latest version of the codebase and then start. Keep committing/pushing your code after a logical piece or functionality is complete. Don’t keep your codebase in an uncommitted state for a long time. Always test your code in the local machine before committing it to version control. However small the change may be, at the time of pushing code make it a habit to check the diff of the modified files, this will help you track changes that you had not anticipated and will avoid unnecessary bugs.
Code refactoring is the process of changing the source code without modifying it’s functional behaviour, in order to improve the code readability and improve the maintainability by reducing the complexity of the code, as well as improving the code extensibility. Failure to perform refactoring can result in the accumulation of technical debt which the developer has to pay at a later point in time. Trust me, no developer would like to be in that situation. Developers often shy away from touching the code that is already working for a long time. The problem arises when a requirement comes to enhance the existing feature. If the code is not in the proper form for it to be easily extended then its a developer hell. So, to avoid such situations, the pro-tip is to always look for areas in your code which can be improved. If you cannot find it yourself then reach out for help in your team.
Feel free to leave comments in your code giving explanations why you made certain choices. This will help future learners since not everyone will know why you wrote your code in a particular manner. Do not leave comments that explain obvious coding behavior as they might become irrelevant. Proper code comments will improve the maintainability of the codebase.
Not all the problems you encounter will have an obvious solution. Always ask Google, there are probably millions of developers who have come across the same problem that you are in and they also have found out a solution for it. So, do not spend too much time looking out for the solution all by yourself. A lot of developers under-appreciate the degree which googling things is a part of a programmer’s job. Sometimes my job is more about knowing how to search for something than actual programming.
Programming is actually a social activity. I would not be as good of a programmer as I am now if I didn’t have other’s help. Each of my friends are good in certain areas so whenever I have a problem, I know which friend to ask. I also help them out in return when they have a problem. This is really the only way to get things done. What may seem like an immovable bug or an unlearnable topic could be quickly alleviated by a fresh pair of eyes or a new interpretation of the subject. So do not program in silos, always discuss and progress.
You can also follow Pair Programming technique at times. Pair programming is a technique that involves two developers working on one computer to complete a task. The two developers switch between being the “driver” and the “navigator.” The “driver” writes the code, while the “navigator” helps guide the problem solving and reviews the code as it is written. Switch frequently to get the benefit of both sides. Pair programming has many benefits, it gives you a chance to not only have someone review your code, but also see how someone else might be thinking about a problem. Being exposed to multiple ideas and ways of thinking will help you in problem-solving when you got back to coding on your own.
I like to think of myself as a programmer first and a language-ist second since there will be a day when all of the programming languages we use right now won’t be used anymore. For example, if I started in the 80s, I would be using certain forms of assembly code that are all gone now for the most part. This will happen to all technologies no matter how good or bad. There will be a day when no one uses Java anymore. That said, there is a broad paradigm that programming languages fall into, and there’s sort of a family tree for programming languages.
So, if you know a language that is similar to another one, it can be very easy to pick that language up. For example, Python and Ruby are almost the same programming language. It’s true that, culturally, there are huge differences. However, other than that, they’re almost the exact same thing, so learning one when you know the other is very easy. So do not associate yourself to any technology or programming language and treat them as just tools that will help you in solving a problem at hand.
We often see a lot of bugs reported in the functionality that we developed, which means most of the time, we’re failing. If all of our programs were feature complete and we didn’t have any bugs, programming wouldn’t even be a thing. Just the fact that we are programming means we either don’t have many features yet, or our software has problems. So, in some ways, you’re always failing as a programmer. This is a weird mindset to get into, but you just have to be okay with things not being perfect and not working; it’s literally our job. Programming is long-term process and in the journey, you will face new obstacles all the time. Keep a habit to record the mistakes that were committed so that you do not commit the same going forward, following which shows you are constantly learning and upgrading yourself as a developer.
There will often be tasks which you do on a more frequent basis. Like running a set of commands or performing certain activities, which involve you switching between multiple applications/programs/screens, which eat up most of your time. It is advisable to convert these time taking daily activities to be automated in some way either through scripts or simple programs which can be run with a single click or command. This will save your time and you can focus on more interesting tasks and not worry about the routine and mundane tasks.
You definitely should have the mindset that is commonly associated with that of a software engineer and start thinking big.
Curious Much? Let me know your thoughts at CuriousMuch@asksid.ai and let’s start a conversation.
Author: Nitish Deshpande (firstname.lastname@example.org)