2016-02-27
When you think about programming, you will have writing code in mind. Although pressing you ideas into executable code is one of the finest discipline for a software engineer, but it doesn't tell the whole story.
There are some techniques and abilities, a good software developer should have from my point of view.
A college of mine called it "brain debug". An ability to debug code without running it. From my perspective a good thing. This shows, that you know what you are doing. You have an idea, how your code behaves, before you execute it for the first time. Often good programmers write a brunch of code, before they compile it.
A lot of people can write code, that simply compile. Good programmers write code a human can understand. Imagine you have to fix a bug in a part of an application you have written half a year or so. Would it be nice you can dive into your own code as quick as possible? Imagine how nice it would be, when the person who have to dive isn't you, has the same chance?
Having a big rock, put it into smaller peaces you can lift and turn round, is another ability a good programmer should have. When you get specifications for a program to build, with hundreds of pages of requirements, you should be able to break it down into parts, a human can understand.
The next part may defer from type to type. After rock bricking, many good programmers like to start with the data structure first. Others like to sketch the UI interfaces first. A short cite for this came from Linus Torvalds (2006)
I will, in fact, claim that the difference between a bad programmers and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
When you are working with together with other developers, software is getting big very quickly. You probably have to work with an existing repository. Therefore reading code is an important ability. New code had to fit in the existing architecture. Writing self-documenting code is a good thing for reducing code size. This leads often more and shorter Functions. This increases the reuse of existing code.
There is no short cut. Programming needs time. The right questions will come, while programming. Talk to colleagues about your work or even better (read) code together.