In Software Development there is no such thing as stagnancy. Everything you develop now is just another version of a component that will probably change in the future. Change is the most common thing in Software Development, and you’re better of accepting it as a fact. Expect future changes to everything you develop, and therefor design your Code more modular. This makes changes more easy and increases the Quality at the same time. Adapt the concepts of
DRY and YAGNI. You will often come to the Situation, where you look at your Code and imagine that you could have done that “better”. Don’t let this thought prevent you from sleeping. Take action immediately and Refactor! If you don’t do it now, you will probably never do it. The longer you wait, the harder and more costly it gets. And you slowly grow up a mess you cant deal with anymore.
“Good code is code that is easy to change. Code tends to change until it is no longer easy to change. All code becomes bad code.” – Unknown
Removal of dead / commented out Code
If you experience dead or commented out code that is not required anymore, but you dont want to delete it because you dont know if you’ll still need it in the future – DELETE IT RIGHT NOW!! Its your versioning tools’s job to remember that code, not the comment’s!!!! I’ve seen too much software filled with tons of commented out Code that no one can even remember any more. And then if you cant remember, you are easily even more afraid to delete it. Well, just delete it – now – for real.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery
Nobody is perfect and everyone makes mistakes. Making mistakes is a process of learning. There is no improvement if you don’t make or recognize any mistakes. So: Everytime you make a mistake, you learn something new greatly improving your knowledge. The more mistakes you make and recognize the better you get. Also, there is no point in hiding your mistakes or feeling ashamed for them. Being honest and frankly about your mistakes makes you a great character and a reliable colleague. Therefor criticism, in a constructive way, is an important tool for successful teams.
“Anyone who has never made a mistake has never tried anything new.” – Albert Einstein
Showing your code to others
Are you afraid of other people reviewing your code? Why is that? Did you not write as good as you could have? Well, then its probably not an adequate job for you. Are you afraid that you have made any mistakes? Well you shouldn’t – because you could benefit of every mistake that you have made that is found in the review – see “Making Mistakes”. You should always write your code as thoughtful as you can. Therefor you should rather be proud of what you have written, and not be afraid of others having a look at it.
And this is one of the most important. If you come to a point where you dont see any solution for your problem: Never give up hope. Take it as a challenge. Try to see things from another angle or explain to other people. Maybe you are just stuck in the wrong perspective. Successfully solving this ridiculous puzzle will make you an even stronger Developer.
“I have not failed. I’ve just found 10,000 ways that won’t work.” – Thomas A. Edison
Your own codes stability
Everyone knows this situation. You come to present your project to your boss or the customer, and you start worrying: “Will it work this time!? Hopefully i havent overlooked anything in the process of development!”. This is a bad sign, and you shouldn’t have to worry. You should rather have tested your project deliberately earlier. Of course, You can never make 100% sure that it works perfectly. But you can greatly improve the trust in your code by writing automated tests. It makes you feel more comfortable adapting changes and showcasing your software.
New & Complex Technology
Developers are lazy and often sit on their “good ol” technology way too hard. IT is improving incredibly fast, new and better technology is born every day. Be open minded, read blogs and stay up to date. If a technology/framework seems to exactly fit your needs, give it a try. Also show it to your colleagues an spread the word. This is a great story about developers being afraid to try something new.
Fighting Time Pressure
Do not ever let time pressure ruin the Quality of your Project. It is your Job to keep your Code clean and stable. Quality requires deliberate decision making and takes time. And sometimes you need to fight for it. Your customer expects a 100%, maybe even 120%, complete Product that is maintainable and state-of-the-art. If you let the quality down and deliver a poor Result, you will end up in even more changerequests, maintenance effort and distrust. The time you saved earlier will be eaten up by the technical debt that you allowed. Also if you allow a single leak, the inhibition of allowing many more significantly drops. Be honest with your boss and show some backbone when it comes to Quality.
“Programming is like sex: one mistake and you’re providing support for a lifetime.” – Michael Sinz
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.