Anyone can be a software developer; however, not all of them can become a ‘great’ software developer. Sadly, this is a fact that is acknowledged even by the more experienced software developers, or those who are at the top of their field. As in any other profession or discipline, it takes a lot to get as much knowledge, training and expertise in order to deserve having the word “great” attached to their name or occupation.

But here’s the good news; no, it’s great news. With the right training, experience, and attitude, a new software developer has high chances of becoming a great one.

How to Become a Great Software Developer

© | dotshock

This guide explains 1) who is a software developer and what does he do on a day-to-day basis and 2) a list of secreat tips for becoming a great software developer.


Take note of all the computer software that you use so often that you can no longer imagine getting by without them in your daily life. There is a 100% chance that there is a software developer, or a team of software developers, behind it.

A software developer is someone directly involved in any facet of the software development process, from research and design stage until the actual programming, testing and implementation. He has some computer programming skills, which can be acquired through computer science courses and subjects. In the past, software developers have been identified with people who have a degree in computer science; these days, however, a degree is not compulsory for anyone to become a software developer.

It has been established that a software developer is one who “makes software that can be used”. If we look at the various job descriptions of software developers, we can break down their roles and functions into the following:

  • Designs software systems that can and will be used by companies, individuals and other end users.
  • Maintain the design as well as the overall maintenance of software system.
  • Identify existing and potential errors in the software.
  • Correct the errors and modify the software for better, or higher, functionality.
  • Assist in the determination of cost constraints and design of the software.

Software developers are increasingly becoming recognized as one of the more important and even powerful people in an organization. The current pace of advancement in technology is largely responsible for this.

Bur organizations are also becoming more circumspect when hiring software developers. You have to be more than good; you have to be great at what you do if you want your skills as a software developer to be recognized, and for you to be hired by the right people.

Wanna know how to become a kick-ass developer? Read through those slides and get the answers.

[slideshare id=16353203&doc=howtodokick-asssoftwaredevelopment-130204233801-phpapp02&w=640&h=330]


When organizations look for software developers to join their company or to work on specific projects, you would think that they would zero in on the credentials of the potential developers. This includes looking into their educational background, their work experience, and even what other previous employers or companies who have worked with the developer have to say about them.

But that’s not all. The best gauges for the effectiveness of a software developer are the software or systems they have developed. These outputs speak for themselves, serving as good indicators on whether the software developer is good, or they should look for someone else.

Several articles have been written on the topic on how to become good at software development. Let us take a look at some of the helpful tips that can actually help you become one.

A. Master Function Naming

Being a software developer, it is a given that you must be more than knowledgeable about programming. You must have all the basics down, and one of them is Function Naming.

“Names” are said to be the “boundary conditions” on a code. Computing essentially involves thousands of functions and, naturally, these functions require a name. Stephen Wolfram described function naming as an art – a “strange and difficult” one. The purpose of naming functions is so that you can immediately tell what the function is meant for once you’ve read the words used.

There are many programmers who do not enjoy this task, mainly because they think it is difficult. It does take some practice, but the important point that one must remember when coming up with these names is to make sure that they know exactly and clearly what the function does. From there, it would be easier for them to choose names to assign.

Take, for example, the functions process_image or process_text. Do you know what will happen to the text or the image when it used the word ‘process’?

Compare it with the function named as safe_convert_to_html. Between the two, the function with the more proper name was the second one, since you, as the one seeing the words used in the function name, can get a better idea what the function is.

What does poor function naming result to? For starters, there is ambiguity. The function name would be so unclear that even you, the one who wrote the code, may have a hard time remembering what it was supposed to do. Poor naming of functions is also likely to end up into bugs and sloppy contracts.

B. Know How to Recognize Bad Code From the Outset

If you hope to develop very good and excellent codes, you must be able to distinguish the good ones from the bad ones. Not only that, you must also know how to detect bad code immediately. Software developers all too often focus on learning about good code. They are fixated on what good code looks like so they can focus on it alone.

But knowing how to detect bad code is also one of the best ways for you to make your code better. It is common sense, really: you know what is bad and so you know what must be improved. Then you can move on to figuring out how to improve it. Do not just focus on the beauty of the code, because by recognizing the ugly and unattractive parts, you will be able to find ways to make it more beautiful.

Granted, it may take a while for software developers to develop a keen sense of sight for bad code – and sense of smell for “smelly” code – but there is nothing wrong with starting early. If it makes you feel better, even programmers who have been writing codes for years and years fail to recognize that their code is bad, or could be better.

C. Write Codes that Others Can Read

There is no point writing codes that will only end up unused or unimplemented for the simple reason that no one else but you can read, much less understand them.

A software developer may be the only one to write the code, but it will be read many times over by others and, most likely, will also be edited. Now this cannot happen if you wrote it in such a way that others cannot understand. Consider the fact that you will not be there forever to keep the code going, or keep it usable for a long time, even after you have moved on to another coding job. By making it readable, you are ensuring that it will still be usable for a long time in the future.

D. Spend Money on “What You Need” More Than on “What You Want”

It is so easy for a programmer to cram as many “shiny” as he could to a system or software he is developing, especially if there is no budget limitation.

