After a long time of programming and software developing, you get a few tricks up your sleeve. Learning about software developing is a complex and practically lifelong process, though. That’s why we made this list for all the beginners out there, the stepping stones to a good IT practice.
When starting developing a project, always remember that large works if it’s on a good base. That’s why it’s always good to start small, and extend your software later on. Planning the whole set of features is recommended, and it’s a good brain gymnastics. In practice it doesn’t work more often than not. It’s much better to make the simplest version on which you will gradually add the required functions.
To do so, keep it clean and add a single thing, then check if it works. Adding too many features at once can bring a lot of confusion if it turns out that it doesn’t work. Take commits for example: before adding a new feature, make a commit just after refactoring. That way you’ll know something’s wrong with the feature and not the refactoring instead stumbling in the dark figuring which one needs change.
But before adding major parts to your system, check the parts first, and then check the whole system. This way you will avoid confusion about what makes the problem – the poorly written part itself or the integration strategy you are trying to implement. If the part itself works fine, you can focus on the mismatches and misunderstandings between modules and other integration issues.
With that in mind, early error handling and logging will save you a great deal of trouble. Take note these are some of the first features you need to add to your process. The sooner you are able to find an error, the better your end product will be. Also, knowing what exactly happens in your program will give you plenty of deeper insights useful in the future.
For example, an unexecuted line is a useless line. So, make sure every line has at least one execution. Automatic tests do the work most of the time, but you can do better than that. Cheating’s fine here – misspell the name of a column, or invert an “if” statement. This way, you’ll know if the line works, that is if anything real is triggered by the command. You can see how logging can help you with these tasks.
Over time, you will get a hang on the parts and the whole, the unexecuted lines, etc. Investing some time in deeper understanding on how the codes work will get you far. When you have a pre-written code you need to work on, take time to read the code and then run it. This will bring you a great deal of insight how others think and how the code concretely works. Yes, it takes time, but after a few codes it gets faster, and you will be able to get a hang of the code much easier, avoiding unnecessary head banging about why this and that doesn’t work.
This is because it’s vital to understand the premade code before you start working on it. If you start adding a new feature through a solution that doesn’t fit the existing one, your feature will more often than not misfire. It can even create problems in other parts of the code. Software developing is not a “there’s one correct answer” thing, and the solution your predecessors went with can be very different from your ideas. Use that to enrich your experience and plasticity when developing a system. With developing code reading as a skill along with writing it, you will be able to understand your past mistakes as well. With that, you will avoid similar mistakes in the future.
Seems like too much work for adding a miniscule feature? Yeah, we know. That’s why really successful developers stick to the motto “It always takes more time”. Successful developers don’t believe the task on paper, because it may seem it’s a breezy job for half of the afternoon, until you check it. Then you figure out it won’t work because the framework, the context is different to that which you had in your mind when writing it. Then you start really doing the work – combing through the code to see how the parts fit together and how you can squeeze your feature in it and not make a mess. Then you tentatively write the feature line by line and double check if the last one didn’t bring mayhem to the system. Then you notice a whole day or even two passed instead of one afternoon. The task always takes longer, and then sometimes longer than that!
Troubleshoot it right
To start with this, let’s agree that a software without bugs doesn’t exist. Whatever you do, a bug will appear somewhere in your program. You have to be a masochistic genius to develop a program on paper, write it, and not worry about bugs. Instead of striving towards a perfect system, it’s better to arm yourself with troubleshooting tools, fixing the bugs, and then deploying those fixes.
When fixing the program, there are a few things you can stick to at all times. The first being is to erase coincidence from your vocabulary. No matter what happens, remember the last few changes and check them no matter how unrelated they may seem. Timer value changed and then you get more frequent restarts? Check it. An old feature is slower just after a new one is added? Check it. In programming, nothing is a coincidence, so don’t think of problems that way.
It can get confusing, yes, but once you’ve mastered one problem, you’ll master a whole group of similar problems. When dealing with complex problem, always start with fixing errors you are aware of, and deal with the rest after you’ve done that. The unseen problems will be clearer once you’ve figured those you can spot. To get even better at fixing a problem, reproduce the bug or the problem before you fix it. This way you will avoid misunderstanding the problem and making sure your fix is doing what you want it to.
In addition to this, you can start using timestamps to correlate the problems with events that were before them. Timestamps can tell you which execution you can look into and which one can be relative to a problem. Additional tip: even increments are the first suspects.
Finally, never stop solving reported issues from clients and customers. Go out there, learn first-hand what your customers are trying and wanting to achieve, how they actually use the system. Checking the design and integrity of the system, or what the troubleshooting process is like, will give your knowledge more integrity once you learn how to constructively take responsibility.
It’s a group work
So, to start acting so is of paragon importance. The benefits of a good cooperation are tremendous. For example, if you stumble on a problem you can’t solve yourself, simple talk with a co-worker explaining the problem to them can help you find a solution half-way through a discussion. This is what we call rubber ducking. While acknowledging the benefits of video conferencing and remote meetings, face-to-face communication gets a surprising amount of work done. You won’t believe it until you try it how different and constructive a discussion in person can be compared to a talk online.
Asking is vital to a good work, and it can save tremendous amount of time. It’s always faster to ask the person who made it about the specifics, if possible, compared to reading and running the program we mentioned above. It opens space for follow-up questions, concise explanation on how the system is framed prepares you to add that feature more easily and with less headache.
Finally, a lesson from the game theory: acknowledge the winners in short games so you can win the long game. It’s a matter of fairness. Never take credit for other’s work, and be loud about your teammates’ achievements. Don’t hide it in “we did…” if they did it. This builds trust in you and maintains a good level of motivation across the team, so you can keep winning together.
On final remarks
Let’s give eggs to bind our omelet with a few final tips that kind of overarch the whole process. Some of them are simple while others take effort to do them right again and again.
Trying stuff for yourself will go a long way. You’re not sure how something works, don’t be lazy and write a short program to test it. You’ll use a one-time short detour that’ll set you on the right track for the rest of your career.
Okay, maybe not for the rest of the whole career. IT is developing and changing fast, so subject yourself to change, be the agent of change in your environment, profession-wise. It’s even good to change roles within your team for a while, and try other work apart from that you most commonly do. The point is to keep learning and constantly developing yourself.
Finally, manage tension – this business relies on gentle brain skills, and too much tension renders these skills rigid, and unproductive. Sleep on your problems, give your brain time (but not too much) to process stuff while you do something else – starting fresh can be enough to get the job done.