The important point here is to pay attention to features’ lifetime cost instead of their implementation cost. Often, programmers want to make use of these “toys”, regardless of their applicability in the future, thinking that the ones who will take over after them will have to deal with consequences, if any.

A great software developer is mindful of this. He focuses first on building the features that are needed, and these features are chosen after careful and thorough consideration. The costs should first be appropriated for what’s important, before they are used on add-ons that are not really all that necessary.

E. Check and Recheck Your Code, and Fix it

Software developers who are good often know that they are good, so they tend to adapt an attitude of complacency about it. They wrote the code, they know it’s good, so once it’s done, they are also completely done with it.

A great software developer takes the time out to check and re-check their code. Even the best programmer makes mistakes, and it is a sign of a great one to be able to acknowledge that he, too, may commit these mistakes.

Do not limit yourself to the requisite testing stage to make sure that the code works. It also falls upon you to see whether it works or not because, if it doesn’t, the responsibility of fixing it will still fall on your shoulders. You created the code, so you are the one who is supposed to fix it when it has problems. It’s not the job of the testers or the members of your team; it is yours.

F. Document Your Progress. All of it.

Some programmers find documentation a little too tedious. They are supposed to write codes, not narratives.

But documentation is not solely about writing lengthy reports or narratives. There are now many ways for a software developer to write down all the things that he has done and share them with the members of the team. It is your obligation to make sure that all the team members are aware of the steps that you have taken when developing the software: the architectural approach you chose to go about it, as well as the discoveries and new information you have learned during the entire process.

Not only will this keep them in the loop, it will also be helpful for future references. Say, for example, that you encountered a few snags with a specific code, and you managed to find a way around it and even fix it to make it better or more functional. By documenting it and sharing it to the team, they will be better prepared and equipped to handle the situation should they find themselves in a similar position that you were in. Remember, forewarned is forearmed. You will also be doing the organization a favor, because it will cut down on time and resources when they already know what to do to deal with a specific situation when it arises.

Read more on the best practices for documenting software code.

[slideshare id=49424140&doc=documentationmotivation4cognisefinal9-150615195600-lva1-app6891&w=640&h=330]

G. Create a Strong and Solid Team

This entails choosing the right people to be part of the team and making sure that they work together to come up with very good outputs while learning from each other. This is where the documentation mentioned in the previous tip comes in handy.

Being a team means working as a cohesive unit, learning from each other and giving each other encouragement to become better programmers and developers. A great software developer is one who is able to lead these teams and help them improve – both as a team and as individual developers.

Remember that being great is not a quest that can be done on your own. You may have all the skills and technical know-how, but you will still need the help of others in your coding or programming efforts.

H. Make Your Fixes Long-Term

Fix, do not troubleshoot. Give a long-term solution instead of a one-time or short-time reprieve. It is a sign of selfishness if you only come up with a fix that will serve for a short period when you can implement changes that can provide a long-term solution and thereby save the organization costs.

This is an attitude adapted by some software developers once they are done with a coding project. They think that, since they are done with it, they are no longer obliged to give 100% of their attention to it. In the event that they have left the organization to seek greener pastures, they consider themselves completely separated from all that it represents, including the software they have developed. This is the reason why some developers only provide short-term fixes: they already know that they won’t be with the company forever, anyway, so why bother?

Great software developers should not think this way. While they are with the company, and are working on the project, they should do everything with a long-term perspective, including fixes and repairs.

I. Keep Things Simple

Simplicity is one key feature that many end users look for in software and applications. True, they may be duly impressed by a lot of flash and complicated features, but they are more likely to backtrack and still go for the one they find simple and easy to understand and use.

This is a problem with most software developers. In their desire to show how good they are at what they do, they end up making things complicated. There is a difference between a complex system and a complicated software; a software may introduce a complex system, but is still fairly easy to grasp and simple to use, whereas a complicated one is simply, well, difficult to follow, much less understand.

What great software developers do is come up with software that, at first, may seem unremarkable and even downright unappealing, but has functionality at least. They keep on working on it, “pounding it into shape”, until it goes back to its simplest form which, more often than not, ends up becoming the final output.

After all that, there is one important tip on how you can become a great software developer, and it doesn’t have a lot to do with your technical skills or know-how. It has to do with your attitude.

Be patient and persistent in your approach to software development. You have probably come across one or two software developers whom you thought was truly gifted and highly skilled. They know coding inside out, and can complete their work in half the time that others take. However, they are not what you’d call great. Or, on the other end of the spectrum, you saw a software developer whom you thought was mediocre at first, but went on to create excellent software that is much appreciated and used by many. Most likely, the difference lies in their approach or attitude to their work. Software developer also takes a lot of heart and determination, and that is, most probably, where the scales were tipped.

Finally, keep in mind that software development is a process, and often a lengthy one, at that. It takes a lot of work, work that is mostly bypassed by many developers because they want to beat a deadline, or they are simply willing to settle on something ‘fairly good’ instead of working further on it to come up with something ‘extremely great’ or even ‘spectacular’. The great software developers are the hardest of workers, and if you want to join their ranks, you should be willing to work, and work long and hard.

Comments are closed.